This post assumes that you have experience with software architecture and services or curious to know about the current trends and best practices towards a scalable enterprise system.
What exactly are Microservices, how can a business benefit from them and at what cost?
Microservices or MSA Architecture (MSA) is an approach of developing a single application as a set of lightweight, independent collaborating services. This is opposed to the ‘monolithic’ system of software architecture, where the application is rather a single, self-contained unit, capable of performing every step needed to complete a particular function.
Is this a new Fad or Trend?
MSA shares many ideas with the already established term SOA (Service-Oriented Architecture), but done right. This approach really shines when one needs to achieve two simple objectives:
When I was first introduced about this approach by my colleague, I initially thought of this is a new trendy approach of referring to reusable components/ libraries/ SOA’s. But, on a bit more study of my design concepts, did alter me dramatically. My intention is to relay this to the community.
First and foremost, caveats of MSA
For some geeks and some architects, MSA is “the next big thing”, whereas for others it’s simply a lightweight evolution of the SOA that we have used years ago “done right”, but by no means it’s a silver bullet since I would hate to have developers jump in for the wrong reasons.
From my experience, there are different ways to build software systems. On the one side we have traditional monolithic systems, where everything is bundled up inside a single deployable unit. This is probably where most of the industry is. Monoliths can be built quickly and are easy to deploy, but they provide limited agility because even tiny changes require a full redeployment. We also know that monoliths often end up looking like a big ball of mud because of the way that software often evolves over time. For example, many monolithic systems are built using a layered architecture, and it’s relatively easy for layered architectures to be abused (e.g. skipping “around” a service to call the repository/data access layer directly).
On the contrary, MSA architectures buys you a lot of flexibility and agility because each service can be developed, tested, deployed, scaled, upgraded and rewritten separately, especially if the services are decoupled via asynchronous messaging. The downside is increased complexity because your software system now has many more moving parts than a monolith.
Back to the objectives;
Fine-grained responsibility
While designing a system, the diagram starts as a strictly layered architecture (presentation, business services, data access) with all arrows pointing downwards and each layer only ever calling the layer directly beneath it. The code unfortunately tells a different story though and the eventual diagram now becomes a spaghetti which no one wants to revisit.
Fault-tolerance built-in
In-process method calls, are replaced with external calls between components. The big difference is that external calls are much more likely to fail. And they will. This requires attention but taking care of it appropriately makes your whole system much more stable and fault-tolerant by design already.
It’s up to you whether you go for a library that handles the issue for you or if you want to take care of it yourself but don’t make the mistake of not taking care. Fault tolerance really is a central issue. Getting it done right early on is the key for success with MSA adoption.
Is it being used just because they are sexy?
It seems as if teams are jumping on MSA because they’re sexy, but the design thinking and decomposition strategy required to create a good MSA architecture are the same as those needed to create a well-structured monolith. If teams find it hard to create a well-structured monolith, I don’t rate their chances of creating a well-structured MSA architecture. As Michael Feathers recently said, “There’s a bit of overhead involved in implementing each microservice. If they ever become as easy to create as classes, people will have a freer hand to create trouble – hulking monoliths at a different scale.”
Who is using MSA?
Netflix, Gilt, PayPal, Conde’ Nast, Liferay have been re-architected to build highly scalable and volume sites and the best part, its technology agnostic.
The adoption and the future
The community has been growing rapidly and is bringing lots of good tools that make building, deploying and maintaining MSA much easier. MSA is going to take that path how Agile took over from a Waterfall model of development. My recommendation would be to not push your developers, but you need to first believe and make them a believer in this approach via small steps of success until they get the idea of what microservices are all about.
If you are intrigued, there is a very fine article published by PwC: Agile coding in enterprise IT: Code small and local.
