Идея о том, что обычному разработчику приложения незачем видеть и понимать внутреннее устройство Kubernetes, звучала бы довольно спорно еще несколько лет назад, а сегодня превратилась в один из самых обсуждаемых и все более широко принимаемых принципов современной платформенной инженерии. Суть этого принципа не в том, чтобы скрыть от разработчика саму технологию из соображений секретности, а в том, чтобы дать ему более простую, соответствующую его реальным потребностям абстракцию, за которой уже скрыты все низкоуровневые детали оркестрации. Подход внутренней платформы разработчика воплощает эту идею вполне конкретно, отдельная платформенная команда строит удобный, дружелюбный интерфейс, через который разработчик описывает свое приложение в понятных ему терминах, а платформа уже сама транслирует это описание в корректную конфигурацию ресурсов Kubernetes со всеми необходимыми деталями. Механизм самообслуживания — это ключевой элемент подобного подхода, позволяющий разработчику самостоятельно, без постоянного участия платформенной команды в каждой рутинной операции, создавать новые окружения и разворачивать новые версии своего приложения, через безопасный интерфейс, гарантирующий соответствие принятым в компании стандартам безопасности и надежности. Концепция золотого пути дополняет эту картину, предлагая разработчику один явно правильный, заранее протестированный способ развернуть типовое приложение, вместо необходимости изобретать собственную конфигурацию с нуля. Практическое следствие подобного подхода состоит в том, что глубокое знание Kubernetes концентрируется в руках относительно небольшой, специализированной платформенной команды, вместо того чтобы размазываться тонким и часто неэффективным слоем по всем разработчикам компании, каждый из которых в итоге знает достаточно, чтобы быть опасным для стабильности production инфраструктуры, но недостаточно для по настоящему уверенной и безопасной самостоятельной эксплуатации. Мой практический совет компаниям, которые задумываются о подобном подходе сокрытия Kubernetes от обычных разработчиков. Помните, что кто-то в компании по-прежнему должен глубоко разбираться во всех деталях устройства оркестратора, именно эти люди и составляют вашу платформенную команду. Инвестируйте в качество и удобство абстракции, которую эта команда строит для остальных разработчиков, потому что именно качество этой абстракции определяет, действительно ли сокрытие сложности приносит реальную пользу, или лишь создает иллюзию простоты, за которой все равно приходится разбираться в исходной сложности при первой же нетипичной ситуации.