О том, как организациям достичь бизнес-целей в области разработки ПО, когда их успеху угрожает множество подводных камней, на портале The New Stack рассуждает Джейсон Блумберг, основатель и управляющий директор аналитической фирмы Intellyx.

Нативные облачные вычисления (сloud native computing) стали доминировать в корпоративных ИТ каждой организации, которой требуется динамичная, гибкая инфраструктура в масштабе.

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

Практики и инструменты DevOps очень важны, но являются лишь отправной точкой. Для успешного применения DevOps в нативных облачных средах организации надеются на развертывание внутренних платформ разработчиков (IDP), следуя пока еще только зарождающимся передовым методам платформенного инжиниринга.

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

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

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

Ниже мы рассмотрим эти парадоксы.

Парадокс продуктивности разработчиков

Все согласны с тем, что высокая производительность разработчиков — это хорошо. Чем продуктивнее разработчики, тем больше ПО они могут предоставить за те деньги, которые им платят организации.

Однако проблема с производительностью разработчиков заключается в том, как ее измерить.

McKinsey предполагает, что такое измерение может улучшить результаты разработки ПО. В частности, компания утверждает, что когда разработчики сосредотачивают свою деятельность на сборке, кодировании и тестировании ПО, они работают более продуктивно. А другие «мягкие» виды деятельности, включая планирование, размышления, наставничество и проектирование архитектуры, плохо отражаются на продуктивности разработчиков.

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

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

Разработчики не любят, когда их измеряют такими суетными показателями, как количество запросов на доработку. Чтобы оптимизировать производительность, лучше всего позволить разработчикам самим решать, на какой деятельности им следует сосредоточиться.

Парадокс платформенного инжиниринга

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

Решение заключается в том, чтобы доверить платформенным командам создание IDP, включающей наилучший набор инструментов для решения поставленных задач. Цель такой платформы — предоставить разработчикам «золотой путь», по сути, рекомендуемый набор инструментов и процессов для выполнения работы.

Однако этот «золотой путь» может стать смирительной рубашкой. Если он слишком зарегламентирован, разработчики будут отклоняться от него, чтобы выполнить свою работу, что сводит на нет его цель.

Как и в случае с измерением своей производительности, разработчики хотят иметь возможность самостоятельно выбирать, как им делать ПО.

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

Например, инструментарий наблюдаемости — важный компонент любой IDP, но большинство инструментов наблюдаемости плохо подходят для нужд разработчиков нативных облачных приложений. В то же время такой инструмент наблюдаемости, как Chronosphere, работающий в Google Cloud, предоставит нативным облачным разработчикам всю необходимую информацию для выполнения их работы даже в сложных и динамичных средах.

Парадокс нативного облачного подхода

Нативно-облачное мышление привносит архитектурную направленность в работу разработчиков.

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

Производительность разработчиков зависит от такого двойного фокуса. От этого же зависит и успех платформенного инжиниринга.

Как же разрешить этот парадокс «лес против деревьев»? Ответ кроется в данных. Единственный способ сохранить должный фокус на общей картине при разработке микросервисов — это иметь представление обо всех соответствующих данных о производительности нативной облачной инфраструктуры.

Однако слишком много данных хуже, чем слишком мало, поэтому для достижения бизнес-целей нативных облачных вычислений необходимы нативно-облачные инструменты наблюдаемости в сочетании с нативно-облачным менталитетом, который привносит Google Cloud.

Найти баланс

Разрешение этих парадоксов зависит от достижения правильного баланса.

Слишком большое внимание к производительности разработчиков контрпродуктивно, а слишком малое — оставляет области для улучшения неизученными. Совет: прислушивайтесь к мнению своих разработчиков, чтобы найти правильный баланс.

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

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

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