Почему все создают внутренние платформы Kubernetes?

В последнее время, вы могли слышать о “внутренних платформах Kubernetes” из самых разных источников: выступлений на конференциях, статей в медиа или просто коллег и друзей. Даже если такие платформы не всегда называют внутренними платформами Kubernetes, решения, позволяющие инженерам получать стандартизированный и простой доступ к Kubernetes в облачной среде, похоже, становятся все более распространенными в настоящее время.

Эта статья – адаптация разбора наших зарубежных коллег и продолжение материала «Создание внутренней платформы Kubernetes».

Так что же побуждает компании создавать и внедрять такие платформы? Разбираемся вместе – поехали!

Внутренняя платформа Kubernetes

Определение внутренней платформы Kubernetes вы можете найти здесь.

Если кратко, то внутренняя платформа Kubernetes предоставляет инженерам прямой доступ к среде разработки и они могут работать в пред-производственной среде. Такая платформа обычно позволяет инженерам создавать пространства имен самообслуживания, но также возможны решения с целыми кластерами или виртуальными кластерами (vClusters).

Хотя термин “платформа” может означать, что это всего лишь компонент инфраструктуры, внутренние платформы Kubernetes часто также содержат инструменты, которые упрощают использование и управление платформой и общими рабочими процессами разработки, особенно рабочими процессами развертывания для разработчиков, даже если у них нет предыдущего опыта работы с Kubernetes.

Поэтому, если вы слышите о внутренних платформах Kubernetes, вы также часто будете слышать об опыте разработчиков и связанных с ними инструментах, а не только о технических решениях в области инфраструктуры.

Что побуждает компании создавать такие платформы?

Создание внутренней платформы Kubernetes для инженеров может быть довольно сложной задачей. Например, Spotify потребовалось два года, чтобы сделать свою внутреннюю платформу общедоступной. Учитывая такие масштабные инженерные усилия и значительные затраты на облачные вычисления для запуска платформы для больших команд, возникает вопрос, почему компании предпринимают такие инвестиции. Очевидно, что для этого должна быть большая ценность или даже давление:

1. Приложения становятся слишком большими для локальных сред

Итак, давайте начнем изучать потенциальные причины внутренних платформ Kubernetes, обратившись к примеру сервиса для организации мероприятий Eventbrite. В интервью Реми Деволф, главный инженер команды DevTools в Eventbrite, объяснил причины, по которым они перешли от локальной разработки к облачной разработке на базе Kubernetes. Как и многие компании, Eventbrite также начинали с создания монолита. Со временем этот монолит становился все больше и больше, поэтому он был частично преобразован в микросервисы, а также добавлены новые сервисы в качестве микросервисов.

Поскольку все они выполняются в контейнерах (по крайней мере, для разработки), изначально это не является проблемой. Однако по мере дальнейшего развития программного обеспечения вы в конечном итоге достигнете точки, когда оно станет слишком большим для запуска на локальных компьютерах с помощью локальных решений Kubernetes, таких как Minikube или Docker Desktop.

На этом этапе вы можете начать разрабатывать обходные пути, например, просто запускать некоторые необходимые части приложения или запускать некоторые части локально, а другие удаленно, чтобы сохранить существующие локальные рабочие процессы разработки. Это может быть приемлемым подходом, но поскольку большинство компаний и систем продолжают расти, со временем становится все труднее продолжать локальное развитие. Это приведет к снижению производительности разработчиков, поскольку разработчики сами все больше и больше страдают от этих локальных настроек и тормозящих ноутбуков.

Для этого вам придется выбирать между инвестициями во внутреннюю платформу (и постоянными затратами на облачные ресурсы) и потраченным впустую временем на разработку. Здесь становится понятно, почему многие компании начинают с локальных решений Kubernetes, но все большее число сейчас достигает “переломного момента”, когда становится целесообразным переход на облачную среду Kubernetes.

Поэтому в Eventbrite также приняли решение перейти на облачную среду и создали внутренний инструмент под названием “yak”, который позволяет инженерам развертывать удаленные контейнеры и управлять ими. Таким образом, каждый инженер теперь имеет собственное пространство имен в общем кластере Kubernetes и может легко запускать в нем около 50 контейнеров.

Подобная эволюция произошла не только в Eventbrite, но и Datadog – платформа мониторинга и аналитики для крупномасштабных приложений, насчитывающая около 800 разработчиков, похоже, приняла аналогичное решение. Интересно, что это справедливо не только для крупных организаций, но и для компаний с меньшим числом инженеров, если они разрабатывают, как правило, ресурсоемкие или сложные приложения, такие как программное обеспечение AI/ML.

Во многих случаях приложения просто становятся слишком большими, чтобы в какой-то момент запускаться локально. Затем часто имеет смысл перейти от локальной среды разработки к среде разработки Kubernetes в облаке.

2. Сочетание автономии с целенаправленностью

В своем выступлении Джеймс Вен, старший исполнительный директор Spotify, прямо не рассказал о причинах, по которым они создают внутреннюю платформу Kubernetes. 

Тем не менее, есть ряд интересных аспектов, о которых упомянул Джеймс Вен: Spotify использует модель “Операции в командах”, которая представляет собой привлекательное сочетание полной автономии команд и полностью централизованных операций. Команды создают и управляют своими собственными сервисами независимо, но они могут полагаться на инструменты и платформы, предоставляемые централизованными операционными командами.

Я думаю, что это разумное решение, поскольку оно дает командам возможность работать автономно и настраивать Kubernetes по мере необходимости (они могут даже внедрять его в желаемом темпе), но им не нужно заботиться обо всем и управлять всем самостоятельно, а вместо этого они могут использовать общую платформу, которая решает все “стандартные” проблемы, которые, в противном случае, пришлось бы решать дополнительно.

С точки зрения администратора (команды DevTool) такое решение также привлекательно, поскольку администраторам не нужно взаимодействовать со всеми средами разработки по отдельности, что может стать огромной проблемой, например, если бы им пришлось создавать все среды вручную. Вместо этого администраторы могут сосредоточиться на предоставлении кластера, а также на поддержке разработчиков, использующих его, например, путем решения проблем, что также проще, поскольку можно совместно использовать среду разработки в облаке.

Благодаря внутренней платформе Kubernetes разработчики могут работать свободно и автономно, но в то же время им не нужно заботиться об операционных задачах, которые лучше решать централизованно. Команды администраторов выигрывают, поскольку они могут сосредоточиться на платформе и поддерживать других инженеров, но им не нужно заботиться о каждой отдельной среде.

3. Оптимизация рабочих процессов Kubernetes

Когда разработчики начинают работать с Kubernetes, это может быть довольно сложно. Использование внутренней платформы может упростить переход на Kubernetes, поскольку некоторые задачи могут быть упрощены, и разработчикам не нужно самим настраивать Kubernetes.

Spotify разработала подробное руководство и документацию, которые позволили новым разработчикам легко и с первого дня начать работу с внутренней платформой и, следовательно, с Kubernetes.

Рабочие среды всегда создаются одним и тем же стандартизированным способом, что было бы невозможно на локальных компьютерах из-за различного оборудования, операционных систем, системных конфигураций и т.д.. Это преимущество, которое также было реализовано Eventbrite: они смогли сократить “среднее время восстановления”, то есть время для восстановления до чистого состояния, которое необходимо, если разработчик застрял или допустил ошибку. Таким образом, внутренняя платформа Kubernetes также снижает риск экспериментов с Kubernetes, делая ее более привлекательной для разработчиков. Благодаря внутренней платформе они могут легко войти в контакт с Kubernetes, а затем шаг за шагом развивать свои навыки.

Здесь важную роль играют дополнительные инструменты Kubernetes. По-видимому, Spotify, Eventbrite и Datadog разработали какие-то инструменты, чтобы упростить рабочие процессы Kubernetes для инженеров. По крайней мере, “tugboat” от Spotify и “yak” от Eventbrite не только служат инструментами управления платформой, но и поддерживают процессы развертывания, что в целом улучшает взаимодействие разработчиков с Kubernetes. 

Внутренняя платформа Kubernetes, которая также включает в себя некоторые инструменты разработки, помогает стандартизировать рабочие процессы Kubernetes и, таким образом, позволяет работать с ней даже инженерам, не имеющим опыта работы с Kubernetes. Это облегчает процесс внедрения платформы и помогает разработчикам узнать больше о Kubernetes.

4. Экономия затрат

Еще одним фактором, стимулирующим внедрение внутренней платформы Kubernetes, может стать экономия средств. Как правило, совместное использование кластеров обходится дешевле, и пространства имен позволяют такое совместное использование кластеров. Экономия затрат основана на более эффективном автоматическом масштабировании вычислительных ресурсов и совместном использовании ресурсов и некоторых центральных компонентов Kubernetes (таких как серверы API). Таким образом, внутренняя платформа может привести к экономии средств по сравнению с другими облачными средами, такими как отдельные кластеры для разработчиков/ команд.

В дополнение к этой прямой экономии затрат, вы также можете сэкономить косвенные затраты за счет повышения производительности, когда разработчикам больше не нужно самим заботиться о своей среде Kubernetes и когда они могут использовать оптимизированные рабочие процессы. Таким образом, все ранее упомянутые причины для внутренних платформ могут в конечном итоге способствовать снижению стоимости Kubernetes.

Внутренние платформы Kubernetes - это очень экономичное решение для обеспечения инженеров средой Kubernetes, поскольку вычислительные ресурсы могут быть полностью использованы, а инженеры могут работать более продуктивно.

Важные факторы для обеспечения внутренней платформы Kubernetes

Теперь, возможно, вы захотите начать настройку своей собственной внутренней платформы Kubernetes. 

Однако, прежде чем вы начнете, есть несколько важных факторов, которые имеют решающее значение для успеха вашей платформы, которые я хочу выделить здесь:

Обеспечьте простоту и скорость разработки: даже если ваша платформа предназначена для внутреннего использования, у вас есть “клиенты”, и это разработчики в вашей организации. Чтобы гарантировать, что они примут и полюбят ваше решение, вам необходимо предоставить им простоту и скорость разработки. В лучшем случае это означает, что они могут делать все с помощью всего лишь одного инструмента, включая создание среды, разработку с ее помощью и, наконец, развертывание в ней. Вам также потребуется обширная документация для разработчиков, и эта документация должна быть написана с учетом простоты разработки (это может быть непросто для администраторов, которые ее пишут). В целом, важно, чтобы ваша платформа была “лучшим выбором” для разработчиков.

Оцените вовлеченность и общайтесь с пользователями: Очень важно понимать своих пользователей. По этой причине вам необходимо постоянно общаться с разработчиками, что часто происходит естественным образом, поскольку поставщики платформы поддерживают разработчиков в ее использовании. Кроме того, вам также следует принять меры по вовлечению, чтобы проверить, действительно ли используется ваша платформа, и выяснить, чего может не хватать.

Измерьте стоимость и производительность платформы: Вы также должны оценить, надежно ли работает ваша платформа, и убедиться, что вы можете быстро устранить проблемы. Наличие резервных копий и тщательное тестирование очень полезны для этого. Здесь вы должны иметь в виду, что, даже несмотря на то, что платформа используется “только” внутри компании, она становится критически важной для производительности всего вашего инженерного отдела, когда все работают с ней. Для поддержки и понимания бизнес-обоснования платформы также важно оценить стоимость до и после внедрения платформы.

Улучшите платформу и опыт разработки: Как вы можете видеть из предыдущих факторов, создание внутренней платформы - это непрерывная работа. Таким образом, вы всегда должны постоянно обновлять и улучшать как стабильность и производительность платформы, так и опыт работы с ней разработчиков (который также включает документацию).

Опыт разработки важнее технических деталей: Для разработчиков самое главное, чтобы они могли эффективно использовать платформу. Обычно их на самом деле не волнует, как именно работает базовая технология или где она работает. (Eventbrite использует EKS, начал с одного кластера, а теперь запускает несколько кластеров, в то время как Spotify полагается на множество кластеров на GKE, а Datadog использует только один самоуправляемый кластер). Таким образом, команда инженеров, предоставляющих платформу, должна быть очень ориентирована на пользователя. Это означает, что может быть целесообразно инвестировать даже в, казалось бы, незначительные улучшения, которые значительно облегчают жизнь разработчикам.

Покупка может быть дешевле, чем создание и построение: Как и в случае с большинством программ, создание кластера самостоятельно не всегда является лучшим решением. Вместо этого вы можете просто купить внутреннее решение для платформы Kubernetes, которое постоянно разрабатывается специальной командой, что может сделать его лучше и дешевле для многих случаев использования (особенно без особых потребностей). И даже если вы решите создать его самостоятельно, вам следует рассмотреть возможность интеграции уже существующих решений с открытым исходным кодом, например, kiosk может помочь вам реализовать многопользовательскую аренду, а инструменты разработки, такие как Skaffold или DevSpace, могут использоваться в качестве инструментов разработки и развертывания.

В заключение

Внутренние платформы Kubernetes стали более распространенными, даже если они имеют другие названия. С помощью такой платформы разработчики получают прямой доступ к среде Kubernetes в облаке.

Команды разработчиков, работающие с Kubernetes и желающие масштабировать свою технологию, должны ожидать, что достигнут точки, когда локальная разработка станет невозможной или, по крайней мере, неэффективной. Затем будет иметь смысл перейти в облачную среду, которая должна быть средой Kubernetes, если ваша производственная система также работает на Kubernetes.

Учитывая время и усилия, необходимые для создания такой платформы, они должны заранее предвидеть, что им может понадобиться внутренняя платформа разработки, и начать постоянно оценивать внедрение такой технологии, чтобы они могли найти правильный момент времени, когда инвестиции окупятся.

Как только решение о внутренней платформе Kubernetes принято, основное внимание следует уделить опыту разработчиков, чтобы обеспечить реальное внедрение и вовлечение, поскольку только тогда возможно реализовать все преимущества такой платформы.