Джин Ким - Руководство по DevOps

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

Рис. 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 г.). В каждом из этих случаев компании смогли перепроектировать свои системы и заложить основы не только выживания, но и процветания и победы на рынке.

Монолитные архитектуры неплохи по своей сути, в реальности они часто становятся лучшим выбором для организации на раннем этапе жизненного цикла продукта. Как отмечает Рэнди Шуп, «нет идеальной архитектуры для всех продуктов и всех масштабов. Любая архитектура соответствует некоторому набору целей или диапазонам требований и ограничений, таких как время вывода на рынок, простота развития функциональности, масштабирование и так далее. Функциональность любого продукта или услуги почти наверняка будет изменяться с течением времени, так что нет ничего удивительного, что наши архитектурные потребности будут меняться. Что работает в масштабе 1x, редко работает в масштабе 10x или 100x».

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

Таблица 3. Архитектурные архетипы

Источник: Shoup, From the Monolith to Micro-services.

Одно из наиболее изученных преобразований архитектуры произошло в компании Amazon. В интервью с обладателем награды ACM Turing и техническим специалистом компании Microsoft Джимом Греем Вернер Фогельс, технический директор компании Amazon, объяснил, что Amazon.com начал работу в 1996 г. как «монолитное приложение на веб-сервере, обращаясь к базе данных на серверной части. Это приложение, получившее название Obidos, эволюционировало, чтобы сохранить всю бизнес-логику, всю логику отображения и все функциональные возможности, которые в конце концов прославили Amazon: аналоги, рекомендации, Listmania, обзоры и так далее».

С течением времени Obidos разросся и стал слишком запутанным, со сложными взаимосвязями отдельных частей. Его невозможно было масштабировать по мере необходимости. Фогельс рассказал Грею, что это означает: «Многие вещи, которые вы хотели бы видеть работающими в хорошей программной среде, больше не могут быть сделаны; множество сложных единиц программного обеспечения объединены в единую систему, но она больше не могла развиваться».

Описывая процесс обдумывания новой желаемой архитектуры, он рассказывал Грею: «Мы прошли через период серьезного самоанализа и пришли к выводу о том, что сервис-ориентированная архитектура могла бы обеспечить уровень изоляции, достаточный для того, чтобы позволить нам создавать множество компонентов программного обеспечения быстро и независимо друг от друга».

Фогельс отмечает: «Компания Amazon в течение последних пяти лет (2001–2005) прошла через большие изменения архитектуры, чтобы сменить двухуровневую монолитную архитектуру на полностью распределенную децентрализованную платформу сервисов, обслуживающую множество различных приложений. Потребовалось множество инноваций, чтобы такие изменения стали возможными, и мы были одними из первых, использовавших этот подход». Из опыта работы Фогельса в компании Amazon можно извлечь следующие уроки, имеющие большое значение для нашего понимания смен архитектуры: