Introduction Reactive Microservices

When I first came across the concept of Microservices a few years ago – I couldn’t believe myself that I was stuck on for so long with other styles of architectures. I still remember when we were struggling to come up with a solution to the requirements quoted by a business sponsor. In a meeting lasting only about an hour, all I could pen down was these points as his requirements

  1. It should respond well to unexpected traffic loads in times of season sales and not just give away.
  2. Not investing a fortune upfront in setting up a system that won’t respond well when complete. Results required at every stage of progress.
  3. Work involves company proprietary algorithms, so a team collaboration in on the cards where in-house team would do some part.
  4. It should behave for the user always in the same fashion – season sale or not – response time stays as defined.
  5. Keep it simple 🙂 [Yes I added the smiley in front of him, he didn’t smile though]
  6. Grow the system further when company can invest more. As the company is planning for online airline ticketing business as well.

I think it was just the Friday spirit that kept me from tossing this one pager to the dustbin, however good sense prevailed. Breaking the six points above I could see that demands were not unjustified.

A business investing/relying heavily on online sales is not wrong in expecting a good ROI through sales that their portal can clock. If the sales don’t go through just because the infrastructure becomes unresponsive – then the entire investment is a fail. The system has to be Resilient enough to withstand different problems.

No one likes to wait and business waits for nobody. So the whole experience for the user has to be at the pace that the user wants hence Responsive.

My attempt to address his fears of system not being simple and future growth capable with words like layered architecture, multi layer, clear code documentation and asynchronous were not enough. I was sure that we would have to divide the system much more than what different architectural layers had to offer. So as to enable isolation and simplicity at the same time. This would allow different teams to work on different parts but would not complicate the way all the pieces fit together.

Message driven seemed like an answer to the part of isolation. But what about the simplicity? Let’s make it autonomous was the reply from my business partner. That’s it. That was our complete answer.

If we could make the system Resilient, Responsive, Autonomous and Message Driven – all the requirements seemed to fit together in single place.

Let’s simplify the whole picture now. We need to identify domain boundaries within the system and isolate the functionality to a part of the code that is easy to maintain. This would also own its data as well. For an enterprise level system this could mean a large number of such pieces with each piece resulting in a sequence of domain functions being executed. In order to enable effective communication among these pieces we will utilize message driven communication which would reduce the cost of it. And also keep it simple at the same time.

We must ensure in such a system that all the pieces can exist autonomously so that in case of a failure of a single point the rest of the system can continue normally. This would make such a system resilient. By having multiple instances of these smaller pieces of the system we can balance the load at a much microscopic level instead of just making the whole system as part of the load balancing.

Taking it one step further we need to ensure that changes in the data entities are reflected across the system easily where required and without additional wiring up of complex asynchronous calls. This is where the microservices go from normal to reactive. This is important otherwise the complexity being added for keeping the data up to date would just offset the advantage of smaller pieces to handle negatively.

It is important to note that in such a system the testing part doesn’t start at the end but begins along with the whole system. So in some ways this might a completely new approach for many companies where the current model of project execution brings the testing much later into the picture.

 

 

About Manish Kanwar
Manish Kanwar completed his masters of science in computer applications from MD University, India, and is a cofounder of Innatus Curo Software LLC, with a presence in India. He has been working in the IT industry across domains for the last 17 years. He started exploring .NET right from the first release and has been glued to it ever since.

Be the first to comment

Leave a Reply

Your email address will not be published.


*


13 Shares
Share7
Tweet
Share5
+1
Pin1