Microservices require a major infrastructure. They are not a drop in replacement for a monolithic application. Many people will argue against them, and for good reason. Techniques and shortcuts that can be masked and hidden in a single application will shine through and could even be the death of your application infrastructure when it comes to microservices.
All examples I’ve seen come from a singular idea that all data comes in from an apache/nginx connection from a client and needs data returned as quickly as possible. The topic of microservices often oozes out from a single request and response path. I want to broaden this basic idea and talk about how they can be used to make a highly available, more robust and scalable application across the world (not just inside a single network).
An experience I would like to share is when a microservice setup is the only reasonable solution when dealing with a network and data stream structure that is unstable and extremely load heavy.
Data coming in from cron import scripts, a tcp data stream and a direct writing mysql replication tool from a 3rd party services.
Many small end points that can be restarted, scaled and updated at different times.
These services could be deployed across the globe, each can submit it to a queue (at the time it was gearman), and then a data worker could process and transform the data and store it into the database / cache system.
Once that data was in the system, a task would be triggered on a schedule to calculate and sum down the data to reliable parts, using another type of data processor. That processed data would be submitted into a redis cache and a pub/sub message would be sent off to the queue for the web server to pull that data and push it out through a websocket (which an angular app renders). All of this would not be possible on any other system than a distributed compute system using microserivces with a queueing system.
There are many ways to skin a cat. The hope here to to give a quick overview of what a microservice can be used for. They are great for taking task like billing processing, sending off welcome emails and doing some extra setup when some event occurs. If done right they give great performance enhancements to your web application. But they can be more than just a helper taking care of some annoying task, they can become the man application source.