Разработали сложный микросервис уведомлений для крупной строительной компании.
На картинке — общая архитектура сервиса.
В новой технической статье рассказываем, как так получилось.
—
Хотите запустить новый продукт с нуля или сервис внутри существующей архитектуры? Пишите в личку @samatg! Мы берем новых клиентов.
Вышла классная заметка DHH о том, что лучше писать нормальные монолиты, чем пытаться делать модные микросервисы. Дэвид — создатель Basecamp и Ruby on Rails.
Поводом для заметки послужила новая статья команды Amazon Prime Video, где они рассказывают, как отказались от микросервисов, решили проблемы с масштабированием и сократили издержки на 90% (не опечатка).
Не буду здесь повторяться; тем более, что Дэвид даже рассказал, как быть, если вы уже поторопились и сделали микросервисы.
—
Вот Дэвид издевается над Амазоном и микросервисами, а я в традиции постмодернизма поиздеваюсь над ним. Хорошо быть здоровым и богатым — в смысле, что опираясь на многолетний опыт и руководствуясь здравым смыслом, делать минимальное необходимое программирование, не переусложнять систему. Спасибо за совет!
По сути я с ним согласен — в 90% случаев микросервисы не нужны. Но если вы об них ещё не обжигались — то не слушайте старых пердунов вроде нас, делайте свои ошибки, учитесь, по-другому учиться очень сложно.
Тем более, что это интересная задача для нас с Федей — разбирать архитектурные завалы. Если вдруг обнаружили себя в ситуации, что разработка начала тормозить или хотите избежать этого со старта — обращайтесь :)
Похвастаюсь. Делаем с Федей аудит одного крупного финансового сервиса. Сегодня был третий день встреч с техдиром.
Каждый фиолетовый прямоугольник — это довольно большой сервис (отдельный репозиторий), над которым работает своя команда.
На схеме примерно треть, а то и четверть всей системы. Базы по много терабайт, тысячи интеграций — вызывает уважение, да что говорить, восхищение, что всё это работает и приносит пользу и деньги. 😍
Новый эпизод! С техническим директором и тимлидом. Даниил Шевчук и Александр Козлов решают те же технические задачи, что и мы с вами — бьют монолит на сервисы, оптимизируют кеши под нагрузкой, налаживают взаимодействие членов команды и команд между собой.
Но есть большое отличие — они работают в благотворительном фонде. У фонда «Нужна помощь» 8 мощных проектов: от популярного медиа «Такие дела» и акции «Рубль в день», которую рекламирует Иван Ургант, до системы автоматизации отчетности благотворительных фондов, этакой «эльбы для благотворителя».
Откуда у благотворителей деньги на разработку? Сколько они денег собирают и сколько тратят? Как устроено IT в этой сфере? — обо всём этом мы поговорили с самыми крутыми технарями в благотворительности в России. Ну и безумные истории запусков по ночам, конечно же :)
Наслаждайтесь: Apple, Google, Castbox, Яндекс, Spotify, Overcast, ютуб и веб-версия.
С гордостью представляю новый эпизод подкаста.
В гостях — Тамара Зуйкова, технический директор Манго Страхования. Это стартап, в который альфа-групп вложила миллиард (!) рублей.
Разбираемся в страховании — как защищаются от обмана, как зарабатывают деньги и как всё это программируют. Тамара умеет объяснять сложные штуки исключительно ясно и понятно. ❤️
В эпизоде: управление рисками, микросервисная архитектура, власть и ответственность разработчиков, база данных kafka и многое другое — простым языком.
Слушайте везде: Apple, Google, Castbox, Яндекс, Spotify, Overcast, ютуб и веб-версия.
Дима Олляк делится в нашем уютном чате хорошим:
«Тем временем на Хабре руководитель разработки российского Леруа Мерлена увлекательно рассказал, как они вдвухсотером пилят российский Леруа с джавой и микросервисами. За неимением апдейтов техблога Медузы вполне годная статья.
Бонустрек — холодной душ от счастливых покупателей в каментах: „Как уже сказали выше, могут эти 200 человек пожалуйста пофиксить поиск?“»
Segment — очень классный сервис, который собирает данные аналитики и раскидывает по десятку доступных интеграций, которые вы выберете. Этакий мультиплексер аналитических данных.
Они рассказывают, как уткнулись в проблемы производительности, выделили отдельные задачи в микросервисы и стало лучше. В течении года число похожих друг-на-друга микросервисов выросло до 140(!) и начались серьезные проблемы менеджмента зависимостей и деплоя. Тогда они собрали все сервисы обратно в один четкий монолит и опять задышали свободно.
Отличный пример, который показывает, что каждому инструменту (и подходу) — своё время и место. Включайте мозги, не идите на поводу у хайпа.
У строителей под моим окном классическая «микросервисная архитектура приложения». У них есть 3 сервиса — полый бур, сверлящий дырку в земле, бетономешалка, не дающая бетону застыть и насос, закачивающий бетон из мешалки в отверстие, сверлимое буром.
Красным на картинке отмечены места, в которых один сервис «передает» бетон другому. Там должны быть подходящие отверстия, крепления и допустимое предельное давление бетона (чтобы это всё не разорвало) — это API. API — договоренности, по которым сервисы общаются друг с другом.
Допустим, можно было бы сделать убер-машину, которая умеет все — сверлить, качать и мешать. Засыпаете бетон, вставляете сверла и она делает вам готовые заполненные бетоном дырки — это была бы «монолитная архитектура приложений». Её было бы сложнее транспортировать по улицам и, наверное, ей нужен был бы очень крутой инженер для обслуживания.
В случае разделения машины на части мы можем выбрать разных производителей отдельных частей, достаточно, чтобы все они соблюдали стандарты и поэтому могли работать вместе.