Облако и инфраструктура как код произвели революцию в нашей отрасли. Они позволили нам приобретать инфраструктуру простым и адаптируемым способом.

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

Одно из наиболее распространенных определений микросервиса можно выразить так:

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

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

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

Может ли это произойти и с микросервисами?

Проблемы

Ясность домена

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

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

Вавилонская башня

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

Неявные зависимости времени выполнения

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

Скрытая сложность

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

Почему… если ЯГНИ

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

Повторение себя

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

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

Заключение

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