Moving from monolith to microservices

We are on the cusp of a revolution in application architecture. According to IDC (International Data Corporation), by 2022, 90 percent of all new applications…

Professional Services  profile picture
Professional Services

September 28, 20214 min read

We are on the cusp of a revolution in application architecture. According to IDC (International Data Corporation), by 2022, 90 percent of all new applications will be based on microservices architectures.

Many enterprises are thinking about migrating their existing apps to microservices-based architectures. But there are many critical questions to ask first. How do you rearchitect an existing system without having to stop all other work on it? How big should a microservice be? When might microservices be a bad idea? What are some of the migration patterns you could adopt when splitting up a monolith?

Table 1: Monoliths vs microservices

Migration patterns

Here are a few migration patterns you could follow to start your transformation journey from monolith to microservices.

Strangler fig

  • The idea here is to have our new system initially supported by, and wrapping, the existing system.
  • The old and the new can coexist, giving the new system time to grow until it can potentially entirely replace the old system.
  • This approach allows for incremental migration to a new system.
  • The strangler fig approach also gives us the ability to pause and even stop the migration, while still taking advantage of the new system delivered so far.
  • When implementing this approach for our software, we strive to not only take incremental steps toward our new application architecture, but also ensure that each step is easily reversible, reducing the risk of each incremental step.

Branch by abstraction

  • This approach involves creating an abstraction for the functionality to be replaced.
  • To use the new abstraction, you change clients of the existing functionality.
  • With branch by abstraction, you create a new implementation of the abstraction with the reworked functionality.
  • To use the new implementation, you switch over the abstraction.
  • After cleaning the abstraction, you can remove the old implementation.

Parallel run

  • Rather than calling either the old or the new implementation, with the parallel run approach, we call both. This allows us to compare the results to ensure they are equivalent.
  • Despite calling both implementations, only one is considered the source of truth at any given time.
  • Typically, the old implementation is considered the source of truth until the ongoing verification reveals that we can trust our new implementation.
  • This technique can be used to verify not just that our new implementation is giving the same answers as the existing implementation, but also that it is operating within acceptable nonfunctional parameters.

Decorating collaborator

  • The decorator pattern allows you to attach new functionality to something without the underlying thing knowing anything about it.
  • Using a decorator makes it appear that our monolith is making calls to our services directly, even though we haven’t changed the underlying monolith.
  • Rather than intercepting these calls before they reach the monolith, we allow the call to go ahead as normal.
  • Then, based on the result of this call, we can call out to our external microservices through whatever collaboration mechanism we choose.

Change data capture

  • With a change data capture pattern, we react to changes made in a datastore rather than trying to intercept and act on calls made into the monolith.
  • For a change data capture to work, the underlying capture system must be coupled to the monolith’s datastore.
  • Change data capture is a useful, general-purpose pattern, especially if you need to replicate data.
  • In microservices migration, the sweet spot for this approach is where you need to react to a change in data in your monolith, but are unable to intercept this at the perimeter of the system using a strangler or decorator and cannot change the underlying codebase.

OpenText™ Professional Services has vast experience in helping customers transition to microservices-based solutions. Contact us to get support toward your microservices transformation journey.

Author: Venkatesh Sundararajan is a Senior Consultant, Professional Services – Center of Excellence, with more than eight years of working experience in building highly scalable, end-to-end customer solutions involving OpenText products globally.

Share this post

Share this post to x. Share to linkedin. Mail to
Professional Services avatar image

Professional Services

OpenText Professional Services offers the largest pool of OpenText IM product and solution certified experts in the world. They bring market-leading field experience, knowledge, and innovative creativity from experience spanning more than 30 years and over 100,000 engagements.

See all posts

More from the author

Don’t get left behind: why upgrading to the latest version is a must

Don’t get left behind: why upgrading to the latest version is a must

Upgrading a major software application can be challenging.  Many factors come into play, including budget issues, downtime, upskilling staff, and addressing software and automation dependencies. If…

April 02, 2025

3 min read

Demystifying cloud migration

Demystifying cloud migration

Migrating to the cloud is a significant step for any business, but it’s often surrounded by misconceptions that can create hesitation. Let’s focus and demystify…

February 28, 2025

4 min read

5 reasons to move to cloud today

5 reasons to move to cloud today

Are you ready? Take the cloud migration readiness questionnaire

February 26, 2025

2 min read

Stay in the loop!

Get our most popular content delivered monthly to your inbox.