idspopd - Fotolia

Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Pros and cons of monolithic vs. microservices architecture

Developers interested in shifting to microservices should seriously consider whether a monolithic approach may be the smarter choice. Here are the key factors to consider.

The monolithic vs. microservices architecture debate is a continually hot topic these days, and there are scores of development shops eager to embrace distributed apps. However, while the microservices approach has gained popularity over the last few years, the monolith is still a viable option in plenty of situations.

Making the right architecture choice depends on several factors, particularly when it comes to management capabilities and developer expertise. Let's examine the pros and cons of monolithic vs. microservices architecture.

Monolithic architecture

A monolith is built as a large system with a single code base and deployed as a single unit, usually behind a load balancer. It typically consists of four major components: a user interface, business logic, a data interface and a database.

Monoliths offer several advantages, particularly when it comes to operational overhead requirements. Here are some of those basic benefits:

  • Simplicity: Monolithic architectures are simple to build, test and deploy. These apps can scale horizontally, in one direction, by running several copies of the application behind a load balancer.
  • Cross-cutting concerns: With a single codebase, monolithic apps can easily handle cross-cutting concerns, such as logging, configuration management and performance monitoring.
  • Performance: Components in a monolith typically share memory which is faster than service-to-service communications using IPC or other mechanisms.
monolithic architecture diagram
Monolithic architecture is more fixed and linear than microservices.

But one major drawback of monolithic architectures is tight coupling. Over time, monolithic components become tightly coupled and entangled. This coupling effects management, scalability and continuous deployment. Other cons that stem from tight coupling include:

  • Reliability: An error in any of the modules in the application can bring the entire application down.
  • Updates: Due to a single large codebase and tight coupling, the entire application would have to deploy for each update.
  • Technology stack: A monolithic application must use the same technology stack throughout. Changes to the technology stack are expensive, both in terms of the time and cost involved.

Microservices architecture

On the other hand, microservices consist of loosely-coupled, independent services. In essence, this architecture splits applications' components into small, autonomous services that can be deployed and scaled independently. Some of the benefits this approach provides include:

  • Scalability: To scale a microservices-based application, you only need to scale certain components, which optimizes resource usage.
  • Low coupling: Microservices components are loosely coupled so they are not interdependent and can be tested individually. It also makes the application more adaptable for changes over time.
microservices architecture diagram
A microservices architecture is distributed with more moving parts than a monolith.

But the switch to microservices comes with its fair share of costs, particularly when it comes to app monitoring and the toll it can take on developers. Adopters will have to consider factors such as:

  • Team expertise: The benefits of microservices are moot without a prepared staff. You should assess the skills of your team members before moving forward with a microservices architecture.
  • Testing and monitoring: Once you break apps into components, you'll have more moving parts to track and eventually fix. Without the right testing and monitoring tools in place, things could quickly spin out of control.

How to decide

Generally, monolithic architectures are the right choice for small, simple app development. It's also worth considering that a switch to microservices won't do any favors for a team that doesn't have enough experience working with distributed architectures.

Alternatively, a microservices architecture is a good choice when you're developing for complex systems, especially if you have developers familiar with microservices and motivated to make the switch.

So when it comes down to the monolithic vs. microservices debate, keep these four basic things in mind:

  • Does your team have microservices expertise?
  • Do you have the right infrastructure for distributed apps?
  • Have you evaluated the business risks involved?
  • Are your application boundaries clearly defined?

Dig Deeper on Application modernization

Join the conversation

3 comments

Send me notifications when other members comment.

Please create a username to comment.

Where would your project stand in the monolithic vs. microservices architecture debate?
Cancel
It wouldn't make sense to have a single team work on a microservices-based application, no matter how experienced they are. That would just create overhead.
Cancel
You're right. I'd venture to guess (or hope I can guess) that he means that within your overall development team structure, you would still divide responsibilities so that certain groups only work on certain services/features. AKA, stay true to Conway's Law.
Cancel

SearchSoftwareQuality

SearchAWS

SearchCloudComputing

TheServerSide.com

Close