Is Micro-Services Architecture A Solution Or A Beginning Of Problems?
Most software architects today have begun believing that microservices is a pattern that will fit most situations regardless of the problem statement. Do you believe so too?
Read on, if you think so or you don’t…!
Most architects I discuss software architecture with seem to believe that the microservices architecture is the only pattern to be followed regardless of the problem statement. However, some of the most experienced architects don’t quite agree. More often than not, it’s coming back to this simple, beautiful notion:
” Keep simplicity as a core value and it will take you places”
We’re going to discuss the following things in this article:
- Why an architect thinks that microservices was a right choice
- What questions should I ask before concluding on my decision of going the microservices way
- What architecture concerns I should keep in mind
Why Do I Believe Microservices Was The Right Choice?
#1 Everyone seems to be doing microservices – I should too
#2 Decoupled services are a solution to every problem
#3 Independent solutions to (seemingly) independent problems •
#4 Independent scalability of components
#5 Independent releases – the varying pace of delivery
#6 I will be having a more complex system to manage – yes, you heard it right – complexity may have a hidden kick for the architects
Am I Doing The Right Thing If Began With Microservices?
Before you finalize your approach and decide to go ahead with the microservices pattern for your architecture, there are several questions you should ask yourself.
› Is it a system with a long shelf-life and a long maturity curve or a one-off system serving the same purpose forever?
› Is it worth affording the cost of multiple applications whereas one app could do just fine?
› Do other systems in the enterprise benefit from loose-coupling within this application?
› Do some parts of the system need better scaling than the others?
› Can this system be built using a single technology just fine?
› Do I know the domain well enough to break it down into microservices right in the beginning? Are bounded contexts realistic?
› Do I have the ability to affect UX design choices, just in case?
› Do we have teams well-versed with agile (probably, at scale)?
› Is there leadership buy-in for investing in enterprise agility?
› Is the organization’s DevSecOps teams quite mature with:•
- Serverless architecture or a K8S+Serverless architecture
- Container orchestration setup on-prem or cloud
- Release/ package management/ CI-CD for distributed workloads
- Infrastructure As Code
- Automated security scans, DAST, SAST, patch management
› Are your IT security audit policies comprehensive enough to cover multiple services independently as well as “as a whole”?
Now, If You Do Decide, What Architectural Aspects Should You Be Concerned About?
We’ll be discussing common challenges you face while adopting microservices, particularly, for a large implementation in one of our next articles. Stay tuned!
