​Why are microservices not just SOA done right?

[#1]

There is a lot of published opinion on microservices versus SOA. I think most of these discussions miss the point. Here is an analogy to help explain why.

Shipping containers have revolutionized global trade. If you tried to understand shipping containers by just looking at what they are—metal boxes into which goods are packed—you would probably be mystified. You only start to understand shipping containers when you see them stacked onto ships, loaded and unloaded at major ports around the world, transferred to trucks for final distribution and so on. When you see those processes in action, you start to understand why a simple metal box of a standard size can have a major impact on the speed, efficiency and security of global trade.

Comparing microservices to SOA is like comparing a shipping container to open-hold ships without considering how they are used. To understand how microservices are used, you should look at the custom-built platforms for micro-services, like Kubernetes, Netflix OSS and mesos/marathon. If you like, these are the container ports for application code. If you understand what these platforms do and how they do it, you will have really understood microservices. If you try to understand microservices by just looking at the microservices themselves, you risk missing the point. I wrote a blog post on this topic and would appreciate your feedback. What do you think?

[parna]

We are seeing more & more enterprises building a "microservices layer" with 100s of them being built.

The blog post would help us better articulate what the architects should be thinking while defining them.

Two questions:

1. As you mentioned the microservices should be able to communicate with each other; what role does an API platform play there? Should a microservice communicate with another microservice via an API platform?

2.Should microservices be "combined/mashed-up" to expose as a service for the consumer layer thru an API platform?

[alan]

Here are some thoughts to answer your question @parna@apigee.com:

Microservices, just like monolithic services, needs to deal with security / governance / visibility. The difference is 10-100x scale. Instead of 10s services connected in a hub & spoke model, Microservices involve 100s to 1000s of services connected in a Point-2-Point fashion. The complexity within a single datacenter mimics more of how services are connected across the internet. That's why API Management platforms - initially built to scale with connecting applications across the cloud, work so well for managing internal microservices too.

Obviously, I'm bias - even microservices should be exposed through a gateway, with all the management capabilities of an API platform. Reality is, the line between "external APIs" and "internal APIs" is blurred, because as soon as an internal API is delivering value, businesses would want to expose those APIs externally. Using a common set of API Management technology to manage both just makes sense to drive the highest amount of agility for an organization.