Штормовое предупреждение: как методологии разработки предопределили развитие «облака»

В прошлый раз мы говорили о том, как виртуализация завоевала мир серверных технологий. Но это — лишь половина «облачной» формулы.

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

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

Традиционная модель разработки программного обеспечения сформировалась в 70-х годах. Она предполагала подход к софту как к самодостаточному продукту. Здесь все походит на строительство дома: сперва закладывают фундамент, и лишь в конце занимаются отделкой.

Так и разработчики софта — двигались из точки «А» в точку «Б» по заранее согласованному плану. По мере завершения задач по программированию — передавали продукт в руки коллег, которые занимались тестированием, и так далее. Эта парадигма получила название «waterfall» (или Каскадная модель), и вплоть до 90-x ей пользовалось большое количество IT-компаний.

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

Подобная «монолитность» присуща и другим проектам — простым сайтам, не требующим трудоемкой поддержки, несложным программным продуктам. Но серьезные бизнес-инструменты обязаны быть гибкими, чтобы долго и верно прослужить заказчику. Поэтому со временем недостатки методологии waterfall стали все более и более очевидными.

Людям требовалась свобода для маневра и корректировки проектов по мере работы над ними. Это было жизненно необходимо: требования клиентов регулярно менялись вместе с новыми технологиями и задачами бизнесов. Появился запрос на гибкость разработки и обновляемость ПО.

С другой стороны, на фундаменте пятиэтажки нельзя построить небоскрёб — резкая смена планов при использовании каскадной модели могла полностью обнулить прогресс в разработке продуктов.

В девяностые начались активные поиски альтернативных подходов к разработке ПО. Появились такие парадигмы, как «Scrum» и «Extreme Programming». В глазах их адептов идеальный «lifecycle» программного проекта был не линейным. Он предполагал постоянные изменения и постоянное тестирование. Такой процесс оперировал на кардинально другом масштабе — каждая итерация приобретала важность конечного релиза.

На первых порах последователей у этих методологий было немного. В конце концов, девяностые были временем быстрого роста IT-индустрии. Руководствуясь принципом «if it ain't broke, don’t fix it», гиганты «бума доткомов» не видели необходимости в фундаментальных изменениях. Только после того, как пузырь лопнул, компании стали избавляться от пережитков прошлого и строить новую культуру разработки.

Лучше всего эту культуру отражает написанный в 2001 году «манифест разработки Agile». Вы наверняка слышали этот термин — он стал общим описанием для различных итеративных методологий. В Agile-манифесте лаконично рассказано о приоритетах новой школы разработки. Среди них — внутренние коммуникации, сотрудничество с клиентом и постоянная готовность к изменениям. Именно эта методология стала толчком больших перемен, знаком того, что индустрия для них созрела.

Переход на Agile-методологии вскоре затронул и специалистов, занимавшихся серверным администрированием. Процесс деплоймента, намного более частый благодаря итеративной разработке, стал источником производственных проблем. «Усложнил ситуацию» и успех первого коммерческого гипервизора VMware Server — виртуализация «превратила сервера в код», абстрагировав их от железа, а граница между обязанностями админов и разработчиков оказалась размыта.

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

Одной из первых компаний, которые занялись кооперацией разработчиков и админов, был один из пионеров Web 2.0, фотохостинг Flickr. Десять лет назад в компании начали нанимать «разработчиков, которые думают как админы» и «админов, которые думают как разработчики», и за год смогли разогнаться фактически до серийного развертывания ПО.

После того, как компания представила свой опыт на конференции O’Reilly Velocity 2009, их идеями вдохновились и другие. И первое событие, посвящённое исключительно этой теме, прошло в Бельгии всего несколько месяцев спустя. Именно организаторы этой конференции придумали ныне привычный нам термин DevOps (Developers + Operations). В последующие годы их философия нашла широкую поддержу, стала настоящей методологией и, наконец, отдельной профессией в лице DevOps-инженеров.

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

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

Чтобы избежать проблем при единовременном развертывании большого количества нового кода, приверженцы Agile-методологий тестируют его на совместимость множество раз в день, каждый раз добавляя что-то новое (CI, Continuous Integration). Многие компании не останавливаются на этом и частично автоматизируют само развертывание (CD, Continuous Delivery).

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

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

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

Предыдущие материалы по теме на vc:

• «Откуда ты, облако: концептуальная ретроспектива»
• «Что такое облачные контейнеры и зачем они нужны»

Дополнительное чтение в блоге MCS:

• «Облачные профессии: какие они бывают»
• «Файлы в облако — админу счастье»