You have a MACH! Розбираємось в архітектурних принципах

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті.

TLDR; MACH is yefa for Microservices-based, API-first, Cloud-native, and Headless principles for designing software applications.

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

Всім відомий REST, який по суті не є протоколом чи стандартом, а просто певною групою правил, яка при повному їх виконанні гарантує очікуваний результат, до якого всі звикли. Достатньо сказати «в мене комунікація по принципам REST» і ти вже розумієш, як усе побудовано (токени, свагер, ендпоїнти ...) Цих акронімів в IT вагони — MERN, SOLID, MVP і ось додається ще один :)

Що таке MACH

Тож MACH — це група архітектурних принципів, які при застосуванні разом забезпечують побудову системи, яка відповідатиме сучасним вимогам до програмного продукту.

Що ж то за вимоги такі? Ну, можна накопіпастити стандартих *-ilty (maintainability, scalability, deployability, saleability), але все зводиться до звичайного «щоб було легше, а не складніше».

Розшифровуємо принципи

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

Microservices-based — ні, не треба все зразу писати на нано мікро-сервісах, просто треба проєктувати систему так, щоб бізнеслогіка була відділена одна від одної, наскільки це можливо (Aggregations form DDD). Писати код, намагаючись зробити гіпотетичне відокремлення цього функціоналу у незалежний сервіс легшим і з меншим впливом на загальний продукт.

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

Cloud-native — не забувати про акронім IaC та користуватись залізом від Andy Jassy \ Sundar Pichai \ Satya Nadella на вибір. І бажано не просто залізом, а інтегруватись з усією доступною кількістю сервісів та автоматизовувати усі доступні процеси. Погодесь, коли все автоматизовано, навіть деплой стає простіший за натискання однієї кнопки merge.

Headless — намагитсь не привязуватись до фреймвоків (фреймворки змінюються а for-цикли назавжди). Про побудову бекенду агностичного до фронтенду, це і так ясно. Але якшо експресовский req-res не протікає в контролери, то замінити його на фастіфай буде легше.

Може, в коментарях напишете, який принцип варто додати до стеку.

Тож що дає нам виконання всіх принципів MACH?

  • Гнучке, але без хаосу у контрактах, рішення. Коли продакт-овнер затверджує зміну у контракті, а бізнес-логіка розділена та концентрована, можна забути про хаотичні рипання і естімейти овер 9000 для додання одної фічі.
  • Коли їдеш на хмарі, то важко загрузнути у болоті старих технологій. Cloud-провайдер сам спонукає користуватись їх новими сервісами та не костяніти в технологіях, заодно хайрити розрабів буде легше.
  • Скейлити мікро-сервіси в хмарі, це далеко не те саме, що адмінити 10 ящиків за балансувальником.
  • Коли фреймворк — це плагін, то повідомлення про зупинку його підтримки не призведе до облисіння техліда.
  • Автономна бізнес-логіка з автоматичними деплоями зробить щасливим будь якого скрам-майстра, спринти крутятся функціонал релізиться.

Може MACH щось забирає?

Як будь-який звід правил, він обмежує та змушує.

  • Як мінімум, він змушує думати кожен раз, як комітиш чи не порушується якесь з правил. А змушення зайвий раз подумати — це вже хороший привід не користуватись ним.
  • Headless-принцип обмежує архітектуру, змушує будувати додаткові механізми забезпечення меж між функціоналом (абстракції, DTO etc). А будь-які зусилля, витрачені не на реалізацію бізнес логіки, марні в очах продакт-овнера (і не тільки).
  • Api-first — змінює процеси розробки, змушує нетехнічний персонал узгоджувати контракти API, забороняє девелоперу додати якусь потрібну йому властивість до респонзу.
  • Глибока інтеграція з клаудом вимагає часу та зусиль на опанування його сервісів, знання доцільні лише для конкретного провайдеру і непотрібні для іншого.
  • Суттєві інвестиції на старті у побудову автоматизованої інфраструктури CI\CD ще до початку побудови MVP йде врозріз з модерновою парадигмою коли після першого спринта вже треба віддавати продукт на апробацію для отримання зворотного зв’язку.

Якщо узагальнити, то ці обмеження та змушення забирають швидкість.

В умовах аутсорсу швидкість завжди важливіша за якість і простоту, але Езоп і Дядька Боб казали — шо go slow is faster, хз вірити їм чи ні.

👍НравитсяПонравилось6
В избранноеВ избранном2
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Не все так просто.

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

Изменения в контракте достаточно редко обусловлены изолированным изменением требований к единственному сервису. Соответственно все

эйстимейты овер 9000

просто неявно перетекают с уровня команды сервиса на уровень интеграционного тестирования.

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

И потом пояснять стейкхолдерам, почему счета за cloud resources в 3 раза больше чем on-prem затраты. Сорян, но достаточно сомнительный пункт

Cloud-провайдер сам спонукає користуватись їх новими сервісами та не костяніти в технологіях

И достаточно часто заодно выступать в роли бета-тестеров

але все зводиться до звичайного "щоб було легше, а не складніше"

Тогда выбросьте микросервисы и вернитесь к СОА.

API-first

Пожалуй это самое важное в статье.
Мода на микросервисы и клауд может пройти как и началась, недостатков в них достаточно.

Треба було б добре, напевне, надати посилання на першоджерело і звідки це все пішло machalliance.org

А в кінці було би добре згадати про KISS і YAGNI, які криють багато інших архітектурних «принципів» :)

Може, в коментарях напишете, який принцип варто додати до стеку.

Один из важных принципов — гугли имя перед тем как его клеймить. Хотя для всего это булшита это не так важно, по историческим меркам это всё пустое, завтра о нём никто даже и не вспомнит.

Я думав, що Mach — це ядро ОС (яке в тому числі увійшло в macos)

Подписаться на комментарии