Anytime I hear a single approach or methodology promoted as working equally well in all circumstances I become leery. For example, general purpose cloud providers recommend the best way to move on-premise applications to the cloud is adopting “lift-and-shift”. Using this technique, organizations harness the power of the cloud to optimize applications once they host them there.
Unfortunately, this methodology may break down when one considers moving backup software to the cloud. The backup software will almost certainly still work if moved to the cloud. However, organizations need to ask how easily, efficiently, and effectively will it perform backups once in the cloud? The answer to that question often necessitates that organizations select cloud backup software that uses a cloud native architecture.
Lift-and-shift Works Really Well … Most of the Time
If the opening gives any organizations pause about their current lift-and-shift strategy, it should not. Trying to optimize on-premise applications before or as organizations move them to the cloud rarely works well. Organizations will almost always find that optimizing their applications after moving them to the cloud works much better.
Once hosted in the cloud, organizations then have access to all the analytical tools and infrastructure resources that the cloud offers. Organizations may use these tools to understand each application’s specific requirements and optimize each one accordingly. This analysis and optimization often occur more quickly and easily than if doing the same tasks on-premises.
The Exception to the Rule
Despite the general logic and success of this lift-and-shift strategy, exceptions to its effectiveness exist. Count backup among those exceptions.
An organization can certainly perform a lift-and-shift with its current backup application. Once hosted in the cloud, it will back up and recover applications hosted in the cloud. Unfortunately, once in the cloud, one cannot easily optimize backup software to perform backups and recoveries in the cloud.
Vendors of on-premises backup software architected their software to work in either physical or virtual environments, or perhaps both. However, few, if any, originally architected their backup software to work in AWS, Azure, or Google Cloud Platform (GCP) environments. As such, placing their backup software in any of these clouds will likely NOT result in cloud backups done well.
Backup Architected for the Cloud
Backup software architected for the cloud displays many different properties than backup software designed for on-premises use. Two key ones they offer, and ways in which they differ from on-premises software, include:
- Delivered as a software-as-a-service (SaaS) offering. One will find nearly 30 different backup solutions that offer backup services for AWS. However, if one requires that the backup solution be available as a SaaS offering, then the total number of solutions drops to about 10. Backup software delivered as a SaaS relieves organizations of the traditional headaches associated with managing it. Using this delivery mechanism, the vendor assumes all responsibilities for backup software patches, updates, and fixes. It also takes responsibility for tuning its software to only use the cloud resources it needs when it needs them. This frees organizations to solely focus on backups and recoveries, not the software that supports them.
- Better utilize and manage available cloud resources. Compute and storage represent two primary ways that cloud native backup applications capitalize on new cloud architectures. When organizations lift-and-shift a backup application into the cloud, they must procure and host it on a VM in the cloud. They must also pay for whatever cloud storage it uses to store backup data. Backup applications based upon cloud native architectures take both cloud compute and storage into account in their design. When organizations obtain these SaaS offerings, they do not have to worry about allocating or managing compute to run it. Further, depending on the SaaS backup solution selected, it may reflect all its costs in a single monthly per GB charge.
Cloud Backup Ultimately Requires a Cloud Native Architecture
Organizations often perform a lift-and-shift and move all their applications to the cloud in masse. As they do so, they may find they can optimize the cloud infrastructure upon which many of their applications run. Other applications they may find it is best to simply abandon them and move to ones architected for the cloud.
Backup applications will likely be among the group of applications that fall into that latter category for many organizations. Large organization or small, many will find it difficult to beat the ease, simplicity, and lower costs that come with using a backup application natively architected for the cloud.
Already organizations may turn to providers such as Arpio, Druva, or Clumio for AWS; HYCU for Azure or GCP; Cobalt Iron for AWS, Azure or GCP; and, SpinOne for G Suite and Office 365. These solutions free organizations to glean the full set of benefits that cloud-native backup solutions offer minus the administrative overhead of products developed for on-premises environments.