SOA больше не в моде или ее просто «не умеют правильно готовить»? О недостатках нисходящей модели сервис-ориентированной архитектуры и достойствах ее восходящей модели рассказывают разработчики из MuleSoft.
C тех пор, как возникло понятие сервис-ориентированной архитектуры или SOA, отношение коммерческих организаций к подобным решениям значительно изменилось. Когда технология SOA впервые появилась в начале 2000-х, и этот термин был у всех на устах, эта новая модель была воспринята с крайним энтузиазмом. Компании с большими инфраструктурными проблемами были уверены, что именно SOA позволит справиться со всеми этими неудобствами, и с готовностью вкладывали миллионы долларов в масштабные SOA-проекты, которые выстраивались по принципу «сверху вниз». Как правило, такие инициативы получались долгосрочными и имели весьма туманные перспективы окупаемости инвестиций.
К 2009 году многое изменилось. Сервис-ориентированная архитектура, мягко говоря, уже не была всеобщей страстью. Абсолютное большинство масштабных нисходящих SOA-инициатив, которые когда-то запускались с такими большими надеждами, бесславно провалились, нанеся компаниям убытки в миллионы долларов и отбросив их архитектуры на годы назад. По данным некоторых исследований, было реализовано всего около 20% SOA-инициатив, запущенных на пике популярности этой модели. Отрицательный эффект от SOA с последующим решительным неприятием этой технологии оказался таким быстрым и сильным, что один IT-аналитик в январе 2009 года даже опубликовал в своем блоге «некролог по SOA».
Почему SOA не потеряла значения
Учитывая такое количество неудач, вполне можно понять решительное отторжение SOA. Однако оно совершенно необоснованное. Слухи о смерти SOA сильно преувеличены, сегодня эта технология востребована как никогда.
Инфраструктурные проблемы, существовавшие в начале 2000-х и превратившиеся в настоящий бич корпораций, никуда не исчезли. Компании, стремящиеся оставаться на ведущих позициях в своих отраслях, в современном экономическом климате должны проявлять еще большую гибкость. Поэтому для них жизненно важно найти способ внедрения SOA. Тем временем, можно привести в качестве примера ряд компаний, в которых SOA всё-таки удалось успешно взять на вооружение. Так, широко известна компания Bechtel, достигшая в этом немалых успехов. Таким образом, невероятно высокая окупаемость инвестиций, прогнозируемая в начале процесса, действительно достижима.
Итак, можно сделать однозначный вывод: неудачи обусловлены именно нисходящим, огульным подходом к SOA, а не методологией SOA как таковой.
В данной статье мы рассмотрим некоторые причины, по которым провалились первые проекты по внедрению SOA, ориентированные сверху вниз, а также обсудим свободные фреймворки, которые позволяют многим организациям обрести настоящий Святой Грааль – SOA, построенную по приницпу «снизу вверх».
Краткая история нисходящих моделей SOA
Когда технический директор пытается справиться с непрерывно усложняющейся инфраструктурой, сервис-ориентированная архитектура кажется манной небесной. Казалось бы, стоит ее внедрить – и расходы резко сократятся, производительность труда разработчиков и всей компании вырастет, сама компания будет подготовлена к гибкой стратегии в будущем.
Основное нововведение, связанное с моделью SOA, заключалось в том, что архитектуры должны выстраиваться вокруг сервисов, а не вокруг приложений. Концепция сервиса – небольшого автономного компонента ПО, выполняющего конкретную задачу для любой программы, которая его вызовет – была совершенно не нова. В инфраструктуре больших предприятий сервисы применялись уже с 80-х годов. Новизна SOA заключалась в том, что область применения таких миниатюрных сервисов радикально расширялась.
Нисходящая модель SOA
В описываемое время инфраструктуры больших предприятий становились все более раздутыми и негибкими. Для удовлетворения новых бизнес-потребностей или для автоматизации процессов обычно разрабатывалось новое собственное ПО. Зачастую такие внутрикорпоративные программы дублировали функционал, уже реализованный в программах из других организаций.
Например, если для многих программ требовалась информация о проверке кредитоспособности, то в каждой из них приходилось дублировать код, выполняющий такую проверку (а в худшем случае – программировать совершенно новую реализацию). Каждая новая программа представляла собой отдельную базу кода, за поддержку которой отвечал IT-отдел конкретной компании. Этот же IT-отдел должен был справляться и с дополнительными издержками, возникавшими в корпоративной сети. В других случаях сложность самостоятельного создания внутрикорпоративного приложения была такой высокой, что приходилось привлекать сторонних разработчиков, заключая дорогостоящие контракты. Правда, полученный в результате продукт мог плохо интегрироваться с уже имеющимися программами.
Сервис-ориентированная архитектура была призвана заменить практику разработки внутрикорпоративных приложений, заменяя их сервисами – мелкими компонентами, пригодными для многократного использования.
Первым делом компания должна была составить подробную карту всех отдельных функций, которые должны выполняться в инфраструктуре. Требовалось сформулировать конкретные задачи, для автоматизации которых, в первую очередь, предназначались все эти собственные программы. Как они связаны? Какие форматы данных и протоколы должны применяться при обеспечении их взаимодействия?
Далее компании требовалось определить, какие элементы этого функционала можно воплотить не как единое приложение, а как набор сервисов. Например, система оформления заказов может быть организована не как отдельный функциональный комплекс, а как логическая комбинация сервисов. Некоторые из этих сервисов будут обслуживать кредитные карточки, другие – вести учет ресурсов, третьи – обрабатывать пользовательские данные, и т.д. На основании этой оценки организация могла идентифицировать такие сервисы, которые используются одновременно во многих прикладных сферах, и выстроить эти сервисы таким образом, чтобы они могли переиспользоваться в разных приложениях.
Когда эти сервисы созданы, те разнообразные приложения, которые использовались в компании до этого, можно «воссоздать» с применением минимальных объемов дублирующегося кода, при помощи таких «общих частей». В качестве дополнения к этому плану, любой функционал, специфичный для нового приложения, также может быть реализован в виде сервисов и будет доступен для переиспользования в любых приложениях, где впоследствии может понадобиться такой функционал.
SOA создает экосистему, состоящую из активно обновляемых компонентов бизнес-логики. Эти компоненты можно быстро связывать вместе при помощи минимальных объемов нового кода и по мере необходимости создавать программы, решающие любые бизнес-задачи любой степени специфичности.
Бочка дегтя – почему нисходящие модели SOA не работают
На бумаге такой смелый план по внедрению SOA кажется великолепным, но при попытке его практического воплощения компания быстро сталкивается с трудностями. Большинство проблем обусловлено в целом похожими наборами упрощенных предположений о том, как строится работа в организации. Такие предположения включаются в любой план приема нисходящей стратегии.
Чтобы понять, что именно может пойти не так, рассмотрим некоторые ошибочные идеи, из-за которых так много инициатив по построению SOA сверху вниз потерпели фиаско.
Первый принцип нисходящей SOA: Команда по внедрению SOA выбирает и приобретает проприетарный продукт по управлению SOA. Команды разработчиков обучаются обращению с этим продуктом, так как с его помощью им придется не только переделать все имеющиеся системы, но и готовить будущие проекты.
Почему это не работает: Огромные расходы на фоне отсутствия опыта у разработчиков и жесткой зависимости от одного поставщика приводят к катастрофе.
При реализации нисходящих моделей SOA многие компании стремились возложить сложную задачу внедрения SOA на отдельную команду. Эта команда отвечала за выполнение всех аспектов такой приемки. В те годы, когда все вокруг только и говорили о SOA, такие отделы работали в условиях жесткого прессинга – от них требовалось запустить SOA как можно быстрее, а поставщики соответствующего ПО с удовольствием нагревали руки на этом ажиотаже. В результате, первый этап работы с SOA во многих компаниях сводился к приобретению баснословно дорогого фреймворка для управления этой технологией.
При таком подходе возникает сразу три сложные проблемы. Во-первых, практически гарантированно возникает зависимость от конкретного поставщика. Такая зависимость может казаться приемлемой в компаниях, которые, например, пользуются строго определенным сервером приложений, где цикл взаимодействий отличается закрытостью. Но она совершенно неприемлема в интеграционных архитектурах. Довольно сложно в точности спрогнозировать, как ваши потребности могут измениться в будущем и не вкладывать при этом огромных денег в «дорожную карту» определенной компании. SOA определяется нуждами ИМЕННО ВАШЕЙ организации – поэтому не позволяйте поставщику диктовать вам, что требуется, а что – нет. Не забывайте, что вам понадобится не только ряд систем, которые должны слаженно работать вместе. Ваше решение также должно облегчить работу как программистам, так и пользователям.
Здесь мы подходим ко второй проблеме нисходящей модели – обучению разработчиков. Ваша команда разработчиков не будет просто сидеть сложа руки и дожидаться, пока вы позволите им реализовать для вас SOA. На самом деле, эта работа лишь добавится к уже имеющимся у них повседневным задачам, которые и так чрезмерно загружают вашу корпоративную сеть. Сами по себе работы по переходу на новые рельсы могут оказаться достаточно нетривиальными. Добавьте сюда поступающее сверху распоряжение: «мы переходим на использование нового инструмента просто потому, что компания приобрела его за большие деньги» - и задача по модернизации может оказаться невыполнимой. Достаточно немногочисленных багов или всего нескольких ошибок проектирования в инструменте SOA, чтобы и так предельно занятые разработчики потеряли всякий энтузиазм ко всему новому проекту.
Наконец, несколько слов о деньгах. SOA – это всегда большие изменения. Необходимость огромных первоначальных вложений в единственный продукт – отличный способ перевести всю организацию в режим турбулентности. На самом же деле в подобной ситуации вам требуется ровно противоположное – четкий и аккуратный план, который можно будет внедрять постепенно, с максимальным участием всех ваших сотрудников. Такой план позволил бы гарантировать безотказную работу на всех направлениях – интеграция, сервисы, рекомендуемые методы работы, усвоение – без сбоев ежедневного рабочего ритма и без сваливания лишней нагрузки на команды разработчиков.
Второй принцип нисходящей SOA: SOA подразумевает изменение парадигмы во всей организации, вклад всего коллектива зависит от вклада каждого отдельного человека. Соответственно, такое изменение парадигмы должно происходить одновременно во всей организации.
Почему это не работает: большинство организаций не могут позволить себе отложить все задачи и полностью сосредоточиться на внедрении SOA. Сервис-ориентированная архитектура падает с потолка как заведомо неосуществимый прожект. Не приходится рассчитывать на хорошо спланированное плавное внедрение.
Решая настолько сложную задачу, как внедрение SOA, требуется внести в организацию работы просто умопомрачительный объем изменений. Ситуация попадает в плоскость «уловки 22» – мы не можем приступить к использованию SOA, не написав сервисы, но не можем написать сервисы, не понимая нашу модель SOA. Выход всего один: отказаться от всех старых наработок и заменить их моделью SOA. При этом одновременно изменится сразу все: от процессов разработки до аппаратного обеспечения.
В чем проблема? Статистика показывает, что обычно такие затеи проваливаются. В большинстве организаций такая модель наверняка приведет к фиаско всех планов, связанных с SOA.
К счастью, SOA не столь похожа на «уловку 22». Если сервис-ориентированная архитектура внедряется сверху, то такая инициатива может показаться непреодолимо сложной. Однако если SOA реализуется снизу, то эта задача вдруг оказывается вполне осуществимой и очень разумной. Так, организация SOA снизу вверх по достоинству оценена в сообществе пользователей фреймворка Mule.
Свободно распространяемые ESB-технологии, в частности, Mule, позволяют разработчикам следовать проверенным практикам SOA и при этом обходиться без тяжеловесных моделей управления, создавать RESTful-интерфейсы, которые доступны для переиспользования «прямо с колес», а также выполнять бесшовную интеграцию с любой моделью управления SOA по мере того, как компания будет развиваться. Если у вас в распоряжении уже есть качественное работоспособное решение, то новый веб-сервис вам даже не понадобится. Просто подключите необходимые компоненты, чтобы вплести это решение в имеющуюся архитектуру и переходите к разработке той области, где первоначальные затраты, связанные с внедрением нового сервиса, могут обойтись вашей организации особенно недешево. Уже сегодня начинайте разъяснительную работу в командах программистов, помогайте им втянуться в процесс, а потом постепенно вводите небольшие легковесные модели SOA в тех сегментах, где можете безболезненно выделить на это ресурсы.
Третий принцип нисходящей SOA: Репозиторий сервисов SOA экономит время разработчиков, которые получают повторно используемые компоненты. Именно поэтому команда должна обеспечивать актуальность всей информации, хранящейся в репозитории.
Почему это не работает: Суть SOA заключается в упрощении разработки, а не в заваливании программистов черной работой. Ваше решение SOA должно автоматизировать составление каталога сервисов.
Как и во многих других посылках, из которых исходят сторонники нисходящей SOA, при данном методе разработчики расцениваются как один из ресурсов, а не как команда профессионалов. Представьте себе, что переход на SOA – это сделка, которую вы предлагаете компании. Предполагаемые преимущества в данном случае заключаются в ускорении разработки, упрощении менеджмента и сокращении необходимой кропотливой работы, связанной с интеграцией. Вот почему возникает серьезный когнитивный диссонанс, когда вы возлагаете на разработчиков обязанности по обновлению репозитория. Фактически, вы обещали им повышение продуктивности и избавление от рутинной работы, а вместо этого взваливаете на них дополнительные неинтересные задачи.
Качественная модель SOA всегда оптимизирует и упрощает работу. При помощи свободно распространяемых компонентов можно создавать замечательные инструменты для организации SOA снизу вверх – например, использовать классы Java с метаданными, которые автоматически заполняют репозиторий информацией о сервисах, либо интегрировать репозиторий в стиле REST, предоставляя их непосредственно разработчикам.
В данном случае речь идет о подходе, который не только не требует на начальном этапе огромных затрат и жесткой привязки к конкретному поставщику. Более того, при таком подходе вы сможете постепенно упрощать работу при помощи дополнительных решений. Ваша SOA-технология продолжит развиваться, по мере работы можно будет оперативно решать новые, ранее не предусмотренные проблемы, ваша архитектура будет постепенно укрепляться и, соответственно, окупаться.
Четвертый принцип нисходящей SOA: Для успешного внедрения SOA в организации должна измениться культура принятия архитектурных решений – такие решения должны быть «эффективными».
Почему это не работает: Основой успешного внедрения SOA является план, построенный на основе ясных, достижимых целевых установок, с хорошо понятными положительными следствиями.
Да, слово «эффективный» очень нравится сторонникам нисходящего выстраивания SOA, описывающим процесс внедрения такой архитектуры. Идея заключается в том, что сервис-ориентированная архитектура настолько благостна, что ее с готовностью возьмет на вооружение любая организация – не только как технологию, позволяющую сэкономить время, но и как идеологию.
Радужные мысли, но они вполне могут похоронить ваши усилия по внедрению SOA, оставив команду без ориентиров. SOA – это не идеология. Это умение решать задачи наиболее простыми и эффективными способами. Команда мотивируется ясными, достижимыми целями разработки, которые должны принести доказанную, несомненную пользу. Умерьте пафос, прекратите расписывать людям, как хорошо продаются программные продукты для SOA. Лучше покажите разработчикам, какие простые изменения внесет такая архитектура в процесс разработки, и насколько это поможет повысить продуктивность.
Восходящая модель SOA – вариант SOA, который действительно работает
Спустя 10 лет безуспешных попыток внедрения SOA следует признать, что традиционный нисходящий метод сервис-ориентированной архитектуры устарел и не оправдал себя. Сегодня требуется новый подход к SOA, который приносил бы реальную пользу.
Основное внимание следует уделить упрощению всех аспектов работы, а не построению «классной» архитектуры, оптимизации уже имеющихся организационных структур, а не огульной пересборке всего и вся. Необходимо прагматично подбирать внедряемые инструменты на уровне рабочих групп, а не взваливать на программистов какие-то баснословно дорогие гигантские системы управления.
Не допускайте, чтобы очередной распространитель SOA приходил к вам, стучал в дверь, нахваливал свое SOA-решение – и вам не придется оправдываться за огромные расходы на приобретение проприетарных софтверных лицензий и обучение персонала. Я уж не говорю о покупке нового аппаратного обеспечения или усовершенствовании систем разработки, что может потребоваться для эксплуатации стандартного стека от конкретного поставщика. Вы видите проблему (или возможность), узнаете, как в настоящее время строятся решения для таких ситуаций, и сами начинаете подыскивать инструменты, которые наиболее рационально было бы применить в вашем случае.
Не бойтесь сервис-ориентированной архитектуры, и уже сегодня начинайте выстраивать ее правильно – снизу вверх.
Источник
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.