Jonathan White
Integration Architect
Setting Something Straight
Let’s be honest. How many times have you seen, or perhaps even drawn, a diagram that looks something like this:
That makes sense, right? A monolith is packaged and deployed as a single large application; SOA is made up of coarsely-grained web services; Microservices are finely-grained interconnected services. Right?
WRONG.
Microservices Architecture (MSA) isn’t a refinement of SOA in the same way that a power drill isn’t a refinement of a nail gun. MSA provides a completely different approach to designi and deliver business functionality. Like nails and screws, one is not objectively better than the other, which one to use depends on the context of the solution and the wider goals of the organisation.
This blog looks at the differences between SOA and MSA and what considerations should be taken into account if choosing between them.
Redrawing the Picture
There are several problems with the first picture.
The first and most critical one is that it completely misrepresents what a proper MSA is. The second is that it is overly simplified. What are these nameless circles? Where does the data reside? How are users interacting with the application or services?
Let’s re-draw the diagram and address both these issues.
Admittedly, this looks a lot busier, and is less likely to be used in glossy marketecture. This represents the differences in frameworks clearer and shows MSA as an alternative solution to large scale application design.
Let’s look into this in more detail.
The Monolith
Monolithic architecture remains as expected. The user interfaces, application code, and datastores are all contained within a single packaged application. These components of the application are tightly coupled and often proprietary to the particular ERP, CRM, or whatever function the application is fulfilling.
SOA
SOA aims to model reusable services, and their organisation. It does this by layering functionality on top of common IT assets such as databases and ERPs.
The Services themselves are not bound to the underlying technology, but follow three basic layers:
- Data (or System) Services provide low-level CRUD operations to the assets
- Process services orchestrate these operations to achieve a business process
- Presentation services provide entry points tailored for the end-user interface
An ESB pattern is usually implemented with SOA to provide the routing, mediation, and transformation of messages between services.
MSA
A Microservices Architecture looks a lot like a monolith with a smaller font size. This is because a true Microservice encapsulates everything it needs to accomplish its function. This includes unilateral control of its data, technology and quite often the team that develops and supports it.
If a service must call another service in order to fulfil its function, then it is — by definition — NOT a Microservice.
This can be confronting, because it often means that Microservices are larger than people might expect. In fact, a Microservice may even contain multiple interfaces, API specifications and technology layers.
To quote Kyle Brown from his excellent article on right-sizing Microservices:
“A Microservice should be ‘small’ in comparison to the enormous monoliths that came before it. However, it shouldn’t be too small — trying to make your Microservices too tiny is probably one of the most common mistakes teams fall into when attempting to implement a Microservices architecture.”
Kyle Brown
Although Microservices won’t rely on external services to fulfil their function, they may emit ‘events’ during that fulfilment. These are actual business relevant events that occur as a result of an operation on a Microservice. Other services (micro or non) receive these events as a processing input.
Note that eventing between two microservices does not break the principle of function encapsulation. The service producing the event has no reliance on the services which receive it, and for the recipient the event is just another inbound interface for the service. It fulfils its function in response to the event with no reliance on other services.
Choosing a Path
Any organisation that designs a system (defined broadly) will produce a design whose structure is a copy of the organisation’s communication structure.
— Melvin E. Conway
It’s easy to say, “choosing between SOA and Microservices”, but it in reality unless you’re in a green-fields start-up or are deliberately re-evaluating an organisations enterprise architecture, it’s not a decision that will present itself.
SOA and MSA should be enterprise-wide architectural frameworks, not decisions which are made on an application-by-application basis.
If the decision is being made, there are some key factors which feed into the decision. These include:
- Preference for custom applications, or Common Off The Shelf (COTS)
- The existing technology and integration landscape
- The operating model of the business
- The DevOps maturity of the organisation
Preference for Common Off The Shelf (COTS)
Organisations that purchase COTS applications quickly find the functionality is not within the control of their developers. This if often bundled into the application codebase, and technology layer.
This type of application is best suited to SOA, where Services can be used as facades to mediate, route and transform the application to work the way they need. SOA is not bound to the underlying technology and relies on Services having dependencies on lower layers to execute the functionality.
Microservices are fully encapsulated, meaning they own the ability to deliver changes to the functionality they provide, and are the sole owner of the underlying data and technology stack.
Existing IT Landscape
The existing IT infrastructure and the way the company operates it has a large bearing on the type of systems it can provide.
In a traditional organisation, teams exist that are focused on the capabilities of networking, application support, development, and business analysis. These are the common shared services that exist to support development.
New organisational models are more product-focused with smaller cross-functional teams managing the entire technology stack. These organisations have self-service technology platforms and pipelines, allowing them to be small and autonomous.
In a shared services organisation, a SOA is best suited as the Services and facades are not bound to the underlying technology or systems. Teams can expand or contract around a capability as required to support the entire organisation.
An MSA is the best fit for a focused cross-functional product team. This will allow the team to focus on their one purpose for existing, and provide them with the autonomy over their technology stack to achieve this.
Operating Model
Conway’s Law, quoted earlier, can be extended to suggest that an organisation will architect systems that mirror their own operational structure. SOA and MSA have very different operating models, so attempting to follow one that does match the way that the company operates to begin with is likely to end in heartbreak.
SOA lends itself to a centralised IT team who is responsible for delivering IT services across the organisation. Because SOA has a focus on service re-use the architects and developers of each service must be familiar with all services available to avoid duplication of effort and maximise re-use.
MSA, by contrast, must be delivered by domain-oriented teams. A team will ‘own’ a Microservice and be empowered to make decisions (within organisational guidelines) on the technology the service is implemented in and how it is deployed.
DevOps Maturity
Shift Left. Static Code Analysis. Continuous Everything. Image Scanning. Golden Signals. Single Artefact. Self-Cleaning Tests. GitOps. Feature Flagging.
The list of buzzwords for rapid software delivery is nearly endless. Every organisation is at a different maturity level when it comes to their adoption of the DevOps mentality. I’m going to quote Kyle again:
“Don’t try to adopt Microservices at scale unless you already understand and have successfully implemented Agile approaches and DevOps Principles such as automated testing and continuous integration. Make sure you can walk the walk before you talk the talk.”
– Kyle Brown
A key goal of MSA is to enable the rapid delivery of features to Production. This allows businesses to deliver value to their users and to adapt to change quickly. The processes and technology of the business need to be mature enough to support this.
If a deployment must be scheduled for a weekly CAB and run through various suites of manual testing before being given a spot in the monthly release window, then it’s probably best to stick with a more traditional architecture.
Conclusion
If you’re spending time and money on integration, then you want to make sure that you are spending that time and money wisely.
It’s all too easy to spin digital wheels churning out bespoke point-to-point ‘smart pipes’ and creating integration spaghetti.
A deliberate integration architecture which considers the existing state of the organisation and the overall strategic goals of the business is required to move the needle towards interoperability.
Service Oriented Integration (SOI) in its various flavours (including SOA and MSA) provides patterns, principles, and approaches to achieve this. The devil, as always, lies in the details.
SOA is focused on reusability. Services are built to suit specific needs, but dependencies are built between these services. This increases the risk of changing any one service.
MSA is focused on autonomy. This allows teams to move fast and break things, but has a higher risk of introducing technical debt.
Not everyone likes the same thing. What works for Netflix might not work for a Bank. Instead of chasing after the latest buzzwords, invest in an Integration Strategy (I know people who can help there), and make decisions that that suit your particular situation.