Побудова архітектури додатку — це комплекс заходів, який спрямовний на те, щоб чітко визначити, як буде побудована система. Согодні я розповім лише про верхній рівень визначення архітектури, тобто про те, що може бути визначеним при наявності обмеженої кількості інформаціїї.
Важливо розуміти те, що немає ідеального рішеня при визначенні принципа проектування архітектури, ми не можемо сказати, що оцей архітектурний патерн підходить под будь-яку задачу та використовувати слід лише його.
Все залежить від конкретного проєкту та його завдань. Але ви можете побудувати усе, що завгодно, на будь-якій архітектурі, але чи буде це виправданим? Навряд чи.
Отже, що нам потрібно для визначення ПОВНОЇ архітектури проєкту:
Технічне завдання
Архітектор, або людина з багатим досвідом розробки
Розуміння дедлайнів
Розуміння життєвого ціклу проєкту
Розуміння навантаження
Як бачімо, це дуже багато інформації, яку треба проаналізувати для того, щоб визначитись з ПОВНОЮ архітектурою проєкту. Але для ВЕРХНЬОРІВНЕВОЇ архітектури іноді нам вистачіть лише ідеї проєкту.
Загалом відокремлюють три типи верхньорівневої архітектури веб додатків, це:
Моноліт
Мікросервіси
Серверлес
Моноліт
Моноліт — це архітектурне рішення, у якому усі компоненти та модулі тісно повіязані між собою, та залежать один від одного, докладніше проілюстровано на зображенні.
Загалом вважаєтся, що це застаріле архітектурне рішення, але я з цим не погоджуюсь, бо у такого рішення є свої переваги, і воно дуже гарно підходить при побудові деяких проєктів.
Переваги:
Простота розгортання. Моноліти дуже швидко і відносно просто розгортати, завдяки тому що у моноліта, зазвичай, єдина точка входу
Розробка. Розробка моноліту зазвичай дуже швидка, бо усі компоненти та модулі знаходяться в одній кодовій базі та завжди під рукою
Відладка. Відладка моноліту дуже спрощена за рахунок того, що усе поряд, і є можливість відстежити усю ланку виконнаня коду
Недоліки:
Маштабування. Моноліти маштабуються лише повністю, тобто якщо навантаження зростає лише на один модуль, ми не можемо маштабувати лише цей модуль, ми маємо маштабувати весь моноліт
Надійність. Якщо моноліт виходить з ладу, то виходить весь цілком
Зміна та оновлення технологій. У моноліті це майже неможлово
Недостатня гнучкість. Моноліти негнучкі, тобто зміна одного модуля у моноліті майже завжди впливатиме на інший модуль
Мікросервіси
Мікросервіси — це архітектурне рішення, яке базуєтся на розподілі модулів на окремі системи, які спілкуються між собою за допомогою повідомлень.
Уся система — це набір маленьких систем, які повіязані між собою, докладніше проілюстровано на зображенні.
Наразі це дуже модна і популярна архітектура, але у неї є свої недоліки та, на мій погляд, вона зовсім не підходить для маленьких та середніх проєктів.
Переваги:
Гнучкість. Мікросервіси дуже гнучкі за рахунок того, що кожен сервіс є самостійною системою, та тому зміни у ній можуть вплинути лише на неї
Маштабування. На відміну від моноліту, ми можемо маштабувати лише певну частину системи, тому що вона самостійна
Гнучкість технологій. У мікросервісах кожна з підсистем може бути реалізована будь-якою мовою программування та за допомогою будь-яких технологій
Надійність. Зазвичй виход із ладу однієї з підсистем не ламає усю систему загалом
Недоліки:
Процес розробки. Мікросервіси дуже непросто розробляти, тому що треба робити декілька підсистем та налагодити взаємодію між ними
Комунікація команд. Дуже часто буває так, що одна команда розробляє одну підсистему, тож треба налагодити комунікації між командами, щоб налагодити взаємодію між підсистемами
Відладка. Мікросервіси дуже складно відлагуджувати, тому що треба знайти, який сервіс зламався, та чому
Розгортування. Початкове розгортання дуже непросте, та додавання нових сервісів потребують налагодження ключових частин проєкту
Рекомендуємо публікацію по темі
Серверлесс
Серверлесс — це архітектурне рішення, яке фокусується на розробці, а не на розгортанні та взаємодії між сервісами.
Сервверлес — це альтернатива мікросервісами, яка автоматизує усе разгортання завдяки хмарним технологіям. Докладніше проілюстровано на зображенні. З назви можна подумати, що тут відсутня серверна частина, але це не так, тут відсутня робота з сервером як з середовищем.
Переваги:
Гнучкість. Серверлес дуже гнучкий за рахунок відокремленості одного модулю від іншого
Абстракція від ОС. Хмара сама вирішить, яка ОС потрібна, та як її треба налаштувати
Легкий поріг входу. Зазвичай серверлес це дуже простий, відокремленний код, тож розібратися з проєктом нескладно
Надійність. При правильній побудові проєкту надійність такаж сама як і у мікросервісів
Недоліки:
Гнучкість. Так, це також мінус, бо у розробника обмежений вплив на маштабування, усе вирішує хмара
Відладка. Так само як у мікросервісах відладка ускладнена взаємодією між компонентами
Vendor Lock. Кожна хмара працює за власними правилами, тому переїзд з однієї хмари на іншу майже неможливий
Cascade Failur. При неправильній побудові проєкту компоненти можуть дуже сильно впливати на інщі компоненти, що призводить до падіння усього проєкту
Висновок
Зрозумівши усі переваги та недоліки тої чи іншої архітектури, ми сміливо можемо обрати верхньорівневу архітектуру, коли ми маємо обмежену інформацію про проєкт.
Ще раз наголошую, що будь-який проєкт можливо виконати за будь-якою архітектурою, але це може бути неефективним або у плані розробки, або у плані експлуатації проєкту.
