Руководство по DevOps. Как добиться гибкости, надежности и безопасности мирового уровня в технологических компаниях

Даже развертывание небольших изменений может потребовать координации с сотнями (или даже тысячами) других разработчиков, и взаимодействие с любым из них может вызвать катастрофический сбой, потенциально требующий нескольких недель на поиск и устранение проблемы (это приводит к появлению другого симптома: «Разработчики используют только 15 % своего времени на создание кода, а остальная часть тратится на совещаниях»).

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

Исходя из перспективы развития корпоративной архитектуры, нисходящая спираль — следствие второго закона архитектурной термодинамики, особенно в больших и сложных организациях. Чарльз Бец, автор книги Architecture and Patterns for IT Service Management, Resource Planning, and Governance: Making Shoes for the Cobbler’s Children, отмечает: «Владельцы IT-проектов не несут ответственности за свой вклад в общую систему энтропии». Другими словами, сокращение общей сложности и увеличение продуктивности всех наших команд редко становится целью отдельного проекта.

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

Архитектура, обеспечивающая производительность, тестируемость и безопасность

В отличие от сильно связанной архитектуры, препятствующей производительности сотрудников и их способности безопасно вносить изменения, слабо связанная архитектура с хорошо определенными интерфейсами, повышающими возможность модулей взаимодействовать друг с другом, способствует повышению производительности и безопасности. Она позволяет небольшим, продуктивным, «двухпиццевым» командам создавать небольшие изменения, разворачиваемые безопасно и независимо от других команд. И поскольку каждый такой сервис имеет также хорошо определенный API, он позволяет легче тестировать сервисы и создавать контракты и соглашения об уровне обслуживания между командами.

Облачное хранилище данных компании Google

Рис. 22. Облачное хранилище данных компании Google (источник: Shoup, From the Monolith to Micro-services)

Согласно описанию Рэнди Шупа, «этот тип архитектуры отлично служил Google, в частности для такой службы, как Gmail и еще пяти или шести других сервисов более низкого уровня. Их она использовала, и каждый базировался на весьма специфических функциях. Любая служба поддерживается небольшой командой, создающей и запускающей функциональность этой службы, и каждая команда потенциально может использовать различные технологии. Другой пример — служба облачного хранилища данных Google, один из крупнейших NoSQL-сервисов в мире. Несмотря на это, она поддерживается командой из восьми человек. Это возможно в значительной степени из-за того, что сервис основан на нескольких слоях зависимых служб, построенных друг на друге».

Ориентированная на сервисы архитектура позволяет небольшим командам работать над более мелкими и простыми единицами развертывания. Каждая команда может развертывать их независимо, быстро и безопасно. Шуп отмечает, что «организации с этими типами архитектуры, такие как Google и Amazon, показывают, как это может повлиять на организационные структуры, создавая гибкость и масштабируемость. Обе организации имеют десятки тысяч разработчиков, небольшие команды невероятно продуктивны».

Архитектурные архетипы: монолитный или микросервисы

В определенный момент своей истории почти все организации, использующие сейчас DevOps, были отягощены плотно связанной, монолитной архитектурой. Успешно помогая им соответствовать требованиям рынка или требованиям к продуктам, она создавала риск сбоев организационной структуры, если пользователям надо было значительно расширять деятельность (например, монолитное приложение на C++ компании eBay в 2001 г., монолитное приложение OBIDOS компании Amazon в том же году, монолитное клиентское Rails-приложение Twitter в 2009 г. и монолитное приложение Leo компании LinkedIn в 2011 г.). В каждом из этих случаев компании смогли перепроектировать свои системы и заложить основы не только выживания, но и процветания и победы на рынке.