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

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

 

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

Для этого мы полностью прекратили работу нашей команды по созданию облачной инфраструктуры и привлекли владельца продукта, который в партнерстве с нами полностью изменил наше представление об облаке. Затем мы переобучили персонал, ориентируясь на концепцию создания продукта, который разработчики приложений могли бы получать и использовать в режиме самообслуживания, а не просто создавать инфраструктуру. Конечный продукт, Atlas, позволяет команде разработчиков приложений начать работу с извлечения кода в конвейер непрерывной интеграции и непрерывного развертывания (CI/CD). Он сам себя обеспечивает.

-Мартин Кристофер, бывший старший вице-президент и директор по информационным технологиям CUNA Mutual Group

 

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

 

Гибкие и масштабируемые песочницы разработки

Раньше на запрос, создание и доступ к среде разработки у команды уходили недели, а иногда и месяцы. Теперь это уже не так. Среды разработки, или "песочницы", могут быть созданы за несколько минут или максимум часов с помощью автоматизации инфраструктуры как кода (IaC). Это быстро позволяет agile-подразделениям создавать свои собственные "песочницы" разработки (см. Рисунок 20.1). Каждая команда получает свою собственную "песочницу" в рамках более широкой облачной среды со стандартизированными инструментами, выделенной памятью и вычислительными возможностями, а также доступом к данным (либо тестовым данным, которые копируются автоматически, либо, в некоторых случаях, доступом к подмножеству производственных данных).

 

Пример платформы для разработчиков

Создайте командную атмосферу для под

Доступ к панели управления песочницы

 

Доступ

Все инструменты доступны через один верстак

 

Упрощение применения в строительстве

Облегчение выполнения общих действий из рабочего стола (без необходимости быть экспертом непосредственно в базовых инструментах)

 

Расширяемый

Со временем возможно добавление новых инструментов/функций

Портал для разработчиков

Agile Pod

 

 

 

 

 

 

 

 

(100% автоматизация)

 

1a

Создайте песочницу

 

2a

Открытие/доступ к данным

1b

Развертывание готовых шаблонов

 

2b

Инструменты для написания кода

1c

Настройте контроль исходных текстов

 

2c

Поиск существующего кода

1d

Настройка CI

 

2d

Эксперименты на дорожках

1e

Настройте инструменты для совместной работы

 

2e

Код сборки

1f

Автоматизируйте сканирование системы безопасности

 

2f

Опубликовать

 

 

 

2g

Монитор

 

 

 

2h

...

 

ПРИЛОЖЕНИЕ 20.1

 

Запуск сценариев IaC, способных создавать такие среды за секунды или минуты, может показаться некоторым инженерам несколько пугающим. А что, если в этих сценариях есть элементы, которые вы хотите, чтобы команды могли контролировать, например память, вычисления или даже приложения для предварительной загрузки? Разработка эффективной возможности самообслуживания в песочнице, способной удовлетворить множество потребностей, привела к появлению внутренних платформ разработчика (IDP) - легкого слоя пользовательского интерфейса (UI), который абстрагирует все сложности обеспечения инфраструктуры, безопасности и инструментов, но при этом предоставляет единый пользовательский интерфейс (UX) для настройки этих сред.

 

 

 

Пример из практики: Spotify решает проблему производительности разработчиков

 

По мере того как Spotify расширялась до множества agile-подразделений, а используемые компанией технологии становились все сложнее, выяснилось, что не все ее инженеры хорошо разбираются в этих технологиях, таких как Terraform для инфраструктуры, GCP/AWS/Azure CLI для различных облачных провайдеров, GitLab CI для контроля версий, Prometheus для мониторинга, Kubernetes и Docker для контейнеров и многие другие инструменты. Все усложнялось тем, что разным agile-подразделениям требовались разные инструменты для разработки внутренних API, внешних мобильных приложений и т. д.

 

Перейти на страницу:

Похожие книги