Технічний борг для масштабування: як уникнути банкрутства

Перехрестя — це те саме неминуче явище, через яке має пройти кожна успішна компанія-розробник програмного забезпечення. Розроблено не поганий MVP, який пройшов тест на відповідність продукту ринку, а багатогранну систему, яка обслуговує тисячі або мільйони користувачів. Але є щось під поверхнею. Нові випуски з'являються повільно. Тижні витрачаються на розробку простих змін. Швидкість виправлення помилок вища, ніж швидкість виправлення старих проблем. Кодова база змушує інженерів витрачати більше часу на боротьбу, а не на створення нових функцій. Цей сценарій з жахливою частотою розгортається у сфері технологій. Бізнеси, які, здавалося, мали стати титанами, задихаються від власного початкового успіху і змушені або працювати в стані поблажливої стагнації, або відновлювати свій розвиток за допомогою дорогих реорганізаційних заходів. Винуватцями є не бідні розробники чи брак ресурсів. Причина лежить у базових архітектурних рішеннях, які були прийняті протягом тих доленосних перших місяців, коли швидкість виходу на ринок була важливішою за довгострокову підтримку. Одним з найважливіших аспектів знань будь-якого керівника, який очолює технологічну організацію, що зростає, є розуміння того, як технічні рішення витримують випробування часом. Будь-які рішення, прийняті сьогодні, або прискорять зростання в майбутньому, або стануть невидимими кайданами, що стримують усі інші ініціативи. Різниця між компаніями, що зростають, і тими, що зазнають невдачі, часто полягає в архітектурній мудрості, яка використовується вчасно і доречно.

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

Неефективний API може без проблем справлятися з поточним трафіком, але зазнає краху, коли навантаження подвоїться. Тісно пов'язана кодова база може спочатку дозволяти швидку розробку функцій, але паралельна розробка може стати ще більш складною із збільшенням розміру команди. Компанії часто схильні неправильно інтерпретувати ці симптоми як тимчасові труднощі, що не мають системного характеру і потребують архітектурних коректив. Керівництво може вважати, що збільшення кількості інженерів прискорить процес розробки, але потім зрозуміє, що координаційні витрати та конфлікти коду насправді уповільнюють розробку. Проблеми, що виникають з продуктивністю, вирішуються шляхом збільшення потужності серверів, а не шляхом підвищення базової ефективності. Проблеми безпеки вирішуються за допомогою точкових рішень, а не системного огляду сайту. Економічні наслідки та масштаби набагато ширші, ніж продуктивність в інженерії. Це впливає на досвід клієнтів, оскільки системи стають менш стабільними та менш чутливими. Коли платформа не здатна задовольнити потреби потенційних корпоративних клієнтів, втрачаються можливості для продажу. Конкурентні переваги зменшуються, оскільки функції розвиваються повільно. Це ускладнює процес найму, оскільки інженери не хочуть працювати в організаціях, які мають технічні дисфункції.

Побудова модульної архітектури

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

Секрет полягає у визначенні чітких контрактів між різними розділами системи та відсутності тісного зв'язку, який спричиняє поширення змін у будь-якому напрямку по всій базі коду.

Роздуми щодо архітектури даних

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

• Вибір баз даних документів замість реляційних баз даних на основі їхніх потреб
• Використання стратегії версійності даних
• Створення API, які приховують базові реалізації сховищ

Збалансування поточних і майбутніх потреб

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

Спостережуваність та безпека

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

Прийняття технічних рішень

Компанії, які хочуть уникнути архітектурних пасток, повинні впровадити моделі прийняття технічних рішень, які рівномірно зважують короткостроковий темп і довгострокову стійкість. Це включає:

• Розробка процедур архітектурного огляду основних технічних рішень
• Документування компромісів
• Часто оцінюйте технічний борг, що виник у порівнянні з пріоритетами бізнесу

Тестування та інтеграція

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

Перегляд коду та обмін знаннями

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

Часті технічні презентації та архітектурні наради дозволяють зберегти спільне розуміння в контексті розширення інженерних команд.

Регулярні огляди архітектури

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

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