Moving Away from Monolithic Architecture 👋🏾

Nature has no problem with using monolithic architecture every once in a while.

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.

Writing good, clean code is hard to do.

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.

FoodPrint, an environmental app by Panda Dreams.

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.

Technical debt is not fun. Its also avoidable if you know what to do.

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.

Bugs, crashes and security risks all loom large over the monolithic application.

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.

Growing as a developer means better, more modular code that can stand the test of time.

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?

Faith Chikwekwe is a back-end web developer and data engineer who is currently leveling up her skills at Make School and looking for internships in the San Francisco Bay Area.

This story is published in The Startup, Medium’s largest entrepreneurship publication followed by +414,678 people.

Subscribe to receive our top stories here.