There is a widespread but misguided belief that the quality of the code defines whether or not a mobile or web application can be successful. The truth is, your app can have the most brilliant code in it and still be too slow or outdated for the customers. It is the architecture, the way your app is designed and built, that influences the user experience most of all. Architecture can quite literally make or break your application.
Historically, applications were designed according to monolithic architecture principles. There are many apps that are still built like that today. However, a popular trend recently is to use microservices architecture instead. We will try to answer the burning questions: how these two approaches are different and whether one of them is better than the other.
Monolithic architecture
The word ‘monolith’ means a single entity, something that can’t be separated into multiple parts without breaking it. It is also often associated with things that are heavy and unwieldy, and thus inconvenient or even useless. This is a pretty apt description of the disadvantages of monolithic architecture. This traditional approach results in applications designed as a single, unified block of code.
An application built as a monolith has one large codebase where all the components are tightly coupled. You can single out several layers in a monolithic application, but they cannot function independently. The layers typically include a user interface that allows end users to communicate with the app, business logic that defines the app’s functionality, and a server-side data access layer that connects to the database. The layers are interwoven with each other, so you can not modify one part of the system without impacting others.
A monolithic app is always packaged and deployed as one big executable. Even though you can choose to implement different software development processes on your project, the core principles will stay the same. It doesn’t matter if you go for an agile or more traditional waterfall workflow, you will still have one big team working on a single deployment artifact that with time can become extremely large.
Advantages of monolithic architecture
The reason why monolithic applications are still created nowadays is simply because this approach still works well under certain conditions. A simple monolithic application is easier to develop, because you can gather just one team of developers to work on the project. It also allows you to save money, since your developers can just focus on the framework or programming language that they know best and don’t need to spend time on learning new skills that distributed systems will inevitably require. These business benefits are especially well-suited for smaller projects, when finances are limited.
A small project can be finished quicker if you decide to build it as a monolith. If your app has a lot of potential competitors, then this is a great opportunity to beat them to market.
If your single codebase is not too big, quality assurance becomes much less complicated. It is much easier to debug and track changes in just one code repository. And if you decide to implement automatic testing, it will also require less effort.
When your monolithic application is ready, it can be deployed at once, since you don’t need to think about any other components.
However, all these pros remain valid only for as long as your codebase is comparatively small. If your project lasts for years and you keep adding new features, monolithic architecture can become a source of frustration and disappointment.
Disadvantages of a monolithic application
-
Complex legacy applications
There are applications that stay on the market for years, and even decades. You keep developing them, adding new features, and your codebase grows and grows. When such legacy applications are monolithic, with time it becomes more and more difficult to manage your codebase.
-
Complex system testing
People from the original team leave, and no one can remember which part of the code contains some specific feature you want to modify. The sheer amount of time needed to test the app grows exponentially, because all the components are so tightly connected that even small changes to one part of the app can cause it to stop working completely.
-
Time-consuming bug fixes
It is almost impossible to predict which part of the functionality will fail when you change something that seems to be totally unrelated to it. This also leads to new builds being few and far between. Users never enjoy having to wait for bug fixes or functionality updates released only a couple of times a year.
-
Monolithic architecture is hard to scale
Both legacy solutions and small startups can end up with thousands and even tens of thousands more users than originally planned. It can take years or months, but monolithic architecture will fail you in that regard too. It is very hard to scale a monolithic app, and it is even harder to scale it quickly, which means your users will inevitably suffer from downtime while your team scrambles to add more resources.
-
Other services involved
These cons of monolithic architecture became obvious a long time ago. The first attempt to solve these issues was introducing service-oriented architecture. According to SOA principles, an application is designed as a number of separate services, each of which represents a single process based on the business logic. This improved the agility and scalability of the app. However, since the communication between services was organized via an enterprise service bus, the problem of a single point of failure still remained. In time, microservices architecture has become the next level solution to all the issues that monolithic applications have.
Microservices architecture
The main idea behind microservices architecture is to build an app as a set of loosely-coupled components or services. Each of the components is dedicated to fulfilling a specific task and has its own codebase and database schema. Microservices communicate with each other through message brokers or APIs to work collectively as a mobile or web application.
Each of the microservices that comprise an app is developed separately, so it can be done by a separate team. Developers that work on each independent service are free to choose the best technology, framework, or programming language that would be optimal for that particular solution.
Since each microservice is built on its own, it shortens the time to market. When you adopt microservices architecture, there is no need to finish the whole application before making it available for end users. It becomes possible to just release an MVP first and then add more microservices for extra functionality as you go.
Since each of the services has a separate codebase, when you need to test, update or fix one of them, the application doesn’t have to go offline completely. Deploying new microservices can also be done seamlessly and often doesn’t require any downtime at all. These specifics of microservices architecture make it more advantageous in certain scenarios as opposed to monolithic apps.
Benefits of microservices
If you aim to succeed and make your software development workflow truly agile, you inevitably come to the realization that the DevOps approach needs to be established in your organization. Microservices architecture enables adopting DevOps practices like continuous integration and deployment. With smaller independent codebases, any changes require less time. The automation of testing, logging, and monitoring reduces the number of errors at earlier stages and makes the production environment safer.
What are other benefits of microservices?
Microservices allow the avoidance of the single point of failure which is present in monolithic applications. Since each service exists as an independent unit, even if one fails, the rest of the system continues functioning. A microservices application is more stable.
It is easy to scale microservices because you can provision additional resources to only those services that need it, not the whole app. Multiple cloud hosting providers offer readily available tools to manage the microservices automatically. As a result, scaling and load balancing can happen without your team's extra input and also cost less.
Drawbacks of microservices architecture
It might seem that microservices offer a perfect solution to all your software development problems. That is not true, unfortunately. Even though microservices architecture has grown in popularity very quickly, it might not be the best option for small apps or projects with limited resources.
Microservices’ flexibility also means you need more people with very different skills working on each of them. When the number of microservices reaches hundreds, managing the services and enabling successful communication between them is an increasingly complex task. Hiring DevOps specialists to set up the workflows can be expensive, and having a different stack for each service might be better for performance, but it will mean either increasing the number of your engineers or improving the skills of the team members you already have.
The distributed nature of microservices also means setting up proper testing with high enough code coverage will be hard. Security will also require more attention. All in all, while from one perspective microservices architecture can save you money, when you are just getting started, it might cost more than getting a monolithic app up and running.
Which one should I choose?
There is no straightforward answer to the question, which one is better: monolithic vs. microservices architecture.
One thing you definitely shouldn’t do is choose microservices only because it seems everyone else has decided to go for it. There are a lot of aspects that can prevent your project from becoming successful if you rush into it. For example, if your team is used to designing monolithic (N-tier) architecture, they are likely to apply the same principles to a distributed system, if you don’t provide the time and resources that the learning curve demands. This will result in a so-called distributed monolith, a set of services organized in layers that communicate via gRPC, or JSON over HTTP, or other direct call mechanisms, thus representing an essentially monolithic system, just made more complex thanks to being built in a distributed way.
Business logic is another thing you should consider. If your application is not doing anything complex, it would be much quicker to build it as a monolith. However, if you plan on adding a lot of functionality with various user journeys in future, it would be easier to do it with microservices. It might be quicker to modify a monolithic application at first, but as the codebase grows, any changes will mean downtime for the whole app. With microservices, introducing new features won’t impact the user experience as a whole.
When choosing a suitable architecture for your project, you always need to think of your own needs first. If you envision the capability for releasing new builds very often, it will be hard with a monolithic app that has a really large codebase. If you plan to have just one team of developers working with the same stack, then using microservices probably isn’t justified.
Very often, when you start, monolithic architecture can meet all of your requirements easily. But at some point, especially if the number of customers increases rapidly, as happened to Netflix, it might turn out that it is impossible to scale your app quickly and safely enough. That is why the costs have to be considered very carefully from different perspectives. It is indeed more expensive to implement microservices at the beginning of the project. It will be more difficult to find excellent specialists, and you always have to pay more for the really skilled ones. Setting up the project infrastructure and other preparations will also cost more with microservices. Still, if you foresee your app growing radically at some point, it still might be worth it, because in the long run a monolithic app can carry a much more significant overhead. A monolith will waste resources eventually, because you will not be able to scale only the exact part of your application that requires it.
Conclusion
Even though it might seem that monolithic architecture is outdated, it can work better than microservices for your project in certain cases. Careful planning will make all the difference. Make sure you don’t rush the decision; determining the architecture that will most benefit your software development project should be an informed choice.
