Below article discusses MyGlamm’s journey from a monolith architecture to a microservice based architecture.
Year 2017:
MyGlamm’s ecommerce platform was launched in 2016 as a monolith architecture. This platform was built using NodeJS. Code was deployed on EC2 instances with autoscaling in place. Everything worked well for us at that point of time.
Year 2018:
By 2018 many other dimensions opened up for us as well. Along with ecommerce platform content also started playing a very major role for us and we now had a section named glammStudio specifically dedicated for content and a dedicated rewards program. Our NodeJS backend had the core business logic of an ecommerce platform along with complete logic of the content and rewards platform. Below are few of the challenges we started facing:
- Our feature enhancement sprints started becoming heavier.
- Code maintainability started becoming an issue.
- Knowledge transfer for every new recruit started taking a longer time.
- QA time started going up as a deeper sanity had to be done with feature changes.
At this point we started separating a few independent modules as a separate service. By the end of 2018 we had an architecture which was a combination of monolith and few independent microservices.
Year 2019:
During this year things started getting more complex. EC2 instances also started taking time to come up during autoscaling even after using AMI’s. Since autoscaling was slow we started using scheduled scaling and also keeping additional headroom in terms of number of servers for handling spikes in traffic. This led to unoptimised usage of resources in terms of CPU and Memory of servers and overall increased infrastructure billing. We started thinking about containers at this time. Overall the challenges related to monolith architecture kept getting complicated. This is the time we took a call of migrating to microservices based architecture along with containerization of these services.
This will help us handle challenges related to scaling both in terms of application and infrastructure thus giving us the agility that was needed. We started breaking down our core backend service which had all business logic into smaller independent services. We used a choreography pattern (an event driven architecture) for our microservices and choreography saga for handling distributed transactions. We used messaging queues extensively in this new architecture. Deployments of all our microservices are handled by CI/CD pipelines. We used spot instances to further optimise our infrastructure costs.
Year 2020:
In the month of march in the year 2020 we finally launched version 2 of our backend which was microservices based architecture working in a containerized environment. Everything worked well for us and this new architecture gave us the flexibility and agility that we were expecting from this version 2 of our backend.
You can expect a detailed blog from us in the future regarding our implementation of CI/ CD pipelines, Container orchestration and usage of spot instances.
Photo by mindandi
