Deciding the architecture of your startup application

By: Prateek Gupta is the VP – Technology of Routofy

Startups today depend heavily on technology for their functionality and efficiency of their operations. As a result, speedy execution of new features and changes to the existing setup are among the core responsibilities of a tech team. Startups generally operate by developing a single web backend that gives life to multiple front ends such as Android, iOS and websites. This backend is initially created with a monolithic design, so that everything resides within the same project. However, this quickly becomes troublesome as the team size grows due to its less organized nature.

Temptation offered by Monoliths
Make no mistake, the monolithic design proves to be a great asset if there are just one or two developers working on the same. The reasons for this are numerous. Setting up the project takes very less time, deployment is straightforward and it gives developers the agility to make code changes easily. When each team member plays the roles of product manager, developer, tester and dev-ops himself, having everything in one application keeps things simple. A feature could be prototyped and using the monolithic design within hours; if satisfactory, it can be pushed to production immediately. In an environment where one is unsure about how much value a new feature could add to the product, this provides a really flexible experimenting ground.

For a startup in its initial stage, the product needs to be rolled out as soon as possible. Early shipping and frequent iterations are required to test market validation, feasibility of complex ideas and the scale of usage. Having a monolithic application can prove to be a great asset for fulfilling these objectives, but the issues start piling when the team grows in number. The early ones come in the form of ‘merge conflicts’, wherein more than one developer has committed code in the same file. Bugs start creeping in and developers are often heard saying that someone has modified their code without their knowledge. Modifications in one feature start interfering with others and it becomes difficult to keep track of who is working on what. That's when the need for microservice architecture starts to become evident.

Microservices To the Rescue

In today's web service world, microservices architecture could be labeled as a silver bullet for most requirements. Creating a microservice entails the separation of a substantial and logically-grouped part from the parent monolith and making it a separate project. Such projects communicate with the parent using some protocol, typically REST, and are deployed as standalone entities. For example, Routofy has separate microservices for travel search, booking, front-end, etc. Here are few advantages of using microservice architecture:

Better Organization of Code - Different microservices are put in separate source code repositories, so the code automatically becomes more organized. Access control of the source becomes more fine-grained and the probability of a critical component being modified inadvertently by someone becomes quite less.
 Individually Scalable Components - It is often the case that one component in an application requires more processing than others. Making it a separate microservice opens the opportunity to allocate more (or less) resources only to it, making it cost-effective & enabling vertical scaling. At the same time, running the component on multiple servers and putting a load balancer at the top allows room for horizontal scaling.
Individually Paced Development - As long as the protocol of communication is not changed, each microservice can evolve at its own pace, without depending on others. Some component may be updated and deployed daily, while others might be deployed monthly without any need to bring down / restart the whole application. This is a great advantage as it reduces dependencies on other projects.
 Increased Flexibility - When a module becomes a microservice, ease of experiment with its tech stack increases heavily as one can try out new libraries, even new languages, without affecting other microservices. Consider the case when a certain component’s function is more suited to a particular programming language. Also, if one of the microservices is to discover something useful during experimentation, it can suggest this to others, hence contributing to overall tech growth of the organization while keeping the risk mitigated.

The Inevitable Switch
The switch from the monolith to microservices typically involves a period of 3-4 weeks, during which it becomes difficult to deliver any new functionalities in the old application. The protocol of communication, whether it should be synchronous or asynchronous has to be decided. Equally important is the degree of decomposition of modules; breaking a monolithic into ten different microservices may seem very tempting, but it is disastrous from a practical perspective. The module to be converted into a microservice must represent a substantial and standalone part of the overall project.

The team size, experience of developers in the relevant field and the time frame for the deliverables are all vital in determining which style one should go with when trying to build a new application. An informed decision should be taken with these factors in mind and after due consideration of the advantages both architectures offer.