Смерть микросервисного безумия в 2018 году / Блог компании Флант / Хабрахабр

Источник: Смерть микросервисного безумия в 2018 году / Блог компании Флант / Хабрахабр

Смерть микросервисного безумия!


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

 

1. Размер команды


Можно ли усадить всю вашу команду за один большой стол?

 

  • Да! Возможно, микросервисы ещё не нужны. Сложности, связанные с деплоем, разработкой, эксплуатацией и т.п., вероятно, легко решаются с помощью хороших коммуникаций и хорошей архитектуры, а микросервисы могут оказаться решением проблемы, которой у вас нет.
  • Нет! Микросервисы могут помочь. Если у вас большая команда или несколько команд, строго обозначить границы компонентов с помощью одной лишь архитектуры может быть затруднительно. Выделение компонентов в изолированные сервисы может помочь в реализации этих границ.

 

2. Stateless/stateful


Ваша система является преимущественно stateless?

 

  • Да! Рассмотрите serverless. Если ваша система в основном stateless, вероятно, вы можете пропустить этап микросервисов и сразу перейти к serverless — по крайней мере, частично.
  • Нет! Микросервисы принесут сложности. Это не означает, что использовать микросервисы не стоит, но помните, что непросто их реализовать и ими управлять — особенно из-за того, что система со временем меняется.

 

3. «Пользователи» системы


Вы собираете решение для одного приложения или сервиса?

 

  • Да! Будьте осторожны — могут встречаться «размытые» предметные области. Если всё, что вы собираете, предназначено одному и тому же приложению-пользователю, может выясниться, что сборка фич потребует одновременного обновления множества сервисов. Микросервисы могут быть уместны, однако будьте очень осторожны с проектированием предметных областей.
  • Нет! Микросервисы могут оказаться очень полезными. Если вы проектируете систему, которой будут пользоваться разные приложения, микросервисы могут оказаться очень уместным паттерном, чтобы быстро доставлять новые фичи новым приложениям-«пользователям».

 

4. Зависимости


У вас есть монолитные зависимости?

 

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

 

5. Компетентность


Есть ли у вас эксперты по контейнерам, оркестровке, DevOps?

 

  • Да! Микросервисы могут оказаться очень полезными. При наличии соответствующих кадров стоит изучить микросервисы. Имеющиеся навыки позволят разобраться с потенциальными трудностями и воспользоваться преимуществами.
  • Нет! Сначала прощупайте почву! При отсутствии должной компетентности или в случае уже имеющихся трудностях с DevOps вы можете прыгнуть выше головы. Рассмотрите возможность адаптации одного простого сервиса в качестве доказательства концепции. Получите первый нужный опыт на проектах, которые не являются критичными для бизнеса.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *