Why Microservices Should Be Event-Driven

Why Microservices Should Be Event-Driven

Why Microservices Should Be Event-Driven

I want to quickly paint the picture in my head about distributed systems (maybe it’s a sloppy picture, but nevertheless). When we talk about microservices, we talk about using microservices as a vehicle for building business Agile IT systems, or systems that allow a business to more quickly change, build new functionality, experiment, and stay ahead of its disruptors and competition (startups, etc.).

As part of autonomous systems that interact with each other to provide business agility, we also need to consider what happens when parts of these systems fail and how a System reacts to overcome failure. A central pre-requisite to being able to build Agile, failure-tolerant systems is autonomy. Autonomous systems can evolve independently from each other because they tend to shed dependencies on other systems, teams, and processes. Changes to a service A shouldn’t force System B to change, nor will there be any other ripple effects. If service A (on which service B depends) goes down, service B should not just blow up.

Where do we have examples of this autonomy in other systems outside of microservices? Well, if you follow the real reasons why microservices are a success, then you know it’s not the technology per se that enables Netflixes and Amazons of the world to be successful with microservices: it’s the organization system structure.

Read Also:
What you missed in Big Data: Open-source power

Some examples of these same types of Agile systems include open-source communities, cities, stock markets, ant colonies, flocks of birds, and countless others. They can evolve, react, and even continue on in the face of massive failure. In fact, they’re a well-studied bunch in the field of Complex Adaptive Systems theory. The underlying common themes between these systems? Purpose, autonomy, and reaction to their environments. These autonomous agents react to events.

When something happens, an autonomous agent (ant, person, service) can do something or do nothing, but it’s these events that drive the behavior in complex adaptive systems. Think about how you (as an autonomous person) do things throughout the day. You wake up, you dress based on the temperature (an event or fact), and you get in your car and drive to work (stopping at stop lights, avoiding the people driving erratically, and partaking in other events). These are all responses to events. You get emails in your inbox, you respond. You get a text from your wife to pick up dinner on the way home, etc. We live our entire life responding to events. IT systems built on events can be made to be equally autonomous, scalable, and resilient to failures.

Read Also:
Global governance is what makes big data valuable

In most distributed systems implementations I’ve seen, we tend to extend the notion of building systems within a single address space to building across an unreliable network. This is a bad idea for many reasons, but many times, it appears to be the simpler approach. We tend to invoke remote objects to prod them to do something, or we call a remote service to look up data. Maybe the tax service is the canonical location for anything to do with tax calculations. If we’re a shopping cart service, we need to calculate the final price for the items in a shopping cart during checkout. So, the shopping cart service calls the pricing service. The pricing service may also call the tax service to do some other adjustments to the price based on shipping location (country, state, city, etc.). The tax service may call the catalog service (taxes may be different depending on product). The shipping service may also call the inventory service, etc.

We may end up with these long strings of calls (which may be okay in monolith application where all these objects live in the same address space, etc.). We’re following the authority pattern of accessing data; we call the service that has authority over the data.

Read Also:
How to find the real value in operational big data

 



Data Science Congress 2017

5
Jun
2017
Data Science Congress 2017

20% off with code 7wdata_DSC2017

Read Also:
Cloudera, Hadoop and the changing role of data in business

AI Paris

6
Jun
2017
AI Paris

20% off with code AIP17-7WDATA-20

Read Also:
Why Facebook, Amazon, Microsoft, and Google all desperately need you to know that the robots are coming

Customer Analytics Innovation Summit Chicago

7
Jun
2017
Customer Analytics Innovation Summit Chicago

$200 off with code DATA200

Read Also:
Why Facebook, Amazon, Microsoft, and Google all desperately need you to know that the robots are coming

Chief Data Officer Summit San Francisco

7
Jun
2017
Chief Data Officer Summit San Francisco

$200 off with code DATA200

Read Also:
Data science: What does it mean and how is it best applied?

HR & Workforce Analytics Innovation Summit 2017 London

12
Jun
2017
HR & Workforce Analytics Innovation Summit 2017 London

$200 off with code DATA200

Read Also:
Data Frankenstein: Bringing Old Business Data Back to Life

Leave a Reply

Your email address will not be published. Required fields are marked *