Сообщение Re: Развертывание (деплоймент) микросервисов от 08.12.2022 15:02
Изменено 08.12.2022 15:03 vsb
Re: Развертывание (деплоймент) микросервисов
Здравствуйте, andsm, Вы писали:
A>• Бесшовное обновление, без простоя системы и без воздействия на пользователей
В простом случае запускается новый экземпляр, когда на лив и реди чеки отвечать начал — трафик переходит на него, старый тушится. Кубер умеет из коробки. От сервиса нужен только работающий лив и/или реди чек.
С архитектурной точки зрения надо думать про БД. Чтобы миграция между версиями всегда была условно мгновенная и всегда можно было откатить сервис на предыдущую версию без отката БД. В целом это не проблема, но сложные миграции придётся разделять на несколько версий, какие-то изменения, которые бы лочили БД надолго (обновление кучи строк) нужно реализовывать через батч-задачи, которые там по 100 строк будут обрабатывать не мешая остальным и тд.
A>• Быстрота доставки изменений на рынок (time to market)
Тут просто CI/CD. Пришёл пулл-реквест, получил код ревью, смерджился, собрался образ, приехал на стейджинг, прогнались тесты, поехал на прод.
Ну и, конечно, культура разработки. Это самое главное. Чтобы писали код нормально, чтобы код ревью делали нормально, чтобы тесты были и на них можно было бы полагаться.
A>• Быстрая обратная связь от пользователей при новых релизах
Не очень понял, о чём речь. Метрики, a/b тестирование, фич-флаги, это всё известные технологии.
A>• Возможность управлять процентом пользователей, которые будут обслуживаться разными версиями микросервиса, для каждого микросервиса
Кубер умеет.
A>• Простота отката изменений, если что-то пойдет не так
Кубер умеет. Понятно, что откаченная версия должна работать на мигрировавшей базе, про это уже надо думать программистам.
A>• Возможность быстрого масштабирования нагрузки
Кубер умеет. В хорошем облаке масштабировать можно от условного нуля до условной бесконечности. Понятно, что для кубера масштабирование это просто запуск очередного инстанса с сервисом, когда метрики переходят какие-то границы. А будет ли это масштабироваться на практике или всё упрётся в БД — это уже вопрос архитектуры, тут надо своей головой думать.
A>Имеется ли у кого успешный опыт перехода на канареечное развертывание? Все ли получилось, что хотелось? Насколько это задевает А/Б тесты? Насколько это трудоемко в разработке, и насколько сложно в поддержке?
Это всё требует квалифицированной команды девопсов, квалифицированных программистов, больших начальных вложений. Если бюджеты неограничены — так все крупнейшие софтовые компании делают. Если бюджеты ограничены, лучше работать в рамках привычных спринтов и редких релизов, тщательно протестированных (или не тщательно, это уже вам видней).
A>Сейчас у нас все сервисы в своем датацентре, не в облаке. Подумываю о развертывании своего кластера кубера, чтобы упростить развертывание и поддержку работы системы. Может кто-то делал такое без кубера? Насколько кубер обязателен?
Есть альтернативы. Docker Swarm производителем признан устаревшим, но технически он работает. Nomad считается простой альтернативой кубера. У меня опыт только с кубером. По-мне он классный и я бы не советовал его избегать. Это стандарт де-факто, это переносимая технология, она позволяет не привязываться к конкретному облаку. Но требует достаточно глубокого и квалифицированного погружения. Я сам не использовал управляемые кластеры, но скорей всего посоветую именно их, если у вас нет жёсткого требования к хостингу на своих серверах. Если есть — вам потребуется хотя бы небольшая команда хороших специалистов. Альтернативно можете эту работу зааутсорсить, в русском интернете очень часто светится компания Флант, я с ними никогда не взаимодействовал, но они производят впечатление знающих ребят.
Ну и скорей всего на переход потребуется ощутимое время а также трансформация скиллов всех технарей. Рассчитывайте на год-два для миграции и на то, что всем нужно будет изучить хотя бы основы.
A>• Бесшовное обновление, без простоя системы и без воздействия на пользователей
В простом случае запускается новый экземпляр, когда на лив и реди чеки отвечать начал — трафик переходит на него, старый тушится. Кубер умеет из коробки. От сервиса нужен только работающий лив и/или реди чек.
С архитектурной точки зрения надо думать про БД. Чтобы миграция между версиями всегда была условно мгновенная и всегда можно было откатить сервис на предыдущую версию без отката БД. В целом это не проблема, но сложные миграции придётся разделять на несколько версий, какие-то изменения, которые бы лочили БД надолго (обновление кучи строк) нужно реализовывать через батч-задачи, которые там по 100 строк будут обрабатывать не мешая остальным и тд.
A>• Быстрота доставки изменений на рынок (time to market)
Тут просто CI/CD. Пришёл пулл-реквест, получил код ревью, смерджился, собрался образ, приехал на стейджинг, прогнались тесты, поехал на прод.
Ну и, конечно, культура разработки. Это самое главное. Чтобы писали код нормально, чтобы код ревью делали нормально, чтобы тесты были и на них можно было бы полагаться.
A>• Быстрая обратная связь от пользователей при новых релизах
Не очень понял, о чём речь. Метрики, a/b тестирование, фич-флаги, это всё известные технологии.
A>• Возможность управлять процентом пользователей, которые будут обслуживаться разными версиями микросервиса, для каждого микросервиса
Кубер умеет.
A>• Простота отката изменений, если что-то пойдет не так
Кубер умеет. Понятно, что откаченная версия должна работать на мигрировавшей базе, про это уже надо думать программистам.
A>• Возможность быстрого масштабирования нагрузки
Кубер умеет. В хорошем облаке масштабировать можно от условного нуля до условной бесконечности. Понятно, что для кубера масштабирование это просто запуск очередного инстанса с сервисом, когда метрики переходят какие-то границы. А будет ли это масштабироваться на практике или всё упрётся в БД — это уже вопрос архитектуры, тут надо своей головой думать.
A>Имеется ли у кого успешный опыт перехода на канареечное развертывание? Все ли получилось, что хотелось? Насколько это задевает А/Б тесты? Насколько это трудоемко в разработке, и насколько сложно в поддержке?
Это всё требует квалифицированной команды девопсов, квалифицированных программистов, больших начальных вложений. Если бюджеты неограничены — так все крупнейшие софтовые компании делают. Если бюджеты ограничены, лучше работать в рамках привычных спринтов и редких релизов, тщательно протестированных (или не тщательно, это уже вам видней).
A>Сейчас у нас все сервисы в своем датацентре, не в облаке. Подумываю о развертывании своего кластера кубера, чтобы упростить развертывание и поддержку работы системы. Может кто-то делал такое без кубера? Насколько кубер обязателен?
Есть альтернативы. Docker Swarm производителем признан устаревшим, но технически он работает. Nomad считается простой альтернативой кубера. У меня опыт только с кубером. По-мне он классный и я бы не советовал его избегать. Это стандарт де-факто, это переносимая технология, она позволяет не привязываться к конкретному облаку. Но требует достаточно глубокого и квалифицированного погружения. Я сам не использовал управляемые кластеры, но скорей всего посоветую именно их, если у вас нет жёсткого требования к хостингу на своих серверах. Если есть — вам потребуется хотя бы небольшая команда хороших специалистов. Альтернативно можете эту работу зааутсорсить, в русском интернете очень часто светится компания Флант, я с ними никогда не взаимодействовал, но они производят впечатление знающих ребят.
Ну и скорей всего на переход потребуется ощутимое время а также трансформация скиллов всех технарей. Рассчитывайте на год-два для миграции и на то, что всем нужно будет изучить хотя бы основы.
Re: Развертывание (деплоймент) микросервисов
Здравствуйте, andsm, Вы писали:
A>• Бесшовное обновление, без простоя системы и без воздействия на пользователей
В простом случае запускается новый экземпляр, когда на лив и реди чеки отвечать начал — трафик переходит на него, старый тушится. Кубер умеет из коробки. От сервиса нужен только работающий лив и/или реди чек.
С архитектурной точки зрения надо думать про БД. Чтобы миграция между версиями всегда была условно мгновенная и всегда можно было откатить сервис на предыдущую версию без отката БД. В целом это не проблема, но сложные миграции придётся разделять на несколько версий, какие-то изменения, которые бы лочили БД надолго (обновление кучи строк) нужно реализовывать через батч-задачи, которые там по 100 строк будут обрабатывать не мешая остальным и тд.
A>• Быстрота доставки изменений на рынок (time to market)
Тут просто CI/CD. Пришёл пулл-реквест, получил код ревью, смерджился, собрался образ, приехал на стейджинг, прогнались тесты, поехал на прод.
Ну и, конечно, культура разработки. Это самое главное. Чтобы писали код нормально, чтобы код ревью делали нормально, чтобы тесты были и на них можно было бы полагаться. Не должно быть ситуации, когда человек берёт задачу и уходит её делать на два дня. Нужно коммитить условно каждые полчаса и постоянно проводить код-ревью и мердж в основную ветку. Новые фичи должны быть закрыты переключалками и тд.
A>• Быстрая обратная связь от пользователей при новых релизах
Не очень понял, о чём речь. Метрики, a/b тестирование, фич-флаги, это всё известные технологии.
A>• Возможность управлять процентом пользователей, которые будут обслуживаться разными версиями микросервиса, для каждого микросервиса
Кубер умеет.
A>• Простота отката изменений, если что-то пойдет не так
Кубер умеет. Понятно, что откаченная версия должна работать на мигрировавшей базе, про это уже надо думать программистам.
A>• Возможность быстрого масштабирования нагрузки
Кубер умеет. В хорошем облаке масштабировать можно от условного нуля до условной бесконечности. Понятно, что для кубера масштабирование это просто запуск очередного инстанса с сервисом, когда метрики переходят какие-то границы. А будет ли это масштабироваться на практике или всё упрётся в БД — это уже вопрос архитектуры, тут надо своей головой думать.
A>Имеется ли у кого успешный опыт перехода на канареечное развертывание? Все ли получилось, что хотелось? Насколько это задевает А/Б тесты? Насколько это трудоемко в разработке, и насколько сложно в поддержке?
Это всё требует квалифицированной команды девопсов, квалифицированных программистов, больших начальных вложений. Если бюджеты неограничены — так все крупнейшие софтовые компании делают. Если бюджеты ограничены, лучше работать в рамках привычных спринтов и редких релизов, тщательно протестированных (или не тщательно, это уже вам видней).
A>Сейчас у нас все сервисы в своем датацентре, не в облаке. Подумываю о развертывании своего кластера кубера, чтобы упростить развертывание и поддержку работы системы. Может кто-то делал такое без кубера? Насколько кубер обязателен?
Есть альтернативы. Docker Swarm производителем признан устаревшим, но технически он работает. Nomad считается простой альтернативой кубера. У меня опыт только с кубером. По-мне он классный и я бы не советовал его избегать. Это стандарт де-факто, это переносимая технология, она позволяет не привязываться к конкретному облаку. Но требует достаточно глубокого и квалифицированного погружения. Я сам не использовал управляемые кластеры, но скорей всего посоветую именно их, если у вас нет жёсткого требования к хостингу на своих серверах. Если есть — вам потребуется хотя бы небольшая команда хороших специалистов. Альтернативно можете эту работу зааутсорсить, в русском интернете очень часто светится компания Флант, я с ними никогда не взаимодействовал, но они производят впечатление знающих ребят.
Ну и скорей всего на переход потребуется ощутимое время а также трансформация скиллов всех технарей. Рассчитывайте на год-два для миграции и на то, что всем нужно будет изучить хотя бы основы.
A>• Бесшовное обновление, без простоя системы и без воздействия на пользователей
В простом случае запускается новый экземпляр, когда на лив и реди чеки отвечать начал — трафик переходит на него, старый тушится. Кубер умеет из коробки. От сервиса нужен только работающий лив и/или реди чек.
С архитектурной точки зрения надо думать про БД. Чтобы миграция между версиями всегда была условно мгновенная и всегда можно было откатить сервис на предыдущую версию без отката БД. В целом это не проблема, но сложные миграции придётся разделять на несколько версий, какие-то изменения, которые бы лочили БД надолго (обновление кучи строк) нужно реализовывать через батч-задачи, которые там по 100 строк будут обрабатывать не мешая остальным и тд.
A>• Быстрота доставки изменений на рынок (time to market)
Тут просто CI/CD. Пришёл пулл-реквест, получил код ревью, смерджился, собрался образ, приехал на стейджинг, прогнались тесты, поехал на прод.
Ну и, конечно, культура разработки. Это самое главное. Чтобы писали код нормально, чтобы код ревью делали нормально, чтобы тесты были и на них можно было бы полагаться. Не должно быть ситуации, когда человек берёт задачу и уходит её делать на два дня. Нужно коммитить условно каждые полчаса и постоянно проводить код-ревью и мердж в основную ветку. Новые фичи должны быть закрыты переключалками и тд.
A>• Быстрая обратная связь от пользователей при новых релизах
Не очень понял, о чём речь. Метрики, a/b тестирование, фич-флаги, это всё известные технологии.
A>• Возможность управлять процентом пользователей, которые будут обслуживаться разными версиями микросервиса, для каждого микросервиса
Кубер умеет.
A>• Простота отката изменений, если что-то пойдет не так
Кубер умеет. Понятно, что откаченная версия должна работать на мигрировавшей базе, про это уже надо думать программистам.
A>• Возможность быстрого масштабирования нагрузки
Кубер умеет. В хорошем облаке масштабировать можно от условного нуля до условной бесконечности. Понятно, что для кубера масштабирование это просто запуск очередного инстанса с сервисом, когда метрики переходят какие-то границы. А будет ли это масштабироваться на практике или всё упрётся в БД — это уже вопрос архитектуры, тут надо своей головой думать.
A>Имеется ли у кого успешный опыт перехода на канареечное развертывание? Все ли получилось, что хотелось? Насколько это задевает А/Б тесты? Насколько это трудоемко в разработке, и насколько сложно в поддержке?
Это всё требует квалифицированной команды девопсов, квалифицированных программистов, больших начальных вложений. Если бюджеты неограничены — так все крупнейшие софтовые компании делают. Если бюджеты ограничены, лучше работать в рамках привычных спринтов и редких релизов, тщательно протестированных (или не тщательно, это уже вам видней).
A>Сейчас у нас все сервисы в своем датацентре, не в облаке. Подумываю о развертывании своего кластера кубера, чтобы упростить развертывание и поддержку работы системы. Может кто-то делал такое без кубера? Насколько кубер обязателен?
Есть альтернативы. Docker Swarm производителем признан устаревшим, но технически он работает. Nomad считается простой альтернативой кубера. У меня опыт только с кубером. По-мне он классный и я бы не советовал его избегать. Это стандарт де-факто, это переносимая технология, она позволяет не привязываться к конкретному облаку. Но требует достаточно глубокого и квалифицированного погружения. Я сам не использовал управляемые кластеры, но скорей всего посоветую именно их, если у вас нет жёсткого требования к хостингу на своих серверах. Если есть — вам потребуется хотя бы небольшая команда хороших специалистов. Альтернативно можете эту работу зааутсорсить, в русском интернете очень часто светится компания Флант, я с ними никогда не взаимодействовал, но они производят впечатление знающих ребят.
Ну и скорей всего на переход потребуется ощутимое время а также трансформация скиллов всех технарей. Рассчитывайте на год-два для миграции и на то, что всем нужно будет изучить хотя бы основы.