Managed cloud services give you everything, don’t they? Wicked availability, speed, simplicity, and backups built right in. So why are we talking about backing up your managed cloud services today? Putting it simply – don’t put all your eggs in one basket.
Managed Cloud Services
What do we mean when we talk about managed Cloud Services? We’re talking about the services which might make up your cloud solution, such as Relational Database Services which provide the database back end for your apps. Or the S3 buckets which provide the storage layer. We don’t have to concern ourselves with upgrading the database versions, or making sure all of our storage servers are in sync – that’s all done for us. That’s the beauty of Managed Cloud Services.
Learn more about Serverless and cloud technologies here.
Backups
We just said it though – managed cloud services come with backups, but we shouldn’t put all of our eggs in one basket. For example, if you needed to spin up your infrastructure in another region, or another cloud provider to mitigate a disaster event in your primary environment. If you don’t have access to your production environment, or it is otherwise unavailable, how would you get your data out to be able to restore it into another platform?
Service Level Agreements – SLA’s
But cloud providers set out Service Level Agreements for all of their managed services, to let you know what levels of service you should expect. Relational Database Service (RDS) has a 99.5% availability SLA. That means that if it’s down for more than 3.65 hours in a month, they have breached that SLA. But what does that actually mean to you? Well it means you get 10% of your RDS spend for that month credited back to your AWS account. That’s all.
Does that cover the damage to your businesses reputation? Or the hours that your team spent trying to fix-forward during the outage? Probably not. So at time like these, it might help to have an alternative to just waiting for your cloud provider to fix it for you.
Options
What are our options for backing up data and copying it somewhere other than the managed services we have come to rely on so heavily? S3 is a great idea, since you can choose which region your bucket resides in. But there’s nothing to stop you copying your data to a completely different cloud provider like Microsoft Azure or Google Cloud. But it could equally be another storage provider entirely, like DropBox or BackBlaze.
Okay, so we’ve sorted out where we’re storing our additional backups. What about the question of how we create those backups? We could string together a CloudWatch event based on a schedule, then have that fire a Lambda function which backs up the database. That keeps everything serverless. But it could be more simple than that – it could just be a tiny EC2 server running a MySQL client which can connect to the production database and run a backup. It could then copy that backup file out to your storage provider of choice.
That’s it – simple isn’t it. There’s no magic to it, it’s just common sense really. You have two keys for your car, right? Well let’s have two backups of your cloud environment.
