Внезапно прошла волна репостов статьи «Microservices considered harmful». Ссылка ниже.
Первая мысль из статьи
>>Если у вас спагетти в монолите, то при делении вы получите «spaghetti over HTTP».
Все правильно, только при чем тут микросервисы? Не устаю повторять две вещи:
1. «Выбирайте микросервисы за их преимущества, а не потому, что код монолита ужасен»
2. «Не нарезайте монолит AS IS, проведите моделирование с самого начала, постройте корректную модель предметной области, выделите независимые модули/пакеты внутри монолита и затем выносите микросервисы»
Вторая мысль из статьи
>>Производительность хуже, потому что пакеты бегают по сети.
Сравниваем время обработки сообщений и время на передачу данных. Потеряли на передаче 5 секунд, выиграли на параллельной обработке 10 минут. Так это работает.
>>Масштабируемость хуже, потому что… лучше масштабировать все целиком и появляются новые точки отказа.
Есть великолепные паттерны и инструменты изоляции сбоев. И независимое масштабирование дает космический эффект в облаках, где оплата за использованные ресурсы.
А вот вывод отличный: «keep in mind that almost all technical challenges (code modularity, scalability, single point of failure…) will not be magically solved by using microservices». Все по делу.
———
Микросервисы — не панацея, они сложны, но у них есть существенные преимущества. Эти преимущества не нужны всем, выбор микросервисов должен быть очень прагматичным выбором. Монолит может быть качественно и модульно написан. Микросервисы нужны тогда, когда требуется независимая поставка/независимая замена/независимое развитие/независимое масштабирование/независимый выбор технологий и это действительно дает серьезное конкуретное преимущество. А не ради хайпа 🙂
Первая мысль из статьи
>>Если у вас спагетти в монолите, то при делении вы получите «spaghetti over HTTP».
Все правильно, только при чем тут микросервисы? Не устаю повторять две вещи:
1. «Выбирайте микросервисы за их преимущества, а не потому, что код монолита ужасен»
2. «Не нарезайте монолит AS IS, проведите моделирование с самого начала, постройте корректную модель предметной области, выделите независимые модули/пакеты внутри монолита и затем выносите микросервисы»
Вторая мысль из статьи
>>Производительность хуже, потому что пакеты бегают по сети.
Сравниваем время обработки сообщений и время на передачу данных. Потеряли на передаче 5 секунд, выиграли на параллельной обработке 10 минут. Так это работает.
>>Масштабируемость хуже, потому что… лучше масштабировать все целиком и появляются новые точки отказа.
Есть великолепные паттерны и инструменты изоляции сбоев. И независимое масштабирование дает космический эффект в облаках, где оплата за использованные ресурсы.
А вот вывод отличный: «keep in mind that almost all technical challenges (code modularity, scalability, single point of failure…) will not be magically solved by using microservices». Все по делу.
———
Микросервисы — не панацея, они сложны, но у них есть существенные преимущества. Эти преимущества не нужны всем, выбор микросервисов должен быть очень прагматичным выбором. Монолит может быть качественно и модульно написан. Микросервисы нужны тогда, когда требуется независимая поставка/независимая замена/независимое развитие/независимое масштабирование/независимый выбор технологий и это действительно дает серьезное конкуретное преимущество. А не ради хайпа 🙂