Microservices: The magic in the middleware

For those of you who haven’t read Martin Fowler’s seminal article on microservices; you should. It’s considered gospel, one of the definitive pieces for microservices experts. Many of us have learned a lot from Fowler over the years; yes I confess I read UML Distilled. And so I have a confession to make about microservices to Fowler, which seems even more appropriate with the Pope visiting the US this past week. It’s also appropriate because of the Webinar that Randy Heffner from Forrester and Mark O’Neill did this past week on Digital Business and microservices.

Bless me, Fowler, for I have sinned against microservices. I have worked on an architecture that:

• Componentized logic as services
• Organized around business capabilities
• Delivered products that could be reused
• Deployed smart endpoints with dumb pipes
• Decentralized by supporting many languages and tools, not just one
• Decentralized data management
• Automated deployment across the languages
• Was completely decentralized with no point of failure
• Supported an evolutionary design

Microservices and SOA: And I called it SOA … 10 years ago

Now, granted, this was somewhat different from the normal SOA architectures, and ahead of its time. But I think Fowler would have spotted the issues even with this architecture, and you need to as well. Because while in many ways SOA is the same, it is also VERY different from microservices, and it’s important we understand the differences if we’re going to succeed with API Management and digital business.

This confession, if it had actually happened, might have led to the following conclusions about the differences between SOA and microservices today, slightly reordered:

1. APIs are real products
2. APIs require smart endpoints with dumb pipes.
3. APIs require evolutionary design
4. APIs require continuous delivery
5. Microservices are organized around business capabilities
6. Microservices need to have decentralized governance

It’s easier to understand the difference if you understand the different goals. The goal of SOA was to lower the time and cost of integration by moving from monolithic application development and integration to composing reusable services. When done well it could reduce integration times down to weeks or a few months. It usually took a specialized center of excellence doing everything, and most of the “customers” were apps that weren’t designed to be integrated. So they needed to be tricked into thinking everything was fine as part of the integration. Read how APIs and microservices are changing the ways people think.

Differences

The first big difference is that APIs are real products. SOA never delivered products, and never had many teams. With SOA and APIs, you need a product manager who designs each API from the outside-in, for the outside developers who consume the APIs. The API is a product that cannot be easily changed either.  It’s a contract with those customers.

Second, APIs require smart endpoints with dumb pipes. If you expect the API to be consumed, it needs to be very loosely coupled. And while we said Web services were loosely coupled, that wasn’t true, for the most part. Many Web services were designed to be part of a process, an orchestration. The design of the inputs and outputs, the error handling, was all built into the process you called. With an API, it’s much simpler. You get customer information, or you update customer information. If either fails, as the client you need to handle it, and so does the logic behind the API. With APIs, you have smart endpoints and dump pipes, not orchestrations that deliver smart pipes.

Third, APIs require evolutionary design, because APIs are products with clear contracts for outside customers. With SOA, you had control over the consumers, the apps, because most of the time they didn’t even know about SOA.  They were being integrated in such a way that they weren’t even aware of the outside world. The only other consumers, other SOA developers, were in a small team completely controlled by the company. If you needed to change something, you just changed it. With APIs, the developers are your customers, and your success is driven by their use of your APIs. If you change APIs in a way that makes their life harder, they could replace your APIs with a better alternative.

Fourth, APIs require continuous delivery, because you need to move at the speed of the customer’s expectations, not at the pace of app integration projects. Most business executives will tell you they need new mobile applications, new external services, even changes to new cloud services in days or weeks, not the 3-18 months that are needed to deliver new projects in SOA or existing systems.  Adopting Agile and a DevOps approach is now a necessity.

Fifth, microservices are organized around business capabilities. They are the magic in the middle that makes it possible to both deliver continual change AND preserve an API contract.  The best architectures usually have at least two layers of “APIs”. AThe first layer is often called the microservice, private API or inner API layer. They sit on top of existing applications and SOA and group functionality together into business capabilities. For example, an internal API might exist to update an account or customer information. The second layer, which sits on top of these APIs, is often called the public, or outer API layer. These public APIs, assembled out of the private APIs using orchestration or some other technique, are the APIs that shouldn’t change quickly.

The magic in the middle, in the microservice layer, is in the design of the microservices.  If they’re designed properly to group business capabilities together, making any changes to support new business requirements will only require changing at most a few APIs at a time, and can be hidden behind the public API interfaces.

Lastly, microservices need to have decentralized governance. It’s not like SOA, where there was a specialized team with centralized governance. Every part of the company can be responsible for delivering their own business capabilities, and their own public APIs. So each group needs to be able to implement their microservices and APIs in their own tools of choice, and in their own timeframes, in order to be able to move quickly. But they also need to own those APIs and commit to the customers of those APIs that they will stick to their contracts.  Only then will the magic in the middle work, and only then will customers continue to use your APIs.

Hopefully, this helps explain the difference between SOA and API management, and what microservices are, how they’re the magic in the middle that lets you deliver continuous, rapid change AND preserve your contract with your customers. Go read Fowler’s definitive piece on microservices.