When learning to develop web applications, many times a programmer will begin by creating their server-side architecture monolithically. This program structure is exactly what it sounds like: a monumental chunk of code or the proverbial “big ball of mud.”
There are a lot of large, successful companies whose main product started as a large pillar of uniform code such as Google, Netflix and Amazon. However, for reasons that this article will discuss, all of these companies have moved to multiple server-side executable programs with microservices and APIs that serve different portions of the given application.
We are going to discuss why it is a good idea to move away from the traditional, monolithic server-side structure to service-oriented architecture as you continue development on a program. We will even go over why it might even been a good idea to start out using microservices early in your development process.
Why is Monolithic Architecture Still a Thing? 🤷🏾♀️
Let’s talk about why a developer might decide to start off with a monolithic structure in the first place. Generally, if you have a relatively simple web application it handles just a few processes. It will handle your HTTP requests and perform some internal logic. It might query and update the database and serve up HTTP templates to the client-side. If you’re still learning how these various items are handled, it might make sense to store all of your code in one executable file, or to house them in a single repository even if they are separated into multiple files.
Learning by Using Monolithic Architecture 📝
The last application that I worked on, FoodPrint, was a learning process. It was built with a very monolithic design. I did respect separation of concerns and organized my code into various files according to the principles of Model-View-Controller architecture. However, there was just one executable file within the app. Every time I update this product, I have to redeploy the entire website altogether. Since the product is relatively small in scale and solves a single problem, this has not been too big of a hassle thus far. However, as I add additional features to the app, I will have to shift to a design that uses APIs and external microservices.
Another reason why you might stick with a monolithic model, is that it is much easier to write tests with good coverage for all of your endpoints. If you analyze the code and documentation for FoodPrint, you’ll see that I have complete test coverage for the various endpoints represented. Since all of the HTTP requests and other logic are contained in one place, thinking about possible edge cases and handling issues is as simple as switching files. When you are still new to development, this can help problems to remain accessible.
Why use Service-Oriented Architecture? 🤔
A main problem of monolithic architecture is technical debt. Technical debt can be described as using an easy, but unscalable solution for the short term benefits it presents. You’ll end up paying later on with long refactors and code reworks when your product scales or your stack changes. Many developers agree that an agile development process which is organized into sprints is the best way to have a product that is improved iteratively based on user feedback. Sinking future resources by creating technical debt undermines the agile development process by potentially causing weeks or months of work to be spent on rewriting deprecated sections of code.
Reducing Crashes and Overall Downtime 💪🏾
Another reason is that a problem in one area of the application can cause ripple effects and even downtime for the entire website. You create a more resilient program by isolating different services. This will hopefully contain any bugs, failures or security breaches to their respective areas.
Recently I created another app called name-ly. Its a name generator which creates unique names for the user, giving them the option to save names they like to their profile, or browse names that others have saved. This application was built with two parts: the main web application and a Markov model microservice to create the unique names. While the main function of the application (taking a quiz to get unique names) is dependent on both the microservice and the web app to work, if there were a serious bug in the Markov chain, the user’s profile and saved names within the web application would not be affected. Likewise the microservice functions as a separate API, accessible outside of the main name-ly app. If I took name-ly off the web, a developer would still be able to use the name-ly API’s documentation to get unique names sent via POST request.
Having grown as a developer over the last several months, name-ly is my most modular program yet. As I continue to fix bugs that come up and add features to the program, I know that I will have less technical debt to deal with since I decided to create and use a microservice for this application.
What about you? Are there any other benefits to service-oriented architecture you’d like to discuss? Do you have any stories of your growth as a developer while learning the benefits of enhanced design?