"Permit me then, in lieu of this more commonplace soubriquet to reveal the identity of this rather dramatic persona."
Imagine you have a web application; it's attracting HUGE traffic. Now, to scale this, you have two options, really:
nginx in my case.Microservices make horizontal scaling easier.
So, in that web application, say you had a some part which processes the payment. Now, if it's not an instantly-delivered-good (digital), you can hold the processing of the payment back by a couple of minutes. This increases the throughput (max. number of clients performing an operation per second), because you don't have a context lock (waiting for something to finish). Another thing, you can have the processing of the payment integrated within the application code.
Now, you can do this the bad way: process instantly. The problem here is that you wouldn't be able to scale this solution. Imagine the frontend doesn't need any scaling. Now, with this monolithic architecture (everything in one package; payment processing, etc.) you either scale everything (Frontend + processor), or nothing.
With microservices, scaling is a breeze. In microservices, you'll be like: "Okay, you will process ONLY and ONLY payments, NOTHING else." Now, you can easily scale every component of the application.
The question you're probably asking is, "how the hell will these services communicate?"
There are two options here:
The first option is pretty straightforward: you create an API for the microservice, and they interact with each other using that.
The second option's better, according to me.
A messaging queue is a stack of messages; it can have literal messages from/to your girlfriend, or it can be code. Let's go with the latter here! ;)
Whenever a payment is made, the front end adds a "payment" to the messaging queue. This is an example of a deferred-data-processor. You don't process the data immediately.
This takes care of a couple of things: i) even if the payment processors are down, the client does not suffer; ii) messaging queues generally write data to cache, so they are super fast.
So, you get perfect scalability.
Now, "workers" (your payment processors, in this case) get the data from the queue, process it and tell you or any other handler.
Simple. Easy. Scalable. Efficient.
That's the end of Microservices 101!
I am writing a 3 part series on "High Availability Infrastructure" (of which microservices are a part), and there I explain everything in great detail. I even show you how to implement one. So, hang tight!
I hope this helps. :)