The rise of the microservice based architecture style is undeniable. If you scroll through hacker news or browse the /r/programming subreddit you’ll see some mention of the style somewhere.
Many believe the microservice based architecture to be the goal state in terms of perfect software architecture design. For many applications it does make sense, it provides you with a number of key benefits such as improved resiliency, graceful degradation, elasticity and so on.
However, the process of migrating our systems will be a long and arduous road and we may never get to our desired goal state without some major changes in developer mentality, the education system and the high barrier to entry that is the complexity of distributed systems.
Management Mentality
The number of developers eager to pursue better architecture styles and refactor existing monoliths is growing. The issue doesn’t lie with the developers mentality, it lies within upper management.
Whilst refactoring work is performed and teams are upskilled to better deal with the complexities of distributed systems, no new work can be done. In stable companies this may not be as big an issue as they already have that dedicated user base but for newer companies looking to cut out their slice of the market, this may be a huge drawback.
Upper management in most situations will opt for working on new features or newer versions of products in order to potentially earn more in terms of revenue. They subsequently chase shorter term gains as opposed to solidifying their current software ecosystem and migrating towards a newer architecture style.
The Education System
In order for us to start migrating to this newer style of architecture, pressure needs to come from both the top (the management) and the bottom (the graduates). This means that newly recruited graduates coming into the workplace need to be able to understand the differences between a monolithic and a microservice based architecture style.
We are taught key concepts such as design patterns and the SDLC whilst at university in the later years, but could more emphasis be placed on looking at architectural styles like this?
This is something I’m torn about, whilst the microservice style of architecture seems to be here to stay and not just some passing fad, does this mean we put more of a strain on the students coming up through courses like Software Engineering and Computer Science to learn these?
As an aside: I would highly recommend any newly graduated programmers Sam Newman’s book: Building Microservices: Designing Fine-Grained Systems
The Complexity of Distributed Systems
This is undoubtedly the highest barrier to entry for all developers. Before universal adoption of this style of architecture can take place, we need to improve the tooling across the board in order to make the lives of those managing these distributed systems easier.
Tools like Zipkin, Kubernetes and Docker are certainly starting to smooth the transition into this style of architecture and AWS’s new EKS (elastic kubernetes service) is a huge step forward in terms of progress but we need more players to step up.
Eventual Consistency vs Strong Consistency
One of the key challenges when it comes to dealing with distributed systems is consistency. Having to manage this consistency across your tech stack poses a challenge when compared to traditional architecture styles and you have to be aware of the cost of things such as Strong consistency and how it can severely impact performance in some scenarios.
This represents just one of the biggest issues developers will most likely face when faced with designing systems that should span the globe across hundreds or potentially thousands of microservices.
Conclusion
These were just a few of my thoughts and I am no way set in stone about any of these. When I write articles like these I am in no way saying that everything I have written is absolute, I am merely trying to get the conversation started.
If you have any comments on what I’ve written above then please feel free to let me know in the comments section below or by getting in touch with me on twitter: Elliot Forbes.