In September 2018, AWS released CloudFormation Macros, a powerful addition to CloudFormation. Macros allow you to write your own mini-DSLs on top of CloudFormation, giving you the power to enforce organization-wide defaults or allow for more flexible syntax in your templates.
In this post, we'll cover the what, why, and how of CloudFormation macros. This post includes:
AWS CloudFormation is a powerful tool for provisioning resources in AWS. It allows you to describe your desired infrastructure in a configuration file, which can be checked into source control for easy review, automation, and tracking over time. You submit this configuration file to the CloudFormation service, which safely and reliably provisions your infrastructure.
One of the trickier aspects of CloudFormation is around its update mechanisms. Changing a property for an existing resource in your CloudFormation file can have drastic effects on your infrastructure, including replacing an existing piece of infrastructure by deleting the old one and creating a new one.
Amazon DynamoDB is a fully-managed NoSQL database that's exploding in popularity. It provides low-latency reads and writes via HTTP with low maintenance in a way that fits with high-scale applications.
At re:Invent 2017, AWS announced DynamoDB Global Tables. With Global Tables, you can write to a DynamoDB table in one region, and AWS will asynchronously replicate items to the other regions.
Serverless is all the rage. Ever since AWS Lambda was announced at re:Invent 2014, there's been an explosion in the serverless space. We've seen more FaaS offerings, more event sources, more managed services, and more pay-per-use pricing models.
Serverless has unlocked a whole new world for developers. But how do you get started? Because serverless is so new, it requires learning new patterns and skills.
In this post, I'll cover a few categories that I see as good entry-level projects with serverless. It's kind of like having your training wheels on -- you get used to the motions and how things work without making a big bet with your core business applications.
In my last post, I showed how to connect AWS API Gateway directly to SNS using a service integration.
A few people asked me about the performance implications of this architecture.
AWS API Gateway is a powerful service for managing your REST APIs. It was released in 2015 as a way to make the newly-released AWS Lambda compute service accessible over HTTPS.
In this post, we'll discuss one of the more advanced API Gateway use cases -- using an AWS service integration to connect HTTP endpoints directly to other AWS services.
I talk to a lot of people who are building REST APIs with AWS Lambda and API Gateway. These tools help them iterate quickly without having to worry about infrastructure.
For those building serverless applications with AWS Lambda and API Gateway, the issue of how to handle authorization is a common question.
During my time at Serverless, Inc., I've talked with a lot of users about their serverless applications. One of the persistent questions that people ask is around which database to use.
Many people reach for DynamoDB as their database of choice, with good reason. It's the most serverless-friendly database, for a number of reasons:
The release cadence of AWS is impressive. In 2018, there were 1381 release announcements from AWS on the "What's New" blog feed. At AWS re:Invent 2018, we saw some amazing announcements like a new fully-managed timeseries database, managed Kafka, a whole host of machine learning tools, and even a managed blockchain.
But that's not what this post is about. This post is about the constant, relentless improvements that AWS makes to existing services. Most of these improvements are unseen and unannounced. After all, it's hard to make a release announcement for under-the-hood improvements. Yet these consistent improvements are why AWS continues to delight its customers -- it's never happy with the status quo.