Member-only story
Guide to move from Monolith to Micro services' and the challenges we faced.
“Monolith to micro services” is the common phrase that is discussed in all technology conferences. The pros of micro services are well talked about: increased resilience, improved scalability, faster time to market.
Microservices is a transformational trend and as with all transformation items implementing microservices comes with its challenges and I faced it first hand while building a fintech application.
For those who are new to micro-services,
The microservice software architecture allows a product functionality to be sliced into bit sized, individual, and independent services. Each microservice runs as an autonomous process and communicates with one via events. Each microservice can be written in a different language and on a different platform. Sounds Cool?
We too felt the same way, we are on a journey of building serverless event-driven microservice-based products.
We started with a bang and everything was super awesome. Whenever we need to build a feature we create a new lambda function using whatever languages and frameworks we wanted to experiment with. We exposed functions as API to provide functionality at the frontend react application or worked on the database directly. We were on cloud nine. We thought about why companies are not moving to 100% microservices-based architecture.
This is just the start of the movie, so don’t expect a happy ending so soon.
The number of functions/microservices starts to increase at a rapid pace. It completely a different ball game when you build 5–10 microservices versus building 100+ microservices.
Now things started to break more and more often, and development slowed. We are more busy finding what went wrong then building new functions.
