Большинство компаний сталкиваются с огромным количеством технических «долгов» во время миграции в облако.
В этой статье мы рассмотрим 5 путей как DevOps может помочь их решить.
Технический «долг» – не оптимальные технические решения, накопленные за все время жизни приложения. Такие вещи становится все сложнее и сложнее исправлять и в конце концов эти инициативы просто останавливаются.
К примеру, плохо описанный процесс управления состоянием (state management) может сильно усложнить горизонтальное расширение. Перед тем как расширять структуру вам придется переписать ту часть кода, которая отвечает за управление состоянием. Это и называют техническим «долгом».
Так же технические «долги» встречаются и в операционной деятельности.
Все еще работаете на Windows Server 2008, or Ubuntu 11.04 которые не поддерживаются производителем?
Не установили последний патч по безопасности? Это и есть технический «долг».
Один из принципов devops это создание небольшой команды, которая несет ответственность за весь жизненный цикл приложения. И так как эта команда и особенно продакт-менеджер каждый день сталкиваются с этими проблемами, они будут максимально заинтересованы в их устранении.
Во-первых, нужно замечать и следить за техническими «долгами» в своем продукте.
Во время работы над продуктом помечайте (в Jira, Azure DevOps или Git) не оптимальные элементы как «techDebt». И выделять время в каждом спринте на эти задачи.
Мы советуем начать с 20% времени, выделяемого на спринт.
После этого в рамках ретроспективной работы с каждой командой оцените текущий уровень ваших технических «долгов». Если большинство оценит эту проблему высоко, то стоит увеличить количество часов в спринте на работу с «долгами», до того момента пока «долги» не перестанут мешать корректной работе продукта.
И конечно старайтесь не создавать новых технических «долгов». Используйте таблицу возникновения «долгов» чтобы оценить решения архитектора и минимизировать «долги». Если вы все же решили оставить технический «долг», то контролируйте его и рассчитывайте загрузку так, чтобы вы смогли его исправить в следующих спринтах.
Все чаще компании создают общие сервисы для поддержки команд ответственных за продукты. Платформы основанные, на таких сервисах помогают избегать технических «долгов» при построении цепочек компонентов. Такие сервисы должны быть созданы в соответствии с запросами разработчиков и лучшими практиками для создания таких систем. Они могут быть, как сторонними SaaS-решениями, так и полностью собственными решениями.
Хорошая платформа — это общее дело. Она не должна быть черным ящиком для разработчиков, поэтому построение платформы стоит начать с изучения опыта открытых проектов и возможности применить эти решения в ваших внутренних платформах.
В определении InnerSource от InnerSource Commons говорится «консолидирует опыт развития open source решений для помощи внутреннего развития компании».
Команды, работающие с платформой, должны быть ключевой точкой изменений и быть готовым к ним. Репозитории с кодом должны быть общедоступны и любой желающий может внести изменения после согласования с управляющей командой.
Неотъемлемой частью DevOps является автоматизация процессов.
Большая часть вышеупомянутых внутренних платформ выстраиваются и используются автоматизировано. Сервисы, которые предоставляют платформы, часто являются наборами инструментов для автоматизации, предназначенными для использования продуктовыми командам.
Для примера возьмем процесс управления инфраструктурой и на его примере рассмотрим, как «инфраструктура как код» и «конфигурация как код» помогут нам в борьбе с техническим «долгом».
Несовместимые системы — это наиболее часто встречающийся вариант технического «долга». Когда ваше приложение работает в среде разработки, но не работает ни в препроде ни в проде чаще всего причиной будет несовместимость систем. Это могут быть как настройки ОС или приложения, так и тысячи межсервисных настроек, с которыми работает приложение. И то время, которое вы тратите на устранение этой проблемы и есть стоимость вашего технического «долга».
«Инфраструктура как код» и «конфигурация как код» позволят вам создать инфраструктуру в точности так как вы ее задумали. А с помощью таких инструментов как Terraform и Puppet, вы можете сконфигурировать ее на каждом инстансе идентично. А контейнеризация выводит это на следующий уровень, но об этом позже.
Время, которое вы НЕ потратили на поиск и решение инфраструктурных проблем, вы можете использовать на погашение других технических долгов, что ведет к «эффективному циклу автоматизации».
Система автоматизации «как код» дает еще ряд преимуществ. Весь код автоматизации хранится в репозитории типа GitHub, что дает возможность быстрого поиска нужных частей, их внедрения и улучшения основанных на запросах пользователей. Это позволяет сохранять код в актуальном состоянии и избегать накопления технического «долга».
Если говорить коротко, то контейнеры позволяют вам сохранить ваше приложение, его настройки, настройки ОС в одной небольшой связке, которую можно легко развернуть, что сэкономит значительное время на конфигурации перед запуском.
Как и с инфраструктурным менеджментом, мобильность, которую дают контейнеры, может облегчить буквально все. Инструмент для оркестрации контейнеров, к примеру Kubernetes
позволяет автоматизировать систему жизненных циклов контейнеров. Это дает возможность DevOps команде не отвлекаться на операционные задачи, а заниматься более высоко уровневыми задачами (архитектура приложения и тд.)
При построении новых облачных приложений обычно используют контейнеры для улучшения гибкости подхода, наращивания мощности при уменьшении общей стоимости.
Архитектура микросервисов отлично работает как с контейнерами, так и с разделенными DevOps командами, отвечающими за продукт, о которых мы писали выше. У каждого микросервиса должен быть не большой, ограниченный список задач и команда поддержки. Это позволит в разы лучше контролировать процесс доработок и не накапливать технические «долги». Это беспроигрышный вариант.
Модель с использованием микросервисов это один из возможных вариантов реализации API-центрированной модели. Глава Amazon Джеф Безос поставил задачу своим сотрудникам пользоваться только API при взаимодействии с системой под угрозой увольнения.
Конечно, в вашей организации все может быть не так сурово. Тем не менее поощрение команды работать с API четко определенных версий, это хороший метод для ухода от технических «долгов». Чаще всего «долги» копятся из-за разных методов доступа приложений к сервисам и данным, которые не соответствуют друг другу. К примеру, команда А читает данные из таблицы созданной командой Б. И если команда Б поменяет схему для своих нужд, то этим они непреднамеренно нарушат интеграцию с приложением команды А.
API делают эти зависимости гораздо более заметными и менее уязвимыми. Каждый продукт должен придерживаться опубликованного API с понятными дорожными картами и политикой изменений. Если на поздних стадиях нужна смена API, то выпускают новую версию, и определяется время, которое будет поддерживаться «старая».
Системы DevOps, к примеру CI/CD практика непрерывной интеграции и непрерывного развертывания кода обеспечивает сквозную прослеживаемость от юзер стори до реализации, а также позволяет разработчикам работать быстрее с меньшими рисками и с меньшими техническими долгами.
Если вы контролируете и помечаете места с техническими «долгами», как обсуждалось ранее, вы увидите результат достаточно быстро. А автоматизация процесса поможет сконцентрироваться на нуждах потребителя.
Наш менеджер свяжется в течение 2х часов
