Microservices is the new kid on the block! Getting all the attention (for good or bad) as naturally as the new kid would.
Before we get into what is Microservices let’s get into Why Microservices? To understand that, I’ll throw another jargon first; SOA (Service Oriented Architecture). Since it has been around a while I’ll just throw in the Wikipedia definition.
Service-Oriented Architecture (SOA) is an architectural style that supports service-orientation. Service-orientation is a way of thinking in terms of services and service-based development and the outcomes of services.
The earliest I’ve got my hands dirty on this was a distributed system built for Sony Ericsson portal. We had a CMS based website, E-Commerce, Retail Portal and Content Media downloads all talking to each other via producing and consuming XML files (not SOAP).
Microservices architectural style came into existence by further refining the SOA architecture (IMHO) to make the definitions perhaps more contextual or formal than the one above. It was noticed that keeping these services small and most importantly independently deployable is one of the key differentiators or refinements to the SOA paradigm. While there’s nothing in SOA that says how these services should be composed, a lot of teams (this writer included) did tend to drift towards creating very heavy services over REST APIs spewing XMLs and JSON. Which would again lead us to the similar (if not same) problems on the n-tier architecture.
Microservices is a growingly common accepted architectural style to get away from the pains aforementioned. I’d how ever like to say that to my eyes Microservices seems to have stemmed from bad interpretation and implementation of SOA than a problem with SOA in itself.
I’m yet to see a more formalised definition than this of microservices but the following certainly figure routinely
Let’s delve deeper into these terms and what they might bring about.
This seems coming more from the concept of “Domain Driven Design”, where we model our systems in a way they represent the real world through code. Looking deeper in to Domain Driven Design I often wondered is this classic object modelling applied at a large scale system (my seniors at work certainly think I’m right). I also think this might have to do more with with Hexagonal Architecture introduced by Alistair Cockburn. Whatever it might be; the intent is clear we have to have a way of services talking to each other how departments would have worked in getting the same job done.
We’re well in the age of Continuous Delivery and DevOps so it is imperative that we ensure our services use these practices so as to ensure teams have greater throughput while modelling complex architectures and systems. Continuous Delivery on microservices isn’t that common yet, but I believe we’d see this becoming a norm sooner than later, as no other mechanisms would actually fit release management of multiple distributed small microservices.
This one is interesting. We’ve all usually seen large schemas which hold all of organisation data in one place. So what would decentralise possibly mean? Simply put it means moving to this architecture
How this works when you are fetching relations, is topic we’d address in a separate blog post; you can argue that it would be a violation of Single Responsibility Principle if such an API endpoint exists in the first place, but then I’d say it’s not as simple as that. Hence would dedicate a separate topic on this. Some clues are in the next section!
Microservices architecture avoids using the heavy centralised bus based communication which has been the prevalent norm in a lot of enterprises for making services talk. Does that mean we’re throwing away Mule and likes completely? Well, at first glance it certainly seems so. What we do here is implement messaging link pretty similar to Unix pipes, i.e. they “just” relay messages and nothing else. AMQP has been a good candidate for this, so RabbitMQ becomes a natural choice. The Services that send messages to these pipes however are in complete control of what, when and how to send. There are multiple approached of making services talk; which again are aspects we’ll delve in detail later on.
It’s early days for Microservices and I agree most of the practitioners would still be discovering all answers, but it looks worthwhile giving a shot as the promise of microservices lies in keeping things simple, and adding a context of what is a “good”way of making services work with each other. I’m hopeful microservices patterns, as they emerge, wouldn’t go down the SOA way! Until then, happy coding!