Возможно, микросервисы вам не нужны

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

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

Сегодня микросервисы очень популярны. Это прекрасный архитектурный стиль, который помогает масштабировать систему и саму организацию. Их используют многие успешные компании (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. Мой посыл в том, что мы, как инженеры, должны мыслить критически и выбирать лучшие варианты.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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