Why Microservices Architecture?
What is Microservices Architecture?
Microservices: Small, and Focused on Doing One Thing Well.
BY Wikipedia: Microservices are a software development technique — a variant of the service-oriented architecture (SOA) architectural style that structures an application as a collection of loosely coupled services. In a microservices architecture, services are fine-grained and the protocols are lightweight.
So what? why would I break my projects into smaller pieces? What is in there for me?
We are living in a digital ERA. Every day a new app comes that reduce man efforts to 1/100th of the original. These Apps start becoming a basic necessity of our life. This lead to a huge increase in the number of customers of these Apps. And Finally scalability issues for the App developers. Developer starts noticing that you can’t scale a monolithic code beyond an extent. As well as monolithic code is so rigid that it is very difficult to adapt the dynamic requirements of the customers.
Some good things about Microservices:
Diversified Technology: Each Microservices can independently choose tech stack according to their need. Different modules have different requirements, some modules require resilience whereas some module needs speed. Some modules should be written in scripting languages whereas some in Object-oriented languages. Some modules use No-SQL whereas some SQL. Each tech has it’s own pros and cons, Microservices Architecture let you choose wisely among them for each of your Microservices.
Failure doesn’t cascade: Failure of one component doesn’t affect others. It will limit the scope of failure and it will much easier to debug and resolve a small broken microservice then resolving a some broken module in a large project.
Tackling bottlenecks: We can independently scale out(increase number of the instances) the bottlenecks modules. We can create a hundred instances of that critical module which will be much cheaper than creating a hundred instances of the full service.
Rocket speed Deployment: To fix a one-line bug, you don’t have to redeploy the whole service. Making a small change or adding a new feature in a module doesn’t require you to have knowledge of the full service. No matter how much you think through, requirement changes in a mysterious way overnight and you need to update the services accordingly. The one certainty is change.