Десятий клієнт має приносити розробнику більше можливостей для зростання. На практиці він іноді приносить десяту копію застосунку, ще один набір налаштувань і нову тривогу перед оновленням. Мультибазовість K2 Platform пропонує архітектуру, у якій спільний застосунок працює з різними незалежними базами даних.
У демонстрації K2 від 2 листопада показано керування підключеннями та роботу з різними середовищами. Для інтегратора це спосіб зменшити дублювання програмної основи. Для підприємства — можливість мати власні дані й налаштування в межах спільної технології.
Як влаштований підхід
Одна база може належати виробничій компанії, друга — торговельному підприємству, третя — використовуватися для тестування. Застосунок працює з відповідним підключенням, а інформація кожного середовища зберігається у своїй базі.
Важливо розділяти кілька задач. Вибір бази визначає середовище роботи. Права користувача визначають його доступ усередині цього середовища. А правила адміністрування, резервування й моніторингу визначають, як команда підтримує його працездатність. У проєкті всі ці рівні потрібно перевіряти разом.
Підхід корисний для SaaS-сервісів, інтеграторів із багатьма клієнтами й груп компаній. Тестова база також отримує чітку роль: у ній можна відпрацьовувати зміни до перенесення в робочий процес. Називати обидві бази «Основна» технічно можливо, але почуття гумору адміністратора колись закінчиться.
Де з’являється економія
Спільна технологічна основа дозволяє скоротити повторення частини операцій із розгортання й супроводу. Команда може централізовано працювати з застосунком і стандартизувати керування підключеннями. При цьому кожна база зберігає власні задачі адміністрування.
Для оцінки ефекту порахуйте витрати на додавання нового середовища, перевірку оновлення, пошук проблеми та відновлення після помилки. Виміряйте ці дії на пілоті. Так стане зрозуміло, яку частину роботи спільна платформа справді скорочує у вашій інфраструктурі.
Фактична кількість баз і одночасних користувачів залежить від ресурсів серверів, навантаження та вимог до доступності. Спільний застосунок потребує продуманої конфігурації, тестування й моніторингу. Його економіку слід рахувати разом із вимогами до ізоляції та відновлення.
Як залишити місце для особливостей клієнта
Різні компанії мають різні реквізити, форми й правила роботи. K2 Platform розвиває механізми конфігурування та характеристики сутностей, щоб частину індивідуальних потреб реалізовувати в налаштуваннях спільного продукту.
На пілоті варто перевірити конкретний сценарій. Додайте необхідний одному клієнту реквізит, перевірте його відображення та використання у звіті, а потім переконайтеся, що інше середовище поводиться відповідно до своїх правил. Така перевірка значно переконливіша за загальну обіцянку гнучкості.
Галузева логіка, інтеграції та складні правила можуть потребувати розробки. Для партнера важливо заздалегідь погодити, які зміни належать до продукту, які — до налаштувань замовника, а які стають окремими компонентами. Це допомагає контролювати подальшу вартість супроводу.
Оновлення баз потребує керованого процесу
Коли застосунок розвивається, змінюється й структура даних. У K2 використовуються механізми міграцій, зокрема Alembic, для роботи з такими змінами та їхніми версіями. У демонстрації показано й ситуацію з невідповідністю ревізій старішої бази.
Для адміністратора це практичне нагадування перевіряти сумісність перед оновленням. Потрібні резервна копія, випробування міграції на копії бази, звірка критичних операцій і план відновлення. За наявності багатьох клієнтів корисно мати перелік середовищ із поточною версією та результатом останньої перевірки.
Подивіться механізм у роботі
Почніть знайомство з безкоштовної хмари K2 ERP. Більше про інструменти розробки є в огляді K2 Platform. Для пілота підготуйте два типових середовища й одну індивідуальну зміну, яка важлива вашим клієнтам.
Команда K2 допоможе обговорити архітектуру, правила розгортання та перевірку такого сценарію. Звертайтеся у WhatsApp +380679016322 або на rs@corp2.net.
Немає коментарів:
Дописати коментар