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 are one of the few things that fall under the umbrella of Service-oriented architecture. Companies like Amazon and Microsoft have been using them for over a decade now and others like Netflix and Spotify recently jumped onto the bandwagon.
I myself have had chance of working with them 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 some other mechanism e.g. a service bus.
Essentially, a microservice is built around a single business capability. It operates independently of others and has its own decentralized storage. Moreover, it is deployed on separate VMs of its own to enable independent scaling.
They are fundamentally a group of small ‘n’ simple web APIs 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 small (or micro) services namely Users, Teams, Projects, Comments and more.
Now, if the UI had to access the details of any single project it’ll call the Projects service. This service in return would get data from it’s data storage and call other services to get data for users and teams linked to that project. In the end, it’ll return a single response that has all the data for the UI to consume.
When and why to use microservices?
Like any other architecture, microservices have their pros and cons. Whenever someone asks me if they should be creating 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 (or at minimum within the team). 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 need them? Well… let me share some of the reasons why I love microservices and than you can decide for yourself.
- Autonomous teams get to have the complete end-to-end responsibility which enables rapid development.
- Developers (esp. new ones) have enough space to innovate freely without the fear of breaking down the complete system.
- Development teams can use multiple technology stacks, as they deem appropriate.
- Loose coupling is enforced, to be able to achieve partial deployments. This results in faster releases and lesser deployment time and effort.
- You can take advantage of polyglot persistence, which although isn’t compulsory but certainly is a nice tool to have in your toolkit.
I could still go on about microservices but let’s save that for the future articles. For me, ever since I have started working on microservices, monolithic apps just don’t seem right. How has your experience been with microservices? I’d love to hear it so do share in the comments below.