«Облегченные» SOA: шаблоны и принципы нового поколения SOA-решений

  • Статья

Хесус Родригес (Jesus Rodriguez) (Jesus.Rodriguez@tellago.com) — главный архитектор в Tellago, Inc. Также является Microsoft BizTalk Server MVP, Oracle ACE и один из немногих архитекторов мира — членов группы Microsoft Connected Systems Advisor.

Дон Демзак (Don Demsak) — старший архитектор решений в компании Tellago, проживает в Нью-Джерси. Специализируется на разработке корпоративных .NET-приложений. Ведет популярный блог www.donxml.com, является Microsoft Data Platform MVP и членом INETA Speakers Bureau.

В статье рассматриваются некоторые типичные проблемы традиционных архитектур, ориентированных на сервисы (service-oriented archi tec tures, SOA), и рассказывается о том, как решить эти проблемы, используя более масштабируемые и гибкие архитектуры, лучше поддерживающие взаимодействие, которые мы предпочитаем называть «облегченными SOA».

Введение

В течение последних нескольких лет мы были свидетелями того, как традиционные подходы к архитектуре, ориентированной на сервисы (SOA), постоянно не справлялись с задачей повышения гибкости и эффективности бизнеса, а ведь это было ключевым преимуществом, предлагаемым SOA. Пожалуй, причины такой ситуации в излишней сложности, присущей традиционным технологиям SOA, например протоколам SOAP и WS-* или корпоративным шинам сервисов (enterprise service buses, ESB). В результате появляются альтернативные облегченные реализации SOA, основанные на таких архитектурах, как Representational State Transfer (REST) и Web-Oriented Architecture (WOA), и постепенно доказывающие, что они более гибкие, чем традиционные подходы SOA.

SOA: создание архитектур без ограничений

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

  • применение SOAP и WSDL как фундаментальных стандартов на интерфейсы сервисов;
  • использование протоколов WS-* при реализации возможностей корпоративных сервисов, критически важных для бизнеса;
  • развертывание централизованной ESB, позволяющей абстрагироваться от различных механизмов управления сервисами;
  • использование сервера интеграции для реализации сложных бизнес-процессов;
  • использование средства управления SOA, позволяющего управлять всей SOA.

Весьма просто, не правда ли? Идеальная SOA-инфраструктура должна выглядеть примерно так, как на рис. 1.


Рис. 1. Идеальная SOA

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

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

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

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

  • SOAP и абстрагирование от транспорта;
  • неправильное использование языков описания;
  • сложность ESB;
  • взаимодействие на основе протоколов WS-*;
  • управление SOA.

Далее мы подробно рассмотрим каждый из этих вопросов и исследуем альтернативные подходы к архитектуре, которые помогут разработчикам в реализации более надежных SOA-решений.

SOAP и иллюзия абстрагирования от транспорта

Существующее поколение SOA-решений развивалось на основе принципов Simple Object Access Protocol (SOAP). Этот протокол изначально предназначался для того, чтобы сервисы могли абстрагироваться от используемого транспортного протокола. В принципе, взаимодействие с SOAP-сервисами может осуществляться по самым разным транспортным протоколам, например по HTTP или MSMQ. Хотя теоретически это отличная идея, из практики мы усвоили, что обеспечиваемая SOAP независимость от транспорта связана с существенными издержками, которые можно было бы уменьшить, отказавшись от такой независимости, когда она не нужна. Один из лучших примеров ограничений, связанных с независимостью от транспорта, — применение HTTP при доступе к конечным точкам SOAP-сервисов.

Подавляющее большинство сервисов SOAP использует в качестве транспортного протокола HTTP. Однако при связывании по протоколу HTTP в SOA используется совсем небольшое подмножество спецификации HTTP — всего лишь метод POST и пара заголовков. В результате SOAP-сервисы, основанные на HTTP, не используют многие возможности HTTP, благодаря которым он стал самым популярным и масштабируемым транспортным протоколом в истории компьютерных систем.

Если SOAP и дал нам что-то хорошее, так это использование XML, которое коренным образом расширило возможности взаимодействия между распределенными приложениями. Однако мы должны признать, что SOAP не оправдал первоначальные ожидания, и вот почему: первоначально SOAP позиционировался как простой протокол доступа к объектам; но, как оказалось, он не простой, не используется для доступа к объектам, и, пожалуй, это даже не протокол.

Неправильное использование WSDL

Язык описания веб-сервисов (Web Service Description Language, WSDL) — одна из важнейших спецификаций в портфеле SOA. Предназначение WSDL — описание возможностей сервисов, например того, какие сообщения может принимать или отправлять сервис, или того, как эти сообщения кодируются при передаче по протоколу SOAP. В принципе, WSDL — результат эволюции предыдущих языков описания, в частности Interface Description Language (IDL), который был ядром таких технологий распределенного программирования, как COM и CORBA. WSDL, основанный на аналогичном шаблоне, быстро стал фундаментальным артефактом, который клиентские приложения использовали для генерации «прокси»-представлений, скрывающих детали взаимодействия с сервисом.

Несомненно, идея генерации прокси-артефактов в соответствии с WSDL-описаниями сервисов может упростить взаимодействие клиентов с сервисами в очень простых средах. Как и в случае предшественников WSDL, основная проблема такого подхода в том, что возникает уровень связи между клиентом и сервисом. В случае крупных SOA, когда имеются сотни сервисов и клиентов, уровень зависимости «сервис-клиент», как правило, является причиной серьезных проблем в управлении сервисами и контроле версий (рис. 2).


Рис. 2. Зависимости отWSDL-описаний — большая проблема в крупных реализацияхSOA

С ESB или без ESB?

Бесшовная интеграция гетерогенных специализированных бизнес-систем (line-of-business, LOB) как составной элемент бизнес-процессов — одна из перспектив корпоративных SOA-систем. Такие возможности интеграции обычно обеспечиваются с помощью набора типовых шаблонов, образующих каркас того, что в свою очередь рассматривается специалистами отрасли как одна из основ SOA, — корпоративной шины сервисов (enterprise service bus, ESB).

Хотя в отрасли нет формального стандарта, определяющего, что представляет собой ESB, как минимум можно обнаружить ряд общих черт, свойственных различным ESB-продуктам. Обычно под ESB понимают набор фундаментальных возможностей, таких как сопоставление протоколов, управление взаимодействием сервисов («хореография сервисов»), адаптеры для бизнес-приложений, распределение сообщений, преобразования и обеспечение надежности. Теоретически можно применить это сложное средство для обеспечения взаимодействия между сервисами и системой, сделав ESB «стержнем» предприятия (рис. 3).


Рис. 3. ЦентрализованнаяESB

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


Рис. 4. Реалии примененияESBна крупных предприятиях

Безумие WS/*

После создания первой волны спецификаций SOA несколько поставщиков технологий объединили усилия, стремясь описать ключевые возможности предприятия, такие как защита, надежный обмен сообщениями и транзакции в рамках модели SOAP/WSDL. Результатом этих усилий стал набор спецификаций вроде WS-Security, WS-Trust и WS-ReliableMessaging, которые стали называть протоколами WS-*. Если не считать несомненного академического интереса, спецификации WS-* не нашли широкого применения в гетерогенных средах.

Ограниченность распространения WS-* на предприятиях в конечном счете можно считать следствием того, что в течение последних нескольких лет появилось невероятно большое количество спецификаций WS-*. В настоящее время имеется более сотни различных версий протоколов WS-*, лишь несколько из которых нашли реальное применение в SOA-решениях. Несомненно, самым сложным аспектом решений, основанных на WS-*, является взаимодействие, поскольку различные инструментальные наборы для разработки веб-сервисов реализуют различные протоколы WS-*, различные версии одних и тех же протоколов и даже различные аспекты одних и тех же спецификаций. Кроме того, применение WS-* в основном ограничено экосистемами .NET и Java, из-за чего эти протоколы совершенно нецелесообразно использовать, когда требуется реализовать в SOA-решениях такие новейшие парадигмы программирования, как динамические и функциональные языки (рис. 5).


Рис. 5. Проблемы взаимодействия на основе протоколовWS-*

SOA: руководство или диктатура?

Управление и руководство должны занимать центральное место в любой средней или крупной SOA. Когда мы предоставляем доступ к бизнес-возможностям через сервисы, важно продумать контроль версий, развертывание и мониторинг сервисов, а также управление ими. Этот набор функций предоставляется платформами управления SOA, как правило, основанными на принципах спецификации UDDI (Universal Description, Discovery, and Integration).

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

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


Рис. 6. Централизованная модель управленияSOAнецелесообразна для крупных реализацийSOA

Знакомьтесь с облегченными SOA

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

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

В последующих разделах статьи вы ознакомитесь с некоторыми шаблонами и архитектурными методиками, которые, как мы уверены, решат некоторые из проблем, описанных в предыдущих разделах. В основном мы сосредоточимся на следующих аспектах:

  • применение RESTful-сервисов;
  • взаимодействие по протоколам WS-*;
  • федеративные ESB;
  • «облегченное» управление SOA;
  • переход на обработку данных в облаке.

Задействуем Интернет: RESTful/сервисы

В предыдущих разделах мы рассмотрели различные ограничения фундаментальных конструктивных элементов традиционных SOA-систем, таких как XML, SOAP, WSDL и протоколы WS-*. Хотя веб-сервисы не зависят от транспорта, подавляющее большинство их практических реализаций использует протокол HTTP. Такие сервисы с взаимодействием по протоколу HTTP должны (по крайней мере, теоретически) работать аналогично системам, основанным на доступе через Интернет. Однако различные уровни абстракции, созданные поверх протокола HTTP, не позволяют этим сервисам в полной мере использовать возможности Интернета.

Чтобы решить некоторые из этих проблем, в SOA-технологиях начали применять более дружественные к Интернету архитектурные стили, такие как REST. Первоисточником REST была докторская диссертация Роя Томаса Филдинга (Roy Thomas Fielding), в которой он сформулировал принципы, превратившие Интернет в систему с самыми большими возможностями масштабирования и взаимодействия в истории программного обеспечения. В сущности, системы, поддерживающие REST, моделируются на основе ресурсов, адресуемых URI и доступных через взаимодействие по протоколу HTTP без хранения информации о состоянии. Следуя принципам REST, можно проектировать сервисы с высокой масштабируемостью, в полной мере реализующие идеи, на которых основан Интернет.

Несомненно, REST стал весьма привлекательной альтернативой веб-сервисам SOAP/WS-*. Применение REST позволяет преодолеть некоторые ограничения традиционных веб-сервисов, например обеспечить более широкие возможности взаимодействия и масштабирования.

RESTful-сервисы предоставляют следующие возможности:

  • задание ресурсов с помощью URI;
  • обмен информацией по протоколу HTTP;
  • обеспечение взаимодействия между системами;
  • взаимодействие без хранения информации о состоянии;
  • использование форматов агрегирования (syndication);
  • поддержка нескольких представлений ресурсов;
  • отношения, основанные на ссылках;
  • обеспечение масштабируемости;
  • кеширование;
  • стандартные методы.

Простота с точки зрения потребителя и высокий уровень взаимодействия RESTful-сервисов — факторы, позволяющие сделать новое поколение SOA-решений гораздо более гибким.

Взаимодействие по протоколам WS/*

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

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

Например, рассмотрим ситуацию, когда требуется защитить веб-сервис, к которому будут обращаться клиенты .NET, Sun Metro, Oracle WebLogic и Ruby. В этом случае можно реализовать три конечные точки с различными конфигурациями системы, зависящими от возможностей потребителей (рис. 7).


Рис. 7. Шаблон использования нескольких конечных точек сервиса

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

Облегченные федеративные ESB

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

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


Рис. 8. Шаблон федеративнойESB

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

Облегченное управление

Ограниченность применения UDDI в крупномасштабных SOA-средах послужила катализатором для развития более «легких» и лучше поддерживающих взаимодействие моделей управления SOA, в которых использовались такие новые архитектурные стили, как REST и Web 2.0. В сущности, целью этих новых моделей было избавление от некоторых сложностей, присущих централизованным архитектурам, основанным на UDDI, за счет замены UDDI широко распространенными стандартами, в частности HTTP, Atom и JSON.

Одна из самых популярных моделей управления SOA основана на идее репозитария RESTful-сервисов. В этой модели традиционные SOA-конструкции, такие как сервисы, конечные точки, операции и сообщения, представляются как ресурсы, к которым можно обращаться через набор RESTful-интерфейсов. В частности, весьма привлекательна возможность использовать стандарты, ориентированные на ресурсы, например Atom и Atom Publishing Protocol (APP) при представлении артефактов SOA и взаимодействии с ними (рис. 9).


Рис. 9. РеестрRESTful-сервисов

В этой модели предлагается более «легкий» и гибкий подход к проектированию и управлению во время выполнения. Например, такие аспекты управления во время выполнения, как разрешение конечной точки сводятся к простым запросам HTTP GET к RESTful-интерфейсам. Пожалуй, основное преимущество такого типа управления — возможности взаимодействия, доступные благодаря использованию RESTful-сервисов, которые позволяют расширить управление SOA, дополнив .NET и J2EE гетерогенными технологиями, таким как динамические или функциональные языки.

Добро пожаловать в облако!

Развитие моделей обработки данных в облаке приводит к тому, что подходы к построению распределенных систем постоянно меняются. В частности, мы полагаем, что следующее поколение SOA-решений будет сочетать облачные и работающие на предприятии (onpremises) сервисы и инфраструктурные компоненты. Влияние облачной обработки данных ни в коем случае не ограничивается возможностью выполнять веб-сервисы в закрытых или общедоступных облаках. Существует ряд компонентов инфраструктуры SOA, которые можно напрямую вызывать из облачных сред, дополняя традиционные SOA-технологии, работающие на стороне предприятия (рис. 10).

Рис. 10. УсовершенствованиеSOA, работающей на предприятии, за счет применения облачных инфраструктур

Рассмотрим некоторые примеры.

  • Шина сервисов в облаке — может ли ESB функционировать в облачной инфраструктуре? Конечно, да! Такой подход к использованию ESB позволяет задействовать возможности, которые являются краеугольными камнями ESB, функционирующих на предприятиях: маршрутизацию сообщений, публикацию/подписку, преобразование и управление сервисами.
  • Сервисы защиты в облаке — последние несколько лет мы наблюдали, как сервисы защиты наподобие Windows Live ID и Facebook Connect получали все большее распространение. Использование облачных инфраструктур защиты позволяет реализовать механизмы безопасности, поддерживающие взаимодействие на основе API для веб-сервисов, доступных через Интернет: аутентификацию, представление идентификаций, авторизацию и создание федераций.
  • Сервисы хранения данных в облаке — хранение данных с помощью сервисов, подобных Amazon S3 и Azure DB, пожалуй, является самой привлекательной возможностью облачных инфраструктур. Использование сервисов такого рода существенно увеличивает гибкость и способность к взаимодействию механизмов обмена данными SOA и в то же время устраняет некоторые сложности, присущие хранению данных на предприятии.

Заключение

Традиционный подход к SOA приводит к серьезным проблемам, из-за которых он становится нецелесообразным для крупных реализаций. В этой статье мы предлагаем ряд шаблонов, которые помогут разработчикам создать более «легкие», масштабируемые и способные к взаимодействию SOA, сделав бизнес крупных предприятий по-настоящему гибким.

Абстрагирование от транспорта

Подумайте о том, чтобы взять за стандарт протокол HTTP. HTTP — отличный «облегченный» вариант, взаимодействие по этому протоколу поддерживается многими инфраструктурами.

Используйте SOAP и WS-*, когда необходимы поддержка транзакций, надежный обмен сообщениями и крайне высокая производительность (при использовании TCP/IP).

SOAPиWSDL

Если вы уже решили сделать HTTP стандартом, в применении SOAP и WSDL нет особой нужды. Постарайтесь задействовать такие технологии, как REST, JSON и Atom Pub, и по максимуму используйте Интернет.

Не используйте SOAP и WSDL, если вы не уверены в необходимости обеспечиваемых ими возможностей.

Подумайте о применении облегченных стандартов — REST, JSON и Atom Pub.

Не соблазняйтесь тем, что побочным эффектом создания сервисов SOAP является генерация WSDL-описаний. Продумывайте контракты заранее.

Управление и обнаружение

Как же управлять корпоративными сервисами, если WSDL не используется? Конечно, с помощью реестра сервисов! UDDI потерпел неудачу, но это не значит, что репозитарий сервисов не нужен, просто UDDI был слишком сложный и решал не те проблемы. С помощью облегченного реестра сервисов, основанного на RESTful-сервисах, также можно обеспечить управление и обнаружение, не сталкиваясь со сложностями UDDI.

Храните артефакты своих сервисов в каком-либо репозитарии, а не просто как параметры конечных точек.

Используйте репозитарий сервисов как средство управления сервисами вашей корпорации.

Подумайте о применении репозитария RESTful-сервисов для обнаружения SOAP- и RESTful-сервисов и управления ими.

Корпоративная шина сервисов

С ESB или без — вот в чем вопрос. Взаимодействия «точка-точка» приводят к жесткому связыванию и просты в реализации. Но такие взаимодействия, по своей сути, ненадежны, препятствуют развитию систем и ограничивают возможности бизнес-анализа, доступные при обмене сообщениями.

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

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

Не воспроизводите в ESB шаблоны «точка-точка» с жестким связыванием, просто перенося код в систему с ESB. При разработке распределенных систем подумайте об использовании механизма публикации и подписки при обмене запросами и ответами.

Сервисы в облаке

В облаке есть все — похоже, надо взять курс на его использование. Microsoft немного опередила время со своей концепцией My Services, но теперь все больше и больше сервисов ориентировано на работу в облаке.

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

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

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

Ресурсы по данной тематике