Monolithic vs microservice architecture: Which is best?

When building a new application, one of the first questions many developers will confront is if they should start off with a monolithic application or one that leverages microservices. Though both of these methods can build robust applications that serve a variety of purposes, the backbone of the application will be very different whether you choose to pursue a monolith or microservices route. In addition, once an application is built, it can be tedious and time-consuming to change the underlying architecture. To avoid a costly mistake, those building new applications should take several factors into consideration when first starting out. Below we outline the key differences between monolithic and microservices-based applications, use cases for each, and what you should consider when deciding between the two techniques.

What is a monolith?

A monolithic application, often referred to simply as a “monolith,” is an application that is made up of one large codebase that includes all the application components, such as the frontend code, backend code, and configuration files. Monoliths are often thought of as an older and more traditional method of building applications, but in reality, many businesses still benefit from using a monolithic architecture. Monoliths are often faster to develop and deploy than an application that uses microservices and may be simpler to manage. However, monolithic applications can also suffer from a lack of scalability and challenges that come with maintaining one codebase as the application becomes more complex.

Pros of monolithic applications:

• Simpler to develop and deploy: Because all components of a monolith are centralized, they can be relatively simple to develop and can result in a faster time to market. For single developers or small development teams, creating a monolith means you can more quickly create, test, and launch applications.
• Easier to test: Monoliths are often easier to test than microservices-based applications, as there is only one code repository to keep track of when testing and debugging.
• Requires less specialized skills: Most development teams today are capable of building a monolith application, while creating an application based on microservices requires specialized skills and training.
• Singular security management: Although there are some security benefits to breaking up an application into distinct microservices, using a monolith means security is handled in one place, rather than having to track vulnerabilities across all microservices.

Cons of monolithic applications:

• Can become complex over time: As an application grows and adds functionality, a monolithic codebase can become extremely large and complex. This can be difficult to manage, especially as the team of developers working on the individual codebase expands. Changes made to one component of the application may inadvertently affect other parts of the codebase, which can result in additional time needed to identify issues.
• Difficult to scale: In order to scale monolithic applications, the application must be scaled all at once by adding additional compute resources, known as vertical scaling. This can be expensive and there may be limits to how much an application can scale vertically.
• Technology limitations: Adding or changing functionality to a monolith can be extremely difficult due to the interlocking dependencies found in a monolith. Depending on the needs of your application, developers may be limited in what new features they can implement with a monolith.
• Single point of failure: Because all parts of an application are tightly linked, an issue anywhere in the code can take down an entire application.

What is a microservices application?

An application built on a microservices architecture splits up each part of the application into independent codebases that perform one specific task. For example, one microservice may be used for managing users, while a separate microservice calculates costs. Each component can be deployed and scaled independently of the other modules. These modules then communicate with each other through an Application Programming Interface (API) in order to create the full functionality of an application. The use of microservices in programming has grown in the last few years–according to a 2020 survey by O’Reilly, 28% of respondents’ organizations had been using microservices for three years or more, while over 61% had been using microservices for one or more years. Despite their growing popularity over monoliths, there are some drawbacks to microservices that should be considered.

Pros of microservices application

• Self-contained services: Each microservice is self-contained, meaning it can be debugged, deployed, and managed independently of other modules. As an application grows, this can be beneficial as changes in one component do not impact the others, and each microservice can be managed by a team dedicated to that functionality.
• Easy to scale: Using microservices, an application can be scaled horizontally, meaning each microservice can increase in size independently as its needs change. Horizontal scaling can be less costly than vertical scaling, and there is no limit to how much an application can scale.
• More flexibility: Teams can more easily add additional functionality and new technologies to a microservices-based architecture as needed. As the requirements for an application grow, the number of microservices used to make up that application easily grows with it.

Cons of microservices applications: 

• Increased complexity: While individual components may be relatively straightforward, an entire microservices-based application can be incredibly complex. The way in which microservices are linked together adds a layer of complexity not seen in monolithic applications.
• Requires specialized skills: Building a microservices architecture requires specialized knowledge which not all developers may have. Teams who build microservices without the correct training can run into a myriad of challenges which may mean a delayed time to market and additional costs to bring in outside experts.
• Distributed security and testing: Each module will have its own security vulnerabilities and bugs. While this can be beneficial in preventing attacks, it also means more potential vulnerabilities to track, and debugging each individual element can become time-consuming.
• Extra costs: Utilizing microservices may save some costs, but will also likely require additional development resources to manage each microservice and its dependencies.

Microservices and containers

When discussing microservices, it is also important to understand how they relate to containerization tools, such as Docker, and container orchestrators, such as Kubernetes. Containers are lightweight virtual operating systems that contain all the elements needed to run microservices or other software within them. They can be run from anywhere, including on virtual machines, physical servers, and on different Operating Systems. Containers can easily be shifted between locations, scaled up, and enable extremely agile development workflows. Most applications that utilize containerization also use Kubernetes, a container orchestration system that manages the hundreds of containers often required for applications. Using Kubernetes, developers can deploy multiple replicas of their containers and stipulate rules that automatically scale their applications or perform other tasks.

While microservices are not the same as containers, microservices are often deployed within a containerization system, so the two are regularly paired. Containers allow teams to deploy microservices in a lightweight and fast environment, and because containers are easily moved, a containerized application has extreme flexibility. Those looking to develop a microservices-based application should also look into the benefits and challenges associated with using containers.

How to choose between a monolithic and microservices application

Both monolithic and microservices architectures have benefits and drawbacks, and developers should carefully consider which to utilize when building an application. Some key elements to consider include:

• Application complexity: While more complex applications may benefit from microservices, monoliths remain popular for many simple applications because they are easy to build and deploy. If you are developing a simple application, such as a web forum or basic eCommerce store, or creating a proof of concept before embarking on a more ambitious project, a monolith may be right for you.
• The size and skills of your team: The number of developers working on your application and their skill sets should be one of the top deciding factors in what type of architecture to utilize. If your team doesn’t have experience with microservices and container systems, building a microservices-based application will be difficult. Monoliths can also be preferable for single developers or small teams. On the other hand, if you have a team skilled in microservices deployments and plan to expand your team over time, starting with microservices can save time in the future.
• Anticipated growth: Monoliths can become more complex and difficult to manage as applications add functionality, and may also have issues scaling to meet user demand. If you plan to significantly grow the number of users for your application, expand its functionality over time, and grow the team managing the application, microservices can ensure you are able to more easily scale. However, applications that are built for more limited use cases will often find success using a monolith.
• Cost and time to develop: The cost of building your application and the timeline to deploy should also be taken into consideration. While monolithic applications may cost more as they grow, they can be more cost-effective and faster to create. The initial resources needed to develop microservices are often high but can result in cost savings when an application scales in the future.

Conclusion

Developers and businesses creating a new application face numerous decisions, and how to architect that application is one that will have trickle-down effects for many years. Businesses such as Atom Learning, an online education platform, have experienced the challenges that come with scaling a monolith over time, deciding ultimately to utilize Kubernetes to create a microservices-based application that could continue to grow with them. On the other hand, using microservices requires time and skills, and may be overly complex for some applications.