Почему модель платформы Kubernetes заменит старые корпоративные архитектуры
В отчете о состоянии DevOps за 2020 год говорится о «платформенной модели» как о крупнейшем развитии облачной среды на данный момент. В отличие от создания и поддержки отдельных кластеров для групп разработчиков, связанных с отдельными продуктами или услугами, модель внутренней платформы набирает популярность благодаря подходу «самообслуживания» и масштабируемости при работе с несколькими продуктами. Хотя продуктовые группы являются важным аспектом эволюции DevOps, они в значительной степени достигают своего предела, когда вы начинаете масштабироваться и имеете сотни продуктов и услуг, каждый из которых имеет свою команду и набор технологий.
Масштабирование с помощью внутренних платформ
В дополнение к большому количеству «изобретения велосипеда», поскольку все команды, по сути, работают над решением схожих проблем, количество времени и усилий, затрачиваемых на управление инфраструктурой, интеграцию и совместную работу, — это время, отведенное от работы над продуктами. Еще одна проблема, когда у вас есть несколько продуктов и приложений, работающих в разных инфраструктурных стеках, заключается в том, что управление затратами и соответствием требованиям может стать совершенно другим кошмаром.
Именно здесь вступают внутренние платформы, которые обеспечивают единообразие в организации, а также предоставляют разработчикам простой способ ориентироваться в сложностях управления инфраструктурой. Внутренняя платформа — это, по сути, стандартизированный технологический стек или набор инструментов, которые можно использовать во всех продуктах организации. Внутренние платформы обычно запускаются и управляются отдельной командой платформы, занимающейся обслуживанием инфраструктуры, что позволяет разработчикам свободно работать над своими приложениями.
Почему внутренняя платформа Kubernetes?
Хотя большинство организаций переходят на облачную среду Kubernetes, потому что в какой-то момент их приложения стали слишком сложными для локального центра обработки данных, они часто недооценивают кривую обучения, связанную с Kubernetes. Опять же, именно здесь модель внутренней платформы упрощает жизнь всем, поскольку у вас есть одна команда, посвященная Kubernetes, в то время как все остальные могут продолжать делать то, что у них получается лучше всего. Кроме того, поскольку большинство приложений работают поверх Kubernetes, имеет смысл использовать Kubernetes только для создания внутренней платформы.
В результате потребность в чем-то большем, чем обобщенное монолитное решение, подпитывает рост платформенной модели. Это означает создание единого интегрированного решения, объединяющего все разрозненные компоненты внутреннего программного обеспечения компании и решений внешних поставщиков.
Платформа Kubernetes отличается от традиционных архитектур
Платформы являются фундаментальной частью архитектуры любой распределенной системы. Однако способ реализации платформы продолжает меняться и развиваться. Модель платформы сильно отличается от архитектуры приложений корпоративного класса предыдущего поколения. В прошлом такие технологии, как корпоративная служебная шина (ESB), использовались для создания звездообразной модели, в которой ресурсы распределялись между несколькими командами. Эта модель не была рассчитана на масштабирование, и предприятия неизбежно сталкивались с проблемами масштаба. Kubernetes с его распределенным подходом к управлению инфраструктурой является ответом на эти вызовы. В частности, модель платформы на основе Kubernetes является заменой устаревшей корпоративной архитектуры.
Безопасность в платформенной модели
Из-за различных требований групп разработчиков возникает множество проблем с безопасностью и масштабируемостью. Платформенная модель помогает обеспечивать безопасность по умолчанию и избавляет разработчиков от необходимости следовать протоколам безопасности каждый раз, когда они инициируют развертывание. Конфигурация безопасности уже жестко закодирована в средах и ресурсах, предоставляемых разработчикам.
Опыт самообслуживания разработчиков
У разработчиков есть доступ к готовым ресурсам, которые они могут сразу запустить, не дожидаясь начала эксплуатации. Это сокращает время, необходимое для перехода от кода к развертыванию. Это расширяет возможности разработчиков и дает им возможность самообслуживания. Это один из ключевых драйверов платформенной модели.
Одна платформа для мультиоблачного мира
Платформенная модель также позволяет использовать мультиоблако. Вы можете использовать ту же платформу для создания сред разработки в центре обработки данных или в любом облачном провайдере, таком как AWS или Azure. Kubernetes позволяет легко перемещать рабочие нагрузки между облачными платформами или масштабировать их в зависимости от спроса. Он также управляет распределением ресурсов между несколькими распределенными хостами, что делает его масштабируемым и отказоустойчивым.
Вместо того, чтобы каждый продукт или услуга нуждались в своем собственном кластере, вы создаете сеть услуг или ресурсов, которые могут обмениваться информацией друг с другом через сеть и плоскость управления. Вы также можете использовать этот подход для создания «подкластеров», которые позволяют развертывать различные компоненты инфраструктуры, масштабируясь вверх и вниз независимо друг от друга.
Преимущества для команды QA
Платформенный подход также является благом для тестирования качества. Как правило, тестирование включает в себя быстрое создание и уничтожение тестовых сред. По мере развития автоматизации тестирования командам контроля качества требуется легкое и быстрое создание тестовых сред. Эти среды должны быть чистыми и не содержать остаточных данных прошлых тестов. Это было невозможно при запуске тестов на виртуальных машинах. Сегодня в мире контейнеров возможно, но непросто создавать и массово уничтожать тестовые среды. Теперь группы обеспечения качества могут легко создавать тестовые среды, как только они потребуются, и уничтожать их после выполнения необходимых тестов. Короткий срок службы этих сред помогает сократить расходы на облачные вычисления.
Проблемы с платформенной моделью
Есть проблемы с платформенной моделью. Во-первых, любая новая парадигма, какой бы мощной она ни была, столкнется с сопротивлением перед лицом проверенных практик. Самая большая проблема связана с изменением культуры и существующих привычек. Например, операционным командам теперь удобно, когда разработчики поднимают заявку с запросом необходимых им ресурсов, а операционная команда возвращается через день или два. Это дает им буферное время для выполнения связанных с этим ручных задач. Теперь, с моделью платформы, они вынуждены использовать подход невмешательства и позволить разработчикам самостоятельно выделять ресурсы, не требуя каждый раз ручного утверждения. Переход от ручного к автоматизированному подходу может быть сложным, если вы делали это вручную в течение многих лет.
Путь к принятию платформенной модели
Чтобы платформенная модель была успешной, со стороны организации требуются самоотверженные усилия, чтобы отделить команду платформы от более крупной команды эксплуатации. Требуется много времени, чтобы управлять Kubernetes в масштабе. Кроме того, создание системы, которая является масштабируемой, гибкой для удовлетворения потребностей различных групп и обладает высокой отказоустойчивостью, — непростая задача. Организациям необходимо накапливать опыт работы с Kubernetes внутри компании, и этот опыт должен быть сконцентрирован в команде разработчиков платформы.
Основное внимание команды разработчиков платформы должно быть сосредоточено на обеспечении беспрепятственного взаимодействия с разработчиками. Соответственно, они должны отслеживать показатели, отражающие, насколько быстро разработчики могут выполнять свои рабочие процессы. Как часто код фиксируется, развертывается, сколько тестов выполняется, сколько времени требуется для внесения изменения в рабочую среду. Ключевым приоритетом для команды платформы должна быть внутренняя евангелизация платформы и стимулирование внедрения. Для этого потребуется обучение, поддержка, документация и мероприятия, посвященные вехам на этом пути.
Конец традиционных оперативных методов?
Принятие платформ на основе архитектур создало среду, в которой традиционных методов, связанных с эксплуатацией, уже недостаточно. Ранние последователи крупных технологий уже перешли на платформенную модель. Теперь мы увидим, как в ближайшие несколько лет к нам присоединятся крупные предприятия. Kubernetes делает технологию возможной, но более масштабным и интересным изменением будет изменение культуры, которое оно навязывает.