Як створювати масштабовані SaaS-платформи: архітектура, що підтримує бізнес-модель

Масштабована SaaS-платформа робить більше, ніж просто обробляє додаткові запити. Вона здатна під’єднувати більше клієнтів, підтримувати більше користувачів і даних, запроваджувати нові плани та виходити на нові ринки, надавати нову цінність продукту, відновлюватися після відмов і виконувати зобов’язання перед клієнтами без такого самого стрімкого зростання експлуатаційних зусиль і витрат, як доходу. Це властивість архітектури й організації роботи, а не параметр автоматичного масштабування.

SaaS зосереджує відповідальність. Один продукт, що безперервно змінюється, обслуговує багато організацій із різними працівниками, правами, налаштуваннями, моделями використання, договорами, очікуваннями від підтримки та зобов’язаннями щодо даних. Помилка в контексті клієнта, правах на можливості, перенесенні даних або адміністративних засобах може одночасно зачепити багатьох замовників. Архітектура має зберігати ізоляцію й водночас забезпечувати достатню стандартизацію, щоб одна продуктова команда могла економно керувати системою.

Почніть із бізнес-сценаріїв і моделі роботи: залучення та підготовки клієнтської організації, облікових записів і членства, налаштувань, основної роботи, співпраці, використання, планів, нарахувань і оплати, підтримки, вивантаження даних, строків зберігання, призупинення, поновлення та видалення. Визначте цілі обслуговування й відновлення, очікуваний розподіл клієнтів, піки попиту, географічні потреби, регульовані межі, ручні операції та відповідальність. Масштабування означає, що ці сценарії залишаються правильними, контрольованими й доступними за ціною зі зміною розподілу навантаження.

Почніть із моделі роботи SaaS-продукту

Будуйте застосунок навколо бізнес-можливостей із вузькими угодами: керування клієнтськими організаціями, облікових записів, прав на можливості, розрахунків, основних предметних областей, сповіщень, пошуку, звітності та інтеграцій. Модульний моноліт часто є надійною відправною точкою, адже спрощує локальні транзакції та розгортання й водночас дає змогу закріпити межі правилами імпорту, відкритими API, перевірками та відповідальністю. Відокремлюйте служби лише тоді, коли самостійна відповідальність команди, ізоляція відмов, масштабування або темп випусків виправдовують витрати розподіленої системи.

Не перевантажуйте синхронні сценарії. Для віддалених викликів потрібні загальний граничний строк, обмежена одночасність, скасування, коротші строки очікування у службах вище за ланцюжком, безпечні правила повтору та зрозумілий режим обмеженої роботи. Переносьте роботу до черги, якщо продукт допускає затримку, піки потребують вирівнювання або ресурсомістке опрацювання не повинно затримувати запит клієнта. Визначте доставлення, впорядкування, усунення дублікатів, повторне відтворення, поводження з несправними повідомленнями, граничний вік, звіряння й засоби для працівників до того, як назвати цей процес надійним.

Відокремлюйте зовнішні служби за угодами, що відображають потреби продукту, а не будову SDK певного постачальника. Фіксуйте достовірний стан, відповідність ідентифікаторів, облікові дані, обмеження, перевірку зворотних сповіщень, безпечне повторне виконання, помилки, контроль роботи, підтримку та спосіб заміни. Така межа робить зміну постачальника явною й не дає правилам зовнішньої служби поширитися на код предметної області.

Зробіть ізоляцію клієнтів властивістю всієї системи

Ізоляція клієнтів починається з підтвердження особи й триває у перевірці прав, пошуку об’єктів, запитах до бази даних, ключах проміжного зберігання, повідомленнях, завданнях, файлах, пошукових індексах, журналах, аналітиці, вивантаженнях, резервних копіях, доступі підтримки та видаленні. Ніколи не довіряйте ідентифікатору клієнтської організації, отриманому від клієнтської програми, доки не доведено зв’язок користувача із цією організацією. Перевіряйте прямі звернення до об’єктів, масові операції, фонові шляхи, адміністративні функції та зведення даних різних клієнтів.

Обирайте модель ізоляції даних відповідно до ризику й умов експлуатації. Спільні таблиці з ключем клієнтської організації можуть бути ефективними, якщо правила запитів обов’язкові й перевірені. Окремі схеми або бази даних можуть краще обмежити наслідки відмови, місце зберігання, відновлення, ключі або вплив надмірно активного клієнта, але збільшують вартість підготовки, перенесень, з’єднань, контролю та керування всіма примірниками. Поєднання кількох рівнів може відповідати різним зобов’язанням перед клієнтами, однак кожний рівень множить кількість шляхів, готовність випуску й відновлення яких потрібно доводити.

Ставтеся до підготовки клієнтської організації як до надійного процесу: створіть межі облікових записів і даних, налаштування, права на можливості, ключі, регіони, інтеграції, обмеження, контроль роботи, зв’язок із розрахунками й перших адміністраторів; передбачте часткову відмову та безпечний повтор. З такою самою ретельністю спроєктуйте призупинення, передавання, об’єднання, вивантаження, поновлення та видалення. Особливу поведінку для клієнта слід утілювати в керованих налаштуваннях і точках розширення, а не в постійних відгалуженнях коду.

Масштабуйте можливості відповідно до виміряного попиту

Описуйте попит як розподіл, а не середнє значення: клієнти відрізняються кількістю користувачів, обсягом даних, формою запитів, інтеграціями, запланованими завданнями, вивантаженнями та часом пікового навантаження. Визначте правила справедливого розподілу й захисту. Застосовуйте квоти, межі одночасності, обмеження частоти, пріоритети завдань, межі вивантажень і пропускну здатність відповідно до плану та пов’язаного облікового запису. Один великий клієнт або несправна інтеграція не повинні поглинати спільні запаси ресурсів і черги, потрібні всім іншим.

За можливості не зберігайте стан у примірниках, що обслуговують запити, а довговічний стан розміщуйте у визначених для цього системах. Масштабуйте API, виконавців завдань, пошук, звітність і процеси оброблення зображень, звуку й відео окремо, якщо вони мають різні потреби в ресурсах. Автоматичне масштабування потребує ознак, пов’язаних зі справжнім обмеженням: віком черги, кількістю одночасних операцій, затримкою, пам’яттю, пропускною здатністю сховища або обсягом незавершених бізнес-операцій. Воно також має враховувати затримку запуску, квоти, прогрівання, найменшу потрібну потужність і умови відмови.

Застосовуйте проміжне зберігання лише з явним першоджерелом, межею клієнта й прав, обіцянкою щодо свіжості, способом скасування збережених даних, обмеженням розміру, правилами для чутливих даних і захистом від одночасного масового перерахунку. Перевіряйте систему на даних і навантаженні, подібних до робочих, за звичайного рівня, поступового зростання, різкого піку, тривалої роботи та відмов. Опублікуйте безпечні межі експлуатації із зазначенням першого обмеження, видимого клієнтові погіршення, часу відновлення й умови для наступного збільшення потужності.

Проєктуйте відповідальність за дані, узгодженість і життєвий цикл разом

Призначте достовірне першоджерело для кожної важливої сутності та зміни стану. Проєктуйте індекси й запити за справжніми способами доступу, зокрема клієнтською організацією, станом, часом, зв’язками та поділом результатів на сторінки. Спостерігайте за співвідношенням повернутих і переглянутих даних, роботою блокувань і запасів з’єднань, тривалістю транзакцій, затримкою реплікації, тиском робочого набору й перекосом великих клієнтів. Копії для читання, проміжні сховища, пошукові індекси, аналітичні сховища й похідні подання — це вторинні представлення; визначте їхню свіжість, поведінку під час відмови, відновлення та значення для клієнта.

Локальні транзакції захищають незмінні умови в межах однієї області даних. Робота, що перетинає межі служб або зовнішніх постачальників, потребує явних проміжних станів, надійно збережених подій, безпечного повторного виконання, компенсаційних дій і звіряння. Зберігайте невідомий результат, а не оголошуйте успіх чи невдачу, яких неможливо довести. Засоби для працівників мають показувати докази й надавати обмежені дії з виправлення без прямого редагування бази даних.

Плануйте зростання й зміну даних: строки зберігання, архівування, поділ, резервне копіювання, відновлення до визначеного моменту, вивантаження даних клієнта, заборону видалення через юридичні вимоги, видалення, місце зберігання, ключі шифрування, розвиток схем, дозаповнення наявних записів і відновлення. Змінюйте схеми через сумісні з одночасною роботою різних версій етапи розширення та звуження. Виконуйте великі перетворення поза критичним шляхом запитів і розгортання, забезпечивши відстеження поступу, обмеження швидкості, перезапуск, перевірку й виправлення.

Будуйте надійність навколо шляхів клієнта

Визначайте надійність через шляхи клієнта: вхід, виконання основної роботи, запрошення учасника, створення звіту, зміну плану або відновлення невдалої операції. Вимірюйте успішні результати, затримку p50, p95 і p99, класи помилок, свіжість даних, обсяг незавершеної роботи, вичерпання ресурсів і звіряння. За потреби розділяйте показники за рівнем обслуговування клієнта, регіоном, версією й залежною службою, не розкриваючи чутливих даних клієнта.

Опишіть відмови через невдалий випуск, перевантаження, перевищення строку очікування залежності, накопичення черги, завершення строку дії облікових даних, пошкодження даних, втрату регіону чи зони, аварії зовнішнього постачальника та помилку працівника. Для кожного критичного шляху визначте виявлення, стримування наслідків, стан клієнта, вплив на дані, спосіб відновлення, повноваження й доказ повернення до роботи. Застосовуйте резервування лише тоді, коли повна модель перемикання та відновлення виконує конкретну вимогу.

Контроль роботи має пов’язувати випуски, запити, простеження виконання, журнали, показники, повідомлення, завдання, операції бази даних, зовнішні служби й зміни стану бізнес-процесів. Сповіщайте про ознаки, на які відповідальна особа може відреагувати. Відпрацьовуйте повернення до попередньої версії або безпечне виправлення поточної, спорожнення черг, втрату зовнішньої служби, заміну облікових даних, відновлення резервної копії, відновлення окремого клієнта й передбачені вимогами регіональні процедури. Резервна копія стає доказом лише після успішного відновлення в межах обіцяного часу й допустимої втрати даних.

Перетворіть безпеку й дотримання вимог на можливості платформи

Розділяйте облікові записи клієнтів, підтримки, адміністраторів, служб, засобів розгортання й аварійного доступу. Перевіряйте права на сервері для кожної операції та об’єкта; звужуйте їх до найменшої потрібної дії в межах відповідної клієнтської організації; захищайте підвищення прав, переглядайте доступ і робіть аварійне використання помітним та обмеженим у часі. Вхід від імені клієнта або доступ підтримки потребує явної мети, згоди чи правила, журналу перевірки, строку й обмежених можливостей.

Класифікуйте дані й простежуйте їх через основні сховища, похідні подання, резервні копії, журнали, аналітику, вивантаження, засоби підтримки та зовнішні служби. Зводьте до мінімуму збирання й зберігання, шифруйте передавання та сховища, визначайте відповідальність за ключі й їхню заміну, керуйте таємницями, обмежуйте відкритий доступ і не допускайте чутливих значень до діагностичних даних. Видалення клієнта має охоплювати похідні й збережені копії відповідно до справжнього зобов’язання, а не лише головну таблицю.

Перетворюйте повторювані зобов’язання на засоби платформи: правила, описані в коді, безпечні початкові налаштування, журнали перевірки з урахуванням клієнта, докази доступу, настроювані строки й місце зберігання, перелік постачальників, процеси усунення вразливостей і оновлення залежностей, реагування на аварії, докази відновлення та пакети відомостей для клієнтів. Ручна робота може лишатися там, де потрібне судження, але повторне збирання доказів не повинно вимагати аварійного проєкту перед кожним продажем великому замовникові або перевіркою.

Узгоджуйте розрахунки, права на можливості та стан продукту

Розрахунки з клієнтами — це окрема предметна область, а не екран оформлення покупки. Опишіть каталог продуктів і версії цін, плани, підписки, пробні періоди, знижки, використання, обмеження, рахунки, податкові дані, стан оплати, повернення коштів, скасування, поновлення й повідомлення клієнтів. Відокремлюйте комерційні записи від представлення зовнішньої платіжної служби, щоб зворотне сповіщення не могло непомітно змінити те, що придбав клієнт.

Права на можливості відповідають на запитання, чим ця клієнтська організація може користуватися зараз: функціями, кількісними межами, ролями, рівнями обслуговування, строками зберігання, регіонами чи підтримкою. Обчислюйте їх через одну керовану можливість із проміжно збереженими похідними даними, де це потрібно, а не через розкидані в коді умови за назвою плану. Визначте поведінку після завершення пробного періоду, переходу на вищий чи нижчий план, несплати, пільгового строку, скасування, спору, поновлення або відмови зовнішньої служби. Зміни доступу мають бути пояснюваними й оборотними.

Облік використання потребує визначення події, клієнтської організації, джерела, часу, кількості, одиниці, ідентифікатора для усунення дублікатів, правил виправлення, цінового періоду, строку зберігання та звіряння. Перевіряйте й зберігайте зворотні сповіщення зовнішньої служби, обробляйте їх безпечно за повторного надходження, допускайте дублікати й порушений порядок подій та звіряйте внутрішній стан підписки й фінансів. Ураховуйте змінні витрати на постачальників та інфраструктуру разом із доходом, щоб зовні успішне зростання не приховало збиткової економіки одного клієнта.

Створіть платформу випуску, що зменшує витрати на кожного нового клієнта

Створюйте один простежуваний пакет, випробовуйте й перевіряйте його засобами безпеки, послідовно просувайте через керовані середовища та зберігайте відомості про походження. Описуйте інфраструктуру, правила, облікові записи, мережі, служби даних, черги, діагностичні дані, бюджети й налаштування у вигляді коду, що проходить перегляд. Зміни бази даних і подій потребують сумісної послідовності випусків, контрольованого дозаповнення записів і шляхів виправлення. Для керованих перемикачів можливостей потрібні відповідальний, безпечне початкове значення, діагностичні дані, строк видалення й рішення про вилучення.

Інженерія платформи має зменшувати повторюване розумове навантаження й експлуатаційну роботу за допомогою підтримуваних шаблонів, перевірених стандартних шляхів, самостійно створюваних середовищ, зразків керування обліковими записами, автоматизованих процесів випуску, діагностичних даних, таємниць, засобів відновлення й задокументованих меж служб. Вимірюйте використання та результати: внутрішня платформа, яку команди оминають або не вміють досліджувати, додає ще одну залежність, а не нову спроможність.

Відстежуйте витрати на кожного додаткового клієнта й обсяг ручної рутини: час підготовки та під’єднання клієнтської організації, звернення до підтримки, ручне звіряння, наслідки аварій, час від готовності зміни до випуску, невдалі випуски, швидкість відновлення, витрати на хмарні та зовнішні служби на корисну одиницю й зусилля для кожного рівня клієнтів. Автоматизуйте сталі, повторювані й безпечні дії. Залишайте людині право ухвалювати неоднозначні рішення з великими наслідками. Зростання здоровіше, коли кожний новий клієнт потребує менше виняткової роботи.

Масштабована SaaS-платформа обслуговує більше клієнтів і швидше надає нову цінність, зберігаючи ізоляцію, довіру, здатність до відновлення та здорову економіку одного клієнта — без такого самого зростання кількості виняткових ручних операцій.

— GARNO.TECH

Розвивайте пропускну здатність SaaS на підставі доказів

GARNO.TECH проєктує, створює й оновлює SaaS-платформи навколо вимірюваних результатів продукту та експлуатації. Ми можемо визначити межі клієнтських організацій і даних, облікові записи та перевірку прав, архітектуру предметних областей, підписки й права на можливості, інтеграції із зовнішніми службами, хмарну основу, випуск, контроль роботи, безпеку, пропускну здатність, відновлення та модель відповідальності, потрібну після запуску.

Робота починається з доказів: шляхів клієнта, розподілу клієнтських організацій, договорів, аварій, архітектури, зростання даних, цілей обслуговування, показників випуску, витрат на хмарні й зовнішні служби, навантаження на підтримку, ручних операцій і спроможностей команди. Ми знаходимо обмеження з найбільшими наслідками для бізнесу, перевіряємо найризикованіше припущення й виконуємо чітко окреслене поліпшення з доказами приймання та передаванням знань.

Результат не вичерпується розгорнутим програмним забезпеченням. Після роботи повинні залишитися обов’язкові правила, інфраструктура й налаштування з історією версій, придатні до експлуатації автоматизовані процеси, корисні діагностичні дані, перевірене відновлення, актуальна документація, відповідальність за витрати та фахівці, здатні розвивати платформу. Масштабована архітектура SaaS успішна тоді, коли зростання збільшує цінність для клієнтів швидше, ніж складність, ризик та експлуатаційні витрати.

Технічне масштабування також потребує чіткої відповідальності за рішення. Скористайтеся нашим посібником, щоб визначити, коли молодому SaaS-бізнесу потрібен CTO, створити готовий до ухвалення рішень план технологічного розвитку або ознайомитися з нашим підходом до залучення технічного керівника на неповний час. Керівництво має пов’язати обіцянки продукту, архітектуру, безпеку, надійність, спроможність команди й економіку одного клієнта до того, як точкові поліпшення закріпляться як системні обмеження.