Have you been hearing a lot about microservices lately? I know I have, so I thought it was about time that I shared my two cents on the topic.
Contrary to the popular belief, microservices are not a new concept. They can be thought of as one of the few things that come under the umbrella of Service-oriented architecture. Companies like Amazon and Microsoft have been using it for over a decade now and others like Netflix and Spotify recently jumped onto the bandwagon.
I myself have had chance of working with microservices and I'll be sharing my experience with you through out the article but first let's figure out what the fuss is all about.
What are microservices?
In comparison to the traditional approach where a single application has different layers with different responsibilities, microservices approach has many small applications that communicate with each other either via HTTP or Enterprise Service Buses.
Each microservice is built around a single business capability, operating independently of other microservices with it's own decentralized data storage. They are deployed on separate VMs as well for better granular scaling.
Microservices fundamentally are a group of small 'n' simple web APIs (preferably REST) that work together to build a larger and more complex system.
Let's consider an example of some online project management tool. This tool would have several microservices namely Users, Teams, Projects, Comments and more.
Now, if the UI was to access the details of any single project it'll call the Projects microservice. This microservice in return would get data from it's data storage and call other microservices to get data for users and teams linked to that project. In the end, it'll return a single response that has all that data for the UI to consume.
When and why to use microservices?
Like any other architecture, microservices have their pros and cons. Not every application should be developed using microservices, therefore whenever someone asks me that if they should be using microservices, I ask them that do they really need to? Honestly, if you're using microservices just for the sake of bleeding edge technology, I'd say you're probably better off without them.
Unlike many other architectures, microservices require a change of mindset and that too at the organizational level. There should be enough trust in individual developers that they can take complete ownership of their tasks. Moreover, there should be some sort of continuous integration/deployment setup so that deployments are not lengthy chores.
Now, the question which still remains unanswered is that why would someone want to use microservices? Well... let me share some of the reasons why I love to use microservices.
- They enable rapid development by giving autonomous teams the complete end-to-end responsibility.
- They provide developers with enough space to innovate freely without the fear of breaking down the complete system.
- They don't restrict your dev. teams to the same technology stack (although more than 2 might not be a very good idea).
- They -- kind of -- enforce loose coupling to be able to achieve partial deployments, which result in faster releases and lesser deployment times/effort.
- They endorse the use of polyglot persistence which although isn't compulsory but certainly a nice tool to have in your toolkit.
I could still go on about microservices but let's save that for the future articles. In the meanwhile, here are some good reads from other amazing authors:
- Microservices Resource Guide by Martin Fowler.
- Microservices architecture by Chris Richardson.
- Azure Service Fabric and the Microservices Architecture in Microsoft Magazine.
- Introduction to Microservices by Nginx.
I'd love to hear from you about your experience with microservices. Feel free to leave a comment below. I'm looking forward to hearing from you :-)