От монолита к микросервисам. Глава 1 Основные сведения о микросервисах / Филипп Дельгядо

• Обсуждение книги "Монолиты к микросервисам" от Сэма Ньюмана.  

• Обсуждение основных понятий микросервисов и монолитов, их отличий и преимуществ.  

• Основные принципы микросервисов: независимость, нейтральность к технологиям, общение по сети.  

• Микросервисы выстроены вокруг бизнес-домена и имеют в себе бизнес-доменные штуки.  

• В книге "Микросервисы" автор Сэм Ньюман обсуждает интеграцию через базу данных и ее недостатки.  

• Он считает, что это плохо и не стоит делать, но признает, что это может быть обосновано в некоторых случаях.  

• Участники обсуждают, является ли интеграция через базу данных нормальным паттерном или антипаттерном.  

• Они также обсуждают, как сделать хорошие контракты и как научиться делать их.  

• Участники обсуждают новую концепцию "дата мэш", которая предлагает использовать контракты на основе данных для связи сервисов.  

• Они обсуждают, как это работает в реальных проектах и какие проблемы могут возникнуть.  

• Микросервисы позволяют использовать больше разработчиков и позволяют делать больше изменений.  

• Однако, важно не забывать о том, что микросервисы могут быть сложными в разработке и поддержке.  

• Важно также учитывать, что микросервисы могут быть не всегда оптимальными для всех случаев.  

• Транк-пейсмент - это подход, при котором все изменения делаются маленькими частями и отправляются под фичи-флагами.  

• Это позволяет сохранять обратную совместимость и упрощает поддержку изменений.  

• Рест создавался для гипермедиасистем, но его использование в других системах может привести к проблемам с безопасностью и масштабируемостью.  

• Лучше использовать подход, при котором каждая команда вызывается отдельно, а не использовать рест в его изначальной идеологии.  

• Микросервисы позволяют разработчикам стать экспертами в конкретном домене, а не просто писать код.  

• Уменьшение контекста: разработчики могут вникать в бизнес и думать о том, как реализовывать фичи.  

• Стабильность: в монолите проще настраивать производительность и обеспечивать стабильность.  

• Количество людей: в больших системах с микросервисами проще выстраивать структуру и определять ответственность.  

• Размер микросервисов может быть разным, но важно учитывать технологии и простоту независимого диплоя.  

• Пример: внедрение нейросети в монолите может быть сложным, а в микросервисе на питоне - простым.  

• Микросервисы могут не иметь отдельного бизнес-домена, но все равно могут быть полезными.  

• Пример: сервис, который делает пдфку, не является микросервисом, но может быть полезен для конкретного бизнес-домена.  

• Обсуждение понятий капли и кохижины, их значения и применения в архитектуре систем.  

• Капли - это изменения в одном участке системы, которые требуют изменений в другом.  

• Кохижины - это группировки элементов системы, которые имеют максимальную внутреннюю связанность и минимальную связь между модулями.  

• Обсуждение способов измерения капель и кохижин для существующих систем.  

• Предлагается нарисовать все агрегаты системы и посмотреть, как они взаимодействуют для выполнения бизнеса.  

• Обсуждение различных видов капель и кохижин, включая темп капли, домен капли и другие.  

• Упоминается, что темп капли может быть менее важным, так как современные системы могут обрабатывать сетевые адреса без необходимости опрокидывать их.  

• Обсуждение причин, по которым монолиты стали менее популярными и перешли к микросервисам.  

• Упоминаются сложности совместной разработки, внедрения новых технологий и масштабирования монолитов.  

• Обсуждение идеи о том, что микросервисы могут быть способом быстрее и проще нанимать разработчиков с меньшим контекстным окном.  

• Упоминается, что микросервисы могут быть полезны для реализации различных нефункциональных требований к одному продукту.  

• Микросервисы могут упростить архитектурный надзор, но квалификация человека, пишущего микросервисы, должна быть выше, чем у того, кто пишет кусок кода в монолит.  

• Упоминается, что микросервисы стали популярными из-за их способности упрощать архитектурный надзор и уменьшать количество ошибок.  

• Однако, квалификация человека, пишущего микросервисы, должна быть выше, чем у того, кто пишет кусок кода в монолит.  

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

• Упоминается, что количество монолитов может уменьшиться, так как бизнес начнет считать деньги и использовать монолиты для реализации фич.  

• Обсуждается, что микросервисы могут породить интерес к разным архитектурным стилям и что модульные монолиты могут стать более популярными.  

• Обсуждение преимуществ и недостатков монолитов и микросервисов, особенно в контексте использования бессервисных контейнеров.  

• Упоминается, что на сотнях или полпибайта данных можно не думать о железе, но как только нагрузка становится интересной, приходится думать о железе.  

• Обсуждается, что на самом деле важно удобство за счет эффективности, и что можно переплатить за это, но получить быстрое решение.  

• Упоминается распределенный монолит и эволюционная архитектура, где отдельные функции монолита могут быть вынесены в отдельные компоненты, которые решают задачи вместе.  

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

• Упоминаются практики разработки монолитов, такие как стратегические паттерны и архитектурные тесты.  

• Упоминается доклад Паши Оскольникова о том, как он распиливает монолит.  

• Упоминаются заповеди архитектора, которые могут помочь в выборе между монолитом и микросервисами: стейкхолдеры всегда врут, вендеры всегда врут, и комон сен всегда врет.