The Cloud Resume Challenge: Closing Brief
Published: 2022-01-29 20:02:16

So I just wrapped up my rendition of The Cloud Resume Challenge.  It could use a little polishing up, but it is largely completed.  I'd like to shout out the creator of this challenge, Forrest Brazeal.  It was very fun, challenging, and I learned a ton!  That said, let's get into it.

The challenge started by getting your AWS Certified Cloud Practitioner certificate.  This is Amazon's starter certificate that shows you have foundational knowledge of AWS.  I had only been on AWS before to use their EC2 service.  I suppose this was more of a start than some people had who take this challenge, but I still had a lot more studying to do.  After a few weeks, some videos, lots of reading, and six practice exams, I took the real exam and passed on my first try. 

The next step was to write your resume in HTML and CSS.  I had basic HTML/CSS knowledge, but it took some Google'ing to entirely reproduce my old resume into raw code.  In the end, it was basically a replica.  I'm very happy with how it turned out.  I even implemented some mobile responsive design so it looks decent on a mobile phone.

After, the page had to be hosted somewhere.  There are many hosting options out there.  This being an AWS project, we use AWS S3.  S3 is a storage service, but it works great for hosting static websites.  I got the page uploaded to S3, but you are left with a long, ugly, random string URL to access it.  This must be fixed.

AWS has its own DNS service called Route 53.  I purchased a domain name from them and then changed a few routing settings to point it to my site over on S3.  Now, my site is accessible through a pretty domain name: josephsatow.com.

Next, we want to implement some website security via HTTPS.  AWS has a service called AWS Certificate Manager.  Here, I was able to get an SSL certificate and attach it to my site.  AWS's certificate manager made things easier for me by automatically inserting records into my DNS routing tables after creating the certificate.

Now that website hosting and security is to our liking, it was time for some back end work.  This was the most intense part of the project for me.  I read a lot of documentation and watched many videos that either directly or indirectly related to what I was doing.  I wanted to understand all of it.  The funny part is that all of this work is for the little "Visitor Count: #" that you see at the bottom of my site.  There's much more going on behind than scenes than meets the eye.

This was where I started using AWS SAM, or AWS Serverless Application Model.  SAM is the framework that is used for deploying your web infrastructure.  This is where I started to see the power of Infrastructure as Code. Before the cloud, you'd need to purchase and set up physical resources for anything you needed.  As you can imagine, there are many drawbacks to managing physical infrastructure.  AWS makes all these problems go away, providing resources on-demand and ready to deploy in minutes.  Now, SAM takes this a step further.  You _could_ set up your infrastructure by going around the AWS web console and going from service dashboard to service dashboard.  But that's the manual, tedious method.  With SAM, you can simply write in code each AWS resource you need into a .yaml file.  Using the SAM CLI, it's just one command to deploy your setup file. SAM then transforms this code into AWS CloudFormation syntax, which finally starts the automatic deployment of your pre-configured AWS resources.

In my SAM template, I created the DynamoDB table, two APIs, and two Lambda functions.  Lambda is a serverless AWS service that runs code which interacts with other AWS services.  In my case, my web page first calls one API to update the visitor count in my DynamoDB table.  This is done by the API triggering a Lambda function that I wrote in Python.  The function connects to the DynamoDB database and increments my "visitors count" table item by 1.  Then, another API is called, which triggers another Lambda function.  This function is what actually _grabs_ the data from that DynamoDB table and returns it to my web page to finally show the visitor count.

One side thought that I had during this whole thing is how - if you were to mess something up in your infrastructure, you can simply tear it all down and re-deploy it again in minutes.  It's a beautiful thing that allows for crazy reliably that you really don't get with physical, on-premise resources.

Anywho, we now have the front end and back end set up the way we want.  The final step was implementing CI/CD for the code.  This fancy acronym stands for continuous integration, continuous delivery, and continuous deployment.  From what I've learned, CI/CD is all about the process of code going from your local/testing environment to your live production environment in an automated fashion.  This was a lot of new learning and definitely the most fascinating part of the project for me!

Before starting any of this though, I needed to create some tests.  Even though there wasn't too much testing to be done, it's an important step in the process and makes for good practice.  I wrote two test for the first API: one to make sure the visitor count was properly incrementing and one to make sure the API returned a "request succeeded" status.  For the data-grabbing API, I wrote one test to make sure the API was returning a success status.

To begin the CI/CD process, I created a new GitHub repository and then synced the repo with the project folder I was using on my laptop.  I then created a GitHub actions workflows file.  This is the file that tells GitHub what to do whenever you push new code edits to your repo.  In my case, GitHub will start by running my custom tests on the code.  If these tests fail, the process is marked as failed and I must fix the code before trying again.  Nothing is deployed to your live environment.  If these tests pass, the process goes forward by deploying the new code to AWS.  I have it set up to where both my back end infrastructure is deployed via SAM and my front end code is uploaded to S3 to replace the old files.  To summarize - once you finish editing your code, all you have to do is run the git commit/push commands and GitHub will automatically take care of testing and deploying it to your live environment.  

There are more benefits to CI/CD than just convenience.  For example, your code is uploaded to your GitHub repository every time it is saved and GitHub saves every version of the code you upload.  This means that if something goes wrong and you need to revert, all the previous versions of the code are available for you. 

So that just about wraps up my Cloud Resume Challenge.  It felt like a very comprehensive project.  It seems like these AWS resources and these processes are very prevalent in the tech world today.  I really enjoyed the challenge and truly learned a ton!  I'm excited to expand on this knowledge and use it in the real world.