Перевод книги DevOps Toolkit 2.0: Глава 2. Непрерывное развертывание, микросервисы и контейнеры
Непрерывное развертывание, микросервисы и контейнеры
На первый взгляд, непрерывное развертыввание(continuous deployment,CD), Микросервисы и контейнеры, три абсолютно не связаные темы, но и в DevOps никто и не говорит, что микросервисы нужны для непрерывного развертывания, и микросервисы должны быть упакованы в контейнеры. Но если объеденить все три темы в одну, вы попадете в совершенно новый мир. Последние разработки в области контейнеров и концепции непрерывного развертывания приложений, позволяют решить проблемы с кооторыми сталкивались микросервисы, с другой стороны мы можем получить гибкость и скорость, без которых CD просто не выгоден для бизнеса.
Прежде чем продолжать дальше, давайте определим какждый из этих терминов.
Непрерывная интеграция
Чтобы понять что такое непрерывное развертывание(continuous deployment), мы должны знать, что предшествовало; это непрерывная интеграция и непрерывная доставка. В цикле разработке, сама болезненая чась была, фаза интеграции, мы проводили недели, месяцы и годы работая в разных командах, которые разрабатывали приложения и сервисы, у каждой из команд есть определенный набор требования и каждая из команд старается изо всех сил им следовать. Конечно не трудно переодически проверять каждую из программ и сервисов в изолированных средах, но мы боялись того момента, когда руководители команд, решали, что прищшло время интегрироваться в основную среду. За плечами был опыт предыдущих проектов и мы знали, что интеграция будет проблемой для всех, на этой фазе обычно всплывали многие проблемы, которых не было ранее, такие как: зависимости, несогласование интерфейсов и протоколов которые работают с друг другом не правильно. Этот этап мог занимать недели и месяцы, но хуже всего то, что ошибка найденая на этом этапе могла означать, возврат к разработки, и опять мы тратили дни или недели. Если вы спросите меня, как я чувтсвую итеграцию, я бы ответил, это может меня загнать в постоянную депрессию. В те времена, мы думали, что это правильный способ разработки….
Прощло время и многое изменилось. Эстремальное программирование(xp) и другие методы гибокй разработки стали повседневными, автомотическое тестирование теперь часть, процесса и проблемы непрерывной интеграции стали не так ощутимы, теперь-то мы знаем, старый подход в корне был не правильным, индустрия прошла долгий и тернистый путь.
С тех пор многое изменилось. Экстремальное программирование (XP) и другие гибкие методологии стали знакомы, автоматическое тестирование стало частым, и непрерывная интеграция начала ослабевать. Сегодня мы знаем, что то, как мы разработали программное обеспечение, было неправильным. С тех пор индустрия прошла долгий путь.