Following on from the previous discussions about running on-premises infrastructure as a service, I’ve been thinking about whether it makes sense (or not) to expand that capability to enterprise operational processes such as data protection. In addition, does it make any sense to run backup in the cloud as anything else other than a service? What are the choices and decision points that enterprises need to consider?
Leap of Faith
First of all, I would say that the idea of having a vendor run on-premises infrastructure could be a significant leap of faith for many organisations. I’ve seen Storage-as-a-Service (StaaS) done many ways and at many levels of engagement and integration. In fact, I’ve been involved in several bid processes to replace technology with a service offering and have evaluated tools to manage the ongoing operation.
I’ve also been involved in outsourced management for data protection, most recently for a widely geographically dispersed organisation. If you consider internal IT delivering to the business with measured service levels, then I’ve seen that too – many times.
Customer
Let’s start by looking at things from the customer’s perspective. As a customer purchasing any data protection service, I need to know at least the following:
- Scope – What is the scope of the service offering? In this instance, what can I back up and at what levels of RTO & RPO granularity? This will include supported platforms and applications. I would also add here that the scope should include whether a service should extend to offer some form of disaster recovery.
- Costs & Licensing – how will I be charged? Is the cost of the service based (for example) on terabytes under protection, numbers of objects protected (VMs, databases) or some other metric? What ancillary costs exist, like a charge for restore or network traffic?
- Transferability – will it be possible to transfer my data from one platform to another? Note that this context could refer to moving to another physical platform (cloud-to-cloud or cloud-to-on-premises) or to another provider.
- Security – How will my data be protected from prying eyes? Encryption at the source offers better security for the data owner but may skew the protected capacity on a platform if charging is based on physical terabytes stored. In addition, consider that vendor-provided encryption may make it difficult to move data outside of that service provider. See our recent podcast on security & encryption below.
- Reporting & Service Levels – what service level agreements does the vendor offer? How does the vendor report on backup success/failures? How can I tell if a vendor is not in compliance? What are my escalation procedures? What are the penalties if the service objectives are missed?
There will also be some extra minor discussion points, depending on the implementation a service provider uses. A fully “in the cloud” provider will need to seed a full backup in some way. This might be tricky, if that provider only runs in the public cloud, for example. Mitigation for this issue could be to physically ship data on an appliance of some sort.
Service Provider
What options are available from service providers? The most obvious solution for delivering backup as a service is to run as a cloud service. This might be implemented as a cloud-native solution or simply running virtual instances in the public cloud. The interesting aspect of delivering as a service is that in most respects, as a customer, the method of choice doesn’t really matter.
Of course, it does matter, if how the service is delivered impacts on the requirements of the customer. If the service provider can’t deliver the service efficiently, then that could have a direct impact. Conversely, if the service provider can’t deliver suitable backup/restore performance on-premises, this could negate any cost saving benefits.
We’ve seen a number of vendor offerings in the market that deliver Backup-as-a-Service in different ways:
- Cloud-Native – This can include running the backup service using native cloud platform services like databases, object storage and virtual instances. Cloud-native can also include “in the public cloud for the public cloud”, with no support for on-premises.
- Virtual Instances – vendors simply spin up virtual instances in the public cloud and use local object storage as a backup target. Some models of this service type will use the customer’s cloud account, some will use a vendor account.
- “Private” public cloud – no, not a typo, but a model where the service provider runs a private data centre (sometimes based in public cloud) and makes that available as a backup target. The customer runs local backup software that manages the data transfer.
- Hybrid – some vendors have started to extend on-premises backup to public cloud (and theoretically vice-versa). Ideally, these solutions should allow for cross-platform restores.
Hybrid
The hybrid model is perhaps one of the most interesting scenarios. Today we have vendors working at both ends of the data protection spectrum, not necessarily as a service. Most of these are based on physical appliances that have been used as a replacement to legacy backup. Operating using the physical appliance model means that increasing the capability of a service requires the shipping of more hardware. In a dispersed environment that’s not great for the service provider, who may be required to seed many locations.
Running purely in software provides a much more flexible model. Spinning up a new VM to expand backup capacity is much easier than having to install a new appliance and is generally much more cost-effective. This is because virtual instances can cater for demand spikes and be shut down afterwards.
All In
Finally, I think it’s worth discussing the nature of a data protection service. Solutions delivered “as a service” are not necessarily managed services. They may simply be another feature of a platform, like the Backup service on AWS. The “managed” aspect could simply refer to the provision of additional on-premises capacity to ensure service levels are met.
What does that mean for the end-user? Many solutions at the file level can be self-service and already have been for many years. This is equally applicable to VM-level backups. Could Backup-as-a-Service actually replace the backup team?
I can’t see this happening, but it does highlight that any backup service offering needs to be fully automated and capable of being built into workflows. That means exposing APIs to the customer – something we’ve discussed before.
The Architect’s View
Back to our original questions. Backup as a service could be run across multiple platforms, but in my opinion, would work best if delivered purely as a software solution. In the public cloud, I would expect data protection to be delivered as a service, whether using cloud-native or otherwise. The specifics of the implementation will determine how well (and efficiently) the service can be delivered. But buyer beware; choosing a backup solution is like getting married. You need to choose your partner carefully as you will be with them for many years – like it or not!
Post #544e. No reproduction without permission, in part or whole.