Add microservices

Author: vladyslavPonomaryovInBev

lesson49.md

@@ -434,7 +434,7 @@ CI/CD - Continuous Integration / Continuous Deployment
 
 Смержили пул реквест, CD за вас автоматически всё задеплоит и перезапустит.
 
-Это описание только одной из конфигураций, на самом деле из может быть огромное кол-во в зависимости от нужд проекта.
+Это описание только одной из конфигураций, на самом деле их может быть огромное кол-во в зависимости от нужд проекта.
 
 ### Термины
 
@@ -846,8 +846,120 @@ jobs:
 
 Но в небольших компаниях вся эта настройка тоже на вас :)
 
+## Монолиты и микросервисы
 
+Настало время поговорить про архитектуру.
 
+![](https://say-hi.me/wp-content/uploads/2014/09/sagrada_familia_4_modifie1.jpg)
 
+И нет мы будем говорить не про здания и урбанистику.
 
+Под архитектурой в данном контексте я подразумеваю архитектуру построения технического решения.
+
+![](https://media.proglib.io/posts/2019/09/19/4fde07b37f99708975add2813082c098.webp)
+
+Под монолитом обычно подразумевается техническое решение, собранное на одном стеке технологий и разворачиваемое целиком,
+одним большим пакетом.
+
+Когда вы разрабатывали django приложение, вы разрабатывали монолит, сами о том не догадываясь.
+
+А как бывает еще?
+
+Как можно догадаться из заголовка еще бывают микросервисы. Что же это такое?
+
+Это когда у нас любые минимальные действия разбиты на маленькие сервисы, и они между собой не зависимы друг от друга.
+
+Возьмем в качестве примера обычный интернет магазин. Предположим мы уже купили базу данных у амазона, а редис сервис у
+гугла.
+
+Как разбить задачу на микросервисы? Например, у нас может быть отдельный сервис (приложение) которое отвечает за логин.
+Отдельное приложение, которое возвращает список товаров. Отдельное приложение, которое позволяет взаимодействовать с
+личным кабинетом. Отдельный сервис отвечающий за рассылку рекламы и новостей, и отдельный сервис который обрабатывает
+платежи.
+
+Зачем такое делать и какой в этом смысл? Допустим вы собрали монолит с таким же функционалом. И вдруг выясняется, что
+посмотреть на товары заходят сотни тысяч людей, а остальным функционалом почти никто не пользуется. Что бы выдержать
+нагрузку необходимо расширять весь монолит, что может быть очень дорого, и гораздо дешевле для одного отдельного
+сервиса. Это лишь один из примеров, давайте пройдёмся по всем плюсам и минусам таких архитектур.
+
+![](https://media.proglib.io/posts/2019/09/18/379a434eb170516211ee253dfc607075.png)
+
+### Плюсы микросервисов
+
+У такой архитектуры достаточно много плюсов
+
+#### Масштабируемость
+
+Как я уже описывал в примере раньше, при таком подходе мы легко можем увеличить ресурсы для одного сервиса и убрать для
+другого, но это еще не всё.
+
+Так как микросервисы могут вообще быть не связанны технологиями, у нас может быть один модуль написан на питоне, второй
+на го, а третий на джаве.
+
+А это значит, что можно распределять разработчиков в зависимости от необходимости конкретного сервиса (Нанять два
+джависта, и уволить питониста)
+
+#### Легковесность
+
+Каждый микросервис при разработке всегда будет меньше размером чем монолит, а значит, что будет деплоится быстрее,
+прогонять тесты быстрее итд. Что позволяет значительно ускорить операционные вопросы.
+
+#### Обновляемость и независимость
+
+Если у нас есть устаревший монолит и мы хотим обновить его на новую версию языка или технологию, обычно это невыносимый,
+мучительный процесс.
+
+В микросервисном подходе в этом нет проблемы, логин может быть написан на устаревшей джаве, а платёжная система на самом
+новом питоне, допустим на FastAPI.
+
+Если мы хотим, что-то обновить или переписать на другой язык, нам достаточно исправить только один модуль, и никак не
+трогать другие.
+
+Еще одним плюсом является не связанность между собой этих модулей, не может получиться такой ситуации, когда поправили
+одну строчку кода, а задели 5 приложений. А значит не надо писать кучу новых тестов, что экономит время.
+
+#### Изолированость
+
+Если по какой-то причине у нас отпадёт сервис который рассылает рекламу, от этого весь проект работать не перестанет,
+при монолитном подходе это не так.
+
+#### Читаемость и онбординг
+
+Гораздо проще разобраться в сервисе который занимается одним процессом, чем изучать огромное скопление кода, хоть при
+переходе в другую команду, хоть приходя с улицы.
+
+Да и в целом монолит очень часто со временем перерастает в не читаемое "месиво".
+
+### Минусы микросервисов
+
+Минусов тоже хватает :)
+
+#### E2E Тесты
+
+Когда нам нужно провести End-2-End тестирование, какой-то фичи это может быть проблемным из-за того, что одна бизнес
+задача может решаться через большое кол-во сервисов
+
+#### Транзакции
+
+Очень сложно контролировать транзакции когда процесс проходит сразу во многих микросервисах, особенно когда несколько их
+них работают надо одними и теми же данными.
+
+#### Обновление
+
+Если нужно внести какие-то глобальные обновления, очень высок шанс, что необходимо будет координировать несколько
+команд, а это часто бывает большой проблемой.
+
+#### Много DevOps
+
+Для поддержки таких процесов часто нужен большой штат из девопсов, что бы они отвечали за отдельные развёртывания
+отдельных процессов.
+
+### Вывод
+
+Правильного ответа какую архитектуру использовать обычно не существует, есть свои плюсы и минусы. В современном мире
+чаще всё-таки встречаются микросервисы, но это не машает, например, инстаграму, работать как монолит. В идеале оставьте
+вопрос архитекруты, для архитекторов, если есть такая возможность
+
+
+## Docker