Hi this is to start a new series of posts about microservices architecture, it’s going to be mainly in the format of Q/A.
In this post.
- What’s the Microservices architecture ?
- What are the patterns of Microservices architecture?
- What are the benefits of Microservices architecture ?
Q:What’s the Microservices architecture ?
A: There’s no specific answer for this question however it’s generally accepted to say that it’s designing systems that are formed of many small (as in small responsibility list) and independently deployed services.
My definition: It’s a child for SOA that’s favoring distributed, single responsibility services over monolithic service(s).
This may trigger another question(s) like:
- How small is microservice ?
- How to ensure that services are independent in terms of responsibility and deployment ?
Please, check next question’s and next posts for answers.
What are the patterns of microservices architecture?
A: Following are the main patterns of what’s usually conceived to be a Microservices design:
- Services over libraries for components
Instead of having systems that are formed of components that are libraries, system is now formed of small services that are often used to share code and logic between other services.
- Business layout over Technical layout
For a normal eCommerce store, instead of having front-end and backend teams and components we will have:
shopping-cart, search, collection services and teams.
“If it’s hurts, do it more often” — Martin Fowler
All the hurting stuff should be done more often or in other words (automated) hence things like (CI/CD, Automated Testing, Accept rewrite of components,etc..) are essentialNote: If you are resisting the fact that services should be completely rewritten in no time then services are either not small enough or it’s designed somehow to be tightly coupled to another service(s) which indicates a bad design.Hint: A good practice and well-known pattern is to have the ability to rewrite and roll-out a rewritten service in 2 weeks for example.
- Choreography vs imestration *
If you have many services this triggers a question how should you conduct some command, do you create a service that’s dedicated for orchestrating what other services should deliver ?
Same for your team do you create a team that’s dedicated for management ?In Microservices it’s more like a ballet dance. Despite how accurate and synced are the dancers you don’t see some manager who guide dancers in execution time. This is called choreography.
In this metaphor every dancer is a service and music is system inputs and services should react to this independently without external governance.
Same for teams each team should be able to code, test and deploy his service independently.
Which comes hand to hand with next pattern.
- Automation and monitoring.
Infrastructure automation CI/CD are essential in microservices.
In a system with 10s and may be 100s of services rate of change and deployment is huge and it can’t be only Ops team responsibility in such architecture DevOps team has a main responsibility to enable automation in infrastructure.
One of the benefits is being fault tolerance(on system level) but the failing service still need to know how did this happen, what’s the current response time what are the consumed Memory, etc..
I can safely say that Monitoring and Automation are essential to any successful Microservices architecture.
- Failure Is Inevitable. What Matters Is How You Deal With It.
“If a short-circuit happened in your kitchen, your laptop in living room should survive.“– Me trying to explain electrical circuit breaker to one of my friends.The lesson learnt from great electrical engineers is that you should be able to handle failure because it will happen no matter you try to avoid it and I strongly recommend reading how netflix are fault tolerant.
Caching, retrying, rerouting are brilliant ideas for mitigating failure in runtime and this article has lots of ideas.
Q:What are the xkeybenefits of Microservices architecture ?
A: Microservices architecture isn’t a silver bullet yet it has many advantages and to name a few:
- Fault Tolerance (in other words failure isolation) unlike monolithic apps there’s no single point of failure.
Example: In e-Commerce store: if searching service is down this doesn’t mean that the store is down, it just means you can’t search now but you still can buy, add to shopping cart, etc..
- No vendor lock-in or technology stack lock-in (every service can be using different stack) microservices favor hetrogenity loose coupling generally hence stack and vendor unlocking is by design.
- Horizontal Scalability (well, it’s the fact that you can split your system into small services and put every service in one machine/vm/container makes it better to scale wisely)
Let’s say that your eCommerce system is composed of shoping-cart, search-engine and catalog
With microservices architecture every component can be a separate service and each service deployment can be scaled (up/down) based on load applied on this specific part of the system.
On the other monolithic hand, scaling up and down is per system deployment.
- Maintainability, test-ability (inherited from being small separable services you can verify if every service can work alone and hence test it, monitor it and rewrite if you want.) What if a spark plug wasn’t removable ?
- Resource utilization (think of it as space utilizing problem for a jar where filling is Sand vs small ball vs big ball.)
the smaller the better.
*1. I’ll do another post about event-driven asynchronous programming to support this point.
- Building Microservices: Designing Fine-Grained Systems Kindle Edition by
- Microservices a definition of this new architectural term www.martinfowler.com/articles/microservices.html
- Micro services, what even are they?