Astronomy, Human, and Microservices

Copernicus was an astronomer and mathematician and who formulated a model of the universe that placed the Sun rather than the Earth at the center of the universe (from Wikipedia).

This model was a groundbreaking concept in that era. As before Copernicus, it was thought or believed that earth is the center of the universe.

Almost same mistake many architects, developers and thought leadership in a company doing right now who are obsessed with the idea the data is the center of the IT landscape/universe. This is based on the view that data means job done, it can be stored, viewed, updated and deleted using a command like a request. The reason for this view is – data is simple.

source: Gartner “CIO Challenge: Adopt Event-Centric IT for Digital Business Success,”

It is ok to have this view if architects, developers and thought leadership in a company stayed with this view and stayed away from microservice. As they move toward microservice with this view enterprises ends up making the whole bunch of microservices with databases at their core, which will result to many tightly coupled application areas that can’t share data in a fast and flexible. So, in a way organization end up a different type of monolith application after spending tons of money and time which is doomed to have the same monolithic issues and fate.

So now THE question would be what should be center of microservice world/universe? Simplest answer: Events

If organization want to increase agility and speed through microservice, they need to replace the static data-driven thinking and have a desire to get to the right event, right API at the right time

It is all about Event

Now let’s think of our own body, We are designed to react and act on the events that arrive via our senses of vision, taste, smell, hearing, and touch. We receive these different events in mind, replay it and act upon required action that again results in the new event for our surrounding/universe to react. Similarly thinking of event-driven designs turns the organization into the sensory system into the universe of IT. When a new event sensed by any sensors like UI, IOT or event sent by any other systems due to others action or reaction. Just like our own sensory system fires event to the central nervous system – A microservice which will be able to receive an event and act on it and produce a new event for another system to act upon.

Not adopting event-driven thinking will be a great block to the success of digital transformation and will result in increased cost and decreased productivity

 

So what should we do – “Application leaders engaged in digital transformation initiatives must add ‘event thinking’ to their technical, organizational and cultural strategies.” source Gartner Business Events, Business Moments and Event Thinking in Digital Business,

 

Synchronous vs. asynchronous

 

Now, as we are talking about the event, another interesting concept we need to talk and understand. Since the beginning of IT, our desire is always to make these systems behave near or like how human behaves/reacts.

Keeping that in mind lets discuss how we host a party at home. We invite family and friends at home prepare food, have fun discussions/games.

Now let’s see how synchronously it will work.

Invitation -We will email/phone family friend and invite them, but now we will not do anything but keep waiting for them to respond. Because we are synchronous and we are worried if we will do this asynchronously, someone might forget to respond, and we will have missed invitation.

Food preparation –  Let’s say we are preparing something tasty in the oven. Now as it is synchronous, we will have food in the oven and will keep waiting there and not go back and entertain guest as we are worried that oven might have some fault and food will burn. So instead of trusting of oven timer, we will wait there till foods get ready

Discussion and fun- Again as we are synchronous, we will have everyone sit in the same area and listen to every discussion and if one person wants to eat, go out or something else. Everyone will wait for him to return and till then, all will be silent and waiting. Because if we do asynchronous, then he will miss the discussion.

 

Now would you like to host such a synchronous party? No. because this will not be fun and we can do all this asynchronous and have a great time. So, let’s revisit part in the asynchronous mode

 

Invitation -We will email/phone a family friend and invite them but now we will not wait for a response and will do other work. We will have reconciliation in place to see whom all responded vs. invited and non-responders can get reminder call or email to ensure they respond.

Food preparation –  Now as we are asynchronous. We can put food in the oven and go back and have fun. If still, we are worried about oven faulty timer, we will put audit/error control and have alarm also set on the watch for the same duration.

 

Discussion and fun- Now that we are asynchronous, everyone is independent and do things they like. Whoever is interested in food will enjoy feed, the discussion will continue, and the interested party will have fun there.

 

Now we will have fun, and we just put one-time controls to make sure everything’s goes smooth.

 

Why not the same we should do with Microservices and event. As we saw, there is the benefit of asynchronous processing, and with correct controls, we can address most of the concerns. These controls will be one time but time, and resource saving is huge.

 

 

Self-sufficient/contained

 

Let’s go and buy pizza. So, for Pizza store needs flour, vegetable, sources, cheese, meats. Now think a world where you go to the pizza store and ask for pizza. They will take the order and ask us to wait as they will have someone go to grocery store pick up all the ingredient and then they will prepare Pizza for us.

Why grocery store? Because they are not authorized to sell needs floor, vegetable, sources, cheese, meats. Moreover, authorities might be worried that they will tell the price or quality or other details of these items so forced Pizza store not to store it and get it from the grocery store. Now if the grocery store is closed, the Pizza store will also have to close as they are tightly coupled.

 

Is this pizza buying a good experience?

Let’s think of another experience where we went to the Pizza store and asked for pizza, they have all the ingredient stored, and they will prepare pizza from those ingredients. Now if you want just vegetable, for flour they will not sell as they have these ingredients for internal use only. So, we want to buy anything other than Pizza we must go to the grocery store. However, now the pizza store in not tightly coupled and work independently.  Moreover, it will be Pizza stores responsibility to ensure the quality of floor and vegetables by reconciliation, quality check, putting an expiry date on that stuff.

Why not microservice behaves like a pizza store. It can store all the details needed for that microservices to complete own task independently. It should be only for internal purpose. Moreover, it should be a microservice responsibility to guaranty the accuracy of those data.

 

Event-driven and Choreography

The very first step towards adopting the event-driven design thinking is to change the way we think about architecting and designing solutions. The normal/old way is to think about all interactions between services as a series request/response service calls in a sequence. In fact, few most used words from design and development world are “calling,” “invoking, “or “requesting” which is a sign of thinking in the pattern of command/orchestrator style.

Instead, we should start talking in terms of: “What events should my service process?” and “What events will my service generate?”

Once we start talking in these terms, we can say we shifted our mindset from orchestration to choreography. Then we can start applying principles of choreography. Going with the example of a sensory system, API/services should react to changes in the environment just link mind reacts.

 

 

To be continued ….