Новые принципы создания ПО позволяют уделять больше внимания обдумыванию поведения наших приложений в ходе их применения. В совместных усилиях разработчиков и операторов делается более серьезный акцент на понимании характера поведения их приложений в процессе эксплуатации, с меньшим уровнем доверия к тому, как за счет сложности можно разрешить ситуацию при сбое.
Как и в случае с Amazon.com, архитектура ПО начала отходить от крупных монолитных приложений. Теперь основное внимание в вопросах архитектуры уделялось достижению высокого уровня масштабируемости без ущерба для производительности и доступности. Разбивая монолит на компоненты, инженерные организации предпринимали усилия по децентрализации управления изменениями, предоставляя командам больше контроля над тем, как функции вводятся в эксплуатацию. Повышая изолированность между компонентами, команды создателей ПО начали вступать в мир разработки распределенных систем, фокусируясь на написании менее крупных, более специализированных сервисов с независимыми циклами выпуска.
В приложениях, оптимизированных для выполнения в облаке, используется набор принципов, позволяющих командам более свободно оперировать способами ввода функций в эксплуатацию. По мере роста распределенности приложений (в результате повышения степени изолированности, необходимой для предоставления большего контроля над ситуацией командам, владеющим приложением) возникает серьезная проблема, связанная с повышением вероятности сбоя при обмене данными между компонентами приложения. Неизбежным результатом превращения приложений в сложные распределенные системы становятся эксплуатационные сбои.
Архитектуры приложений, оптимизированных для работы в облачной среде, придают этим приложениям преимущества исключительно высокой масштабируемости, притом гарантируя их всеобщую доступность и высокий уровень производительности. Хотя такие компании, как Amazon, пользовались преимуществами высокой масштабируемости в облаке, широко доступного инструментария для создания приложений, оптимизированных для работы в облачной среде, еще не появлялось. В конечном итоге инструменты и платформа будут представлены в виде коллекции проектов с открытым кодом, поддерживаемых первопроходцем в мире открытых облачных вычислений — компанией Netflix.
Масштабируемость
Чтобы ускорить разработку ПО, нужно заранее продумывать возможности масштабирования на всех уровнях. В самом общем смысле масштаб обуславливается издержками, приносящими пользу. Уровень непредсказуемости, сокращающий этот полезный эффект, называется риском. В таких условиях приходится определять границы масштабирования, поскольку создание программ сопряжено с рисками. Риски, заложенные создателями ПО, не всегда известны операторам, то есть тем, кто занимается его эксплуатацией. Выдвигая разработчикам требования по скорейшему вводу функций в дело, мы добавляем риски к процессу эксплуатации этих функций, не испытывая никакого сочувствия к проблемам операторов.
В результате со стороны операторов возрастает недоверие к ПО, произведенному разработчиками. Дефицит доверия между обеими сторонами создает практику обвинений: люди предъявляют друг другу претензии вместо того, чтобы рассматривать системные проблемы, которые привели к возникновению или к ускорению появления проблем, оказывающих отрицательное влияние на ведение дел.
Для снятия напряженности, возникающей в традиционных структурах ИТ-организаций, следует переосмыслить порядок взаимодействия команд, занимающихся поставкой и эксплуатацией ПО. Общение операторов с разработчиками способно влиять на возможность масштабирования, поскольку со временем цели каждой из сторон расходятся. Чтобы добиться успеха в решении данного вопроса, необходимо перейти к более надежному способу разработки ПО, при котором основное внимание внутри процесса создания уделяется опыту команды операторов и который способствует взаимообучению и совершенствованию.
Надежность
Ожидания, возникающие во взаимоотношениях команд (относительно порядка разработки, режима эксплуатации, алгоритма взаимодействия с пользователем и т. д.), выражаются в виде соглашений. Заключаемые командами соглашения подразумевают предоставление или получение определенного уровня услуг. Наблюдая за тем, как команды предоставляют услуги друг другу в процессе создания ПО, можно прийти к более глубокому пониманию того, каким образом отсутствие надлежащего уровня общения способно повлечь возникновение рисков, приводящих к сбоям при дальнейшей совместной работе.
Соглашения об услугах между командами заключаются с целью уменьшить риск неожиданного поведения в общих функциях масштабирования, которые создают ценность для бизнеса. Данные соглашения носят конкретный характер, чтобы гарантировать соответствие поведения ожидаемой стоимости операций. Таким образом, услуги позволяют отдельным частям бизнеса довести до максимальных показателей его общую отдачу. Здесь целью для бизнеса, относящегося к производству ПО, является надежное прогнозирование создания ценности за счет затрат, то есть то, что мы называем надежностью.
Модель услуг для бизнеса — та же самая модель, которая используется при создании ПО. Именно так гарантируется надежность системы, неважно, к чему именно это относится: к программному продукту, производимому для автоматизации бизнес-функции, или к людям, обучаемым выполнению ручных операций.
Адаптивность
Мы начинаем понимать, что больше не существует лишь одного способа разработки и практического применения программного обеспечения. Благодаря внедрению адаптивных методологий и продвижению в направлении к бизнес-моделям ПО как услуги (или сервиса) — Software as a Service (SaaS) — комплект корпоративных приложений становится все более распределенным. Создание распределенных систем — весьма непростая задача. Переход к более распределенной архитектуре
приложений обуславливается необходимостью сокращать сроки поставки программ с меньшим риском возникновения сбоев.
Возможно, кто-то воскликнет: «Адаптивность? Она все еще актуальна?». Адаптивность в нашем понимании относится как к целостному, общесистемному устремлению к незамедлительной поставке новой ценности, так и к замыслу по поводу быстрого реагирования на смену обстановки. Мы просто говорим о малом — об адаптивности, не касаясь при этом понятий управленческой практики. Существует множество путей, приводящих к эксплуатации продукта, и нас не интересует, какой именно методики управления вы будете придерживаться на своем пути. Главное, вам нужно усвоить, что адаптивность — полезное свойство, а не самоцель.
Современный бизнес, ориентированный на производство ПО, стремится реструктурировать процессы разработки, чтобы получить возможность более быстро внедрять программы и непрерывно вводить приложения в эксплуатацию. Компании хотят увеличить не только скорость разработки программ, но и количество создаваемых и сопровождаемых ими приложений, чтобы обслуживать различные бизнес-подразделения организации.
ПО все чаще становится для компаний конкурентным преимуществом. Все более совершенные инструменты позволяют бизнес-специалистам открывать новые источники дохода или оптимизировать бизнес-функции таким образом, чтобы можно было обеспечить быстрое внедрение инноваций.
И в центре всего этого движения находится облако. Когда о нем заходит речь, подразумевается весьма специфичный набор технологий, позволяющий разработчикам и операторам сопровождения пользоваться преимуществами веб-сервисов, существующих для предоставления виртуализированной вычислительной инфраструктуры и управления ею.
Компании начинают переходить от дата-центров к применению публичных облаков. Одной из таких является Netflix, популярная компания по предоставлению потокового мультимедиа по подписке.
