Why we have decided to move to microservices
Kalpik Singh, Test Analyst, discusses why iPLATO has chosen to switch to microservices.
APIs are essential in our day-to-day work – an API is a set of definitions and protocols for building and integrating application software.
“The philosophy of the microservices architecture essentially equates to the Unix philosophy of ‘Do one thing and do it well.”
Over the past year, our monolithic application has grown considerably.
It takes a long time to develop, test and deploy and there are functionalities that are no longer used and have accumulated within our architecture.
Decoupling our monolithic application into micro service architecture is a great opportunity for iPLATO to improve organisational culture and capabilities.
This year we decided to break our monolithic architecture into micro services to better manage the scalability, quality assurance and time to market, an additional advantage of using micro services is to reverse technical debt built up over the years. Technical debt reflects the implied cost of additional rework caused by choosing an initial ‘easy fix’. By switching to micro services, this debt reversal will improve both performance and stability.
Our development teams are continuing to work hard to deploy and operate independently so that future feature releases are quicker. Having the ability to choose the programming language that is best suited for the service is one of the biggest advantages of using micro services. We want frontend, backend and data storage to be handled in a way that allows resources to be used more effectively – enabling us to scale only the parts which require more resources.
Implementing a micro service architecture is not a simple switch; it is a process that will take a few months.
Initially, we will not completely remove the monolithic application. Rather, we will develop one component from the monolithic application into a micro service. Until all the components are smoothly migrated to micro services. This will reduce the migration risk with the transition. Once the new micro service architecture is stable, we will develop new features as micro services to reduce the workload and time to market.
To help us gain experience with micro services and assist the developers and architects to better understand the extraction process, we will begin with modules that are easy to extract from our old system or are more loosely coupled.
To accelerate development, the primary focus will be on the modules which change more frequently to take full advantage of micro service architecture so that we can develop and deploy them independently of the monolith, increasing quality as a result. The aim is not to rewrite the application from scratch, rather we will incrementally refactor myGP into a set of microservices. Over time, the number of micro services will grow which will increase the agility and velocity of the development team.
How do we make sure the communication and interaction between the old monolith and new micro service remains smooth?
When a system is redesigned via micro services a common practice is to utilise highly coupled code. We will need to minimise the dependencies of the newly formed micro services on the old architecture. If we have dependencies on monolith API, data and logic we cannot have a fast and independent release cycle.
As our system grows we will ultimately have more micro services to monitor. Each of these will use a different language, container and database, as well as have its own version control; this will make our system highly fragmented and we will require cross-functional and vertical teams that can work together to develop and maintain such a complex system.
Each service must be able to manage service failure. Whenever a service failure occurs this can have a knock-on effect on other services. One option to explore is to introduce fault tolerance capabilities for our application so that it can operate to a certain degree of satisfaction when failures arise.
Our transformation to micro services is a significant investment with equal benefits now that we are operating at scale. It will be both an organisational and technical transition as we will decouple both the code and the teams. We have a long–term plan, required resources and the money that will help us deliver a successful transit.Share