Куда ушли микросервисы Перевод

Когда я ушел из Microsoft и присоединился к стартапу в 2015 году, первое, что я узнал, — это концепция микросервисов. Его рекламировали как будущее разработки программного обеспечения, обещая повышенную масштабируемость, гибкость и отказоустойчивость. Кажется, все запрыгнули на подножку, даже молодые стартапы, несмотря на присущие им проблемы.

Был анекдот по этому поводу:

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

Когда в 2021 году я перешел из мира бэкэнд-разработки в мир полного стека, я обнаружил, что вся шумиха вокруг популярного стека, такого как Next.js, Prisma и tRPC, кажется монолитной, люди больше не говорили о микросервисах. .

Итак, что случилось? Это связано с появлением новых трендов и технологий или отражением самих микросервисов после извлеченных уроков?

Монолит первичен

Мартин Фаулер хорошо известен как влиятельный человек в сообществе микросервисов, но знаете ли вы о следующих его заявлениях:

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

• Почти все успешные истории микросервисов начинались с монолита, который стал слишком большим и был разбит.

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

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

Есть две причины:

• Когда вы запускаете новое приложение, насколько вы уверены, что оно будет полезно вашим пользователям? Лучший способ выяснить, полезна ли идея программного обеспечения, — создать ее упрощенную версию и посмотреть, насколько хорошо она работает. На этом первом этапе вам необходимо расставить приоритеты по скорости (и, следовательно, по времени цикла для обратной связи), поэтому премия микросервисов — это препятствие, без которого вам лучше обойтись.

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

Ни одна архитектура часто не является лучшей архитектурой в первые дни существования системы…

Полная версия (анг.): dev.to