[Перевод] До микросервисов нужно дорасти, а не начинать с них

Мы можем спокойно кодировать целыми днями, а затем прочитать статью о чём-то — и она подвергает сомнению всю нашу работу, потому что какой-нибудь Netflix сказал XYZ. У нас, разработчиков программного обеспечения, довольно интересная профессия.

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

Когда мы читаем HackerNews и другие новостные сайты, то часто видим технические сообщения от Google, Netflix, Amazon и Facebook, и они любят говорить о том, сколько сотен или тысяч сервисов они запускают. Они говорят о преимуществах всё делать по-своему. Это тенденция последних нескольких лет.

Вряд ли у вас в наличии 1000 разработчиков, которые работают над массивным проектом с более чем 10-летней историей. Но давайте посмотрим правде в глаза.

Просто потому, что Google делает это, не означает, что вы тоже должны делать это.

Google сталкивается с проблемами, с которыми мы, вероятно, никогда не столкнёмся, но в то же время мы можем делать вещи, которые Google не может. Мы работаем в совершенно другой галактике.

Многие проекты начинаются с одного человека, который делает всю работу. Есть миллион примеров, но давайте посмотрим на Shopify. Изначально сервис закодировал Тобиас Лютке (он был основан на Ruby on Rails и до сих пор, кстати, работает на «рельсах»).

Как вы думаете, Тобиас сидел в нерешительности, кропотливо продумывая идеальную архитектуру на микросервисах, прежде чем написать первую строчку кода?

Я не присутствовал при разработке первой версии Shopify, которая изначально была просто интернет-магазином для сноубординга, но если Тобиас похож на меня (типичный разработчик), то процесс выглядел примерно так: Чёрт, нет.

1. Изучить новую технологию в процессе написания исходного продукта.
2. Написать довольно нестандартный (поганый), но полностью рабочий код.
3. Посмотреть, как всё работает вместе и возбудиться.
4. Провести рефакторинг типа «выжигание огнём» и улучшить код, когда возникает проблема.
5. Повторять этот цикл при добавлении новых функций и запуске в рабочей среде.

Это может показаться очень простым циклом, но мне потребовалось около 20 лет программирования, чтобы понять, насколько он глубок.

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

Со временем он во многом помогает вам повысить свой уровень. Тот первоначальный код, который вы заменили, не является впустую потраченным временем или усилиями. Это секретный ингредиент.

Как разработчики, мы все слышали фразу «DRY: don't repeat yourself», и в целом это разумный совет не делать работу повторно. Но часто её стоит сделать.

Её стоит повторить, когда вы пытаетесь абстрагировать что-то без полного понимания и создаёте то, что называется неполной абстракцией (leaky abstraction).

Часто лишь после 4-го или 5-го раза я принимаю какие-то меры. Я обычно выполняю работу трижды, прежде чем вообще ПОДУМАТЬ о рефакторинге какого-то кода и удалении дублей.

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

Уровни абстракции, от встроенного кода до внешних библиотек:

1. Написать встроенный код.
2. Продублировать код в нескольких разных местах.
3. Извлечь продублированный код в функции и т.д.
4. Некоторое время использовать эти абстракции.
5. Посмотреть, как этот код взаимодействует с другим кодом.
6. Извлечь общую функциональность во внутреннюю библиотеку.
7. В течение длительного времени использовать внутреннюю библиотеку.
8. Действительно понять, как все части собираются вместе.
9. Создать внешнюю библиотеку (open source и др.), если это имеет смысл.

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

DHH (автор Rails) не проснулся однажды и сказал: «Ой! «Рельсы» — отличный пример. Пора создать директории models/, controllers/ и views/!».

Он разработал Basecamp (реальный продукт), тогда появились определённые шаблоны, и эти шаблоны были обобщены, а затем выделены из Basecamp в Rails. Нет. Этот процесс всё ещё продолжается сегодня, и, по-моему, это единственная причина, по которой Rails остаётся настолько успешным.

Это также объясняет, почему почти все фреймворки типа «Rails, только на языке XYZ» не работают. Это идеальный шторм очень хорошо обкатанных (читай: не теоретически разработанных) абстракций в сочетании с языком программирования, который позволяет написать привлекательный код. Они пропускают ключевые компоненты цепочки абстракций и думают, что могут просто дублировать Rails.

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

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

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

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

Не думаю, что кто-то назовет их маленькими, хотя они и не работают в масштабе Google.

Shopify зарабатывает $17 млн в месяц на монолите

По состоянию на середину 2018 года Shopify публично объявила, что на их платформе работает более 600 000 интернет-магазинов.

В любом случае, даже если 600 000 клиентов использовали самый дешёвый план за $29, это доход $17,4 млн в месяц только от SaaS-направления их бизнеса. Shopify — это приложение SaaS, у которого самый дешёвый тариф составляет $29 в месяц, и у меня такое ощущение, что многие компании выбирают тариф $79 в месяц.

Что интересно в Basecamp, так это то, что у них всего около 50 сотрудников, и только часть из них — разработчики программного обеспечения, работающие над основным продуктом. Приложение Basecamp — другое большое монолитное приложение.

Не создавайте микросервисы просто так. Я хочу сказать, что можно зайти ОЧЕНЬ далеко, не спускаясь в кроличью нору микросервисов.

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

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

В такой ситуации, наверное, не стоит разбивать монолит сразу на 100 микросервисов, стартуя с места в карьер. Имейте в виду, что если у вас маленькая команда, которая медленно растёт с течением времени, то можно начать с одного или двух микросервисов.

Стоит ли овчинка выделки?

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

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

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

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

Я недавно услышал о них, потому что они были представлены на Cloud Field Day 4. Их продукт больше ориентирован на крупномасштабные приложения (понятно почему), но также работает и для небольших проектов.

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

В основном, я написал эту статью по двум причинам:

Он должно выйти через несколько месяцев, но здесь я хотел подробнее остановиться на некоторых моментах. Во-первых, две недели назад я посетил Cloud Field Day 4 и случайно поучаствовал в групповом подкасте на смежную тему.

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

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

Этот момент мешает им двигаться вперёд, и как коллега-разработчик я знаю, насколько тяжело застрять в нерешительности (у меня такое было!).

Прямо сейчас над проектом работаю я один, и вы можете быть уверены, что я просто открыл редактор и начал писать код в первый же день. Кстати, в настоящее время я работаю над довольно большим SaaS-приложением — платформой для размещения пользовательских курсов.

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