Disclaimer: This article is based on my professional experience, inputs from my mentors and friends. I acknowledge the trademarks and IPs owned by others.
This article is a prequel to the article on the role of Integration in Microservices Architecture (MSA). The earlier article focuses more on the architectural components that are required for Microservices Architecture. I would request to go through the article if you have not yet read it yet.
Now, let's see if you already have answers for the below, you might already have answers.
Are you really ready to take the next step towards Microservices Services Architecture (MSA)? How do I break my current Monolith into microservices? What should be the roadmap towards Microservices practice?
Let us take to a look at few definitions of Microservices again to answer this.
“Loosely coupled service-oriented architecture with bounded contexts” - Adrian Cockcroft
“Microservices are small, autonomous services that work together” - Sam Newman
"Small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API" - Martin Fowler
Some even say "Microservices are SOA rightly done, MSA is a specialization of SOA".
Step - I: Governance, Services & APIs
The first step is to take a look at your landscape to validate if it is already SOA enabled. Take a look at the below diagram depicting the EAI -> SOA -> ROA.
This is true that lot of customers are still in before SOA era, with traditional point to point integrations. If the principles of Microservices are well understood and believe that you need a shift towards MSA, then first take a step towards SOA. The Modern era of digitalization demands adoption towards Mobile, IoT, BigData, Cloud, etc. enablement. For this reason, you might want to make your services lightweight with consumer-driven contracts. This is referred as Bottom-up SOA in the below diagram about the evolution of Integration requirements and approaches.
This is nothing but Resource Oriented Architecture (ROA). Implementation concentrated around business objects will also help to break the Monolith into microservices following the Domain Driven Design. You need to have API Management practice enabled for this.
Step - II: Automation, Metrics & Monitoring
Below diagram depicts the IT demands and evolution in development, architecture, deployment and infrastructure practices over the past few years.
Validate your development & delivery (CI/CD) process maturity level.
- Level 0: No version control
- Level 1: webMethods DevOps Edition (Designer Workstation) + Packages versioned with version control system
- Level 2: Level 1 + automated code quality reviews (Sonarqube/ISCCR) & ABE for builds on build server
- Level 3: Level 2 + deployments to reference server & unit testing, code coverage (Unit Test framework)
- Level 4: Level 3 + Artifactory to store builds (Nexus/Jfrog) + automated regression testing
- Level 5: Level 4 + nightly builds + automated deployments to SIT
- Level 6: Level 5 + automated integration testing & performance testing
- Level 7: Level 6 + containers for deployments
You should be at Level 6 before you move towards MSA. Use CI/CD tools(e.g.Jenkins) to drive this. I would advise targeting Level 7 for MSA. This is something we strictly followed before moving to MSA. Please do note that Monolithic and microservices deployment processes slightly different. CI/CD in a microservices landscape is usually driven with Docker Containers.
Microservices needs a high amount of observability. If you are already practicing log monitoring with ELK or similar solutions then you are definitely in the right direction. It is good practice to insights from the logs collected from the application and servers. Containers usually provide console logs that can be aggregated with EFK (fluentd), this is similar to EFK. Microservices needs both log aggregation and distributed tracing.
Step - III: Microservices Hosting
It is really difficult to answer if someone asks a question about infrastructure sizing for MSA while it is very easy to answer what kind of sizing you need for a particular microservice.
If you think you can afford the cloud, you might want to consider this. Once you start deploying your first set of microservices, the count will always increase (+ dynamic scaling would add more) and you would realize that you need more resources. And make sure you have container orchestrator (Kubernetes/Docker Swarm, etc.) to orchestrate your microservices.
Conclusion: These are few steps you can consider to move towards MSA. There could be more or less depending on the maturity of assessment. Please refer to the assesment topics mentioned eariler article.