Технологий стало слишком много — и это мешает разработчикам

Сложнее — не значит лучше, а много — не значит хорошо. Так, уверены многие эксперты IT-индустрии, растущая сложность современных систем «медленно убивает» разработчиков, а причина тому — бурное развитие и разнообразие технологий. Как вернуть контроль над ситуацией и не потерять лучшее, что технологии могут предложить, пытались разобраться специалисты портала InfoWorld. 

За рост возможностей приходится платить

«Сложность убивает. Она высасывает жизнь из разработчиков, затрудняет планирование продуктов, их создание и тестирование, бросает вызовы в сфере безопасности и приводит конечных пользователей и администраторов к разочарованию», — написал в 2005 году создатель Lotus Notes и ветеран Microsoft Рэй Оззи. 

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

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

С другой стороны, сложные технологии еще никогда не были так просты в использовании: часто все доступно с помощью единого API — от базовых библиотек и фреймворков до возможностей распознавания изображений или даже целых стеков платежей. Казалось бы, останется только собрать и построить бизнес-логику поверх — и готово, но действительно ли все так просто? 

«Никогда еще не было так трудно быть разработчиком, как сегодня. За рост уровня возможностей, которые позволяют делать больше за счет использования высокоуровневых фреймворков для создания приложений и машинного обучения, приходится платить. Разработчикам сложно охватить разнообразие технологий и уследить за темпом их развития», — сказал консультант и бывший директор по стратегии корпоративных технологий в компании Walt Disney Найджел Симпсон. 

Сущностная и случайная сложность

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

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

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

Минусы разнообразия технологий

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

«Раньше было намного проще, но не потому, что мы совершили ошибку как индустрия, а потому, что спрос на системы вырос настолько, что мы должны поставлять их быстрее», — отмечает основатель стартапа Humanitec Каспар фон Грюнберг.

На инфографике Cloud Native Computing Foundation (CNCF) представлена почти тысяча уникальных сервисов, составляющих экосистему облачных вычислений, многие из которых бесплатны и имеют открытый исходный код. Кроме того, каждый из трех крупнейших облачных провайдеров — Amazon Web Services, Microsoft Azure и Google Cloud — предлагает клиентам около 200 уникальных сервисов для вычислений, хранения данных, баз данных, аналитики, сетей, мобильных устройств, инструментов для разработчиков, инструментов управления, IoT, безопасности и корпоративных приложений.

Аналитик RedMonk Стивен О’ Грейди в 2020 году написал, что процесс разработки приложений слишком фрагментирован. Времена, когда каждая архитектура компании была трехуровневой, каждая база данных реляционной, а каждое бизнес-приложение было написано на Java и развернуто на сервере приложений, прошли. Определяющая характеристика современной инфраструктуры — то, что у нее нет определяющей характеристики, она разнообразна до предела, уверен специалист.

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

«Золотые пути»

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

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

Теперь в Spotify говорят об идее «золотых путей», с помощью которых упрощается процесс разработки и отправки продукта в продакшен. Их суть не в том, чтобы ограничить или сдерживать айтишников и устанавливать стандарты ради стандартов. Идея в том, что при наличии фиксированных «золотых путей» командам не нужно изобретать колесо, им приходится принимать меньше решений, и они могут направить силы на более высокие цели. Проблема только в том, что разработчики все-таки любят изобретать колесо заново.

Основанная в 1987 году IT-компания Amadeus, поставщик решений для индустрии туризма и перевозок, пережила несколько технологических изменений. Она создавала свои первые приложения на мейнфрейме, затем перешла к разработке на базе открытой платформы Linux в начале 2000-х, а последнее время склоняется к контейнерным приложениям, оркестрированным с помощью Kubernetes. 

По словам руководителя отдела инфраструктуры и облачных вычислений Amadeus Эдуарда Хубина, новые технологии приносят больше сложностей для безопасности и стабильности. Рост data-driven-приложений — это совершенно другой уровень сложности, новый способ написания приложений и построения контуров обратной связи. Все это новые технологии, и каждая усложняет проект.

В Amadeus стремятся снизить сложность там, где это возможно, с помощью внутренней команды, разрабатывающей нужные решения, либо оплачивая управляемые услуги. Например, раньше Amadeus управляла собственными экземплярами MongoDB, но теперь использует MongoDB Atlas — платформу, которая автоматически настраивает и размещает базу данных. Единственное, что требуется от пользователя — заполнить БД содержимым. Это снимает нагрузку по управлению базами NoSQL и позволяет сфокусироваться на приложениях. Компания придерживается аналогичного подхода при работе с Kubernetes.

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

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

Заключение

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

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