Martin Fowler expands on what a microservices architecture is all about.
A lot of the concepts are similar to SOA, so I’m gradually trying to understand what the practical and philosophical differences (and similarities) are. Here’s one:
When building communication structures between different processes, we’ve seen many products and approaches that stress putting significant smarts into the communication mechanism itself. A good example of this is the Enterprise Service Bus (ESB), where ESB products often include sophisticated facilities for message routing, choreography, transformation, and applying business rules.
The microservice community favours an alternative approach: smart endpoints and dumb pipes. Applications built from microservices aim to be as decoupled and as cohesive as possible – they own their own domain logic and act more as filters in the classical Unix sense – receiving a request, applying logic as appropriate and producing a response. These are choreographed using simple RESTish protocols rather than complex protocols such as WS-Choreography or BPEL or orchestration by a central tool.
Also I’ve been pondering services granularity and RPC vs the coarse grained calls of SOA. In this regard microservices seem closer to the SOA approach if anything:
In a monolith, the components are executing in-process and communication between them is via either method invocation or function call. The biggest issue in changing a monolith into microservices lies in changing the communication pattern. A naive conversion from in-memory method calls to RPC leads to chatty communications which don’t perform well. Instead you need to replace the fine-graining communication with a coarser -grained approach.
Are microservices made of the clear design principles of SOA but without all the heavyweight implementation details of SOAP, WS* standards, XML and all the rest of it. More reading needed!