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.