Strategies for Migrating Legacy Applications to Serverless
Perhaps surprisingly, the questions companies ask when they’re thinking about adopting serverless are often not related to technology, but strategy. Back in 2010, when the cloud was gaining attention (and serverless wasn’t even a word!), Gartner published its 5 Rs model as a framework for developing a strategy for migrating to the cloud: Rehost, Refactor, Revise, Rebuild, or Replace. Later, Stephen Orban, author of Ahead in the Cloud: Best Practices of Navigating the Future of Enterprise IT (CreateSpace), created the 6 Rs strategy: Rehost, Replatform, Repurchase, Refactor, Retire, and Retain. While these strategies focus on cloud migration as a whole, they are relevant to serverless adoption as well.
Every technology migration has challenges. Compared to a start-up, with a simple domain, a smaller customer base, and fewer employees, enterprises have many strate‐ gic angles to contemplate before deciding on a serverless migration strategy. These include:
- The experience and relevant skills of their engineering teams (i.e., whether they will be able to successfully execute the migration tasks)
- Making the business stakeholders understand the technology, the necessity of migration, and its business impact
- A clear assessment of the impact on customers worldwide or in specific areas where the business operates
- Presenting the case to the executive team and the board of directors
- Possibly, assuring the shareholders of their investment’s benefits and monetary value
For an organization serving customers 24×7, unsurprisingly, customer impact is usually the first question raised about migration. In our competitive business world, a minor blip in one’s trading can lead to significant gains for someone else.
Downtime and Disruption
Every technology migration raises two common concerns: service downtime and disruption. Service downtime is when an entire application or parts of it become unavailable to its end users. It may be planned or unplanned. Depending on how the system is architected and built, disruption during downtime can be severe, minimal, or nonexistent.
Whereas with scheduled downtime there are usually defined steps (a playbook) to keep the system operational, unexpected disruption requires problem investigation and mitigation. Depending on the nature of the root cause, the disruption can be minor or devastating.
With cloud and modern architectural patterns, consumers expect 100% uptime of services. Even a few milliseconds of downtime in a competitive consumer market could be extremely costly. Hence, serverless migration tasks should be well-thought-out and carefully coordinated activities.
Convincing your business and stakeholders about the benefits of serverless is only part of the process, as soon after you will be asked questions like the following:
- What do we do with the acres of tech spread across our organization?
- How do we decide which applications are suitable for the serverless stack?
- How quickly can we move everything over to serverless?
The standard answer to all such questions in the software industry is, it depends! And while the appropriate strategy does depend on your domain, the state of existing applications, their complexity, etc., you must be able to offer the proper guidance. In the following sections, we’ll take a look at the three most common serverless migration approaches:
- Lift-and-shift
- All-at-once service rewrite
- Phased migration
