Microservices is a variation of the service-oriented architecture (SOA) that organizes a core application into a collection of loosely coupled single-function service modules. It has seen a large degree of hype over the last few years due to its scalability and agility – but does it live up to it?
Let’s unpack the similarities and differences between SOA and microservices and explore why a business should – and shouldn’t – take them on
A service-oriented architecture (SOA) is an approach to creating software applications that focuses on reusability and ensuring that non-functional requirements (like security, scalability, and performance) are met.
Although there is no formal definition of what a microservices architectural style must look like, they each have a similar set of characteristics. The architecture is made up of multiple, independent components that are loosely coupled and light-weight.
And instead of teams focussing on areas of the system like UI and database as they would in an SOA, for microservices they are organized around specific business outcomes that bridge system functions – like a product or service.
Service-oriented architecture and a microservice architecture differ essentially in three aspects:
SOA is made up of a portfolio of applications and services operating at the enterprise level, requiring developers to have a complete understanding of the application and all its dependencies in order to code successfully.
Microservices, on the other hand, is an application architecture. It breaks-down a single application into multiple independent services, each serving a specific functionality. In other words, each functionality does one job very well, reducing the scope of understanding developers need to work on each module. However, it also reduces the ease at which code can be re-used between functionalities.
In short, where microservices is inward-looking – into the internal architecture of the application – SOA is concerned with the enterprise level architecture.
SOA is “coarse grained”, meaning it focuses on large, business-domain functionalities. As a consequence of this, each functionality has a long list of dependencies.
Microservices is much “finer grained”, creating a mesh of functionalities that each has a single focus called a bounded context. Each bounded context is independent – only loosely coupled – and far more focused than the domain functions of an SOA.
This also makes microservices far more scalable than SOAs, as they can be built grain-by-grain.
SOA requires a software that handles communication. Historically, businesses have used web service access protocols like SOAP to expose, and then transact with, each functionality. But connecting all a business’s applications together negatively affects the system’s scalability and can require time-consuming maintenance.
This is why SOA uses a middleware tool called an Enterprise Service Bus (ESB) that handles the communication and reduces the number of point-to-point connections between functionalities. However, ESBs also create a single point of failure: should the ESB go down, then all the SOA services would be inaccessible.
When it comes to a microservices architecture, each individual service operates and scales independently and so each has their own separate point of failure, making microservices far more resilient and agile, and enabling the independent coding of each individual functionality.
Microservices architectures are highly scalable applications designed to reach millions of users, like Netflix, Twitter and Amazon. They are cloud-native architectures focused on achieving high levels of agility and autonomy. And thanks to the granularity and independence of these services, you can achieve a fluid, continuous delivery of service.
But all this begs the question – why wouldn’t you use microservices?
By breaking down a system into these fine-granular pieces, you create one that is incredibly complex. And with complexity comes consequence.
One symptom of this complexity is that the Atomicity, Consistency, Isolation, Durability (ACID) rules of a database no longer apply equally across the microservices mesh of functionalities at all times. The set of rules depicted by ACID aim to guarantee data integrity against errors, failures and mishaps across a system. For example, Atomicity dictates that a transaction in a system must be either successful or unsuccessful.
But across a microservice mesh, this is not so simple. Instead, this atomicity is eventual. Eventually the whole system will be consistent, but this is not the case for each individual transaction.
This makes microservices an architecture that is far more challenging to build, maintain and run.
Businesses and enterprise architects must be aware of the complexity they are buying into before they invest in a microservices architecture. It’s not uncommon for an organization to commit to microservices and find that the large disruption far outweighs the potential returns.
It’s vital that a business reflects on what exactly the problem is they are attempting to solve. And more importantly, asking if there is a simpler solution that doesn’t completely granulize and distribute their existing infrastructure.
Do you have a business like Amazon or PayPal? Do you need a highly scalable, high-performance cloud-based system that will complete millions of transactions per minute? If so, then maybe it’s time to bite the bullet and begin exploring the complexity of microservices.
But you will also need to consider the significant addition to your developer talent and the complexity of your processes.
Microservices are not a panacea. They have their pros and cons and poor implementation can lead to unworkable situations that do nothing to solve the desired challenges.
For businesses who aren’t looking to carry the burdens associated with microservices, you can find more about Microservice Architectures in OutSystems or explore OutSystems Domain Driven architecture.
