John's story
John, a good coding developer, joins a company that deals in stock exchange software. The software provided by this company also gives users recommendation of stocks, which are likely to rise in the near future. It is based on some probability logic. John has done his homework, and the very first day, he suggested a tweak in that probability logic that can improve the prediction of stocks. His suggestion was to change a few lines in the code, and John expected to finish this before lunch. The software of the company was a monolithic application with over 40 modules inside it. It took one whole day's effort from John to clone the code, figure out in which module he has to change carry out code, and the setup to run it locally. Third-party tools stub dependencies, configurations mismatch, and many other issues took time to get figured out and be resolved to run the application.
So, challenges faced by John in a monolithic environment can be summarized, as generic problems in monolithic, in the following words:
- When we talk about monolithic, we are talking about a single large code base. It may or may not be in the small sub modules, but they are not self-dependent or self-deployable.
- This whole code base is written in a single specific language. Excited or new developers are bound to work in that technology.
- Being a single bundle application, if traffic increases, the whole application has to scale, even if that traffic is affecting only one module of the whole code base. A monolithic application can be scaled only horizontally by running multiple instances of the whole application.
- As the code base grows, it becomes more prone to bugs while introducing any new feature. As modules may be interdependent of each other, the testing cycle and deployment cycle increase in the case of a monolithic application.
- It is hard to find an ownership sense in the case of a monolithic application. Employees generally don't like to take ownership of such big projects.
In other scenario, John suggested a tweak. The application was on microservice architecture. So, John clones the receptive repository. Code cloning was fairly instant (less code, less branches). With less code, John easily figures out where to make changes. Running this microservice in a local environment was fairly easy. He committed the code and pushed for review. CI/CD is in place, so his code merged to branch and deployed in, say DevOps, the Dev environment. John was ready to ship the project just after lunch.
Although the situation is hypothetical, a similar kind of situation is encountered by most of the new joiners. Making their code live on the very first day increases the confidence of an employee. New joiners can be productive on the very first day, if they have to grasp less code base at the beginning. Understanding a big monolithic code base and having working knowledge of a fair number of modules may take a week's time or more by a new joiner before starting.
Microservice architecture brings many benefits to the organization. It breaks the whole application into smaller services, typically each in a different code repository. Smaller codebases are easy to understand. Microservices works on the isolation principle also, so deployment of each microservice doesn't affect the existence of other microservices. It makes applications language agnostic. Each service can be written in a different language with a different database (SQL, MongoDB, Cassandra, and so on). The application can accommodate a completely heterogeneous technology stack. This offers the developer the freedom to choose a language for their microservice.