Защо монолитът все още има място в devops средите въпреки остарялата технология. Кога и дали е необходимо да усложняваме архитектурата с допълнителна фрагментация. Плюсове и минуси при използване на оркестрация с microservices и алтернативния монолит.
6. Монолитна архитектура
● Архитектура, при която всички компоненти се намират на
една физическа среда (сървър)
● Апликацията е самостоятелна и независима
● Апликацията отговаря не само за дадена задача, а за цялата
функционалност на приложението
● Липсва модулност
● LAMP & LEMP stack
8. Архитектура с microservices
● Апликацията е разделена на отделни компоненти
● Компонентите са независими
● Компонентите изпълняват една задача
● Модулна структура
● Комуникират посредством мрежа, в общия случай
17. Исторически преход
● Physical server -> VM -> container-based solutions/microservices -> serverless and
function as service model.
Физ. сървър VMs Containers Функции
18. Three billy goats Gruff
● Michael Hausenblas, RedHat
monolith container function
21. Някои твърдения
● Microservice работи изолирано и индивидуално
● Microservice върши една единствена задача
● Microservice комуникира с други microservices
● Комуникацията е проблем
● Сложни думи свързани с microservices - discovery,
coordination, security, replication, data consistency, failover,
deployment.
● Фактор мрежа
● Дистрибутирани системи:
○ мястото, където се случва информацията да се загуби, разбърка, та дори
и фалшифицира.
○ мястото, където трудно някой може да каже къде точно е проблема.
22. Някои твърдения
● Монолита е прост
● В монолитна среда по-лесно се установява проблема
● Комуникацията по мрежата е нулева
● Добра производителност в монолита
● Монолита ни предлага сигурност
● Монолита е лесен за разбиране
● Монолита е old fashioned, vintage
“Too old to be considered modern, but not old enough to be considered antique”
24. Монолит +++
● Опростена архитектура
● Евтина комуникация м/у компонентите
● Лесен тест на цялата функционалност
● Лесна за deploy
● Лесно скалира хоризонтално
25. Монолит ---
● Приложението е трудно за разбиране
● Приложението е голямо, бави стартирането
● Подновяване на цялото приложение при малка промяна
● Споделени ресурси
● Малък бъг може да съсипе цялото приложение.
(мултиплициране)
● Използва един език за програмиране
26. Microservices +++
● Изолация на компонентите
● Независим deploy на отделните компоненти
● Всеки екип си работи на собствен microservice
● Свобода в избора на технологии
● Continuous deployment
● Всеки компонент може да скалира самостоятелно
27. Microservices ---
● Добавя допълнителна сложност на проекта
● Трудно тестване на цялото приложение
● Допълнителна конфигурация и авторизация за всеки
microservice
● Сложен deploy
● Фактор мрежа
29. service discovery
● Работи по мрежата
● Допълнително усложняване на архитектурата
● Single point of failure - service provider
● Проблеми с дерегистрирането
● Допълнителна конфигурация и оторизация
● Монолит load balancer
31. Distributed storage
● Работи по мрежата
● Сигурността е в опасност
● Загуба/подмяна на данни
● Нужда от дебела жица, голям трафик
● Производителността спада
● Добри технически познания за имплементиране и
поддръжка
35. Практически съвети
● Не използвайте microservices когато сте наясно, че мащаба на проекта не е
голям. Монолита върши работа.
● Започнете проекта си върху монолитна инфраструктура като обърнете
специално внимание на модулността на софтуера и как отделните модули ще
комуникират помежду си и какъв код ще споделят.
● Хибридна архитектура с монолит и microservices. Модулна апликация с
възможност кода да се преизползва и лесно да бъде скалиран към microservice
или друг monolith. Добавяне на load balancer
● Трудно връщане назад към monolith
● Монолитната архитектура може да се състои от няколко сървъра
● Тясното специализиране не е нещо хубаво
“successful microservice projects almost always start out as a monolith that got too big and
was broken up.”
Martin Fowler
39. Реален пример
● Presentation layer – HTML‑based web UI / HTTP requests
● Business logic layer – Основната функционалност. Свързва
Presentation layer с Data-access layer.
● Data‑access layer
40.
41. Коя архитектура е подходяща за нас ?
● Имате ли необходимите знания за реализиране на microservices - network
latency & reliability, storage over the network, etc. Монолита е по-безопасен при
липса на тези умения.
● Имате ли подготвен екип и достатъчно хора, които да се грижат.
● При стартъпи монолита е по-подходящ, защото:
○ Имате ограничен брой технически служители
○ Искате бързо да деплойнете и стартирате апликацията си. Пазара не чака.
○ Няма време за мислене на комплексни архитектури
○ Липса на голяма натовареност, поне в началото
