Помните клиента, который делает стартап в одно лицо и уже напрограммировал два миллиона строк кода?
Наш архитектор Леша придумал, как выделить из его монолита отдельный голосовой сервис и написал ADR , а этот парень за день все реализовал :) завтра будем разбираться, не выплеснул ли он по пути ребенка.
С таким я ещё не сталкивался — мы ставим клиенту задачи, а он их программирует!
Вышла классная заметка DHH о том, что лучше писать нормальные монолиты, чем пытаться делать модные микросервисы. Дэвид — создатель Basecamp и Ruby on Rails.
Поводом для заметки послужила новая статья команды Amazon Prime Video, где они рассказывают, как отказались от микросервисов, решили проблемы с масштабированием и сократили издержки на 90% (не опечатка).
Не буду здесь повторяться; тем более, что Дэвид даже рассказал, как быть, если вы уже поторопились и сделали микросервисы.
—
Вот Дэвид издевается над Амазоном и микросервисами, а я в традиции постмодернизма поиздеваюсь над ним. Хорошо быть здоровым и богатым — в смысле, что опираясь на многолетний опыт и руководствуясь здравым смыслом, делать минимальное необходимое программирование, не переусложнять систему. Спасибо за совет!
По сути я с ним согласен — в 90% случаев микросервисы не нужны. Но если вы об них ещё не обжигались — то не слушайте старых пердунов вроде нас, делайте свои ошибки, учитесь, по-другому учиться очень сложно.
Тем более, что это интересная задача для нас с Федей — разбирать архитектурные завалы. Если вдруг обнаружили себя в ситуации, что разработка начала тормозить или хотите избежать этого со старта — обращайтесь :)
Segment — очень классный сервис, который собирает данные аналитики и раскидывает по десятку доступных интеграций, которые вы выберете. Этакий мультиплексер аналитических данных.
Они рассказывают, как уткнулись в проблемы производительности, выделили отдельные задачи в микросервисы и стало лучше. В течении года число похожих друг-на-друга микросервисов выросло до 140(!) и начались серьезные проблемы менеджмента зависимостей и деплоя. Тогда они собрали все сервисы обратно в один четкий монолит и опять задышали свободно.
Отличный пример, который показывает, что каждому инструменту (и подходу) — своё время и место. Включайте мозги, не идите на поводу у хайпа.
У строителей под моим окном классическая «микросервисная архитектура приложения». У них есть 3 сервиса — полый бур, сверлящий дырку в земле, бетономешалка, не дающая бетону застыть и насос, закачивающий бетон из мешалки в отверстие, сверлимое буром.
Красным на картинке отмечены места, в которых один сервис «передает» бетон другому. Там должны быть подходящие отверстия, крепления и допустимое предельное давление бетона (чтобы это всё не разорвало) — это API. API — договоренности, по которым сервисы общаются друг с другом.
Допустим, можно было бы сделать убер-машину, которая умеет все — сверлить, качать и мешать. Засыпаете бетон, вставляете сверла и она делает вам готовые заполненные бетоном дырки — это была бы «монолитная архитектура приложений». Её было бы сложнее транспортировать по улицам и, наверное, ей нужен был бы очень крутой инженер для обслуживания.
В случае разделения машины на части мы можем выбрать разных производителей отдельных частей, достаточно, чтобы все они соблюдали стандарты и поэтому могли работать вместе.