Независимый консультант в области разработки ПО Дэвид Истман приводит на портале The New Stack соображения, которые должны учитываться при выборе платформы облачной разработки.
Около 10 лет назад одна финансовая организация пыталась рационализировать свою систему разработки и создать то, что мы сегодня называем платформой. Они обратили внимание на то, насколько медленно происходила адаптация новых разработчиков и насколько непоследовательным было использование технологий. У них был архитектурный совет, но он был далек от повседневной разработки. Agile-методология показала им, что все должно быть автоматизировано, и они применили этот подход к своему конвейеру.
Они решили перейти к облачной среде разработки (CDE). У них было смутное понимание того, что если они соберут «лучшие в своем классе» инструменты, то это обеспечит хороший опыт адаптации новичков. Однако одна из проблем заключалась в том, чтобы понять, как синтезировать различный опыт разработки в рамках организации и как избежать потери опыта, накопленного в уникальной среде.
Имеет ли смысл жертвовать опытом ради стандартизации?
Эта заметка посвящена тому, чтобы понять, как ответ на этот вопрос отразится на вашей команде перед лицом всех новых возможностей CDE. И это требует честного анализа того, как работает ваша команда в вашей организации.
Аналогия CDE и WordPress
Чтобы изучить опыт работы с облаком, не обязательно обращаться к разработке. Как и многие другие онлайновые издания, The New Stack работает на платформе WordPress. В процессе написания данной статьи была большая вероятность того, что мне захочется представить фрагмент кода, включающий угловые скобки. Если я просто вставлю сниппет прямо как часть контента, то угловые скобки могут быть интерпретированы как инструкция или заменены HTML-сущностями, с которыми вы, вероятно, хорошо знакомы: «<» и «>». Так или иначе, я столкнусь с проблемой в своей роли пользователя платформы, с проблемой в системе. И дальше начнется отсчет времени.
- Сможет ли платформа или хотя бы Google направить меня к решению проблемы?
- Кто на самом деле разбирается в проблеме? Есть ли у человека, который разбирается, доступ к платформе?
- Сколько времени займет решение?
- Стоит ли мне просто избегать кода?
В данной ситуации ответ заключается в том, что отличная внутренняя команда распознает проблему и быстро предоставит доступ к соответствующему плагину WordPress. Время здесь важно, но ни в коем случае не критично. В конечном счете, главное, чтобы автор как можно точнее выразил свои мысли. Но если понадобится, я смогу исправить свой текст позже.
А теперь представьте, что ваша команда разработчиков ПО приближается к дедлайну, и тут возникает проблемный вопрос. Хватит ли у команды навыков, чтобы изолировать проблему? Что важнее: возможность самовыражения самобытных разработчиков или сохранение коллективного подхода? Честный ответ на эти вопросы помогает понять, как работать в онлайновых средах.
Вычисления по требованию с использованием CDE
Сегодня мы понимаем CDE как среду разработки по требованию, которая поставляется со всеми инструментами и предварительно настроенными зависимостями, необходимыми для создания и развертывания приложений — при условии, что существует шаблон для того типа приложений, который вы хотите создать. Обычно CDE работают в известном диапазоне производительности, т. е. вы имеете представление о том, какие ресурсы оперативной памяти и процессора могут задействовать их контейнеры. Как и для большинства облачных продуктов, доступ к CDE может осуществляться только через Интернет.
В документе Gitpod CDE описаны четыре основных качества CDE: равноправие, согласованность, расширяемость и доступность по требованию. Любой человек может начать сеанс работы со средой разработки и получить ту же среду, что и все остальные. Это больше, чем просто запустить контейнер и передать его; должен быть доступен полный конвейер для создания законченного приложения из кода. Подобно Google Docs, сессия доступна немедленно, 24 часа в сутки 7 дней в неделю. Совместная работа вполне естественна.
Самостоятельное размещение и стандартизация
У Daytona есть так называемая стандартизированная среда разработки (Standardized Development Environment, SDE), которая в значительной степени связана с самостоятельным размещением CDE и необходимостью контролировать эти усилия. У Coder.com несколько иной подход к саморазмещению.
Многие крупные организации создают собственные облачные среды, ссылаясь на необходимость контроля затрат, безопасности или масштабируемости. SDE признает необходимость создания шаблонов, позволяющих разработчикам использовать собственные инструменты или обращаться к содержащимся ресурсам с помощью ИИ; работать локально или онлайн.
Самостоятельный хостинг делает гибкость и контроль ближе к внутренним пользователям, но явно отдает предпочтение организациям, обладающим навыками подключения всего необходимого.
Некоторым разработчикам действительно нравится конфигурирование
Некоторым инженерам нравится работать с конфигурациями и инфраструктурным кодом. Если в вашей команде есть такие специалисты, то имеет смысл их использовать. И наоборот, многие разработчики не любят возиться со скриптами, которые не похожи на их повседневный код. Более того, возможно, они никогда не изучали, как работают такие системы, как Ansible или Chef, когда они были в моде, и могут придумывать спагеттиподобные решения для исправления платформ.
Вы внедряете стандартизацию или нет?
Самое важное преимущество «коробочной» среды (Software-as-a-Service, SaaS) — такой, как GitHub Codespaces, — заключается в том, что она значительно ускоряет процесс адаптации. Знания команды об этой среде не будут настолько широки, как в ситуации, когда каждый имеет немного разный опыт из-за того, как он ее устанавливал. Любой документ, посвященный началу работы, с гораздо большей вероятностью будет полностью точным для каждого пользователя. Но есть проблемы с предположением, что если я хочу получить такую среду, то я хочу ее по той же причине, что и последний человек, который хотел ее получить.
Такой менее ортодоксальный подход позволяет быстро ввести каждого пользователя в среду без необходимости точно знать, что он захочет делать, когда туда попадет. Хорошим примером может служить любознательный руководитель отдела маркетинга, который хочет не только использовать слайды, но и запустить текущую сборку. Предоставление возможности запуска сборки имеет смысл, но не в том случае, если для этого необходимо сначала настроить SSH-туннели. Выигрыш от обновления одного изображения логотипом потенциального клиента, чего нельзя сделать просто из веб-браузера, может быть очень большим. С другой стороны, человек, пришедший для быстрой оценки проекта, может захотеть запустить несколько сборок, сделанных в разное время, однако он столкнется с проблемой отсутствия полного контроля над привычными инструментами.
Кодирование для инноваций или производства?
Огромным преимуществом морских контейнеров (или интермодальных контейнеров) является то, что они имеют стандартный размер. Это произвело революцию в управлении затратами при перевозках, поскольку контейнерные порты можно строить по рабочим шаблонам. Вы можете задаться вопросом, почему для их создания потребовалось так много времени
Безопасность данных никогда не была такой проблемой, какой ее принято считать. Это скорее вопрос юридической географии — где можно хранить данные. Иначе говоря, данные, хранящиеся в вашем собственном внутреннем дата-центре, вряд ли будут в большей безопасности, чем в дата-центре компании, которая специально занимается вопросами безопасности. Однако термин «безопасность» может означать и безопасность в собственной «песочнице», и заботу о том, чтобы у разработчиков не было слишком много кода на ноутбуках. В большинстве случаев этот вопрос остается скорее политическим, чем буквальным.
Начните с того, чем занимается ваша команда
Итак, сперва необходимо убедиться в том, что вы знаете, чем действительно занимается ваша команда, а затем сделать небольшой задел на будущее. ИИ может быть полезен сейчас, но необходим в будущем. Вы можете точно знать, контейнер какого размера вам нужен сейчас, но ситуация может измениться. Возможно, вы придете к выводу, что единственное, чем должна совместно пользоваться ваша команда, — это git-репозиторий. Может быть, несколько контейнеров под Docker. Может быть, полная CDE, а может быть, что-то самохостируемое. В любом случае, начните с основ того, как будут разрешаться возникающие конфликты.
