A Little Bit About Me
Hello Dev Community, my name is James Wurbel. I'm an audio engineer from Arizona who recently has been studying computer science and I have also been getting into cloud computing. As an audio engineer who solves problems for various concert and corporate settings I have leveraged that mindset to concepts in the cloud. Running big shows where everything is on the line live, you have to come up with solutions quickly if and when problems arise. As an engineer whether it be audio, space, software, or in the cloud taking into account single points of failure and creating redundancy is a concept every engineer is familiar with and implements. During live events I've had to switch to a second wireless microphone with clean signal just because the main microphone cut out. Playback on a video engineer's computer fails during a crucial PowerPoint presentation from the CEO so you need to switch over to the backup computer specifically setup for that situation in order to keep the show going. Hope is not a strategy, and in the real world problems always occur. Planning ahead will help you get through those problems and get the job done.
In January of 2020 I was on a 14 day conference for Stryker Medical in Arizona. It was arguably the biggest conference in my career and I was the lead audio engineer. By March of 2020 when the pandemic hit full force all of my work had been cancelled indefinitely. I knew that I wasn't the type of person to sit idly by and wait for things to return to normal so I started to study computer science and cloud computing. My good friend Dave Arnold pointed me in the right direction about things to study and what to learn but to be honest it was overwhelming. I knew nothing about Linux, the command line, AWS, GCP, Ansible, Python, Terraform, Packer, Jenkins, Kubernetes, Vagrant, what a container was, and the list goes on. Dave also has a tough love mentality and teaching style that made me do the work. He wasn't going to hand me the answers but rather made me pour over documentation and struggle through concepts. At first I was angry and frustrated at this approach but then I remembered a Chinese proverb that helped me push through: The work will teach you how to do it. So I continued to hone my Googling skills and kept my eye on the prize and eventually things got easier and easier.
Looking For A Challenge
I was always looking for projects to do and things that I could build that would be real world examples of how things operated in the cloud. That's when I came across the Cloud Resume Challenge created by Forrest Brazeal. The challenge included writing up a resume in HTML and then deploying it online as a static website in a S3 bucket. Other tasks included using https for security, a custom DNS domain name pointed to a CDN for low latency and high performance, writing some Python to increment a visitor count, creating a database to store the visitor count, writing Javascript to fetch that count through an API gateway, using a CI/CD pipeline to deploy the website from a source controlled repository, and using Infrastructure as Code (IaC) to configure all of your resources. A full list of tasks to complete the challenge using AWS can be found here: https://cloudresumechallenge.dev/docs/the-challenge/aws/. I had been learning Terraform so I thought that I'd use it to complete this challenge. Since I was using Terraform I also created another private S3 bucket with object versioning and encryption for my Terraform state file and another Dynamodb table for my state locking file.
Diving in Head First
Starting with the first task I converted a resume that I had already written into HTML with a dash of CSS styling. Admittedly I'm not much of a designer and kind of old school so I went with a minimalistic design which I can always update and change later. Next I started writing some Terraform to define my S3 bucket, Cloudfront, and DNS records with my custom domain name pointing to Cloudfront. Figuring out which S3 resource to use was a bit tricky because the provider was being updated and I wanted to run my Terraform code with zero deprecation warnings. I did also have a bit of trouble figuring out the DNS records part as well as incorporating a certificate but eventually I had things configured correctly and my static website was up and running secured with https. To quote Mario, "YaaaWhooooo!!"
Next I moved onto getting a Dynamodb resource with the Lambda function setup to be triggered by the website through an API gateway. I wasn't quite sure as to how to setup the Dynamodb table item (with Terraform or with my Lambda function) but after reading through the boto3 documentation it became clear that I could create the table item with the Lambda function.
This part of the challenge definitely reminded my of working with new equipment as an audio engineer. How does this audio console work? How do I configure this part of the system? Those are questions that I asked myself as an audio engineer and now they were very similar to the questions I was asking myself during this challenge. RTM, aka Read The Manual was the answer as an audio engineer, and in this case RTD aka Read The Documentation was the answer as a cloud engineer.
I wrote my Lambda function in a way that just returned a very simple response after incrementing the visitor count which made fetching the response easier with the Javascript that I also needed to write. This point also reminded me of being a good audio engineer, don't try to overcomplicate the situation and focus on your strengths. Rather than parsing the response with the Javascript, I parsed it within the Lambda function because admittedly my Python skills are a lot better than my Javascript skills.
Lastly, I needed to get all of this code into two separate repositories and then use Github Actions to trigger deployments. Version control and Git are two concepts that are very familiar to me as an audio engineer specifically with the advent of the digital age. Audio consoles used to be all analog based, but now you're really hard pressed to find one unless you go see a band like Dead and Company. With a digital audio console you can save different versions of your show files and settings just as you can version control your code base with Git and then store it somewhere remotely like Github.
Conclusion
With my CI/CD pipeline configured I was finally done! I had a great time putting all of the pieces together to complete this challenge and I especially enjoyed doing the IaC part with Terraform. I'd like to thank Forrest Brazeal for taking the time to put all of this together to make a great challenge that incorporated all parts of the tech stack in the cloud. There were definitely times that had me frustrated, but I remembered that the work would show me how to do it!
Please visit my site/resume at: https://jameswurbel.com
Top comments (0)