Переход на DevOps: различия между корпоративным бизнесом и стартапами
Чтобы быть конкурентоспособными, как динамичные стартапы так и устоявшиеся корпорации со сложной структурой должны применять наиболее эффективные методы оказания услуг заказчикам. В наши дни, методология DevOps позволяет оптимально распределить ресурсы и предоставить потребителю безупречное качество услуг с непрерывным потоком улучшений.
Хотите узнать разницу в переходе на DevOps между стартапами и корпоративным бизнесом?
В основном, сегодняшние стартапы принимают DevOps модель разработки и обслуживания ПО по умолчанию, поскольку она помогает им достигать успеха, предоставляя услуги через нативные облачные приложения. В случае с корпоративным бизнесом всё не так просто, ведь там присутствует устоявшаяся структура с четко определенными ролями и ответственностями специалистов, что позволяет получать заданный результат в установленный срок. Однако, главным недостатком таких систем является сопротивление изменениям, как структурным так и поведенческим. “Если это работает, не меняй это” — вот любимый девиз корпоративного бизнеса, который был релевантен на протяжении десятилетий. Но это больше не так…
Ежегодных или полугодовых обновлений программ больше недостаточно. Если потребитель запрашивает какой-либо функционал и не получает его в течение месяца — он с легкостью может сменить поставщика услуги, у которого есть данный функционал. Таким образом, корпоративному бизнесу придется обеспечить более высокий темп разработки продуктов и более оперативное реагирование на отзывы пользователей, если компании хотят оставаться конкурентными. Но как это сделать? Как реформировать структуру, которая предпочитает стабильность, а не перемены?
Как помочь корпоративному бизнесу освоить DevOps?
Существуют три основных направления приложения усилий, которые помогут корпоративным специалистам быстрее освоить работу по методологии DevOps:
Основание Центров Передового Опыта. Центр Передового Опыта (ЦПО) — это группа профессионалов, работающая отдельно от традиционных задач отделов разработки (Dev), текущих операций (Ops) и контроля качества (QA). В состав такого центра требуется включить как сотрудников данных отделов, так и приглашенных специалистов, умеющих работать по модели DevOps. Это позволит корпоративным специалистам довольно быстро и легко отойти от установившихся практик разделения ролей в процессе разработки и освоить модель работы DevOps, где все члены команды обладают хорошим пониманием и навыками работы с утилитами на всех стадиях процесса разработки ПО, и могут работать взаимозаменяемо.
Начиная с оценки идеи, и на протяжении всего процесса написания кода, тестирования и сборки приложения, публикации продукта, его обслуживания и обновления, сбора и применения отзывов клиентов, до момента прекращения поддержки данного ПО — все это время ключевой идеей DevOps является парадигма “ты построил - ты обслуживаешь”. Это значит, что любой DevOps инженер может и писать код, и тестировать приложение, и запускать инфраструктуру, и решать вопросы от потребителей продукта, являясь универсальным специалистом. После участия в работе ЦПО и получения опыта работы по модели DevOps и связанных с этим преимуществ, сотрудники корпоративного бизнеса становятся сторонниками и помощниками в дальнейшем продвижении данной методологии в их департаментах и по всей корпорации.
Разделение структуры ПО на микросервисы. Когда вместо сложных продуктов, требующих усилий больших команд для разработки и дальнейшего обслуживания, вы применяете набор небольших микросервисов, обменивающихся данными через API, скорость разработки значительно увеличивается, при этом вы получаете чистый и понятный код высокого качества.
Когда сравнительно небольшая команда DevOps специалистов отвечает за отдельный микросервис, в процессе разработки ПО становится гораздо меньше проблем. Любой человек в составе команды может приложить усилия для решения текущих задач, будь то написание кода, тестирование новой версии приложения, проведение апгрейда или решение запросов от потребителей. Это идет вразрез с привычной практикой работы ИТ-отделов, где избыточная нагрузка на один из отделов может стать причиной остановки работы всех зависящих от этого отделов.
Построение инфраструктуры в виде кода. Вместо того, чтобы нагромождать раздельные инструменты, обязанности и технологии в отделах Dev и Ops, работа по модели DevOps помогает комбинировать все эти процессы. Это значит, что разработчики не считают свою работу завершенной, после того как новая версия кода успешно проходит тесты и идет на сервера в эксплуатацию конечными пользователями. Ops инженеры, с другой стороны, не настраивают сервера по отдельности, вместо этого работая со всей инфраструктурой как единым целым. Все процессы, включающие работу с инфраструктурой могут и должны быть автоматизированы, используя инструменты типа Puppet, Chef, Kubernetes и прочих для управления конфигурациями и быстрого размещения необходимых ресурсов.
Когда все процессы автоматизированы, каждый человек в составе команды DevOps может писать код, запускать тесты, собирать новую версию приложения и отправлять ее в эксплуатацию с помощью всего нескольких строчек кода или нажатием нескольких кнопок в соответствующем инструменте DevOps.
Выводы
Начало процесса использования DevOps довольно затруднительно как для стартапов, так и для крупного бизнеса. Однако, этот выбор несомненно окупается сторицей. Для стартапа предпочтительнее сразу вести работу по модели DevOps, чтобы избежать накопления отложенного технического долга и больших трудозатрат, когда необходимость перехода на автоматическое тестирование и применение обновлений для приложения станет очевидной.
Для крупного бизнеса этот выбор является еще более простым. Переход на DevOps модель работы является залогом их выживания в конкурентной борьбе, а проигрывать не хочет никто. Так что придется или эволюционировать, или плестись в хвосте толпы конкурентов.
