If you are an early stage startup you will start with something small and a single piece of software that proves your idea. Scale and complexity are not on your mind and your first few customers are there to help you prove your thesis. Once you have done proving your thesis, and have managed a steady flow of customers you have a good problem to solve. One of Scale and Complexity. The question then becomes “How do I move my tech to solve for complexity and scale” without disrupting the rest of the work.
So let’s see where we are. We have built a monolith, we have a database Running on RDS, we add servers to the farm manually when we see things spiking. The problem with doing that is that the choke happens at the DB level as the no of requests increases. Your software isn’t scaling and you are busy adding hack after hack to keep things going. Your scale story is on the verge of failing. Does this scenario happen, you bet it does.
There exists an Architectural Pattern called Strangulation (It’s also called the strangler pattern). In layperson’s term, you take the monolith and extract a service out of it and make it work outside the monolith as a microservice. Ideally, a service will be a single responsibility with its own data. The problem with a monolith is that data gets shared across functions/services. So the best way to do this is to extract the service and let it have its own data set and anything else that is needed comes from the monolith via an API. Of course to enable continouity on the monolith (since the dependency on existing data will still be there) sync the service specific data back to the Monolith’s db. Congratulations you have Strangulated out your first microservice from the monolith. Of course you will continue to build new microservices. I wont talk about containers here except to say that it’s the vehicle for deploying our newly strangulated microservice or any newly built one.
Read More:- What is Procurement and How To Optimize Processes, Performance, and Technology?
As and when the opportunity arises you will continue to strangulate and extract more and more services from the monolith. Eventually, you will gradually stop syncing data back to the monolith. Each service can be scaled on its own depending on the demand for the service. You won’t choke on a single database either. Make sure you have the infrastructure to support the benefits of scaling by service. Don’t overdo your microservices. You can land up with an orchestration nightmare. We will come back with more details on some of these issues and share our pains and gains.
So what’s bad about stranglers? The biggest complaint is that end-to-end strangulation is a slow-moving beast. The second is in the process of implementing it, it slows down the delivery of the immediate feature. You always tie removing a piece out with a deliverable (How else can you justify doing a non-revenue job to your manager) with a feature that was waiting to go out yesterday. Testing is another challenge to ensure your functionality works well backward as it always did. When you build your microservice, build your tests.
Mohan Gopalakrishnan
VP of Engineering at Simfoni
Simfoni
Follow Simfoni on LinkedIn
