So, the obvious first thing that needs to be decided is how to actually write an application. This means the language that we are working in and the tooling around it.

Tooling

I'm aiming for AWS, simply because it's the big name and it's insanely comprehensive in what it offers whilst still being very affordable with the Free Tier.

This means that we need to work out how to get software from my codebase up onto AWS. And there are several options for this.

1. Manually. Do not do this. This is not sustainable in the long run, but it is technically an option. The AWS Web Console is insanely flexible and you can create all of the infrastructure resources you need from this.

2. Using the AWS CLI. This is technically possible, but it will take a lot of effort to keep things in sync correctly. And it is exactly this effort that the rest of the tools are designed to do for you.

3. CloudFormation. This is the defacto AWS tool for managing infrastructure. We can write scripts that we store in our repo alongside our code, and use it to deploy the code. It works, but has a lot of knowledge needed to actually achieve anything.

4. Terraform. This is an alternative to CloudFormation that is agnostic of the provider we are deploying to.

5. AWS SAM. Where CloudFormation is designed for any AWS Infrastructure, SAM is a layer on top of it that is specifically targetted to the Serverless programming model. That makes it easier to work with for our use case, but it still gets quite in-depth very quickly.

6. Serverless. This is another third-party, provider agnostic tool - like Terraform - but targetted at Serverless programming instead of Infrastructure in general.

The serverless tool is, from my experience, the best balance between flexibility and ease-of-use. It does a lot for you, but still allows you to do everything you want/need. You can literally put CloudFormation definitions in your scripts which means you can define anything you want, but if you use the Serverless structures it'll do a lot of heavy lifting for you.

Language

Once we know how to get our code up onto AWS, we need to decide what that code should be. Part of this is shaped by the platform itself, part by the tooling and part by our own preferences.

If we're working in Serverless terms, i.e. we're writing Lambdas and having infrastructure connect them, then this immediately points us in certain directions.

From my personal experience, the options that we get to are either Go or Node. These are the langauges that fit the Lambda process well - because they have library support for working with AWS and they have fast startup times.

Out of those, I've then chosen to go with Node because it is slightly easier with the tooling - there's no need to pre-build it, and the resulting lambdas are smaller so they incur less S3 charges and take less time to deploy. This is nothing against Go - if you want to use it then it's still a fantastic fit. It just wasn't for me.

On top of that, I'm actually going to use TypeScript instead of pure JavaScript. This is simply so that I get more modern features and to have typesafe code, but the actual tooling to get that into AWS is still quite small.

Getting TypeScript onto AWS

To get TypeScript onto AWS we simply need to add some modules to our project and a specific serverless plugin. We need to install the serverless-plugin-typescript plugin, and all of the tooling needed for TypeScript itself to work.

Importantly, make sure that all of this is set up as devDependencies. That ensures that they are not in the resulting archive that gets uploaded - and they don't need to be - but they will still be used for the build process. This can make a huge difference to the end result. Simply adding typescript to the dependencies section instead of the devDependencies will inflate the archive by a whopping 10MB.