Update or rewrite? A cloud-application perspective |
|
It can be hard to know when to pull the plug on a handy application that has been around forever and just works. If it’s more than a few years old, the application is probably not one the IT staff loves to work on, considering the outdated platforms and tools they have to use. Most importantly, not moving the app’s functions to the cloud is costing the organization some competitiveness, and not just when it comes to attracting top-flight development talent.
So why are so many key applications remaining in-house at companies of all sizes, with little thought and no immediate plans to move the hardware, software, and network components to their cloud counterparts? Complexity. Plain and simple. Duplicating via cloud services the intricate connections between diverse subsystems that have been fine-tuned through years of updates and patches is no easy feat. That’s one reason why training and dev/test operations are typically the first to find a home on the cloud: they tend to be short-term, and their workloads are easy to replicate. What makes an application ‘cloud-native,’ anyway? There are no shortcuts: The only one way to make an application cloud-native is to write it from scratch. Ars Technica’s Alan Zeichick distinguishes apps that have already been virtualized to run within VMware’s ESXi or Microsoft’s Hyper-V virtual machine from those that are written in C/C++, C#, Java, or some other high-level language. The former have already been cloudified to a great extent. The latter typically run on a specific machine and talk directly to Windows, Linux, or a similar OS. These systems are worlds away from Amazon Web Services, Google Cloud Platform, and Windows Azure.  Cloud-native apps are stateless and elastic, based on microservices, and independent of any terminals or standalone virtual machines. Source: Yaron Haviv, Iguazio
The typical migration scenario is to create a virtual server on a cloud service that runs Windows Server or a Linux version. You control and manage the apps the same as always, but you haven’t realized the benefits of cloud APIs or special servers. If you choose instead to run the application code in a cloud-native execution engine, you get access to the cloud services’ special features, but you may have to rewrite big chunks of your code or redesign some aspects of the apps. You also lose some control over the environment, which can have security repercussions.
Putting security front and center in cloud migration To address public cloud security concerns related to app migration, TechRepublic’s Keith Townsend recommends using packet capture and analysis tools. These utilities are likely to be considered only as last resorts in private data centers. Townsend describes three situations where packet capture pairs well with the public cloud:
Why thinking ‘long’ won’t catch you short Not many organizations can afford to press the pause button while they re-architect their entire spectrum of data systems all at once. After you’ve decided it’s time to move an in-house app to a cloud service, you can use one of three methods: lift and shift, partial refactoring, and complete refactoring. The most straightforward way for in-house apps to migrate to the cloud is to lift and shift them in more-or-less their current form, but running on a virtual cloud server rather than an in-house server. As InfoWorld’s David Linthicum explains, cloud services frequently promote lift and shift because it’s usually the quickest way to migrate applications, which means it’s the fastest way for cloud vendors to get your money. You might have guessed, lift and shift is also likely to be the most expensive app-migration alternative in the long run. Lift and shift apps generally consume more cloud resources than their cloud-native counterparts, which are designed from scratch to maximize the cloud’s benefits.  The planning phase, which AWS calls Application Migration Assessment, includes determining business logic and infrastructure. Source: AWS, via SlideShare
You probably also guessed that the other two migration choices are far from painless. The intermediate step of partial refactoring entails rewriting some components of the existing application so that you can take advantage of cloud services’ scalability and efficiency. However, with partial refactoring, you’re keeping a foot in both worlds. Ultimately you’re going to have to bring along that other foot.
This would seem to suggest that complete refactoring is the best app-conversion choice for the long run, despite the time, effort, and resources required to completely recreate applications as cloud-native. Not so fast – literally. Not all migration projects require that kind of commitment of time and resources. This is the real-world we’re talking about, which means you use the combination of platforms, tools, and resources that are right for your situation. Rewrites start with a rock-solid plan Business stakeholders tend to be slow to buy into rewrite projects, which they see as “pure expenses,” as Atom Objects Shawn Crowley writes. This includes a risk assessment and cost comparison. Business departments will also want assurances about the project schedule, not to mention potential impact on daily operations during the transition. Crowley offers five ways to improve the chances of a successful rewrite project. Two points in particular stand out:
|
