Kubernetes – Monolithic Architecture of Kubernetes
There is a new way of developing software apps using a microservices architecture. That’s when all the buzz around containers and container orchestration has increased but we have been developing and using these large software apps even before most of us were born. So in this article, we will be discussing what is that old software architecture we used even before microservices and what are the disadvantages of it that led to shifting our focus to microservices.
So coming to the primary objectives of this article, there are four major things that we’ll discuss:
- What is Monolithic?
- What is monolithic architecture?
- Advantages and Disadvantages of Monolithic Architecture.
- Challenges of Monolithic architecture.
What is monolithic?
Monolithic in general is something that is a single large block, indivisible, inflexible, and moveable. So that briefly explains at a high level about monolithic architecture unity and its characteristics as well.
Monolithic application in IT is an application built based on monolithic architecture. It is self-contained which means it contains all parts of applications packaged and deployed together. So to simplify this you can imagine this like a big container where all software components of applications are assembled together and tightly packed and deployed as a single unit. Imagine that you have developed an application on the Java platform, then you can package them using various formats such as .jar accordingly and which is then finally deployed as a single unit onto the application server.
What is monolithic architecture?
So in business terms, you can say that all different business services are packaged together as a single unit which is tightly coupled so typically when you look at the monolithic architecture it primarily consists of three tiers.
High-Level Monolithic Architecture:
- Application tier: This is where you have all the business logic. It is often written in Java, Dotnet, C, Python, C++, or some more related languages.
- Data-tier: This is where all the data is stored and this data is accessed by the application layer when API calls. This tier consists of database technologies such as MySQL, Oracle DB, Microsoft SQL Server, MongoDB
So that’s a high-level overview of the monolithic architecture and its tiers. So all these layers are packaged and deployed together as one single unit and that is one of the main reasons why it is called monolithic architecture.
Now let’s look at an example of a simple monolithic application. When you take a bookstore web app it primarily consists of four components they are:
- Customer accounts
So if the developer develops this application based on a monolithic ID picture then all these four components will be developed together which may be interdependent on each other and deployed onto a web server as one single unit.
Advantages & Disadvantages of Monolithic Architecture
With this architecture style of developing an application, there are some advantages and there are disadvantages and now it’s time to see some of the advantages and disadvantages of monolithic architecture.
Advantages of Monolithic Architecture:
- Single unit of deployment: Since it is a single unit of deployment so there is only one application to test and deploy overall. So monolithic applications are simple to develop and deploy.
- IDE support: We have been developing monolithic applications for almost two to three decades. It is mature and old so IDEs and other development tools are designed in sync with monolithic architecture in mind.
Disadvantages of Monolithic Architecture:
- Large Applications: Applications built with monolithic design are often very large. If the application is small then there are no problems. Then it will be easy to develop and maintain. In case if the application is large and has multiple components to it, then there will be a situation where the developer might get lost between business requirements, components, and its code. And most likely there is a scope for no single developer or even a group of developers to understand the entirety of the application, especially for those developers who have recently joined the team and it will take a lot of time to understand an application
- Technology Dependency: These monolithic applications will get locked in with initial decisions around the technologies that they have developed this application in. Even if there are better technologies and languages and tools that rise over a period of time to solve the business problems but unfortunately these monolithic applications will have to stick with their initial technologies and initial decisions that they have taken at the beginning.
- Single Stack Development: When developing software applications there is no one-size-fits-all principle here, meaning let’s imagine that there are multiple components inside the application and there might be a situation where you feel that one technology is best suited to one component and is not suited to other components. However, this monolithic design will restrict you to use a single development stack across.
- Impractical Frequent Deployments: Frequent deployments are not practical because there are various application components linked together in a monolithic application as a result it requires coordination of many developers and even departments who are responsible for these components. It may take hours or even days to schedule deployment and test new features and bug fixes.
- Difficult to Scale: The scaling of monolithic applications can often be very challenging since this is deployed as a single unit of the app, not an individual component so had to scale the entire application.
Challenges of Monolithic Applications
Now there is one big challenge with monolithic architecture even though it has served well for over three decades. Large organizations have used this way of packaging and deploying applications for decades and have developed effective ways of dealing with these shortcomings, but this was before the internet brought new challenges and one of the challenges is the unpredictable nature of user demands on the application.
Imagine that you have an internal web application just inside your company and there are about 10,000 of your company employees using it every day. So you know exactly how many of your company employees you have when they are working and for how long. So based on these criteria you can provide just enough resources for these applications to perform best. So if more employees join the company you know this in advance and can add more resources to the server where this application is running to keep up with the best performance possible.
Now let’s imagine that your company has an external website where they sell products online like amazon.com or walmart.com. In this scenario, you don’t know exactly how many people will be using your website today. All you can make is a good estimation based on some historical data that you have but that cannot be certain. So if you look at the sales during the holiday season you see a rapid jump in visitors numbers as a result of some marketing campaign or a social media buzz. So as soon as you see that spike in traffic you need to immediately scale the application resources. Unfortunately, you do not have the luxury of a few weeks notice, so if you just fail to provide those resources it obviously reduces the performance of your applications which might even cause them to crash.
This used to happen during the early days of the Internet where web applications who are monolithic and when they were certain visitor numbers it would slow down the applications and possibly stop them altogether. The primary issue here is resources cannot be provided quickly enough to meet the demand. So the main disadvantage of the monolithic architecture pattern is it does not go well with scaling resources dynamically as and when needed.