Monolith to Microservices: Should I Migrate and How?

Microservices have dominated software development in the past decade as the most popular system design. Over 70% of organizations surveyed by Gartner in 2023 use microservices, with 22% having migrated over within the past 12 months. While there has been buzz about microservices being over-hyped, the trend towards microservices remains a steady force, with more than 20% of surveyed organizations planning to make the shift to microservices.

Just like any system design, microservices is not a one-size-fits-all approach. What are the benefits and challenges of using microservices? Should my organization switch to a microservice-based design? How can I migrate from a monolith to microservices? Let’s explore these considerations below.

Monoliths vs Microservices

In a monolith design, the entire system is built and deployed as a single unit. In other words, the user interface, application methods and services, and database are stored in a single codebase and these modules are tightly coupled, typically with a shared context.

In contrast, a microservices-based design consists of separate services that can be individually deployed. These services each have its own database and bounded context, and are loosely coupled. Communication between each service occurs over a network protocol, typically through API, gPRC, message brokers, or an orchestration layer.

Architecture of a monolithic application vs a microservices-based application.

Benefits of monolithic architecture

Because monoliths are designed as a single consolidated system, it is typically the preferred approach in the early stages of development.

• Simplicity: Monolith systems are more straightforward to build, test, deploy, and debug—developers don’t have to worry about coordinating and tracing across distributed components.
• Lower infrastructure overhead: With only one application to monitor and maintain and fewer moving parts, the costs and infrastructure requirements are easier to manage.
• Lower latency: Different services in a monolith are tightly coupled, with a shared memory and no need to communicate over a network. This set-up provides better performance and faster response times at a given load.

Limitations of monolithic architecture

However, as an application grows with new features, the limitations of a monolith architecture become apparent:

• Slower development cycles: Multiple teams working on the same codebase can lead to conflicts or breaking changes, requiring careful coordination and resulting in slower releases. Small changes or bug fixes become too effortful to make in light of long build times.
• Limited scalability: Horizontal scaling across multiple machines calls for the entire application to be scaled, even if only certain modules require more resources. It’s not just harder to optimize specific components in a monolith but also more inefficient at resource utilization.
• Risky to innovate: A tightly-coupled system means that new features or changes to the tech stack can result in unintended cascading consequences elsewhere, making it harder and harder to implement changes over time.

At some point, the monolith system becomes too complex to maintain at a performant level. Without proper code discipline and organization, you run the risk of creating a big ball of mud or spaghetti code. This is when the shift towards microservices becomes relevant.

Benefits of microservices

When implemented carefully, microservices offer numerous benefits that overcome the limitations of monoliths.

• Reliability: Unlike a monolith where one unresponsive component brings down the entire system, a microservice-based architecture reduces the blast radius. Orchestration patterns like retries and compensation workflows also help to handle partial failures gracefully.
• Speed: Likewise with independently-deployed services, teams can iterate features and fix bugs more quickly, using automated CI/CD pipelines to test and deploy releases.
• Scalability: Since each service has its own dedicated resources, they can be scaled independently based on demand, maintaining service performance while minimizing resource wastage.
• Flexibility: Each service can use the tools, technologies, and language best suited to its functionality, and critical services can be reused across multiple domains.

Challenges of microservices

The benefits of loosely-coupled, independently-deployed services with a bounded context come with some trade-offs. Distributed systems tend to be more complex, which introduces additional challenges for inter-service communication, resource management, data persistence, and testing and debugging.

• Failure: The more components a system has, the more points of failure get introduced. Distributed systems, like microservices, face a greater risk of single points of failure, cascading failures, resource leaks, and network failures.
• Infrastructure: Microservices require more infrastructure overhead, like a dedicated DevOps team, tools for service discovery, load balancing, networking, message queues, orchestration, and so on.
• Data: Maintaining data consistency across services, especially for distributed transactions, also poses more challenges compared to a single, unified database, and requires more careful planning.
• Testing: It is much more difficult to design end-to-end tests with production environments for distributed systems, and likewise, debugging poses challenges with global observability and reproducibility.

Microservices: To migrate or not to migrate

As organizations and systems scale, the question of migrating from a monolith to microservices inevitably emerges. Microservices have provided businesses like Netflix, Uber, Amazon, and SoundCloud a way to move and innovate rapidly, even in large teams.

A successful migration involves many technical hurdles but is a worthy investment when there is a solid business case to create a clear separation between services. You should migrate to microservices when:

• Multiple teams working on the same codebase create blockers in development speed.
• A single service needs to be reused or shared across multiple programs or domains.
• Significantly more computing resources are required for a particular feature but not others.
• A specific functionality becomes a unique business capability that requires more innovation and a dedicated team.

How to migrate to microservices

If microservices prove to be the path forward, next comes the dreaded project of overhauling, refactoring, and migrating your code. Here are some best practices you can follow when migrating from monolith to microservice:

1. Plan the migration using domain-driven design

One of the biggest challenges in migrating a monolith to a microservice-based system is ensuring proper separation of services. If not carefully implemented, it is easy to end up with a distributed monolith, where the services communicate over a network protocol, but are still tightly-coupled and dependent on each other. A distributed monolith should be avoided, as it introduces all the challenges of a microservice-based architecture without any of its advantages.

Before migrating, inventorize the monolithic codebase and identify areas where services can be decoupled from each other. Despite what its name suggests, microservices do not need to be micro: as long as there is a bounded context, data model, and independent deployment, the service can be as encompassing as your system demands it to be.

Domain-driven design is a handy set of principles for deciding how to split up your monolith. The core idea is to model your services based on the business domain—an insurance app entails concepts like claims, plan tiers, or renewals, while a shopping app should model concepts like customers, products, or discounts. Using these standard terminology, you map out the services required in your system—a shopping app would have a product inventory, checkout, and order tracking. These are the bounded contexts that have emerged from the monolith, allowing you to design the scope and function of your microservices grounded in business sense.

Example of the bounded contexts in an order application and how they are linked to one another.

2. Gradually decouple your monolith services using a strangler pattern

Strangler pattern. Reference

Once you have identified the candidates for microservice refactoring, gradually pull them out of the monolith by setting up a separate microservice. During this process, any new feature or service should be implemented as a separate microservice instead of being added to the monolith. These microservices, extracted or new, should have their own database. Integration code, or glue code, is added to bridge between the microservice and the monolith in the interim.

Glue code is used to bridge between the extracted services and the remaining monolith during the migration process.

Once the microservice is ready to be used as a standalone service, use blue/green or canary deployments to gradually transition your user traffic from the monolith and roll back if necessary.

Use blue/green or canary deployments to gradually transition your user traffic from the monolith to the newly-extracted microservice.

3. Set up robust testing for your microservices

Finally, when deploying your microservices, testing is crucial to ensuring that there are no code regressions. Since microservices can be tested and deployed individually, the approach should fundamentally differ from testing monoliths.

While it is easier to test your microservices independently, it is more challenging to visualize and trace the entire process from end to end. Here are some tips for testing microservices:

• When doing unit tests, the microservice’s inputs/outputs should be treated as one of the critical functionalities to test, avoiding overreliance on test doubles or mocks.
• Instead of having developers spin up an end-to-end application instance, use a shared test environment to reduce test coupling and isolate the test request to minimize its impact.
• Use context propagation tools like OpenTracing or OpenTelemetry to get a view of your distributed system.
• Implement chaos engineering to test the resilience of your system.

Managing inter-service coordination using orchestration

One key challenge of using microservice: what about the plumbing code that manages the communication between all your microservices? Orchestration is a powerful way to coordinate services and components in a distributed system, providing both state tracking and durable execution.

Orchestration simplifies the added complexity and infrastructure overhead of microservices by providing a centralized platform to model, manage, and route your application flows and implementation details, abstracted away from the business logic encoded in each microservice.

Microservice orchestration with Conductor

Conductor is an open-source orchestration platform used widely in many mission-critical applications for microservice orchestration, LLM chaining, and event handling. Using orchestration with Conductor, teams can build multi-language microservice-based systems that are even more fault-tolerant, highly observable, and performant.

• Resilience parameters: Conductor allows you to specify resilience parameters like the number of retries, rate limits, compensation flows, and timeouts, decoupled from your microservice logic, and provides in-built tools to recover from failures gracefully.
• Data flow: Be it inputs/outputs, secrets, or environment variables, Conductor securely stores and passes these parameters across microservices.
• Centralized monitoring and logging: Conductor provides a centralized platform to inspect your workflow execution and logs for troubleshooting, as well as to monitor your workflow performance and cluster health.
• Load balancing: Conductor runs on a worker-task queue architecture that round-robins tasks across a pool of workers that can be dynamically scaled based on demand.
• Lifecycle management: From development and testing to deployment, Conductor facilitates version control and rolling updates without disrupting your production runs.

Migrating to microservices with Conductor

When you migrate from a monolith to microservices with Conductor as your platform, refactoring is as straightforward as injecting Conductor’s SDK into your application and annotating your endpoints with @WorkerTask. This prepares individual tasks for eventual refactoring into a microservice without disrupting the overall application functionality.

Annotate your functions to turn it into a task worker.

From there, you can gradually remove each task from the monolith and set it up as an individual microservice. Using Conductor’s task-to-domain, differentiate the worker pools and slowly transition traffic from the monolith to microservices.

Use different domains to split the worker pools.

Conductor SDKs are available in Java, Python, JavaScript, Go, CSharp, and Clojure, allowing you to write services in your preferred language.

With a platform like Orkes Conductor, you can streamline microservices development and rise above any challenges associated with it:

• Simplify migration: Gradually transition monolithic applications to microservices without disrupting operations.
• Safeguard from failures: Ensure robust execution of distributed processes with built-in fault tolerance, failure flows, and retry mechanisms.
• Gain full visibility: Debug in minutes rather than days, with comprehensive monitoring and tracing capabilities.

By choosing Conductor, you're investing in a battle-tested solution that tackles the complexities of microservice-based applications.

---

Orkes Cloud is a fully managed and hosted Conductor service that can scale seamlessly to meet your needs. When you use Conductor via Orkes Cloud, your engineers don’t need to worry about setting up, tuning, patching, and managing high-performance Conductor clusters. Try it out with our 14-day free trial for Orkes Cloud.