Многие рассматривают микросервисы как результат эволюции сервис-ориентированной архитектуры (Service Oriented Architecture, SOA), считая их новым поколением SOA. Однако это не совсем так. Хотя технология микросервисов действительно построена на базе SOA, в ней кое-чего не хватает.

Как утверждает независимый консультант и программный архитектор из Бостона Марк Ричардс в онлайновой брошюре «Microservices vs Service Oriented Architecture», между этими архитектурами есть различия, которые следует учитывать в каждой конкретной ситуации при выборе подходящего решения.

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

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

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

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

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

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

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

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

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