Разработчик призвал большинство компаний отказаться от микросервисов

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

Управление данными — это кошмар 

В микросервисах бывает непросто поддерживать синхронизацию данных.

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

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

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

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

Больше времени на настройку 

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

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

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

Микросервисы лучше подходят для больших команд 

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

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

Структурная схема монолита и микросервисов

DevOps — это более сложный процесс 

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

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

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

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

Архитектура приложения надежна лишь настолько, насколько надежна самая слабая часть. Чем больше движущихся частей, тем больше вероятность ошибки. 

Заключение 

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

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