I come from a background in the VOIP industry. I have worked all my career on delivering cutting edge Unified Communication solutions which were large scale, distributed, real time systems. We prided ourselves on building extremely complex systems but with elegant design (Or so I think). The architectures were tiered with distinct and clear boundaries and well defined interfaces between them. Our systems had several components – Application Servers, Network Servers, Registrars, Proxies, Location Servers – each serving distinct roles and running on independent machines (although there were some overlap in functionalities depending on how you configured and deployed them) and they all collaborated over the network to serve a common goal.
Each of these in turn was a monolith – these systems were so huge and complex that it was really hard to understand them in it’s entirety by any one person. Note that this is in spite of following good design principles, brought on by the sheer size of the system. The teams were structured around the tiers in the architecture so that each team was isolated to their areas of expertise. Any person new to the team took months to understand the system well and make a decent contribution.
Leap forward to now and I’ve been casually looking at the architectures of distributed, extremely large scale companies and Microservices is the word I keep coming across. With my curiosity in high gear, I was intrigued enough to look in depth into this phenomena sweeping the software land. Well it turns out that you can think of Microservices as a way of doing SOA (just like how Scrum is a way of doing Agile).
We had tried our hand at SOA using SOAP,WSDL,RPC, proprietary integration protocols etc and it never did deliver on the promises. One of the biggest concerns in VoIP is the latency that is introduced by every network call and the aim is to always minimize it, to satisfy the real time requirements of the system. So we moved away from anything that added to the latency. Hence the monolith systems where all calls are in-process and calls across the network are minimized.
So my own experience had led me to rest the case on SOA and I thought all this time that it was one dead paradigm. Turns out that I’ve been wrong, very wrong. Google, Amazon, Netflix, SoundCloud, Twitter and many more companies have all been using SOA for years and have kept it alive, thriving in fact. Amazon and Netflix actually called their architecture ‘SOA’ before renaming to Microservices.
Google claims to have the largest ecosystem of Microservices – Here is what they say :
Over the years, Google has developed underlying systems and technologies to support the largest ecosystem of micro-services in the world; our servers make tens of billions of calls per second within our global datacenters. At this scale, nanoseconds matter.
Yes, you read it right, it says tens of billions of calls with nanosecond latencies. (Source)
Matt McLarty, author of the book ‘MicroService Architecture’ calls it the Agile software architecture (Source):
Just as agile development solves an engineering bottleneck, microservices solve an architectural bottleneck.
With so much of empirical evidence, there is no denying that Microservices are indeed an important architectural style that is worth considering for any large scale complex system. My gut feeling has been one of disbelief but empirical evidence beats gut feeling.
With that I’ve decided to embrace this architecture style and dig into it in depth. I’ll be writing a series of posts about it and hopefully it will intrigue some of you enough to join me on the not so micro journey.