I’m trying to crystalize my own thinking around what microservices are, and how they differ from traditional SOA services.
Microservices are clearly a form of SOA service, which we can also call Web services (…a method of communication between two electronic devices over a network…). Some people will say that microservices are just SOA services, and this is just a new name for something we’ve been doing before. The reality though is that building applications using microservices is about quite a bit more that the architecture of the services themselves. Sure, some of the rules or guidelines that define microservices (Martin Fowler and James Lewis above describe 9 characteristics in their seminal post) do relate to the architecture of the services, but others are about things external to the microservice itself. The things that appear to me to distinguish microservices from any other service-oriented architecture are the inclusion of DevOps principals, particularly configuration as code, and the strong bent towards containerization as popularized by Docker. One thing I’ve seen and heard a fair bit is that Microservices is SOA+DevOps+Containers, and I think this is a reasonable way of thinking about it from a marketechture perspective.
I’d like to be a bit careful though. While microservices is the intersection of SOA, DevOps, and Containerization, it is certainly not all of each of these things.
- Not every SOA service will be a microservice. Many SOA services are exposed from existing monolithic applications to enable enterprise integration scenarios, and are definitively not microservices, in fact, very few SOA services will display the characteristics of a microservice.
- Not all DevOps programs will be in place to support the development and operation of microservices. It really doesn’t matter how an application or service is architected, it can benefit from an agile approach to development and operations.
- Not all containers will be running microservices. From the webopediea article above, “containerization is a lightweight alternative to full machine virtualization”. You can run anything in a container; it doesn’t have to be a microservice.
Think of it as the left side of the diagram, not the right.
Another thing to consider is that Containerization in this context is an enabler for Continuous Delivery and so should really be considered part of DevOps, but from a mindshare perspective, and as an easily consumable way of thinking about how some things fit together the Venn diagram above works quite well.
Of course the microservices paradigm involves a lot more than this simplistic view, in upcoming posts I’ll ponder how we can reconcile the need for containers to be immutable with the need for a microservice to own its own data, and will start to discuss when you should use SOA services, APIs, and Microservices.