Между DevOps и открытым исходным кодом нет прямой связи. Тем не менее методологии DevOps не существовало бы без инноваций, внедрению которых способствовало развитие открытого программного обеспечения.
Что общего у технологии разработки и эксплуатации приложений DevOps с открытым программным обеспечением? Может показаться, что не так уж много. Компании, использующие DevOps, часто работают с закрытым кодом, а методология DevOps разрабатывалась независимо от движения открытого кода.
Строго говоря, между DevOps и открытым исходным кодом нет никакой прямой связи. Однако на концептуальном уровне у них много общего. В самом деле, методологии DevOps не существовало бы без культурных инноваций, внедрению которых способствовало движение открытого программного обеспечения.
Чем же методология DevOps обязана открытому исходному коду?
Прежде всего, хочу подчеркнуть очевидное: DevOps ни полностью, ни частично не дублирует экосистему программного обеспечения с открытым исходным кодом. Без сомнения, некоторые открытые технологии необходимы для многих современных групп, использующих DevOps.
Мир DevOps был бы совсем другим без открытых инструментов, таких как Jenkins, Kubernetes, Chef, и контейнеров DOCKER. В то же время, однако, существует ряд важных технологий DevOps, которые не относятся к числу открытых.
Например, бессерверные вычислительные службы от основных «облачных» поставщиков являются закрытыми, как и почти все в общедоступном «облаке». Различные платформы автоматизации DevOps и средства обеспечения безопасности микрослужб тоже не являются открытыми, как и многое другое.
Чтобы не выглядеть беспристрастным, я не буду называть имена, но поставщиков закрытого программного обеспечения, ориентированных на рынок DevOps, определить несложно. Вывод: открытый исходный код не является необходимым атрибутом DevOps. Вполне возможно построить успешную платформу или службу DevOps без использования открытого программного обеспечения.
DevOps и открытый исходный код: концептуальная связь
Однако на более глубоком уровне каждый, кто успешно работает с DevOps, во многом обязан тем принципам, подходам и процессам, начало которым было положено благодаря разработке программ с открытым исходным кодом. Все организации, использующие DevOps, следуют перечисленным ниже принципам, сформировавшимся в значительной мере в рамках движения открытого исходного кода.
Быстрый выпуск программного обеспечения
Маловероятно, чтобы непрерывное развертывание программного обеспечения изобрели программисты открытого кода. Но именно они внедрили идею, согласно которой программное обеспечение должно выпускаться своевременно и часто.
Чтобы оценить новаторскую роль сообщества разработчиков программного обеспечения с открытым исходным кодом, вернемся мысленно в начало 1990-х, когда понятия открытого программного обеспечения еще не существовало, а бытовал термин «бесплатное программное обеспечение». В то время пользователи привыкли годами ждать появления новых версий операционных систем и приложений. Когда же эти версии наконец появлялись, обычно приходилось ждать присылки диска по почте, потому что лишь малое число пакетов программного обеспечения предоставлялось через общедоступную сеть.
Результатом такого медленного темпа разработки и распространения программного обеспечения стало то, что программисты в то время действовали в соответствии с известным принципом, предложенным Фредом Бруксом в книге «Мифический человеко-месяц». По словам Брукса, хорошее программное обеспечение — это как изысканное блюдо. Его создание требует времени. Лучше потратить много времени на работу над проектом и попытаться разобраться во всех ошибках до очередного релиза, чем снабжать пользователей быстрыми обновлениями.
Затем, в 1991 году, на сцену вышел проект ядра Linux. Линус Торвальдс, тогдашний 20-летний разработчик Linux, мыслил совершенно иначе, чем большинство программистов того времени. Он выпустил в свободное плавание свой исходный код, прошедший лишь минимальную проверку, рассчитывая на помощь пользователей в исправлении многочисленных ошибок, с которыми они неизбежно должны были столкнуться.
Сегодня об этом забыли, но в свое время это стало важнейшим событием. Редакторы Linux Journal тогда писали, что количество и частота выпуска новых версий Linux, драйверов и утилит «поражает всех, кто знаком с традиционными циклами разработки UNIX».
Концепция выпуска программного обеспечения часто и небольшими фрагментами в противоположность долгому ожиданию выхода основных версий платформ дали Linux необходимый импульс к опережению других Unix-подобных операционных систем, а также Microsoft. Кроме того, это послужило прецедентом для того, что мы сегодня называем непрерывным развертыванием.
Оперативность и гибкость
Способность создавать гибкие наборы инструментов и при необходимости переключаться с одного инструмента на другой — важное свойство DevOps, обеспечивающее динамичную разработку ПО. Развертывание программного обеспечения гораздо менее эффективно, если вы жестко привязаны к конкретным средствам разработки и платформам.
Сегодня инженеры, использующие DevOps, как должное принимают то, что большинство инструментов взаимозаменяемы, стандарты и протоколы открыты, а привязка к поставщикам ограничена. Если бы не движение открытого кода, этого могло и не быть. Одним из великих достижений сообщества разработчиков программного обеспечения с открытым исходным кодом стало продвижение идеи о том, что жесткая привязка к платформе подавляет творчество и что на основе принципа открытости можно построить лучший мир.
Желание уйти от жесткой привязки было одной из причин завоевания открытыми платформами, такими как Linux и веб-сервер Apache, столь высокой популярности в 1990-х, когда поставщики закрытого программного обеспечения строили свои бизнес-стратегии на основе привязки клиентов. Оно также стимулировало обратную разработку платформ, таких как протокол Microsoft SMB, с помощью открытых проектов вроде Samba.
Еще большим благом, чем собственно открытый исходный код, является то, что движение открытого кода способствовало широкому внедрению открытых стандартов. Сегодня даже компании — разработчики программного обеспечения, чей бизнес строго закрыт, вынуждены уважать открытые стандарты и протоколы, потому что в противном случае рынок не примет их всерьез. С точки зрения DevOps это хорошо.
«Чем больше людей изучают код, тем проще найти ошибки»
Одним из девизов сообщества разработчиков программного обеспечения с открытым исходным кодом в 90-х годах стало то, что Эрик Рэймонд назвал законом Линуса, согласно которому (в формулировке Рэймонда), «чем больше глаз, тем быстрее ошибки всплывут на поверхность». Рэймонд имел в виду, что чем больше людей изучают код, тем проще выявить все его уязвимые места.
Такое видение предполагает постоянное и непрерывное сотрудничество, которое сегодня является центральным принципом DevOps. Концепция DevOps относит к числу приоритетных задач удаление «барьеров», ограничивающих прозрачность процесса развертывания программного обеспечения и препятствующих свободному взаимодействию инженеров разных специальностей.
В основе этого лежит идея о том, что максимальная прозрачность максимально увеличивает шансы найти и исправить ошибки на начальном этапе развертывания, когда это сделать легче всего.
Речь не идет о предоставлении открытого доступа к исходному коду всем желающим, а не только программистам. Но идея, согласно которой специалист по информационно-техническому обслуживанию (IT Ops), которому предоставлена возможность тесно сотрудничать с разработчиками, способен выявить проблему кода, не очевидную для разработчика, имеет много общего с законом Линуса.
Работа над ошибками
Если, подобно большинству групп, использующих DevOps, вы отдаете предпочтение частым выпускам программного обеспечения в противовес затяжному кропотливому анализу кода, предшествующего его выпуску, то вы должны принять тот факт, что будете периодически выпускать код, содержащий ошибки. Этот риск является неотъемлемой частью непрерывного развертывания.
Вместо того чтобы жить с этим риском, инженеры DevOps реагируют на неудачи, следуя концепции работы над ошибками. Иными словами, когда в коде возникает проблема, они стремятся извлечь урок и быстро ее устранить, чтобы создать лучший продукт.
В определенном смысле, в рамках концепции DevOps и непрерывного развертывания, всякая неудача — благо, так как она помогает организациям быстрее внедрять инновации.
Работа над ошибками — концепция, популяризации которой способствовали разработчики открытого программного обеспечения. Быстрые циклы выпуска версий платформ, таких как Linux, несли в себе риск возникновения ошибок выше среднего, но это был негативный побочный эффект быстрого внедрения инноваций, заключенных в подобных проектах.
В первое время в некоторых открытых проектах выявлялись серьезные проблемы, которые в конечном итоге были решены благодаря готовности программистов принять их и извлечь из них уроки.
Именно из-за принятия неудач, в частности, Mozilla Firefox смог превратиться в один из наиболее широко используемых веб-браузеров, несмотря на то что в 1999 году, вскоре после рождения открытого проекта Mozilla, его ведущий разработчик заявил, что это «полный провал».Таким образом, DevOps и открытое программное обеспечение — разные идеологии и движения в сфере ИТ. Однако у них есть общие ключевые концептуальные особенности.
Если бы разработчики программного обеспечения с открытым исходным кодом не продвигали новаторские идеи, такие как быстрые выпуски версий программного обеспечения, противостояние жесткой привязке к поставщикам и принятие неудач как блага на пути внедрения инноваций, методологии DevOps могло бы и не существовать.
Источник: журнал «Windows IT Pro/RE»