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:
- Applications that rely on broadcast or multicast traffic rather than standard transport protocols for TCP and UDP IP packets may lose some functionality because cloud provider networks drop broadcast and multicast traffic. Packet capture can be used to identify apps that rely on broadcast and multicast streams.
- If you’re using AWS’s C3 instance, you can use Jumbo Frames rather than the standard 1500 bytes. Packet capture lets you see whether your instance sizes are translating into efficient network throughput.
- The public cloud doesn’t provide much visibility into how well your applications are running. Packet capture helps troubleshoot performance glitches by reporting the packets entering and leaving each instance. This is particularly critical information in the absence of error counters on a physical switch or a storage array’s I/O counts, neither of which is available on the public cloud.
“Cloud Management from an Enterprise Perspective” from October 12, 2016, describes the deliberate approaches enterprises are taking to address complexity in migrating apps to the cloud.
How to think ‘long’ without getting caught short
Not many organizations can afford to press the pause button while they re-architect their entire spectrum of data systems all at once. Systems generally move from in-house to the cloud in ones and twos, less critical to more critical. How they make the move is often more important than when they do.
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:
- Don’t short-change the time you set aside for research.Determine the priorities and needs of each user group, create a high-level inventory of features, and understand the areas of most benefit and most risk.
- Design for parallel deployment. Be ready to release portions of the new app while continuing to support the one it’s replacing. During the transition, you’ll be releasing patches and even updates for the old app while you’re deploying the replacement in a deliberate piecemeal fashion.