CNCF спонсировал этот пост.
Современный облачный мир породил фундаментальное столкновение культур. С одной стороны, у вас есть разработчики, действующие как автогонщики, которые живут скоростью. Их цель — внедрять инновации, выпускать новый код и функции как можно быстрее, расширяя границы скорости.
С другой стороны, у вас есть инженеры платформ, авиадиспетчеры цифрового неба. Их единственная задача — поддерживать безопасность, стабильность и контроль, обеспечивая безопасность и соответствие каждой рабочей нагрузке.
Обе роли жизненно важны для бизнеса, но когда их цели могут столкнуться — автономия и контроль — это может создать глубокие и дорогостоящие разногласия. Речь идет не о том, что одна сторона ошибается; речь идет о двух важных функциях, работающих в противоположных целях, о разъединении, которое все замедляет.
Невысказанное бремя облачной разработки
Основное желание разработчика простое: выпустить код. Но эта, казалось бы, простая цель — это сложный путь, полный препятствий и множества точек трения. Для автогонщика это эквивалент внезапных шиканов и пит-стопов, которые постоянно мешают гонке за скоростью. Каждая из этих проблем задерживает доставку приложения и требует отдельного решения.
Во-первых, это трудности доступа. Представьте себе, что разработчику нужно протестировать свое новое приложение в кластере Kubernetes. Вместо того, чтобы просто его раскручивать, им приходится подавать заявку, ждать одобрения и ходить туда-сюда с командой платформы. Умножьте это на десятки разработчиков, и инженеры платформы внезапно погрузятся под гору повторяющихся запросов. Это превращает разработчиков в узкую систему обработки заявок, расстраивая обе стороны и отвлекая от более стратегической работы.
Далее, есть трудности с доставкой. Это происходит из-за задержек, вызванных ручной передачей документов, медленными утверждениями и непоследовательными процессами. Для новой функции может потребоваться билет на ресурсы, после чего следует ожидание проверки безопасности, а затем проверка кода. Поскольку эти этапы выполняются разными людьми, часто возникают несоответствия, и к тому времени, когда код наконец выходит, бизнес теряет драгоценное время. Это не незначительное замедление; Это конкурентный недостаток, когда гоночная машина застревает в боксах, в то время как другие находятся на трассе. Когда конкуренты выпускают релизы несколько раз в день, каждая задержка становится серьезным конкурентным недостатком.
Наконец, у нас есть когнитивное трение, вызванное сложностью самой среды. Разработчики являются экспертами в построении бизнес-логики и кодировании на таких языках, как Go или Java, но они часто не хотят становиться мастерами конфигураций YAML, диаграмм Helm или сложных сетевых технологий. Когда им приходится преодолевать эти сложности, их внимание переключается с создания стоимости на борьбу с инфраструктурой. Этот «водопровод» истощает их умственную энергию, замедляет роды и может привести к дорогостоящим ошибкам.
Две основные функции, работающие в перекрестных целях
Пока разработчики сосредоточены на финише, инженер платформы управляет всей экосистемой. Их работа заключается не только в создании и поддержании кластеров; речь идет о жонглировании постоянно растущим списком обязанностей. Как и авиадиспетчер, они должны внимательно следить за всем, чтобы обеспечить безопасность и предсказуемость.
Они являются сборщиками, которые создают кластеры и конвейеры CI/CD, обеспечивая надежность и производительность инфраструктуры. Они также являются хранителями, ответственными за безопасность и соответствие всей платформы, от понимания правил цифрового суверенитета до обеспечения соблюдения политик, предотвращающих риски.
Вдобавок ко всему, они являются финансовыми менеджерами, перед которыми стоит незавидная задача: оптимизировать затраты на облако и обеспечить эффективность и устойчивость всей системы.
И они являются стратегами, всегда следящими за новыми технологиями и развивающими платформу, чтобы поддерживать конкурентоспособность бизнеса.
Но каким бы квалифицированным ни был контролер, он не сможет справиться со всем самостоятельно. Реальность такова, что число разработчиков платформ значительно превосходит их численность. Типичное соотношение составляет примерно один инженер платформы на каждые 10 разработчиков. В крупных предприятиях это число может резко возрасти до одного на каждые 200. Этот дисбаланс создает неустойчивую ситуацию, когда каждый запрос разработчика — от простого билета доступа до сложной проблемы устранения неполадок — накапливается, оставляя инженеров платформ погребенными под потоком мелких запросов. У них практически не остается времени на стратегическую работу, которая так важна для бизнеса.
Золотой путь к сотрудничеству
Концепция «золотого пути» была представлена в отрасли как мощный способ расширить возможности разработчиков, не жертвуя при этом контролем. Для автогонщика это чистая, хорошо асфальтированная трасса без каких-либо внезапных препятствий. Для авиадиспетчера это стандартизированный план полета, который гарантирует безопасную посадку каждого самолета. Это четко определенный, стандартизированный и безопасный маршрут, проходящий через лабиринт разногласий, с которыми сталкиваются разработчики.
Но хотя идея и является хорошим началом, этого недостаточно. Видение платформы должно включать в себя полный набор возможностей, позволяющих по-настоящему преодолеть разрыв. Во-первых, должны быть доступны песочницы самообслуживания. Разработчикам нужна возможность развертывать легкие локальные среды и изолированные виртуальные кластеры по требованию. Это дает им свободу экспериментировать и даже безопасно ломать вещи, не рискуя при этом производством.
Кураторские базовые изображения также являются ключевым компонентом. Разработчикам не придется задаваться вопросом, содержит ли базовый образ, который они извлекают из Интернета, уязвимости. Вместо этого команды разработчиков платформы должны предлагать безопасный и постоянно поддерживаемый набор строительных блоков, позволяющий разработчикам начать с основы, имеющей практически нулевое количество уязвимостей.
Тщательно подобранный набор надежных компонентов, включая приложения с открытым исходным кодом, позволяет разработчикам начинать свои проекты с прочной основы и применять настоящий подход к безопасности «сдвиг влево».
Путь также должен включать встроенную систему безопасности. Безопасность не должна быть воротами в конце конвейера. Он должен быть встроен во весь рабочий процесс с самого начала. Благодаря автоматическому применению политик и мер безопасности разработчики могут действовать быстро и уверенно, а инженеры платформ могут быть спокойны, зная, что каждая рабочая нагрузка защищена.
Более того, автоматизированное и последовательное развертывание не подлежит обсуждению. Золотой путь должен использовать такие принципы, как GitOps, для обеспечения автоматической автоматизации и согласованности с нулевым дрейфом. Это исключает ручные действия, подверженные ошибкам, и освобождает разработчиков и команды платформы от утомительной работы по развертыванию.
Наконец, путь должен обеспечивать управляемую наблюдаемость. Вместо того, чтобы тонуть разработчиков в потоке информационных панелей, платформа должна предлагать четкие, взаимосвязанные данные и управляемое устранение неполадок. Это дает разработчикам возможность быстро устранять свои проблемы без необходимости становиться экспертами в базовой инфраструктуре.
Вывод: будущее — это общий путь
Суть этого нового подхода заключается в поиске баланса между скоростью и контролем, позволяющего гонщику уверенно ускоряться, а авиадиспетчеру надежно направлять его. Внедряя комплексный «золотой путь», мы можем выйти за рамки простого преодоления хрупкого разрыва и вместо этого создать единое видение, в котором смогут добиться успеха как разработчики, так и инженеры платформ. Это будущее, в котором их цели больше не противоречат друг другу, а идеально синхронизированы.
- Для разработчиков золотой путь обеспечивает автономию, скорость и свободу, необходимые для инноваций. Они могут сосредоточиться на создании ценности, а не на борьбе с инфраструктурой.
- Разработчикам платформ это обеспечивает контроль, спокойствие и время, необходимые для стратегического развития платформы. Они становятся помощниками, а не привратниками. Будущее облачной разработки не связано с победой одной стороны; речь идет о построении пути, на котором выигрывают все.
Создание этого общего пути требует фундаментального изменения в том, как организации думают об инструментах платформы. Чтобы бизнес был по-настоящему устойчивым и гибким, его платформы должны быть основаны на открытом исходном коде, обеспечивая свободу инноваций без привязки к поставщику.
Выбрав золотой путь с открытым исходным кодом, компании могут создать прочную и надежную основу, которая будет не только более быстрой и безопасной, но и по-настоящему устойчивой. Нам бы хотелось узнать о ваших подходах к преодолению различий в DevOps и историях обмена опытом на стенде SUSE (110) на KubeCon + CloudNativeCon North America.
KubeCon + CloudNativeCon North America 2025 пройдет 10–13 ноября в Атланте, штат Джорджия. Зарегистрируйтесь сейчас.
Фонд Cloud Native Computing Foundation (CNCF) размещает критически важные компоненты глобальной технологической инфраструктуры, включая Kubernetes, Prometheus и Envoy. CNCF — это нейтральная площадка для сотрудничества, объединяющая ведущих разработчиков отрасли, конечных пользователей и поставщиков. Узнайте больше Последние новости от CNCF TRENDING STORIES YOUTUBE.COM/THENEWSTACK Технологии развиваются быстро, не пропустите ни одной серии. Подпишитесь на наш канал YouTube, чтобы смотреть все наши подкасты, интервью, демонстрации и многое другое. ПОДПИСАТЬСЯ Группа, созданная в Sketch. Йерун ван Эрп — технологический евангелист в SUSE, специализирующийся на платформе наблюдения. Имея богатый опыт работы в области проектирования, архитектуры и управления продуктами, Йерун обладает более чем десятилетним опытом работы в сфере DevOps. До прихода в SUSE он играл… Подробнее от Йеруна ван Эрпа.
