Писать эту статью было весело. Многие наверняка её захейтят, но …

Дорогие коллеги-разработчики, нам нужно поговорить. Поговорить о микросервисах и ряде нежелательных ситуаций. Да, будет непросто, но это необходимо. Иначе нам не справиться.

Сегодня микросервисы очень популярны. Это прекрасный архитектурный стиль, который помогает масштабировать систему и саму организацию. Их используют многие успешные компании (Netflix, Spotify и прочие). Поэтому вполне нормально, что большинство организаций уже применяют или планируют начать применять этот стиль. Однако не все учитывают сопутствующие затраты.

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

Как всё начиналось — были ли это микросервисы?


В 2012 году компания, где я работал, столкнулась с проблемой: нам нужно было расширить штат до тысяч инженеров и 1000-кратно увеличить число обрабатываемых транзакций. Сразу поясню, что в этой статье мы будем говорить не о найме специалистов и онбординге, а об архитектуре.

В то время я читал книгу «Scalability Rules: 50 Principles for Scaling Web Sites», где была представлена модель AKF Scale Cube.


Модель AKF Scale Cube из книги «Scalability Rules: 50 Principles for Scaling Web Sites»

Я нашёл эту модель чрезвычайно понятной, поэтому стал с её помощью объяснять другим, почему нам нужно использовать в продакшене иные исполняемые файлы. Картина трафика, обрабатываемого модулем Search, сильно отличалась от его картины для модуля Shopping Cart. Разумным решением было разделить эти компоненты. Кроме того, это бы позв��лило нам наладить независимую работу нескольких команд, решив проблему масштабирования штата до тысяч инженеров.

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

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

Так в чём проблема?


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

▍ Пример 1 — вы создаёте сервис, они создают сервис, все создают сервисы


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

В частности, припоминаю случай, когда общался с двумя директорами по разработке (Director of Engineering) в стартапе, инженерный отдел которого включал 200 человек. Невероятные ребята, очень умные и открытые к общению.

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

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

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

▍ Пример 2 — вы меняетесь, я меняюсь, все мы меняемся


Нелегко правильно реализовать концепцию высокой связности и слабого зацепления (high cohesion and low coupling), особенно в контексте микросервисов. У вас могут получиться очень маленькие микросервисы (иначе называемые наносервисами), имеющие тесное зацепление и слабую внутреннюю связность.

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

И это очень хороший пример, поскольку поверх всего этого разработчики хотели создать ещё один сервис, который бы совместил в себе всю информацию для повышения быстродействия. В итоге эта идея слияния мелких сервисов для повышения связности была сочтена неудачной, поскольку результат, цитирую: «Выглядел как монолит».

▍ Пример 3 — всё было хорошо, пока не испортилось


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

Это может быть не лучший пример, поскольку в таких случаях никто не мог знать наперёд, что компании начнут урезать штат технических специалистов. Суть в том, что в нашей отрасли весьма сложно делать вещи простыми. Тем не менее я считаю, что нам нужно стр��миться сохранять всё максимально простым, но не проще.

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

▍ Пример 4 — давайте запустим стартап на основе микросервисов


Это будет последний пример, обещаю. Вообще он связан с чьим-то выступлением, которое я не могу найти. Если вы поймёте, о каком выступлении речь, отпишите в комментариях, чтобы я мог дать подобающую ссылку.

Думаю, вы согласитесь, что очень круто создавать проекты с нуля. Можно сравнить такой проект с пустым холстом, ожидающим руки художника. В данном случае художник решил нарисовать цветную картину. Он выбрал для неё основные цвета — Ruby, Golang и Java — смешав их с небольшим количеством Postgresql, Elasticsearch и Cassandra.

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

Всегда ли это плохо?

Я не говорю, что это плохо. Я считаю, что проект Jet.com фактически начал с использования микросервисов, и в последствии прекрасно интегрировался с Walmart. Мой посыл в том, что мы, как инженеры, должны мыслить критически и выбирать лучшие варианты.

Хорошо, но почему?


Некоторые, читая мои рассуждения, подумают, что «Всё дело в недостатке навыков». Это не так. Я лично знаю людей из первых двух примеров. Это очень умные и опытные инженеры. И я уверен, что люди из других примеров тоже достаточно умны.

На мой взгляд, причина глубже, и Скотт Ханнер неплохо выразил одну из версий в своём твите:


Перевод
Думаю, что я сильно привык к микросервисам, ровно как и к ООП. Я уже не помню, как выглядит что-то иное. Эта информация оказалась вытеснена из сознания многих знакомых мне людей. Можно сравнить это с «Новоязом» из романа «1984». Мы утратили способность выстраивать мысль. Нам нужна помощь.

Пожалуй, мы слишком глубоко впитали концепцию микросервисов. Возможно, поэтому её применяет так много небольших команд. Она глубоко укоренилась в нашей модели мышления.
Часть вины также можно возложить на политику нулевой процентной ставки (zero interest-rate policy, ZIRP), о чём говорит DHH в этом твите:


Перевод
DHH: Помешательство на микросервисах стало, пожалуй, чистейшим примером ZIRP. Рузвельт при всём желании не смогу бы придумать для программистов более эффективную программу полной занятости.

Скотт Ханн: Я слышал, что микросервисы вызвали ажиотаж. Но дело обстоит куда хуже. Они уничтожают всё остальное. Даже если я предложу не разделять какие-то два компонента, кто-нибудь обязательно выпучит глаза со словами: «Это же будет монолит», будто мы все должны понимать, насколько это глупо.

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

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

У вас ещё есть время


Если какой-либо из приведённых мной примеров напоминает ваш случай, не беспокойтесь. Программное обеспечение хорошо тем, что вы почти всегда можете его измени��ь. Есть один интересный приём — если вы видите проблему, попробуйте заменить слово «проблема» словом «возможность».

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

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

Вы основываете компанию?
Если вы запускаете компанию и подумываете об использовании микросервисов, составьте дизайн-документ, поясняющий, какие перед вами стоят сложности, почему именно микросервисы, и какие альтернативы вы ещё рассматривали. Если у вас есть доверенный человек, покажите ему этот документ и попросите оценить — если, конечно, имеете на то юридическое право. Это поможет прояснить мысли и отчётливо понять, действительно ли микросервисы станут подходящим архитектурным стилем для вашего стартапа.

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

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

Итак, дорогие разработчики, я начал эту беседу, потому что меня её тема волнует. Меня волнует сама внутренняя суть нашей индустрии. Я хочу, чтобы она была устойчива, стабильна и способствовала созданию долговечного ПО. Это должна быть такая индустрия, в которой мы будем принимать прагматичные решения и использовать технологию как средство, а не как цель.

Иногда микросервисы прекрасны, но вам они, возможно, не нужны.

Telegram-канал со скидками, розыгрышами призов и новостями IT 💻