In 2016, AWS built upon Gartner’s 5 Rs and introduced the 6 Rs, detailing six different cloud migration approaches.
Migration away from monolithic apps to modular microservice-based platforms improves security, performance, and maintainability.
Amazon’s bookstore is a prime example of modular replatforming to achieve scalability and quick innovation and deployment of features.
With fabric, modular e-commerce replatforming results in 10x faster implementation and 10x lower TCO.
Replatforming is an application migration strategy for transitioning an existing app from a legacy platform to a modern cloud platform to leverage the benefits of a cloud deployment model.
Gartner’s Migrating Applications to the Cloud is the seminal work of cloud migration strategies. It details the 5 Rs to cloud migration: rehost, refactor, revise, rebuild, and replace. In 2016, AWS built upon Gartner’s 5 Rs with its 6 Strategies for Migrating Applications to the Cloud (also known as the 6 Rs).
Replatforming helps enterprises strike a balance between simple rehosting and complex refactoring. Rehosting or “lift-and-shift” simply moves legacy monolithic apps to the cloud as-is. Since the underlying architecture is still monolithic, enterprises don’t get the cloud-native benefits a microservices architecture provides.
Conversely, refactoring a monolithic app can take years. As a result, the cost of refactoring can outweigh the benefits. Replatforming is a “lift-tinker-shift” approach that allows enterprises to capture the benefits of cloud-native while minimizing the time and complexity of migration.
In practice, traditional e-commerce replatforming often fell short of the ideals of “lift-tinker-shift.” That’s because, in the e-commerce space, replatforming usually meant moving from one monolithic app to another. For example, an enterprise that wants to migrate a legacy e-commerce app to Shopify Plus or Salesforce Commerce must move the entire app at once. This requires a “rip-and-replace” approach to replatforming that can be expensive, risky, and time-consuming.
Modular replatforming is a top-down approach that minimizes the risk and complexity of migration. It follows the strangler pattern to gradually transition from a monolithic app to a modern e-commerce platform. For example, suppose your CMS is your biggest performance bottleneck. You can first update your CMS while leaving the rest of your app alone. Then, over time you can replace the rest of the app piece-by-piece.
The technical specifics of replatforming are different depending on your industry, application, and business needs. However, there is a general framework that replatforming projects should follow.
Microservices are decoupled and discrete pieces of functionality. Each service can leverage different programming languages, OS, and best-of-breed technologies. The modularity of each service eliminates the need to migrate an entire application when changing or replacing each microservice.
Creating microservices with small, autonomous functionality is important when designing a microservices-based ecosystem. This pattern decreases the chance of interdependency between other services. It also eliminates the need to swap out large sections of your application when making changes. Let’s look at some best practices for moving from a monolithic to a microservices architecture.
When migrating a large monolithic app to microservice components, we recommend planning the migration in phases. You should consider developing a facade layer that intercepts the requests between the frontend and backend systems.
As you create microservices to replace your legacy system, modify the facade to call the new services. Eventually, you can remove the facade once all phases of the migration are complete. This pattern will help mitigate risk during the migration effort.
Designing smaller discrete units of functionality is much easier than creating a tightly coupled monolithic application. When migrating from a monolith to microservices, you must revisit your logging, monitoring, and troubleshooting processes.
Generally, microservices are easier to debug than a complex monolithic application. Modifying your monitoring processes is a one-time event. Once you move to microservices, it is unnecessary to update these processes ever again.
It is essential to identify scaling requirements for microservices during the design and eventual load testing of the services. Unlike a monolithic application, you can scale each microservice (or group of microservices) for performance. It frees you from the complexity of having to scale an entire platform.
When implementing a microservices platform, it is crucial to revisit your existing continuous integration (CI) and continuous deployment (CD) processes. With microservices, you can deploy each service (or group of services) separately without redeploying the entire application.
This isolation means you can implement a much more prolific CI/CD deployment schedule. You can also modify and deploy much smaller units of functionality with far less risk of downtime across the entire application.
When your company decides to migrate, you must involve the entire business, not just IT. For example, implementing microservices offers sales and marketing advantages over a single monolithic application. With service-oriented architecture, they can implement best-in-class third-party marketing solutions.
Today, Amazon is a prime example of the benefits of microservices. However, it wasn’t always that way. As Amazon’s CTO Werner Vogels says in this post and at HackFwd’s Build 0.7 event, Amazon’s “bookstore” changed a lot before becoming the e-commerce platform we know today.
Initially, the bookstore was a monolithic app with tightly coupled services: one front end was interfaced with multiple large databases. This was intentional as Amazon’s original focus was simply to “get big fast” and not worry about optimizing or future-proofing their architecture.
In 2001, Amazon realized its monolithic design and massive databases hindered its ability to scale. To break through the bottlenecks, Amazon came up with a service-oriented architecture based on: 1) looking for unique business logic 2) looking at the data the business logic operates on 3) combining the data and business logic into a single unit, and 4) exposing an API for other services to call.
By eliminating its large relational databases as bottlenecks and single points of failure, Amazon solved the biggest scalability challenges. Breaking the app down into microservices aligned with its “two-pizza teams” and “you build it, you run it” principles. Small and agile teams that own specific functionalities, like the “buy” button, can innovate and ship features. With standardized microservices in place, they can then iterate and automate their CI/CD workflows.
Compared to traditional “monolith to monolith” replatforming, using modular replatforming to migrate from monolith to microservices provides these benefits:
Timelines vary depending on the size of your app and approach to replatforming. For example, with traditional e-commerce replatforming, the end-to-end process often takes 12-18 months. On the other hand, modular replatforming can take eight weeks or less.
Microservices is a modern approach to software design where multiple small services that perform specific functions work together to create an app. Compared to legacy monolithic apps, microservices-based apps tend to perform and scale better across distributed cloud platforms.
The services in a microservices architecture communicate using lightweight protocols and well-defined APIs. Modular replatforming allows you to transition from a legacy monolithic app to a more cloud-friendly scalable microservices-based app that uses APIs.