Да, сейчас DevOps очень страдает от проблемы идентичности. Очень часто этот термин используют для обозначения принципиально разных вещей. При этом многие фокусируются на инструментах, а не на принципах и результатах работы. Например, можно увидеть команды DevOps, которые запускают сервера с помощью инструментов автоматизации, но очень редко встретишь разработчиков, которые принимают участие в операционных аспектах кода, или представителей других ролей, которые сотрудничают с инженерами DevOps, помогая улучшить ПО.Еще одна проблема — это попытка проведения ребрендинга существующего процесса в DevOps. Часто встречаются ситуации, когда члены команды девопс по сути просто являются переименованными системными администраторами. Одна из практик реализации методологии заключается в интеграции команд эксплуатации в команды разработки в надежде на увеличение скорости работы путем тесного взаимодействия. К сожалению, в современных реалиях эта стратегия плохо работает, т.к. DevOps сам по себе, это нечто большее, чем попытка встроить девопс-инженеров в команду разработки. Всё-таки здесь, в первую очередь, должно уделяться внимание улучшению качества жизненного цикла разработки ПО, непрерывной доставке и релизах. Если сфокусироваться именно на этих целях, появляется истинная ценность DevOps.
Думаю, что тем, у кого нет собственной внутренней (in-house) разработки, где всё используемое в компании программное обеспечение является полностью коробочным. В таком случае просто нет необходимости применения DevOps. Также сложности могут возникнуть в организациях, где разработка вынесена на аутсорс, т.е. выполняется сторонней компанией или средствами отдельных разработчиков. Здесь полноценно включить их в общий поток может быть затруднительно из-за совершенно различной мотивации участников. Сотрудники компании, находящиеся в штате, как правило более заинтересованы в удовлетворении потребностей основного бизнеса, в процветании компании, в собственном карьерном росте, а значит — в быстро полученном и качественном конечном результате работы всех участников команды. Следующие ограничение применения DevOps — это четко устоявшиеся и сложившиеся процессы, подкрепленные организационной и корпоративной культурой. Некоторые большие компании трезво оценивают свои способности меняться как ограниченные, в то время как переход к DevOps требует большой перестройки не только IT, но и принципов работы других бизнес-подразделений. Можно вспомнить отличия культуры традиционных больших корпораций от культуры стартапов, чтобы оценить масштаб необходимых преобразований. Также необходимо отметить, что для многих организаций полное изменение имеющейся практики работы является принципиально невозможным, несмотря на потенциальные успехи, которые могут произойти в отдельных бизнес-подразделениях с переходом к DevOps.
На самом деле их очень трудно описать очень коротко. Можно выделить основные — IaC (инфраструктура как код, от англ. Infrastructure-as-Code), непрерывная поставка (CI/CD), Observability (мониторинг, сбор логов и трейсинг), слабосвязанная архитектура. Главное — это подход, на котором базируется все вышеперечисленное. По сути, автоматизируется всё, что только возможно. Ведь одним из важных моментов DevOps является полный уровень контроля, который требует полной автоматизации всех операций, в особенности, это касается создания окружений, конфигурации всех элементов инфраструктуры, развертывания и мониторинга.
Инфраструктура как код решает множество проблем. Одна из основных — это упрощение управления конфигурацией, которое гарантирует, что инфраструктура будет каждый раз настраиваться одинаково. То есть, IaC не только позволяет документировать инфраструктуру в виде кода, но и является важной частью контроля версий в любой современной разработки ПО. При правильном применении все это поможет выявить проблемы еще до применения изменений в продуктивной среде.Развертывание инфраструктуры в виде кода означает, что её можно не только развернуть разделив на отдельные модули, но и комбинировать их между собой, тем самым подстраивать все необходимые компоненты под ваше приложение. За счёт такого подхода экономятся часы, которые раньше требовались на предоставление и настройку различных компонентов инфраструктуры.
Обычно разработчики настраивают свои окружения (в т.ч. сервера и приложения) путем ручной настройки всех параметров. В зависимости от того, сколько различных приложений, а также зависимостей к ним требуется развернуть, такая настройка может занимать значительное время. Проще говоря, IaC помогает автоматизировать всю эту рутину. А возможность переиспользовать существующий код помогает значительно снизить ошибки. Иногда можно услышать, что этим должен заниматься только отдел эксплуатации, так как чаще всего они выступают в качестве экспертов по настройке инфраструктуры, и разбираются в ней лучше чем программисты, но это верно лишь отчасти. Так как за счёт документированного процесса описания развертывания приложений с помощью кода и контроля версий, разработчику уже не нужно беспокоиться о том, что что-то может пойти не так, чем если бы он настраивал все вручную.
И да, и нет. В IaC существует две парадигмы — декларативная и императивная. Декларативность определяет, что вы хотите, чтобы система делала, а не то, как это должно быть сделано. В декларативных системах Вам не нужно знать языков программирования, так как Ваши задачи в большинстве случаев будут описанные понятными спецификациями.Системы же с императивным подходом способны решать действительно сложные проблемы, они более эффективны, т.к. позволяют использовать всю мощь популярных языков программирования, например, Python и Java для описания поставленных задач. Обе парадигмы имеют свои положительные и отрицательные стороны.
