Monolith and Service-Oriented Architectures
Learn about the monolith and service-oriented architectures that existed before the microservices system.
We'll cover the following
Two major systems existed before the microservices system: the monolith and the service-oriented architectures.
Monolith
A monolith is a large application codebase that contains many components existing as a single unit and is connected to a single but large database. In this system, all the components and functionalities of an application are in one large piece and are tightly coupled. This means that all the parts that make up the application combine to form one large application.
For greater clarity, let’s look at an e-commerce web app as an example. In the application, we might have the following components, which exist as one large unit: the “Product Category,” the “Related Products" (which uses algorithms to suggest various related products to buyers), the “Product Finder" (which may draw more traffic than other components), “FAQ,” and “Contacts" (which may have the least traffic).
The main issue with this architecture is managing it over time. For instance, if we want to scale the application or update one component, such as the “Product Finder,” which has more traffic than others, we might also have to rewrite or update the other components. So, in this case, we'll also reproduce the parts of the application codebase that have little or no traffic, such as the “Contacts” or “FAQ” components. Also, since it is just one large codebase, only one programming language is used to develop all the components. Therefore, we are likely to introduce bugs or cause problems for the teams in charge of the other components if we tamper with segments of their codes when trying to scale the application. These issues can create further problems for the development teams as the application grows.
Service-oriented architecture
A service-oriented architecture is a system that permits independent application components—known as services—to mutually exchange information over various platforms and languages to form an application. In this system, each service performs a specific task. Therefore, for the system to perform a complex task, developers will connect various independent services over a network.
Let’s consider an e-commerce web app with the following components: the “Product Catalog,” the “User Authentication,” and the “Payment Gateway.” Each component will be an independent service supplied by a different service provider. It is up to the development team to decide how to incorporate them into the business application. For instance, if the developers decide to use Amazon Cognito and PayPal for the “User Authentication” and “Payment Gateway” components, respectively, they'll have to connect them over a network. This is how a service-oriented web application is created.
The major limitation of this architecture is that of shared resources, such as a single large physical or logical database, which can slow down the entire system and affect scaling. When interoperating services share several resources to execute their functions, scaling the system becomes more difficult. So, as services within a system develop various interdependencies over time, the system can become more complex to scale, update, modify, or debug.