A single place to configure your backups is available with AWS Backup and Google’s Cloud Functions now supports Go.
As AWS Auto Scaling did for auto scaling functionalities, AWS Backup is a convenience wrapper around (mostly) existing backup functionalities. It allows you to create a single backup configuration for a variety of services, ranging from EBS to several database types, and even Storage Gateways.
It works by creating a plan, which is really just a schedule, and then assigning resources to it. One thing I noticed though is that apparently this was released without CloudFormation support. My understanding is that new services from AWS shouldn’t be launched anymore without CloudFormation support, but that definitely seems to be the case here and I find that very disappointing. Hopefully, this oversight will be rectified soon.
Most interestingly perhaps is that AWS Backup1 introduces support for backing up EFS. Until this introduction, EFS backups were… well… unpleasant… to deal with? There was no native solution, and the while the recommended way according to AWS answers has improved over time2 it wasn’t what I would call a good solution. So it’s great to see that this is included.
Of course, while it’s not mentioned in the announcement post, it is limited to the usual short list of regions at the moment. Hopefully, this will expand soon to other regions like Sydney. I just checked, however, and the aforementioned AWS Auto Scaling was released one year ago3 and didn’t become available in Sydney until late December. Let’s hope that’s not a precedent.
Go in Cloud Functions
Speaking of news from exactly a year ago, it’s been a year since Lambda received support for Go and now GCP’s Cloud Functions supports it as well. Admittedly, it’s only in beta right now but I’m very happy to see that it’s available.
It’s only the third language supported in Cloud Functions, after Node.js and Python, and considering Go originated at Google it’s no surprise that it comes before some of the other languages that Lambda supports4. The implementations between Lambda and Cloud Functions are quite different though.
First, Cloud Functions specifically uses Go 1.115 whereas Lambda has a go1.x catch-all type. Presumably, sometime after the February release of Go 1.12, Cloud Functions will have a version for this as well. While I don’t have any special insight, I suspect that one reason for the explicit version here6 is that with Cloud Functions you only need to upload your code.
With Lambda, Go is different from most other languages as you are expected to upload a binary file instead of only your source code. In Cloud Functions, you don’t need to do this as Google will compile it for you and even install any modules you have configured. It will be interesting to see how this difference works out in practice.
- And I can already tell you that an overly generic name like this is going to be wonderful to search for in your search engine of choice. After all, who has ever written anything about backing up AWS? [return]
- The early versions especially were very fiddly and a lot of work. [return]
- If we go by Weekly Notes, it was exactly a year. [return]
- Of course, technically speaking Lambda now supports all languages. [return]
- Which is indeed currently the latest version. [return]
- Which is likely to be more work by the way, considering a new version of Go is released every 6 months. [return]
Read more like this:
- Week 4, 2018 - Go in AWS Lambda; AWS Auto Scaling; Cloud AutoML
- Week 39, 2019 - Step Functions Dynamic Parallelism; S3 Same-Region Replication
- Week 34, 2019 - App Mesh Routing; Nested Step Functions; CodeBuild Runtimes
- Week 23, 2019 - Aurora Serverless Data API; Amazon Textract; Terraform Remote State Management
- Week 22, 2019 - AWS Backup CloudFormation; EBS Encryption; AWSCLI Tips
Or always get the latest by subscribing through RSS, Twitter, or email!