It’s management. I’m not going to draw it out past the subtitle — management is the problem

While I’ve always been more of a hamster person, I recently decided to get a bird. I kept hearing good things about them and was referred to a place that sells hand-raised cockatiels. I picked the one that jumped and perched on my hand right away.

Cockatiels are smart but also deeply lazy

Cockatiels are low-energy birds that just want clean food and for you to be home an hour a day. While picking out a cockatiel I saw that at this same store I could buy a cockatoo. The cockatoo is a type of bird that hates to be left alone, often bonds to one person hating everyone else in the house, and can bite hard enough to cost you a finger.

A cockatoo plotting murder

Cockatoos are sold at the same store as cockatiels and they even have similar names. And I tell you all this because this is what serverless apps are like. They’re extremely easy to set up, but as time goes on it’s hard to know if you will have a cockatiel or a cockatoo on your hands.

Management is the serverless problem no one tells you about

Serverless is fast to build. There’s really no other platform where I could take a group at a hackathon and expect everyone to have working stacks in 2 hours with no demo starter project to deploy. Even better, the stack deployed by a single amateur is relatively easy to scale and control. So the app you built at a hackathon might actually well work in production.

So, should we use your weekend project? Absolutely not. Let me list three questions any good team lead would ask:

• What AWS account is this stack associated with, and who would have control of it if something goes wrong?
• If a team member wants to propose changes to your stack and test that the new version works, how would they clone this stack?
• At some point, we’ll want two or more versions of this app, at the very least dev and a prod version. How will these two versions be kept appropriately in sync and configured correctly with things like DB names and URL’s that would be different for the two versions?

The tools everyone talks about are not for building but managing

AWS CloudFormation is, for most developers, the first stop in “serverless for production”. In this case, storing the infrastructure of your serverless app as code, as a fairly readable YAML template makes basic collaboration and change tracking possible once you track your code with version control. Using CloudFormation is not a faster way to build apps; it would be faster to just click through the AWS console. AWS CloudFormation exists to make future management of your app easier.

Various companies offer third-party tools, all of which make use of CloudFormation as their bridge into AWS: they generate and manage the CF templates for you. ServerlessFramework, Terraform, and Stackery are all closely associated with this concept of having CloudFormation templates built for you.” But I would posit, dear reader, that this is not the point of these tools. Anyone can buy a Cockatoo. The point of all of them is management.

How third-party tools help

I’m not going to dive too deeply into how these tools help you manage AWS accounts and permissions. Suffice to say they all attempt solutions, and while I think Stackery’s offerings are particularly robust, a bit of planning ahead of time is also a key component of your fix for account permissions issues.

All three of the services listed above have rather distinct methods of managing different app instances, specifically the config that varies between each instance:

Terraform

In an attempt to be ‘multi-cloud’ Terraform templates are written in an abstracted language not explicitly tied to CloudFormation. This allows for some use of external variables when building from Terraform

Stackery

Stackery lets you group all the key variables into an “environment” and deploy the same function code and stack config to one or multiple environments. Stackery lets you track the status of your multiple environments’ deployment from a single dashboard

Serverless Framework

Serverless Framework has you working with simpler AWS CloudFormation templates that are automagically expanded at deploy time. Accepting variables from a second file, you could version control separate files for each environment to consistently manage the different places your stack will run. If this solution doesn’t work perfectly Serverless Framework has a plugin ecosystem to find user-written solutions.

Be Wary of DIY Solutions

While all of these tools offer extreme advantages over just managing serverless with the AWS console and a million Slack messages, a few of the pioneers in this field have written their own solutions for this: it’s just a few values in each template, why not write some Python to swap out the variables based on some manually entered deploy target. Then some more Python to check a shared resource for whether any of these values should have changed… then I guess a server to share them on or a git repo checker… then some logic to handle conflicts between local and remote config changes…

There’s nothing wrong with a team-built tool for deployments and hardcore smarties like Ben Kehoe at iRobot have gotten great results. Fundamentally, however, serverless is not a technology; it’s a goal of disengaging from the server technology layer and focusing on business logic, so any work you’re doing to write such tools is really taking you in the wrong direction.

As the proud new owner of a cockatiel, take it from me: they are much easier to manage and you’re way less likely to get bitten.

‍