Comments 3
1) Сервисы на разных языках это не преимущество, а недостаток. Если у вас все микросервисы на одном языке, то их легче саппортить, легче найти нового человека на проект или заменить отсутствующего.
2) Вы не пробовали один-два девопса и несколько команд для микросервисов? У нас в районе 40 микросервисов и полтора девопса на проекте. 5 релизов в день в среднем и неограниченное количество деплоев в 25+ дев энвайронментов.
2) Вы не пробовали один-два девопса и несколько команд для микросервисов? У нас в районе 40 микросервисов и полтора девопса на проекте. 5 релизов в день в среднем и неограниченное количество деплоев в 25+ дев энвайронментов.
Спасибо за вопросы. Я — Алексей Баитов, у кого брали интервью в этой статье.
1) Согласен, что очень удобно, когда язык сервисов совпадает. Ещё удобнее, когда язык сервиса (сервисов) совпадает с языком инфраструктуры. У меня даже доклад есть на эту тему. На Golang: разработанный сервис, среда оркестрации (Kubernetes), система сбора метрик и алертов (Prometheus), контейнеризация (Docker). Чувствуешь себя как рыба в воде, когда везде видишь единый формат ошибок.
Но реалии не всегда позволяют нам написать все сервисы на одном языке: нет достаточно людей со знанием одного языка, порой нет возможность сразу найти нужного человека на рынке, не всегда язык подходит под все задачи, у языка может не быть полной совместимости с инфраструктурой (например, сырые или недостаточно развитые библиотеки). В нашем случае также большой код (C#) был уже написан и давно отточен в монолите. Гораздо дешевле его было переиспользовать в виде отдельного сервиса, хотя остальные сервисы уже писали на другом языке (Scala).
2) У нас на 8 человек (2 C#, 3 Scala, 2 Javascript, 1 QA) изначально приходилось 1-2 DevOps, только они совмещали соответственно Scala и QA. Командой можно считать всех вместе (мы так себя и считаем), а можно разделять по языкам разработки (тогда получилось бы 3 небольшие команды со своими микросервисами — это лучше укладывается в концепцию микросервисов). Сейчас роль DevOps распределилась на всех, потому что так гораздо лучше для разработчиков и сервисов. Разработчики в процессе сопровождения сервисов понимают, как можно сделать сервис лучше: полнота логов и метрик, SLA, ближе к потребностям конечных пользователей.
У нас в районе 20 сервисов, бывает 4-5 релиза в день и это не предел и также неограниченное количество деплоев в 15+ дев энвайронментов.
Так что да, пробовали и перешли от 1-2 DevOps к роли DevOps на всех.
1) Сервисы на разных языках это не преимущество, а недостаток. Если у вас все микросервисы на одном языке, то их легче саппортить, легче найти нового человека на проект или заменить отсутствующего.
1) Согласен, что очень удобно, когда язык сервисов совпадает. Ещё удобнее, когда язык сервиса (сервисов) совпадает с языком инфраструктуры. У меня даже доклад есть на эту тему. На Golang: разработанный сервис, среда оркестрации (Kubernetes), система сбора метрик и алертов (Prometheus), контейнеризация (Docker). Чувствуешь себя как рыба в воде, когда везде видишь единый формат ошибок.
Но реалии не всегда позволяют нам написать все сервисы на одном языке: нет достаточно людей со знанием одного языка, порой нет возможность сразу найти нужного человека на рынке, не всегда язык подходит под все задачи, у языка может не быть полной совместимости с инфраструктурой (например, сырые или недостаточно развитые библиотеки). В нашем случае также большой код (C#) был уже написан и давно отточен в монолите. Гораздо дешевле его было переиспользовать в виде отдельного сервиса, хотя остальные сервисы уже писали на другом языке (Scala).
2) Вы не пробовали один-два девопса и несколько команд для микросервисов? У нас в районе 40 микросервисов и полтора девопса на проекте. 5 релизов в день в среднем и неограниченное количество деплоев в 25+ дев энвайронментов.
2) У нас на 8 человек (2 C#, 3 Scala, 2 Javascript, 1 QA) изначально приходилось 1-2 DevOps, только они совмещали соответственно Scala и QA. Командой можно считать всех вместе (мы так себя и считаем), а можно разделять по языкам разработки (тогда получилось бы 3 небольшие команды со своими микросервисами — это лучше укладывается в концепцию микросервисов). Сейчас роль DevOps распределилась на всех, потому что так гораздо лучше для разработчиков и сервисов. Разработчики в процессе сопровождения сервисов понимают, как можно сделать сервис лучше: полнота логов и метрик, SLA, ближе к потребностям конечных пользователей.
У нас в районе 20 сервисов, бывает 4-5 релиза в день и это не предел и также неограниченное количество деплоев в 15+ дев энвайронментов.
Так что да, пробовали и перешли от 1-2 DevOps к роли DevOps на всех.
Sign up to leave a comment.
Не бойся микросервиса: Алексей Баитов об использовании микросервисной архитектуры на практике