Most of us have heard about the crisis Southwest Airlines had over the Holidays. Most articles cite “problems related to legacy systems…” and “outdated scheduling software called SkySolver.” And, of course, there will be a huge financial impact as they try to make everything right with their customer base.
Most likely, the CEO, CFO, COO, CIO, and CTO of Southwest are receiving many calls and emails from vendors offering to “Let us fix it. We will convert everything to be cloud native…” This path sounds like the old saying, “No one ever got fired for buying IBM…” Southwest has a stated multi-cloud strategy, but legacy applications like SkySolver were obviously not priority cloud-native candidates. Though there will be pressure from investors, the industry, and the press to convert legacy applications like SkySolver to cloud-native, I would not initially recommend this approach.
Why? Here are a few reasons:
- Southwest is a 24X7 production operation with global implications when there is an operational failure of some type. Think of what it would take to “cut over” to an entirely new system to replace a core scheduling application.
- It would be “megabucks,” maybe 100’s of millions of dollars to engineer, and very high risk to implement.
- Southwest’s reputation is based on “low cost.” Think of what would happen if they re-wrote SkySolver to cloud-native and the new version “failed.”
Southwest’s stated multi-cloud strategy is undoubtedly reasonable for new applications or for applications where refactoring makes sense. For very high technical debt applications like SkySolver, Southwest should attempt a lower-risk approach based on lift-and-shift.
Sometimes antiquated legacy applications depend on older operating systems or other outdated software, which becomes the “anchor” for why the application is difficult to modernize. This problem is solved using a multi-cloud technology like VMware or ESX-compatible hosting services. You run the same “older” guest operating system but on modern hardware that has increased performance, reliability, and scalability. Cloud-native VMs don’t support ancient operating systems, but cloud services based on VMware can often run old x86 Windows or Windows Server operating systems. Every cloud vendor can run VMware as a service or as a native hypervisor, and SkySolver running on modern VMware, would become multi-cloud agnostic.
SkySolver has been lifted and shifted to the cloud. Now what?
Southwest would immediately have a core business risk reduction if it were possible to migrate SkySolver, and then successfully cut over using a lift and shift cloud strategy. The process would be similar to a traditional DR (disaster recovery) scenario, where there is a need to switch to the “secondary” site because the primary site was lost. Migrating with this style of architectural thinking could be used to move SkySolver from on-prem to the cloud.
The last part of the plan for SkySolver, now running “as-is” but in the cloud, would be to somehow isolate any interfaces to it so that Digital Transformation could happen. For this, use the “Strangler Pattern.” This approach provides a “safe path to the cloud” and allows for incremental transformation rather than a “big bang” cloud native re-write that would be risky and costly. This type of strategy would provide Southwest with “multi-cloud” compatibility. They could pick and choose cloud services, implement them at their own pace, and incrementally and safely digitally transform SkySolver or other similar legacy applications.