Как убедить владельца бизнеса или своего руководителя использовать Docker

Разработчики (как и системные администраторы или DevOps-инженеры) прекрасно осведомлены о плюсах в использовании Docker, но как изложить преимущества данной технологии в контексте бизнеса?

Давайте разберемся!

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

В итоге получится базовый набор задач, для решения которых прекрасно подходит Docker — далее, в зависимости от того насколько технически подкован руководитель (и насколько эти решения вам близки), вы можете приводить их в качестве аргументов в пользу Docker’а.

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

Управление несколькими проектами в своей среде разработки

Проблема: Сложно управлять несколькими проектами на локальном окружении разработчика — такие инструменты, как composer, npm, phpbrew, virtualenv, [ваш_инструмент] сбивают с толку, и вызывают много проблем, например, при обновлении версии пакета или зависимости в разных проектах.

Примечание. Еще это можно назвать “проблема с настройкой среды разработки”.

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

Бизнес аргументация: Для добавления новой функции нам необходимо обновить версию ПО (зависимость, компонент приложения — нужное подчеркнуть), что замедлит разработку продукта в течение нескольких дней (часов, минут). Кроме этого нужно выделить время на общение с отделом QA и на обсуждения плана обновления на testing|staging|release|production-серверах с DevOps-инженерами (сисадминами). В лучшем случае это может занять несколько недель.

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

Адаптация новых разработчиков

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

Примечание. Данную проблему также можно идентифицировать “У меня все работает!”.

Решение: После того, как вы установите Docker, вы будете поражены простотой развертывания проекта в локальной “песочнице”. Новым разработчикам достаточно запустить одну-две команды (ну, может, еще добавить свой ssh-ключ в систему контроля версий) и расслабиться — все будет сделано в лучшем виде.

Бизнес аргументация: Мы проанализировали и выяснили, что новому разработчику требуется в среднем 10 часов для запуска сайта на своем компьютере (развертывания локального окружения разработки). Кроме этого, еще требуется 3 часа времени Боба и Алисы, для устранения проблем, которые не описаны в наших документах по установке и их документирования. Такая ситуация повторяется каждый раз, ведь каждый раз установка производится на новую версию ОС (конфигурацию железа) и мы не можем создать универсальную документацию.

Я уверен, что мы способны сократить этот процесс до 30 минут. Да, это звучит слишком хорошо, чтобы быть истиной, но здесь нет подвоха. Можете ли вы дать нам “зеленый свет” и выделить некоторое время на дополнительное исследование этой технологии? Это Docker, хорошо финансируемая компания, которая активно развивается с 2008 года.

Конечно же, для начала мы опробуем его в разработке и тестировании, так что это никак не затронет живой сайт (production-сервера). Кроме того, мы будем готовы запустить сайт (локальное окружение разработки) на компьютере нового разработчика к его появлению с помощью всего пары команд!

Неожиданные проблемы на разных окружениях разработки testing/staging/release/production

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

Примечание. Кратко это звучит как “проблема развертывания”.

Решение: Поскольку Docker позволяет легко создавать и распространять приложения с помощью docker-образов, можно разворачивать код и необходимые пакеты/зависимости в разных окружениях разработки с помощью контейнеров. Это значит, что код (и его зависимости), который запускается в testing|staging|release|production один и тот же. Теперь можно не обращать внимание на особенности серверной архитектуры.

Абсолютно все равно, где писался код — под MacOS, Windows или Linux. Он будет работать одинаково на любой ОС (даже в другом дистрибутиве Linux на вашем сервере).

Бизнес аргументация: Мы динамично развиваемся, но наша служба поддержки “завалена” обращениями пользователей. Кроме того, в твиттере увеличилось количество негативных отзывов о нашем продукте и надежностью нашего сайта. Если мы ничего не предпримем, то потеряем лояльность пользователей что неизменно отразится на доходах бизнеса.

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

Давайте попробуем двигаться в этом направлении? Начнем с малого и посмотрим, что у нас получится.

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