10 причин НЕ использовать микросервисы

1273

10 причин НЕ использовать микросервисы

Микросервисы

Микросервисная архитектура — это модель разработки программного обеспечения, при которой приложение строится из автономных и слабо связанных между собой модулей. На практике это упрощает создание и управление проектами, поэтому такой подход используют в своих продуктах даже известные бренды, в том числе PayPal, Netflix и Amazon.

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

Повышенная сложность

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

2. Сложность тестирования

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

3. Микросервисы трудно отлаживать

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

4. Низкая производительность

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

5. Увеличение операционных издержек

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

6. Повышенные затраты на развертывание

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

7. Сложность в отслеживании данных

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

8. Для разработки требуется специальная команда

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

9. Безопасность продукта

Защита данных в микросервисной архитектуре — это гораздо более сложная задача, по сравнению с обеспечением безопасности монолитного приложения. Разумеется, разработчики могут использовать распространенные фреймворки и библиотеки, в том числе такие, как Spring Security, JWT и OAuth 2.0, но все же они закрывают не все вопросы.

10. Микросервисы нужны не всегда

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

Заключение

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

Если вы хотите получать больше интересной и полезной информации про IT-рынок — подписывайтесь на наш Telegram-канал!