As more repeatable systems and smaller footprints come into play in the tech world, there’s a question that’s on every developer and startup's mind; how do we build an app?

Some go for the let’s build it as fast as possible to get the MVP out approach while other, more mature organizations are thinking about how to make an application as efficient as possible.

Once these questions arise, the bigger question is around architecture and what approach to take when developing an application.

In this blog post, you’ll learn about the key differences between microservices and monolithic applications.

Monolithic Architecture

The architecture in a monolithic-style application is definitely more of a standard, traditional way to build applications.

Typically with a monolithic-style architecture, all of the code for the application is under one codebase. For example, maybe you build an application, and inside of the codebase, there’s a backend, frontend, some middleware, and a presentation layer. Once the app is ready, you package it up and deploy it from that codebase. Since all of the pieces of the application are together and deployed together, that’s considered “mono”.

Because you’re deploying all pieces of the application together, there are dependencies assigned. For example, maybe pieces of the middleware will completely fail and exit if the backend isn’t up and operational. Because of that, the middleware can’t live on its own.

Microservice Architecture

The architecture in a microservice-style architecture is essentially a bunch of pieces of an application broken up, living independently on their own.

Because these applications are broken up, living and breathing on their own, there needs to be a way to communicate from one piece of the application to another. This can be done a few ways, but you’ll typically see HTTP communication or other lightweight protocols. The idea is to keep it as light and transferable as possible.

Essentially, everything that makes up one platform is broken up into several different pieces. All of the pieces make one big pie.

Due to the applications being split, there’s a pretty big impact on databases. There is no longer just one database to rule them all. Instead, most microservice-style applications have their own database schema. It typically looks like one database per schema.

Advantages and Disadvantages of Monoliths

First, let’s start with the advantages. Number one, if a team is small, it may be easier to start with a monolithic app. Perhaps the team members don’t have the knowledge of a microservice architecture, but they still need to get the application out. Although best practices would be to learn the microservice architecture, financial-backing members of a startup may be lighting a fire to get the application out as soon as possible. It’s not ideal, it’s just the reality.

A few other advantages include:

• It’s usually easier to deploy
• Less complex
• Only a few pieces to put it all together

Now, let’s chat about the disadvantages. The biggest disadvantage is the size of the application. In the beginning, it makes sense to put every bit into one codebase. It’s all under one roof and easier to manage, especially with a small team. However, a year, maybe two years, or even three years down the line, that codebase is going to grow. Once it grows to a certain point, it’s going to be insanely hard to manage it. Not because the code gets too complex, but because the sheer size of it becomes a nightmare to manage.

A few other disadvantages include:

• You need to deploy the whole app for a small change
• It becomes more difficult to adopt new technology
• More difficult to scale

Advantages and Disadvantages of Microservices

Now that we understand monoliths, let’s think about the advantages of a microservice. One of the biggest advantages of a microservice is the ability to split up the application into different codebases. When doing that, you can task engineers to each piece of the codebase, which makes it insanely easier to manage, update, fix, and deploy. You no longer have to worry about deploying every single bit of the application just to fix one small bug in the frontend or add a new feature on the backend. Because of a microservice’s contained nature, engineers can truly focus on one piece at a time, which makes scaling and growing the app much more efficient.

A few other advantages include:

• Small codebase
• Reduces the barrier of bringing on new tech
• Each app can use a different piece of tech based on its needs

Although there may be some bias against disadvantages in a microservice, there actually are a few. The biggest is a microservice does add complexity to the product and the team. Typically with a microservice, there are 1-2 engineers working on each bit of the application. Because of that, they’re geared solely on that bit of the app, which is great for large organizations, but potentially bad for small orgs. You typically need to hire more engineers, have more specialists, and have way more process/communication. The disadvantages are actually all good things that are needed, but the truth is, some organizations may not be ready for them at the startup stage.