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

• урок 1: при неукоснительном применении строгая ориентация на сервисы — отличный метод для достижения изоляции, вы можете добиться невиданного прежде уровня владения и управления;

• урок 2: запрет прямого доступа клиентов к базе данных делает возможным выполнение масштабирования и повышение надежности вашего сервиса, не затрагивая клиентов;

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

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

Термин «удушающее приложение» был введен Мартином Фаулером в 2004 г., после того как он увидел огромные удушающие лозы во время путешествия в Австралию и описал их так: «Они выбирают верхние ветви смоковницы и постепенно растут вниз по дереву, пока не укоренятся в почве. Долгие годы они разрастаются, приобретая фантастически красивые формы и постепенно удушая и убивая дерево, на котором паразитируют».

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

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

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

Если вызываемые службы не имеют четко определенных API, то мы должны создавать такие интерфейсы или по крайней мере скрыть сложность взаимодействия с такими системами использованием библиотеки клиента, имеющей четко определенный API.

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

Создав удушающее приложение, мы сможем избежать точного воспроизведения существующей функциональности в некоторых новых архитектурах или технологиях — часто наши бизнес-процессы более сложны, чем необходимо в связи с особенностями имеющихся систем, которые мы реплицируем (изучая пользователя, мы часто можем перепроектировать этот процесс, чтобы создать намного более простые и более рациональные средства для достижения наших бизнес-целей [105]).

Наблюдение Мартина Фаулера подчеркивает этот риск: «Значительную часть моей трудовой деятельности составляло участие в переписывании критически важных систем. Вам может показаться, что это очень просто — написать новую программу, делающую то же самое, что и старая. Но такая работа всегда более сложна, чем кажется, и изобилует всевозможными рисками. Впереди маячит важная дата завершения проекта, и давление нарастает. В то время как новые функциональные возможности (всегда существуют новые функциональности) нравятся всем, старые никуда не деваются. Нередко в переписанную систему приходится добавлять даже старые ошибки».

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

Компания Blackboard — один из пионеров предоставления технологии для учебных заведений с годовым доходом в размере примерно 650 миллионов долларов в 2011 г. В то время команда разработчиков флагманской программы Learn, пакетного программного обеспечения, установленного и запущенного локально на сайтах клиентов, ежедневно сталкивалась с последствиями использования унаследованной базы кода на J2EE, писавшейся еще в 1997 г. Как отмечал Давид Эшман, главный архитектор компании, «мы до сих пор имеем дело с фрагментами кода на языке Perl, встречающимися на многих участках нашего кода».

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

Рис. 23. Репозиторий кода Blackboard Learn до создания Building Blocks (источник: DOES14 — David Ashman — Blackboard Learn — Keep Your Head in the Clouds, видео на YouTube, 30:43, размещено 28 октября 2014 г. оргкомитетом конференции DevOps Enterprise Summit 2014, https://www.youtube.com/watch?v=SSmixnMpsI4)

Как это начало влиять на производительность труда разработчиков, Эщман увидел на графиках, созданных на основе данных из репозитория исходного кода начиная с 2005 г.

На рис. 24 верхний график показывает число строк кода в репозитории монолитной программы Blackboard Learn, нижний график показывает число фиксаций кода. Проблема, ставшая для Эшмана очевидной, заключалась в том, что количество фиксаций кода стало уменьшаться, объективно показывая нарастающую трудность внесения изменений в код, в то время как число строк кода продолжало увеличиваться. Эшман отмечал: «Эти графики свидетельствовали, что нам нужно что-то делать, в противном случае проблемы будут усугубляться, и этому не видно конца».