# Micro-services vs monolithic architecture

micro-frontend vs mono-repository

A monolithic application is built as a single unified unit while a microservices architecture is a collection of smaller, independently deployable services. Which one is right for you? It depends on a number of factors.

# What is a monolithic architecture?

A monolithic architecture is a traditional model of a software program, which is built as a unified unit that is self-contained and independent from other applications. A monolithic architecture is a traditional model of a software program, which is built as a unified unit that is self-contained and independent from other applications.

Monoliths can be convenient early on in a project's life for ease of code management, cognitive overhead, and deployment. This allows everything in the monolith to be released at once.

# Advantages of a monolithic architecture

Organizations can benefit from either a monolithic or microservices architecture, depending on a number of different factors. When developing using a monolithic architecture, the primary advantage is fast development speed due to the simplicity of having an application based on one code base.

The advantages of a monolithic architecture include:

  • Easy deployment
    • One executable file or directory makes deployment easier.
  • Development
    • When an application is built with one code base, it is easier to develop.
  • Performance
    • In a centralized code base and repository, one API can often perform the same function that numerous APIs perform with microservices.
  • Simplified testing
    • Since a monolithic application is a single, centralized unit, end-to-end testing can be performed faster than with a distributed application.
  • Easy debugging
    • With all code located in one place, it’s easier to follow a request and find an issue.

# Disadvantages of a monolithic architecture

Making a small change in a single function requires compiling and testing the entire platform, which goes against the agile approach today’s developers favor.

The disadvantages of a monolith include:

  • Slower development speed
    • A large, monolithic application makes development more complex and slower.
  • Scalability
    • You can’t scale individual components.
  • Reliability
    • If there’s an error in any module, it could affect the entire application’s availability.
  • Barrier to technology adoption
    • Any changes in the framework or language affects the entire application, making changes often expensive and time-consuming.
  • Lack of flexibility
    • A monolith is constrained by the technologies already used in the monolith.
  • Deployment
    • A small change to a monolithic application requires the redeployment of the entire monolith.

# What are microservices?

A microservices architecture, also simply known as microservices, is an architectural method that relies on a series of independently deployable services. These services have their own business logic and database with a specific goal. Updating, testing, deployment, and scaling occur within each service. Microservices decouple major business, domain-specific concerns into separate, independent code bases. Microservices don’t reduce complexity, but they make any complexity visible and more manageable by separating tasks into smaller processes that function independently of each other and contribute to the overall whole.

# Advantages of microservices

Since a microservices architecture consists of units that run independently, each service can be developed, updated, deployed, and scaled without affecting the other services. Software updates can be performed more frequently, with improved reliability, uptime, and performance. We went from pushing updates once a week, to two to three times a day.

Plus, more generally, microservices make it easier for teams to update code and accelerate release cycles with continuous integration and continuous delivery (CI/CD). Teams can experiment with code and roll back if something goes wrong.

In short, the advantages of microservices are:

  • Agility
    • Promote agile ways of working with small teams that deploy frequently.
  • Flexible scaling
    • If a microservice reaches its load capacity, new instances of that service can rapidly be deployed to the accompanying cluster to help relieve pressure. We are now multi-tenanant and stateless with customers spread across multiple instances. Now we can support much larger instance sizes.
  • Continuous deployment
    • We now have frequent and faster release cycles. Before we would push out updates once a week and now we can do so about two to three times a day.
  • Highly maintainable and testable
    • Teams can experiment with new features and roll back if something doesn’t work. This makes it easier to update code and accelerates time-to-market for new features. Plus, it is easy to isolate and fix faults and bugs in individual services.
  • Independently deployable
    • Since microservices are individual units they allow for fast and easy independent deployment of individual features.
  • Technology flexibility
    • Microservice architectures allow teams the freedom to select the tools they desire.
  • High reliability
    • You can deploy changes for a specific service, without the threat of bringing down the entire application.
  • Happier teams
    • The Atlassian teams who work with microservices are a lot happier, since they are more autonomous and can build and deploy themselves without waiting weeks for a pull request to be approved.

# Disadvantages of microservices

When we moved from a small number of monolithic codebases to many more distributed systems and services powering our products, unintended complexity arose. We initially struggled to add new capabilities with the same velocity and confidence as we had done in the past. Microservices can add increased complexity that leads to development sprawl, or rapid and unmanaged growth. It can be challenging to determine how different components relate to each other, who owns a particular software component, or how to avoid interfering with dependent components.

The disadvantages of microservices can include:

  • Development extension
    • Microservices add more complexity compared to a monolith architecture, since there are more services in more places created by multiple teams. If development sprawl isn’t properly managed, it results in slower development speed and poor operational performance.
  • Exponential infrastructure costs
    • Each new microservice can have its own cost for test suite, deployment playbooks, hosting infrastructure, monitoring tools, and more.
  • Added organizational overhead
    • Teams need to add another level of communication and collaboration to coordinate updates and interfaces.
  • Debugging challenges
    • Each microservice has its own set of logs, which makes debugging more complicated. Plus, a single business process can run across multiple machines, further complicating debugging.
  • Lack of standardization
    • Without a common platform, there can be a proliferation of languages, logging standards, and monitoring.
  • Lack of clear ownership
    • As more services are introduced, so are the number of teams running those services. Over time it becomes difficult to know the available services a team can leverage and who to contact for support.

# Tips to migrate from a monolith to microservices architecture

Many projects initially start out as a monolith and then evolve into a microservice architecture. As new features are added to a monolith, it may start to become cumbersome to have many developers working on a singular codebase. Code conflicts become more frequent and the risk of updates to one feature introducing bugs in an unrelated feature increases. When these undesirable patterns arise, it may be time to consider a migration to microservices.

The following are some of the best practices we learned from our migration:

  • Map out a migration strategy
  • Tooling
  • Manage expectations
  • Embrace a culture shift
  • Balance speed and trust

# In summary

Microservices may not be for everyone. A legacy monolith may work perfectly well, and breaking it down may not be worth the trouble. But as organizations grow and the demands on their applications increase, microservices architecture can be worthwhile.

# Reference

  1. Microservices vs. monolithic architecture (opens new window)