Monolith to Microservices — Mission Possible?
What are Microservices?
Microservices refer to a development approach where large Monolith applications are broken into smaller, independent Micro-services.
The reasoning behind this approach is that smaller, independent services will allow for better, faster, and more flexible development.
In this blog post, I’ll share my experience so far, of transitioning from a Monolithic application to a Microservices Architecture.
The Monolith: A Tale of Complexity
Some background….
Joining the PPQ development team, primarily as a QA Software Engineer, I was stepping into a project already months into development.
This meant a complex landscape of new technologies and processes and a well established Monolith Repository, a single codebase responsible for every aspect of the system.
Labyrinth of interconnected components and branches — lots of new tech and code being pushed, pulled and reviewed all around.
Navigating this repository afresh, there was a lot to get familiar with; understanding the code structure, locating the right files and folders, figuring out how to build and run the project.
Undeterred I dove in — getting to know the repo, setting up environments and working with Docker, Mongo DB, Postman, Python, Selenium and PyCharm — writing test cases, creating and running automated tests, contributing to CI/CD, Git PRs, pulling and pushing code, contributing to UX/UI and code reviews.
Microservices — A New Hope?
As the project progressed, we began thinking about the application’s future. We realised the API, built specifically for this project, had the potential to be used by other app teams across multiple applications and services
This sparked a conversation about Microservices architecture. We explored the idea of breaking down the Monolithic application into smaller, independent Microservices, each responsible for a specific function.
Each Microservice with its own codebase, database, and deployment pipeline. This was an exciting shift.
Get Azama.’s stories in your inbox
Join Medium for free to get updates from this writer.
A fantastic learning opportunity for the entire team, that would also involve modernisation of the front-end technology — transitioning from JavaScript to React — and updating our testing tools from Selenium and PyCharm to Jenkins and Playwright.
Microservices Planning
We analysed our application, carefully defining clear service boundaries. This analysis also allowed us to adjust our testing strategy.
The developers then got to work creating the Microservices, while the QA team focused on planning
Microservices— Day One.
In no time, the first of the new Microservices, the API Microservice was completed, I hurriedly stepped inside and WOW.
It felt peaceful, a beautiful thing to behold. A sanctuary of calm; like stepping off a bustling city street onto a quiet lane.
This new Microservice was a simple, elegantly structured repository that was easy to navigate. The README file, a concise overview of the service, its purpose, and its dependencies.
It was awesome to see the changes and updates!
I leapt into new the code and structure and was soon up to speed, creating and running tests, setting up CI/CD pipeline and contributing to PRs, Code reviews.
It definitely felt leaner, easier to navigate and test. Bugs or issues were easier to identify and fix; I was looking forward to getting started on the next Microservice.
Conclusion
Does one size doesn’t fit all?
It’s early days for me in terms of Microservices. So far so good. The process made the process, for our small app, faster, more flexible, testing and development feels streamlined and lighter somehow.
Post Monolith, this feels incredibly liberating — aided with tools like Docker, Jenkins, and Playwright and the PPQ-Team, the whole process feels streamlined and even more efficient.
However, ours is a relatively small app. How might the Microservices work for larger apps and teams.
What about for large legacy code bases for large long established apps. And what of Microservices Architecture Governance framework.
This got me wondering the experiences of other development teams that have made or are making the switch.
