Эволюция транспорта: от CORBA до Service Mesh

В 1999 году Amazon строил книжный магазин на CORBA и Java EJB. В 2006 запустил AWS. Эти события связаны: болезненный опыт с enterprise middleware заставил Amazon полностью переосмыслить распределённые системы. Понимание истории объясняет почему REST выглядит так, gRPC устроен именно так, и чего ждать от следующего поколения.

• **Amazon Bezos Mandate (2002)**: 'All teams will henceforth expose their data through service interfaces. No exceptions.' Ответ на CORBA-эру tight coupling. Это foundation AWS и modern microservices
• **Google Protobuf** используется для 100% internal RPC с 2001 года - 14 лет до open source. Stubby (внутренний) стал gRPC после 1 млрд вызовов/секунду на Google scale
• **HTTP/3** первым крупным deployer стал Google: весь youtube.com, google.com трафик через QUIC с 2020. Cloudflare обрабатывает 30%+ запросов через HTTP/3 в 2024

CORBA и RPC эра

1990-е: распределённые системы строились на CORBA (Common Object Request Broker Architecture) и Sun RPC. Идея: вызов метода на удалённом объекте должен выглядеть как локальный вызов. CORBA скрывала network за IDL (Interface Definition Language), генерируя stubs на C++/Java/Ada. Microsoft ответила DCOM (Distributed COM). Амбициозно - и катастрофично на практике.

Jeff Bezos в 2002 году выпустил 'Bezos Mandate': все команды должны коммуницировать только через service interfaces, без direct database access, без shared memory. Это был ответ на CORBA-эру tight coupling. Mandate заложил основу AWS SOA архитектуры. Команда не следующая мандату - fired. Жёстко, но именно это сделало Amazon масштабируемым.

SOAP и XML эра

2000-е: SOAP (Simple Object Access Protocol) - попытка сделать CORBA через HTTP с XML. W3C стандарт, WSDL для описания сервисов, WS-Security для auth, WS-Transaction для distributed transactions. Работало через firewall (HTTP!), vendor-neutral. Microsoft .NET и Java EE активно продвигали. SAP, Oracle, IBM строили enterprise интеграции на SOAP.

SOAP живёт до сих пор: PayPal SOAP API (legacy), Salesforce SOAP API, большинство банков (SWIFT, SEPA интеграции). Замена SOAP в энтерпрайзе - многолетний проект. Российские банки и ФНС до сих пор используют SOAP для B2G и B2B интеграций (ФНС API, ФСС, ПФР). Если приходится работать с SOAP - обёртки типа Zeep (Python) или node-soap делают жизнь терпимее.

REST революция

2000: Roy Fielding в диссертации описал REST (Representational State Transfer) - архитектурный стиль основанный на ресурсах, uniform interface и stateless. Amazon (2006) публично перешёл с SOAP на REST для AWS API. Twitter (2012) REST API стал стандартом для social platforms. GitHub API (2012) - образцовая RESTful реализация. REST победил за счёт простоты: curl, browser, любой HTTP client.

REST до сих пор доминирует для public API: Stripe, Twilio, Shopify, Twitter. Причина: maximum developer accessibility - любой разработчик с curl может интегрироваться без специальных инструментов. Для внутренних microservices тренд смещается к gRPC, но public API практически всегда REST или GraphQL.

gRPC и Protocol Buffers

2015: Google открыл gRPC - внутренний RPC фреймворк Stubby переработанный для open source. Protobuf для сериализации (10x меньше JSON), HTTP/2 для транспорта (мультиплексирование), строгие контракты через .proto файлы, кодогенерация для 10+ языков. Google использует Protobuf для миллиардов внутренних вызовов в день. Kubernetes API server - gRPC.

GraphQL (Facebook 2012, open source 2015) - альтернативный ответ на REST limitations. Вместо binary protocol: flexible query language, single endpoint, клиент запрашивает только нужные поля. GitHub перешёл на GraphQL v4 API в 2016 - первый крупный публичный GraphQL API. Shopify, Twitter (Threads), Airbnb используют GraphQL для internal и external API. gRPC vs GraphQL: gRPC для microservice-to-microservice, GraphQL для client-facing API.

Future Trends

2020-е тренды: **HTTP/3 + QUIC** (IETF RFC 9000, 2021) - UDP-based, устраняет TCP head-of-line blocking, нативный connection migration (смена Wi-Fi->4G без разрыва). **WebTransport** - QUIC для браузера, заменит WebSocket для low-latency gaming и real-time. **AsyncAPI** - OpenAPI для async протоколов (Kafka, WebSocket). **Service Mesh** (Istio/Cilium) переносит TLS, retry, circuit breaker из кода в инфраструктуру.

AI/LLM меняет API ландшафт: streaming tokens через SSE стал стандартом (OpenAI, Anthropic, Gemini), MCP (Model Context Protocol) - новый стандарт для tool calling в AI агентах. WASM (WebAssembly) + WASI позволяет запускать server-side код в browser environment без сериализации - потенциально новая парадигма для edge computing. Но: большинство production систем в 2025 году работают на REST + gRPC + Kafka - 'boring technology' выигрывает.

Итоги

• **Эволюция не линейна**: CORBA (1991) -> SOAP (1998) -> REST (2000) -> gRPC (2015) -> каждый шаг решал конкретные боли предыдущего, но создавал новые trade-offs. SOAP не исчез, gRPC не заменил REST
• **Каждая парадигма оставила след**: 8 fallacies от CORBA, WSDL контракты в SOAP, resource-oriented thinking от REST, binary serialization и streaming от gRPC - всё это живёт в современных системах
• **Boring technology выигрывает**: 99% production систем в 2025 году работают на REST + gRPC + Kafka. HTTP/3 и WebTransport - будущее, но не сегодняшний production выбор для большинства компаний

Связанные темы

История транспортов объясняет почему существуют современные паттерны:

• gRPC и Protocol Buffers — gRPC - прямое наследие CORBA идей (remote = local) но с правильными trade-offs: явные ошибки, streaming, binary. Понимание истории объясняет дизайн-решения gRPC
• Event-Driven Architecture — EDA - ответ на CORBA и SOAP tight coupling. 'Bezos Mandate' заложил идею service interfaces через events. Kafka - современная реализация того что CORBA пыталась решить через CORBA Event Service
• Decision Matrix — История показывает: нет одной правильной технологии. Decision Matrix из предыдущего урока - формализация уроков эволюции: разные протоколы для разных задач

Вопросы для размышления

• CORBA обещала 'location transparency': remote call неотличим от local. gRPC не делает такого обещания. Но junior разработчики иногда обращаются с gRPC вызовами как с локальными функциями - не добавляют timeout, не обрабатывают network errors. Как это проявляется в production и как с этим бороться?
• REST Fielding определил в 2000 году, HTTP/2 в 2015, HTTP/3 в 2021. Какие ограничения REST (как architectural style) сохраняются независимо от версии HTTP, и какие были решены переходом с HTTP/1.1 на HTTP/2?
• Service Mesh (Istio) переносит retry, circuit breaker, mTLS из кода приложения в инфраструктуру. Это звучит как абстракция в стиле CORBA: 'скрыть network complexity'. Чем Service Mesh отличается от ошибок CORBA, и в чём потенциальные риски того же класса?

Связанные уроки

• net-54-rpc