Microservices Architecture – In a nutshell

The year is 2015. Netflix, breaks out with its newly software development technique – ‘Microservices’ (effort that started in 2009). Their huge success encouraged many development teams across the world, and today it’s considered best practice.

So, what is this concept, and were Netflix really pioneers when it comes to this architecture? Or was it always here under our noses? Bear with me.

First of all, Let’s talk about the era before microservices. Say we have a social media web app, where users can upload photos, message other users, create groups and events etc. This was used to be implemented using a Monolith – one large application, that communicates via HTTP protocol with a client (browser).

This Monolith was responsible for all logic acts taken by the client, such as chat messages, uploading videos and photos, profile management, group management, etc.

One might say – this sounds about right! The truth is, it is. Monolith architecture has been with us for a while and it has its pros – one single repository and a single database. Simple. Fast to develop. “Simple is better than complicated” – Key aspect in software development (this famous line is from the Zen of python – written by python creators themselves).

But where this architecture falls (big time)? you guessed it: Scalability (the ability to grow & change dynamically according to client needs). As our app grows bigger, more features are requested and more developers are in on the project. This could lead to many developers working on the same code-base! File conflicts, data conflicts and more are becoming a daily routine. Suddenly, our application feature delivery rate becomes slow. Slow feature delivery means unhappy customers. Unhappy customers mean loss of money.

Here comes microservices design. This architecture is all about splitting those logic responsibilities into separate micro software developed apps (called ‘services’), therefore the name ‘microservices’. Like everything in life, this architecture is by no means perfect. While we try to encapsulate each microservice from the rest, they are all part of the same project. They often need to communicate (with each other and with a shared client), share data and share code. Suddenly what was easy while writing a monolith, becomes complex and harder to manage. When designing & writing a monolith, there’s no need to worry about communication and sharing data between multiple HTTP servers.?Of course, there are several design patterns to make our life easier when it comes to solving those problems (i.e. API Gateway – [invented by Netflix themselves], Event based communication etc.). The introduction of docker technology to the world – made deploying a microservice much easier.

But those are simply solutions to problems that pretty much didn’t exist before. One might say – overheads.

So why does this architecture remain the best practice while designing & building current software applications? Because of where it really shines, you guessed it (again): Scalability. Separating our logic services & databases, solves all the problems mentioned above in the monolith introduction, allowing us to deploy (using CI/CD pipelines) hundreds of independent services (each responsible for a different logic process) in a single day! Now, several developers can work in parallel without worrying about conflicts. Therefore, our application can handle large scale, and keep our feature delivery fast & furious and our clients happy.

Although it seems like Netflix were pioneers when it comes to this design concept, truth is – breaking down one big problem into many separate and independent little problems and handling each one on its own, has been here formally since the beginning of Game Theories and practically since the beginning of time.

I encourage you to read “Games and Decisions” by R. Duncan Luce and Howard Raiffa, it explains pretty well the splitting technique and how it helps us to solve problems and riddles – both in science (tech, math, physics) and in life.