“Cattle, not Pets!” they say. Except that for a lot of development, coders make their own laptop their favorite pet. “It works on my machine!” becomes normal. I got tired of that and automated the creation of my dev environment..
In my day job I’ve been writing reference code and blogs a lot lately. I’m writing stuff to help people learn how to use the Amazon Chime SDK to build modern communications software. Any modern software has a lot of dependencies, usually in the form of things that need to be installed. I want to make sure that the code works on a new system and not just on mine. To do this, I test out my code and all the steps in my blog on a clean, fresh cloud server. Amazon EC2 instances are perfect for this, but there’s a lot of “undifferentiated heavy lifting” (ok, more like a long list of annoying admin tasks) to make a new instance actually usable. Doing that every time is a waste of time and finally got on my nerves. So I automated it. For the impatient, just head on over to github and check it out.
I’ve posted before about how important all the “ilities” are, and that the essence of cloud is DISPOSABILITY. “Cattle, not pets” as they say.
AWS Cloud Development Kit (CDK)
I’m a huge fan of the AWS Cloud Development Kit (CDK) instead of using CloudFormation or Terraform. With the CDK I can write real code, using a mainstream language. CloudFormation (CF) is just writing what you want into a config file, and Terraform (TF) has some more programmability but is it’s own proprietary language. With the CDK I can write in a real language.
There’s nothing all that special about the EC2 part. The CDK script reads a config file, spins up a VPC, configures the security group and creates an EC2 instance. It then sets the host name in DNS (if you added a zone ID for Route53 in the config file).
The Magic is in the User Data
The setup all happens when the new EC2 runs the user data script. This installs a pile of software routinely used for AWS development. Optionally, if you add another script of your own (pointed at in the config file, described here) you can add your own username and personal configuration. For example, I always set up a new linux box with my “gch” folder where I install my preferred tools and configure them. If you were going to use that you’d need to change usernames and settings to suit yourself. It’s useful as an example though.
Conclusion
If you are developing for the cloud, you should probably embrace it all the way. That means that you should be able to re-create a functional development environment on demand, toss it out, and get a new one in moments. That’s what cloud is all about. That’s why I build this automation. I hope you find it useful! Pull Requests welcome!
