Migrating to the InformationGrid

The InformationGrid is a Polyglot Data Management Platform. It combines the best of Open Source storage technology with a radical approach to data-evolution and out-of-the-box support for modular architectures like Microservices and Event Sourcing. It combines the strengths of major Open Source projects like Apache Kafka and Apache AVRO with main stream databases like MongoDB, JanusGraph and OpenTSDB.

How to migrate to an architecture with the InformationGrid?

Although it sounds deceptively simple, is not to try to rebuild the existing system in one big effort, but the replace it one piece at the time. The basic idea for this approach was laid out by Martin Fowler in 2004 when he wrote about the StranglerApplication.

“One of the natural wonders of this area are the huge strangler vines. They seed in the upper branches of a fig tree and gradually work their way down the tree until they root in the soil. Over many years they grow into fantastic and beautiful shapes, meanwhile strangling and killing the tree that was their host.”

The StranglerApplication approach to migrating an existing system to a more agile and evolvable architecture is based on an analogy to a vine that strangles a tree that it’s wrapped around. Basically, you use the structure of the business-domain to divide the system into different functional domains, and replace those domains with a new Microservices-based implementation one domain at a time. This creates two separate applications that live side by side. Over time, the newly refactored system “strangles” or replaces the original application until finally you can switch off the monolithic application. For example, in case of a web-based system, the StranglerApplication applies the steps transform, coexist, and eliminate:

  • Transform: Create a parallel new site; this could even be done in your existing environment but based on more modern approaches.
  • Coexist: Leave the existing site where it is for now, but redirect from the existing site to the new one so the functionality can be implemented incrementally.
  • Eliminate: Remove the old functionality from the existing site (or simply stop maintaining it) as traffic is redirected away from that portion of the old site.

The great thing about applying this pattern is that it creates incremental value in a much faster timeframe than if you tried a “big bang” migration in which you update all the code of your system before you release any of the new functionality. It also gives you an incremental approach for adopting Microservices.