Телеграмм чат группы cloud

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

После прочтения одного артикула, свербить стало уже не на шутку - это далеко не первый раз, когда люди зачем-то смешивают два независимых термина - ESB (Enterprise Service Bus) и Service Mesh.

Хуже только когда говорят: "Х это новый Y". Так например @SinTeZoiD на записи подкаста пизсказанул, что Service Mesh это новый ESB (ссылку не найду, ищите сами). И ладно бы только Миша! Подобное я слышу слишком часто и не могу молчать, когда коллеги по цеху несут такую околесицу.

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

По сути у вас ставится некая центральная система регистрации, в которой указаны все узлы/прокси сервисов. Сервис А узнает у SM адрес сервиса В, а затем общается с ним напрямую.

Собственно, причем тут, мать его за ногу, ESB? Да ни при чем.

ESB в свое время тоже возник как идея, вокруг которой ушлые вендоры понастроили своего ИСКОННОГО инструментария, из-за чего всю идею благополучно просрали (но это уже другая история).

Для тех, кто не застал те времена, когда веб состоял из PHP, единственной промышленной СУБД был Oracle, а WebLogic и WebSphere делили между собой рынок enterprise-сектора, поясню - тогда было очень сложно подружить между с собой системы, построенные по модели SOA (Service-Oriented Architecture). RPC всех проблем не решал, да и настроить общение между программами, разработанными на Java и .NET, было тем еще приключением.

Поэтому умные дяди решили, что неплохо бы иметь такую ШИНУ, куда все дружно и стандартизированно будут писать и читать.

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

Итого, ESB:
1) берет на себя накладные расходы по работе с входящими и исходящими данными - маппинг, трансформацию и т.д.
2) предоставляет определенный стандарт и протокол обмена данными, одинаковый для всех.
3) само собой обеспечивает маршрутизацию и отправку данных туда-сюда.
4) обеспечивает сохранение данных до востребования
5) обспечивает "слабую связность" (loose coupling) между сервисами.

Таким образом под ESB-системами можно считать:
1) весь проприетарный мусор созданный жадинами из Oracle, IBM, RedHat и т.д.
2) системы очередей сообщений (MQ)
3) системы передачи потоковых данных (Amazon Kinesis, Apache Kafka)

Важно понимать, что ESB не имплементируется на "полшишечки". Либо соблюдай все целиком, либо трусы надень.

Собственно поэтому SM никак не является ESB. Не ведитесь на мудаков. Если кто-то (включая меня) будет уверять вас в этом - "гоните их, насмехайтесь над ними".

P.S. Честное слово, хуже только те, кто называет Kubernetes операционной системой для дата-центров.

InfoQ

Service Mesh Ultimate Guide: Managing Service-to-Service Communications in the Era of Microservices

This online guide aims to answer pertinent questions for software architects and technical leaders, such as: what is a service mesh? Do I need a service mesh? How do I evaluate the different service mesh offerings? In software architecture, a service mesh is a dedicated infrastructure layer for facilitating service-to-service communications between microservices, often using a sidecar proxy.