Облачная архитектура предприятия

Бесконечные разговоры об облачных и корпоративных архитектурах сообществу профессионалов порядком надоели, мало того, многим облачная тема уже практически в самом начале ее появления представлялась затасканной. О ней, по их представлениям, слишком много говорят в общих выражениях, а в итоге приходится наблюдать, как в аудиториях при упоминании облаков у значительной части присутствующих появляется снисходительное, ироническое настроение. По состоянию на март 2012 года 80% из числа опрошенных в США руководителей информационных подразделений осознают значение перехода к облакам, но тем не менее в их реальных шагах наблюдается очевидная заторможенность — только 20% предпринимают активные действия. И это при том, что по прогнозам Forrester Research, в 2020 году на облака во всем мире будет затрачено более 240 млрд долл., что означает пятикратный рост по сравнению с нынешними расходами.

Не лучше дело обстоит и с корпоративными архитектурами — практически мыслящим представителям ИТ эта тема кажется попросту навязанной. Их отношение объяснимо, и в жизни потребность в профессиональной архитектуре возникает только тогда, когда складываются необходимые условия — прежде всего, когда у заказчика есть ресурсы, возможность выбора, когда у него имеются соответствующие требования. А если всего этого нет, то архитектура не нужна — ни строительная, ни компьютерная. Тысячелетиями все постройки, бывшие исключительно утилитарными (народными), создавались исходя из здравого смысла, без привлечения архитекторов. Как специальность архитектура появилась из потребности возводить культовые сооружения. Аналогичная ситуация наблюдается и при создании информационных систем: пока выбор был невелик и реальной потребности не было, любые, чаще всего псевдопрофессиональные, разговоры об архитектуре оставались притянутыми. Не случайно в статье «Нужна ли нам архитектура?» («Открытые системы», № 06, 2008) Марина Аншина заметила: «Об архитектуре предприятия (Enterprise Architecture) говорят сегодня все кому не лень». Можно добавить в качестве комментария к этой мысли известную фразу из чеховской «Свадьбы», точно отражающую распространенное в среде ИТ отношение к тем, кто рассуждает о корпоративной архитектуре: «Они хочут свою образованность показать и всегда говорят о непонятном». И еще — «Слава богу, прожили век без образования и вот уж третью дочку за хорошего человека выдаем». Переводя на язык ИТ — обходились мы без архитектуры и отлично жили. Однако вместе с облаками открылась возможность выбора, и теперь при создании сложных информационных систем уже не обойтись без архитектуры.

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

Подобное неоправданно скептическое отношение к той или иной перспективной технологии далеко не новость — аналогичная ситуация наблюдалась неоднократно. Самый яркий пример — язык Java, который активно критиковался в середине девяностых. А самый недавний пример — SOA, уж чего только и в каких количествах не довелось услышать по поводу сервисных архитектур, однако сегодня они прочно заняли свое место. И вот теперь —  облака.

Одно из достоинств облачных решений в том, что они не только позволят рациональнее использовать все виды информационных ресурсов, смещая затраты от капитальных (CapEx) в сторону эксплуатационных (OpEx), но и обеспечивают более тесную взаимосвязь между инфраструктурой бизнеса и поддерживающей ее информационной инфраструктурой. Результатом этого становится «облачное предприятие» Cloud Enterprise, построенное по соответствующей ему архитектуре Cloud Enterprise Architecture (CEA), которую можно считать синонимом Next Generation Enterprise.

Предприятие следующего поколения (как и культовые сооружения) невозможно строить без архитектурного проекта, и здесь облачная архитектура встречается с корпоративной. Тема чрезвычайно актуальна, и не случайно в конце 2012 года в ответ на запрос “Cloud Computing” в сочетании с “Enterprise Architecture” любой поисковик неожиданно выдает в ответ колоссальное количество страниц, причем многие из них в формате pdf, а обычно это документы, опубликованные компаниями, — значит, дело принимает серьезный оборот.

Oблачная платформа как результат эволюции

Популярные лет десять назад инициативы типа utility computing или autonomic computing не смогли получить широкое признание, поскольку опережали время, и только с появлением облаков открылась практическая возможность для реализации заложенных в них идей:

• модель оплаты по мере использования ресурсов с минимальным начальным вкладом;
• эластичность — пользователь потребляет ровно столько ресурсов, сколько ему нужно;
• отсутствие привязки к определенному местоположению;
• доступ к ресурсам в виде сервисов из произвольных мест в различных форматах.

Все эти качества не придуманы и не изобретены, а сформировались в результате эволюции корпоративных ИТ-инфраструктур. Начальное представление о таких инфраструктурах возникло в начале шестидесятых вместе с появлением мэйнфреймов IBM System/360. На первых порах для ввода использовались перфокарты, а для вывода — только печать, но вскоре был предложен терминальный доступ VTAM (Virtual Telecommunications Access Method), обеспечивающий работу на алфавитно-цифровых терминалах по протоколу SNA (Systems Network Architecture) — в какой-то мере аналогу TCP/IP. В результате уже на мэйнфреймах сложилась инфраструктура, напоминающая облака, достаточно перечислить такие ее атрибуты, как виртуальные машины, отказоустойчивость, нереляционные базы данных и, что, пожалуй, самое главное, — централизованное управление.

Близость технологических подходов далекого прошлого и современности, разделенных между собой тремя десятилетиями, дает основание верным адептам мэйнфреймов говорить, что уход в сторону открытых систем был ошибкой. С уверенностью можно сказать — это не так, и причины не только экономические. Да, мэйнфреймы были дороги и доступны ограниченному количеству организаций, но следует учитывать и социальные причины. В 70-е и 80-е годы в активную жизнь входило поколение бэби-бума, и тогда же установился более демократический миропорядок, что и нашло свое отражение в ИТ. В этом контексте не случайна была роль Университета Беркли, до сих пор остающегося самым левым в США, — для нового поколения главными словами стали Unix и ПК. Как следствие, стали развиваться архитектуры клиент-сервер в двух версиях — с толстым и тонким клиентами, конкурировавшими между собой на протяжении многих лет.

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

Ограниченная масштабируемость была вызвана упрощенной конструкцией Unix-серверов — обладая формально равной мэйнфреймам процессорной мощностью, они не имели адекватных средств управления ресурсами (виртуальные машины, системы управления заданиями, разделение доступа к центральным процессорам и дискам), собственно говоря, всем тем, что отличает мэйнфреймы. В качестве средства для выхода из положения были предложены мониторы управления транзакциями, созданные по аналогии с сервером транзакций Customer Information Control System (CICS), используемым в мэйнфреймах.

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

Следующим шагом в развитии корпоративных систем стали интернет-приложения, основанные на HTTP и HTML, стандартизованных консорциумом W3C, браузерах и серверах HTTPD (HyperText Transfer Protocol Daemon). Использование HTML делало такие решения удобными для доступа к приложениям на мэйнфреймах, но их недостатком стали ограниченные возможности для работы с клиент-серверными и трехзвенными архитектурами. Это ограничение было преодолено с появлением новых технологий, например таких, как AJAX (Asynchronous Javascript and XML), поддерживающих «богатые функционально» приложения (Rich Internet Application, RIA). В начале двухтысячных с появлением и ростом популярности XML, SOAP (Simple Object Access Protocol), UDDI (Universal Description, Discovery and Integration) и WSDL (Web Services Description Language) стало складываться впечатление, что Сеть сама по себе станет платформой для приложений. Любой может создать сервис, описать его на WSDL, UDDI позволит найти то, что нужно, а SOAP — использовать сервис. Но с самого начала идея сервисов через WWW казалась сомнительной из-за отсутствия необходимой управляемой инфраструктуры. В итоге стандарт SOAP существует до сих пор, а WSDL и UDDI практически забыты, но идея сервисов осталась, и теперь она прочно связана с SOA, а SOAP стали расшифровывать как Service-Oriented Architecture Protocol.

Термин SOA был предложен в 1996 году аналитиком Gartner Ефимом Натисом, но до 2001 года о сервисной архитектуре никто не вспоминал, а потом стала ясна перспективность этой архитектуры как отражения природы изменений, происходящих в корпоративных системах. Оказалось, что SOA есть следствие закономерного эволюционного процесса — при переходе от мэйнфреймов к клиент-серверным конфигурациям и далее к SOA изменяется функциональность, пересматриваются представления об информации и данных, а это явления более глубокие, чем простые изменения в аппаратной или программной архитектуре.

В 1997 году профессор Рамеш Челлаппа первым предложил термин “cloud computing”, и вскоре состоялся прочный союз SOA с облаками, плодом которого стали самые разнообразные вещи, предоставляемые в виде тех или иных услуг — «все как сервисы» (XaaS).

Из совокупности разнообразных сервисов складывается желаемая облачная экосистема предприятия (Enterprise Cloud Computing Ecosystem), являющаяся на данный момент венцом в эволюционном развитии корпоративных платформ и базисом для предприятия будущего. Теоретически такая среда делится на:

• собственное частное облако предприятия, образованное из виртуализованных ресурсов, на которых выполняются приложения, — ИТ-службы поддерживают внутренние сервисы IaaS, мониторинг и балансировку нагрузки;
• внешние сервисы IaaS — мониторинг и балансировку нагрузки осуществляет провайдер, а управление облачными сервисами и развертывание приложений остается за пользователем;
• услуги провайдера — от пользователя ничего не требуется, лишь потребление;
• сервисы SaaS — могут осуществляться с использованием арендованных платформ PaaS, в таком случае за пользователем остается только развертывание приложений;
• собственные платформные сервисы предприятия PaaS — могут быть развернуты на арендованном оборудовании в виде сервисов IaaS, а пользователю предстоит осуществлять их мониторинг и обеспечивать балансировку.

Другие сервисы — Monitoring as a Service, Communication as a Service, Data as a Service, Information as a Service, Desktop as a Service, Storage as a Service — нарушают стройность облачной картины и существенно ее усложняют. Получается, что, с одной стороны, сервисный подход упрощает логику взаимодействия приложений, а с другой — инфраструктура предприятия становится намного сложнее.

Таким образом, наступило время всерьез заняться архитектурой инфраструктуры предприятия — пора строительства «на глазок» закончилась, и появился реальный интерес к Cloud Computing в сочетании с Enterprise Architecture.

Предприятие следующего поколения

Вместе с облаками предприятие, их внедряющее, может приобрести принципиально новые качества, стать тем, что сейчас называют предприятием следующего поколения (Next Generation Enterpise). Часть из этих свойств предприятия будущего приведена далее, понятно, что многие из них пересекаются, по той причине, что отражают единое целое. Данное перечисление не ставит своей целью сделать что-то вроде классификации — скорее, наоборот, оно сделано с тем, чтобы представить в общем виде возможные результаты внедрения CEA.

Динамичность (Dynamic Enterprises). Впервые термин Dynamic Enterprise Architecture (DEA) был предложен в 2001 году, но тогда еще не было адекватных технологий, а совсем недавно вышла книга “Dynamic Enterprise Architecture, How to make it work”, где не только определяется предмет — динамика, но и то, как следует идти к ней. Подход DEA позволяет интегрировать сервисы, предоставляемые различными облаками и различными провайдерами, ресурсы могут перераспределяться так, как нужно в данный момент, что и придает требуемую динамичность.

Адаптивность (Adaptive Enterprises). В конечном счете адаптивность означает согласованность между запросами на те или иные сервисы со способностью их гармонизации. С начала десятилетия эта тема была в центре внимания компании Hewlett-Packard, которая воплотила ее в программе Darwin. Удивительно, что практически все составляющие, в том числе виртуализация в том виде, как мы ее сегодня понимаем (виртуализация серверов, приложений, сетей и систем хранения), была предусмотрена уже тогда в технологиях, собранных под шапкой Utility Data Center (UDC), предназначенных для построения центров обработки данных. В IBM аналогичное решение назвали On-Demand Enterprise.

Глобальная интеграция (Globally Integrated Enterprise). Этот термин в 2006 году озвучил Сэм Палмизано, бывший в то время президентом IBM, таким образом подчеркивая переход мировой экономики на новый транснациональный уровень. Облачные технологии, в первую очередь глобально распределенные системы хранения данных, усиливают эту концепцию.

Прозрачное предприятие (Liquid Enterprise). Этот взгляд на предприятие был предложен примерно десять лет назад компанией BEA до поглощения ее Oracle. Его суть в наведении мостов между людьми, процессами и данными, в создании горизонтальных коммуникаций и в конечном итоге — в формировании социальных компьютерных систем (Enterprise Social Computing). В последние годы эти взгляды воплощаются в методах краудсорсинга, и здесь облака с их природной централизацией и практически неограниченной возможностью предоставления любых ресурсов по требованию дают возможность множеству людей работать с одними и теми же данными. Иногда как синоним используется термин Connected Enterprise.

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

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

Этапы пути к предприятию будущего