A discussion on Monolithic Architecture: Why Bob can’t scale his Taco Business Easily
This is part one of a four-part series, a continuous discussion of two main types of application architecture designs; Monolithic architecture vs. Microservices architecture.
Sometimes it may seem like a battleground! Which design can overcome the other? Are microservices pushing monolithic application design out of the market? And is Bob’s Taco really the best?
It may well be the case as businesses focus on agility and scalability to cope with their growing amount of data and tasks. Software development teams sitting in different locations need the flexibility to work on a system simultaneously. The right architecture is crucial.
Refer to this list below to stay updated on our upcoming articles:
Part 1: Monolithic Architecture
Part 2: Introduction to Micro-services
Part 3: Upgrading to the next level: Responsibility Segregation and Service-Oriented Thinking
Part 4: McDonalds Order System & role of message dispatcher
Both types of architecture have shifted how the IT industry approaches software development. In the first part of this series, you will start to understand the structure of monolithic design. This in turn will guide you further to understand the architecture of microservices.
What is monolithic architecture?
Monolithic Architecture is one of the oldest and most straightforward application design structures. This design model has its structure unified in a single divisible unit. Each component is interconnected with the next and must be present in order for code to execute.
This structure is still ideal in many software systems today. Monolithic architecture is convenient for starting new software projects that need minimal setup on its server or cloud environment.
Bob’s Beef Tacos
Let’s think of this system as a person who is running a small-scale restaurant. Your local street-food vendor is serving home-made beef tacos.
Bob runs the entire operation.
You order beef tacos.
Bob takes your order,
Bob prepares your Taco
Bob serves it to you.
He performs all the services himself. Bob is handling the entire operation from start to finish – representing one system.
Bob’s Monolithic Thinking
Bob implements every capability he needs, described as his services, within one single system. This is a monolithic approach.
In this case, Bob is the system. For the scale of his business, Bob is capable of running the system and perform all tasks himself. Similarly, a monolithic application design runs all tasks through one program.
This kind of service is time and cost-effective. It’s a very simple and straightforward process.
Other benefits of Monolithic Architecture:
Starting a new project is easy due to the simplistic structure
Debugging and troubleshooting is much easier. There are fewer dependencies to other systems
Frameworks, templates, or scripts can be easily integrated
Disadvantages of Monolithic Architecture
If Bob calls in sick tomorrow, it will affect all of his services. If you replace Bob, you need to replace the whole system. If Bob wants to start offering enchiladas or quesadillas, he will have to take a break. First, he needs to learn how to cook and prepare ingredients. This might take him a week or two. Within that timeframe, he will not be serving any food.
We often see this in software engineering, when companies are putting their systems down for maintenance. Of course, the maintenance might have a different reason but, let’s keep it simple here.
In software engineering, to update one component, you will have to take down the entire system. You might have to pause background tasks that are currently running, and out comes the announcement that “your system is currently down.”
Other risks of Monolithic Architecture:
Other components that need updating could be overlooked. These will fail to start and, as a result, can discourage developers to perform frequent updates.
Slow startup time if the environment is overloaded