I have worked with Microservices architecture in the past and in fact, this website is built with Microservices architecture style. I have given a talk on Microservices in various meetups including DigitalOcean and Microsoft. In this article, I am going to explain to you about the Microservice architecture and how Codeforgeek is leveraging this technique.
What is Microservices Architecture?
Here is the standard computer science definition of Microservice which I prefer:
“An architecture pattern that allows you functionally decompose the software into a manageable and independent deployable unit”
Or in a simple Codeforgeek definition.
Make EACH program/service do one thing WELL
In this architecture, we divide our system in a way that each service is independent to deploy/scale and has no direct dependencies on each other.
Each microservice should handle one resource. Resources can be defined at a domain level. For example, in an e-commerce based application, the cart could be a resource, order management could be a resource and so on.
The 4 I’s of Microservices architecture
This is kind of my own creation of metrics to test the working of microservice.
Your microservice should be:
- Independent deployement.
- Independent codebase.
- Independent technology stack.
- Independent scalable.
Let’s understand each I’s in a brief.
Independent deployement
Your microservice should be deployed without the dependencies of another service. This ensures that codebase is written in such a way that if one service goes down, it doesn’t affect the overall working of the system (one feature may be missing).
Pro tip: Dockerize each microservice in a container. Thank me later!
Independent codebase
The codebase of each microservice should not be restricted to a specific design pattern. In fact, each microservice can use different design patterns depending on the programming language and suitability.
Independent technology stack
This is the most loved characteristic of Microservices. You can use any technology that suits the use case of a particular service instead of following one language philosophy. Imagine using Java, Python, Node all together to build a rock-solid system without any glitch. With microservices, it’s possible.
Independent scalable
Since microservices should not depend (direct) on each other, it should also scale independently without having to depend on other systems. Let’s revisit our e-commerce application example again, imagine the homepage is getting lot of traffic and you need to scale it to a better server with a load balancer.
Since it is a microservice, you just need to scale that service and leave the rest. No need to scale whole systems when there is a need to scale just few services. Saves lots of money!
Microservices Communication
Microservices do not perform direct communication (to avoid dependency) instead we use two different approaches:
- For synchronous requests – Proxy such as Nginx, Amazon API Gateway, etc.
- For Asynchronous requests – Queues such as RabbitMQ, Amazon SQS etc.
Synchronous requests require timely responses such as API calls while asynchronous requests can wait for a while such as to send newsletter emails.
You may need to use proxy and queue together to have both kinds of communication in your system.
Microservices with Node.js
Microservices architecture is an architectural style. It’s not coupled with any technology say Java or Node. You are free to choose any technology to build systems with Microservices style.
Let’s understand this with the practical example, the article you are reading right now is being served by the Microservice running in the cloud server.
Here is the number of Microservice we have to run Codeforgeek:
- Content Service – Serves posts, courses.
- Analytics Service – Collect page views and analytics information.
- Sitemap service – Generates Sitemap XML files.
- Pageview service – Sync pageviews from Google analytics.
- RSS Service – Generates RSS feeds.
- Communication service – Sends system email.
Each of the microservices listed above is a self-contained container using Docker. We are using Node.js in all of the services at the moment. Content service uses MongoDB and Redis to store (cache) and serve the content.
We also have an Nginx instance running as a reverse proxy that forwards the incoming traffic to the Content service.
We use ZeroMQ for microservices communications.
For example:
Whenever I publish a new article, content service generates an event in the queue which is later consumed by the communication service that in turn sends the email.
So to design a microservice using Node, you need to make sure you divide your system in such a way that it does not depend on each other and can be deployed independently.
And, you don’t need a framework to build a microservice. Yes, that’s right.
Microservices monitoring
Due to a large number of services, it gets overwhelming to monitor these services. For Node.js based microservices, I highly recommend and use PM2 with Keymetrics to monitor the services.
Microservices deployment
I highly recommend using the Docker to deploy your microservices. You can Jenkins or systems such as Travis CI, Circle CI to automate the deployment cycle.
Conclusion
Microservices architecture will allow you to design and build scalable, secure and fault-tolerant systems. It’s easy to scale, cost-efficient, code ownership can be easily divided into teams and help you grow exponentially.
Need help?
Do you need a consultation in Microservices? I have done and deployed pretty large systems using this technique and willing to help you on the same. Reach me using this contact page.
