Week 23, 2019 - Aurora Serverless Data API; Amazon Textract; Terraform Remote State Management

By (4 minutes read)

AWS released the Aurora Serverless Data API and Textract, and Hashicorp now offers a way to manage your Terraform remote state in the cloud.

Aurora Serverless Data API

HTTP based access for the Aurora Serverless database came out in beta at re:Invent, but has now been become generally available. It’s still limited regarding the regions its deployed to, but once it rolls out to your region1 this will allow you to make API based calls to your database.

The biggest advantage here is when you use it as a backend for your Lambda functions as it means you no longer need that function to run inside a VPC. And as that has a big impact on the speed of your Lambda function, that means you have an easy2 win. Based on a quick look, it seems that the API is well integrated in the various SDKs so in theory it should be easy to implement.

That said, the queries take longer than when using a native SQL connection, as this article3 shows. Depending on your use case that might be an issue. I suspect we’ll see this query time go down over time though.

Amazon Textract

One of the new machine learning services announced at re:Invent, I’ve been looking forward to seeing the OCR service Textract come out. Even if it’s just so I can play with it4. I haven’t done so yet, but luckily there are other people who have.

A quick summary of what it does5, Textract is an OCR service like many others and is quite good at dealing with typed text. Where it stands out from other similar services however is its ability to deal with tables and forms. Most OCR services have trouble with this, and while the results here aren’t always perfect, it does a pretty impressive job. When you try this out however, keep in mind that the costs scale here with the difficulty so you probably shouldn’t turn out the form detection on 10.000 pages just to try it out.

Terraform Remote State Management

Several weeks ago Hashicorp announced that they’re now offering a way to manage state for your Terraform projects. This is part of their new Terraform Cloud service, which is free for small teams. While this may have been part of their Terraform Enterprise offering before, making it free for many use cases means that it becomes far more usable.

Ok, time to go back to an important question. What is this and why should you care? If you’re not familiar with Terraform that is a very valid question. Terraform is an infrastructure management tool, similar to CloudFormation in AWS or ARM in Azure. It has its own syntax however6, and is often ahead of what CloudFormation offers in terms of services. That brings us to the matter of state. Remote state for a tool like this is the way of seeing where the resources defined in your code are actually deployed. For native solutions, like CloudFormation, this is handled by the cloud provider. However, obviously Terraform can’t do this and therefore needs to handle it differently.

Traditionally this is done using a so-called state file, which is created when you deploy your infrastructure. This works well, if you’re the only person doing deployments. If that’s not the case however7, you need a way to manage this state file, which is a hassle and can cause issues unless you have a single source of truth that is carefully managed. And that is exactly what Hashicorp offers here, which makes it useful.


  1. Or you’re lucky enough to be using one of the supported regions. ↩︎

  2. Relatively speaking, considering you’ll need to rewrite your queries. ↩︎

  3. I have to be honest, I’m not a fan of the way the article was updated for the new release as it makes it hard to read, but you can still get the information. ↩︎

  4. Although I discovered I’ve done a good job of getting rid of anything actually printed on paper in my life. ↩︎

  5. Just read the above article though. ↩︎

  6. For the record, the multi-cloud part of Terraform is not an argument to use other than the format of the language it’s not really multi-cloud. In the end you will write against different APIs meaning you can’t just port your code from one cloud to another. That doesn’t stop Terraform from being a good solution, just keep that in mind when someone hypes it up. ↩︎

  7. Or even if your deployments happen from a CI/CD system. ↩︎

comments powered by Disqus