The Internet Doesn't Run on a Bus—Your APIs Shouldn't, Either
There is no bus in the internet. It is the caller’s responsibility to make the right call. Yes, there's a broken link or two on the internet, but then one of the two parties fixes it and the problem doesn't last too long.
The world of internal APIs looks like the figure on the right, not the one on the left. Don’t move into the future using a bus architecture. DON’T.
- The scale of thousands of microservices and billions of internal calls rules out the monolithic architecture on the left.
- Connectors are legacy; every service will expose clean, RESTful APIs.
- Orchestration is pushed to code and logic within the services; what remains is much less onerous.
- Stable interactions are less common; things change in months, not years.
- Centralization of interaction is an antipattern
Keep your current integration architecture. Definitely. But build your future around APIs, and not integration architectures masquerading as APIs.
For more on this topic, check out the eBook, "Beyond ESB Architecture with APIs: How APIs Displace ESBs and SOA in the Enterprise."
Thoughts? Comments? Questions? Join the conversation (or start one) in the Apigee Community.