This content originally appeared on DEV Community and was authored by PeterMescher
To refresh my memory for AWS and Terraform implementation basics, I decided to implement the AWS edition of the Cloud Resume Challenge.
The GitHub repo for this project, including deployment notes, is here.
The README for the repo contains a basic explanation of the architecture, so I won’t repeat all that here. The purpose of this post is to discuss what I learned while implementing this project (and it was a lot!)
I’ve been an Infrastructure specialist for nearly my entire career (Networking, SANs, storage, data replication, DR, and some server work) so getting into the nitty-gritty of an application deployment on the cloud was… educational. (And by “educational” I mean a lot of time spent with the Terraform AWS Provider documentation, Google, ChatGPT, and banging my head against my desk.)
This post is organized loosely into the various major parts of the project, and the things I learned along the way.
Web Content
A very long time ago (the Stone Ages in Internet-years), I had a job implementing a website to handle registration for a conference. After somebody else made a pass with MS FrontPage (which produced something unusable that crashed everything but Internet Explorer) I re-implemented the whole thing, from scratch, with hand-coded HTML (using ColdFusion and MS Access for the back-end.)
The Cloud Resume Challenge suggests hand-coded HTML/CSS for this project, just to give you some exposure to it; this was definitely a throwback to that long-ago project. It made me very grateful for markdown, because putting together some quick informal content in hand-coded HTML was just as painful and annoying as I remember.
“Vibe Coding”
I will readily admit that I don’t know JavaScript, so I had ChatGPT write the code that called the website counter API (and the python for the lambda back-end.) This “vibe coding” was a very interesting and rewarding experience. While I would never trust a chat-bot for complex tasks, for simple programs like this it worked very well. Being able to engage in a two-way dialog to ask it what various parts of the code do was extremely useful.
I made extensive use of Copilot auto-completions (within VSCode) to write the Terraform. It has a pretty uncanny sense of what I’m trying to accomplish, and it really speeds things up having an AI do a lot of the “syntactic sugar”, required parameters for a resource, etc., which reduced the amount of time I had to spend poring over the AWS Terraform provider documentation.
In the spirit of admitting my mistakes, I learned that it is important, when encountering an error, to go to the docs first, triple-check them, and consult ChatGPT last. I thought I had run into a really-gnarly limitation in the AWS provider where it would not export the hosted zone ID for an API Gateway domain name (necessary for building a Route53 alias to it.)
ChatGPT wasn’t wrong at the beginning; when I fed it the error message, it gave me the example code, straight out of the Terraform documentation, to solve it. However, I thought that was the code I already had, and when I told ChatGPT that the API Domain Name resource apparently didn’t export the attributes I needed, instead of pointing me to the Terraform documentation, or asking to see my code…? “You’re absolutely right — as of now, the aws_apigatewayv2_domain_name resource in Terraform does not expose hosted_zone_id directly, even though you need it for a Route 53 alias record.”
It should have provided a link to the TF AWS Provider docs, or asked to see my code. But it was so eager to please, I wasted way too much of my time (at least an hour) on an awful, terrible, no-good workaround involving a ChatGPT-generated shell script to parse the output of the appropriate AWS CLI command, and feed it back into Terraform. (And remember what I said earlier about how ChatGPT is no good for complex coding tasks? It took a really long time to interactively debug that shell script with the chat bot… turns out AI isn’t much better than humans at chaining together awk, sed, and regex’s (to parse JavaScript without a tool/library for the job) than humans are.)
Terraform
I’ve lightly used Terraform before, but this was my first opportunity to implement an entire project in it. Overall, I was very impressed. Its straightforward syntax was very appealing to me, and the ability to trivially do things like run commands for things that were not supported natively within Terraform (like uploading website content or code) or work across accounts. (Yes, CFn has StackSets, but in TF, x-acct work consisted of five lines of code to create another provider instance and give it a label.)
The AWS CDK looks great for experienced coders, which I am not. CloudFormation has come a long way over the last few years, but ultimately I chose Terraform for its familiarity and ease of use.
AWS in General
It was a pleasant exercise to create/deploy this simple serverless application, starting from an empty account and building everything from the ground up. I had, of course, gone through plenty of guided exercises before, but nothing helps you learn like pounding your head against the desk while you spend a half-hour correcting a misunderstanding the hard way.
For this project, I used the console, and then created all my resources in Terraform separately. (I did not import any of the resources into TF; all the Terraform was written from scratch.)
I think if I was more-familiar with all the pieces and parts, I’d just start with Terraform, since I had to implement everything twice. But it was very handy to be able to go to a working copy of the site to check on things like policy documents, and various unfamiliar resource attributes that the console set for me.
This content originally appeared on DEV Community and was authored by PeterMescher