Моноліт як послуга (MaaS): Корпоративний антипатерн, який не хоче помирати

pic

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

Зустрічайте: Моноліт як послуга (MaaS) — корпоративний антипатерн, настільки хитрий, що заслуговує на свій власний шпигунський фільм. Він виглядає як мікросервіси, пахне як мікросервіси, але якщо зняти зовнішній шар, це просто старий моноліт, замаскований під новий API смокінг.

Що таке Моноліт як послуга?

Моноліт як послуга (MaaS) — це коли ваша організація стверджує, що впровадила мікросервіси, але насправді просто працює з тим самим важким, нечистим кодом, накинувши кілька API зверху. Це як подати застарілий фруктовий торт, але переробити його в «деконструйований десерт».

У вас є контейнери Docker? Kubernetes? Вітаємо, тепер ви просто запускаєте свій роздутий моноліт у хмарі! Технічно, це «послуга». Функціонально — це як намагатися проїхати вантажівку через годину пік, і при цьому називати її «спортивним автомобілем».

Ознаки, що ви маєте справу з MaaS

Ось як зрозуміти, що ви потрапили в трагікомедію Моноліт як послуга:

1. Централізовано все

«Ми дистрибутивні!» — кажуть вони. Але чи це справді так? Реальність: є один величезний додаток, який робить все — користувачі, замовлення, платежі, звіти, навіть ваші ранкові запити на каву — і він тримається на скотчі та надії.

А API? Це просто трохи красивіші способи надіслати ваш монолітний спагетті-код в інший поштовий індекс.

2. Одна база даних, що править усіма

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

А зміни в схемі? Забудьте про відклеювання лейкопластиру — це як виривати цілу пасмо волосся, намагаючись не заплакати на нараді.

3. Перевантажені API

Ваш «Сервіс керування користувачами» має такі кінцеві точки, як /getUserWithEverythingButTheKitchenSink і /thisDefinitelyIsntMonolithicISwear.

І звичайно, ці API повертають роздутих JSON-відповідей, які розбираються довше, ніж юридичний контракт. Потрібно знайти один елемент даних? Краще візьміть обід — це займе деякий час.

4. Спільні проблеми з розгортанням

Мікросервіси повинні дозволяти розгортати незалежно, правда? Не в світі MaaS! Тут кожен реліз — це синхронізований танець страху і відчаю.

Ви хочете розгорнути свій маленький «Сервіс каталогу», але вибачте, «Сервіс платежів» щось зламав, і тепер вся система не працює. Знову.

5. Єдине джерело збоїв

Мікросервіси повинні бути стійкими! Але в дистопії MaaS, якщо моноліт дасть збій, все зруйнується швидше, ніж картковий будинок під час урагану.

І, давайте будемо чесними: він дає збої часто.

Чому виникає MaaS?

MaaS не з’являється за одну ніч — це повільне сповзання в хаос, спричинене сумішшю поганих звичок, хороших намірів і корпоративних витівок.

1. Страх змін

«Ми завжди так робили!» — кричать вони, коли наклеюють API на свою 15-річну систему і вважають, що це все. Справжні зміни вимагають зусиль, планування і — осмілюсь сказати — мужності. Але дедлайни та зони комфорту часто перемагають.

2. Надмірне захоплення модними словами

Десь у залі засідань віце-президент почув слово «мікросервіси» і подумав, що це звучить круто. І ось уже є компанійне розпорядження «перейти на мікросервіси», не маючи жодного розуміння, що це насправді означає.

Тепер у вас є моноліт на Kubernetes, і хтось називає це інновацією.

3. Блискучі інструменти, нульові принципи

Docker? Є. Kubernetes? Є. CI/CD pipeline? Звичайно. Але рефакторинг моноліту? О, на це немає часу.
Ви залишаєтесь з роздутою системою в хмарі, яка працює на модних інструментах, наче потрощений автомобіль з гоночними смугами.

4. Організаційні залежності

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

Іронія MaaS

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

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

Як вибратися з пастки MaaS

Добра новина — ви можете вибратися з MaaS! Але це не просто.

1. Почніть з реальної автономії

Дайте командам право володіти своїми сервісами — кодом, базами даних, розгортаннями, всім. Якщо одна команда хоче використовувати Postgres, а інша — MongoDB, нехай так буде! (Лише не забувайте встановлювати деякі обмеження. Хаос не весело виглядає теж.)

2. Розділіть (обережно)

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

3. Інвестуйте в спостережуваність

Ви не можете виправити те, чого не бачите. Використовуйте інструменти, як-от розподілене трасування, щоб відобразити безлад у системі і зрозуміти, що ламається (і де).

4. Навчайте керівництво

Допоможіть вашим керівникам зрозуміти, що мікросервіси — це не про наклейки Kubernetes чи «міграцію в хмару». Мова йде про проектування систем, які дійсно працюють.

5. Розгляньте альтернативи

Іноді найкраща відповідь — це не мікросервіси, а модульний моноліт. Добре спроектований моноліт часто може перевершити погано реалізовану архітектуру «мікросервісів».

Висновок

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

Якщо ви помітили MaaS у дикій природі, не впадайте у відчай — смійтеся, вчіться і боріться за кращі системи. І пам'ятайте, наступного разу, коли хтось скаже: «Ми переходимо на мікросервіси», нахиліться і запитайте:

«Ви впевнені?» і покажіть йому цю статтю.

Є власні жахливі історії про MaaS? Поділіться ними в коментарях.

Перекладено з: Monolith as a Service (MaaS): The Corporate Anti-Pattern That Won’t Die

Leave a Reply

Your email address will not be published. Required fields are marked *