The Day I Jumped Into the Clouds...

So, hey! My name is Ekemini Essien!

Kemi or Minnie for short, but this is my story about how I blindly jumped into the clouds. Trust me, I'm not trying to be cheesy. A little backstory: I graduated with my bachelors and masters in business administration, and was a basketball player at both schools with scholarships. Cool stuff! With my established competitive nature, it only made sense that I took that competitive edge into the world of sales. Finish what you start, right?

So I stepped into the world of sales (most recently cyber security/software sales), and let's just say I got sick of it. I was tired of chasing quotas, managing inconsistent workflows, constant rejection from prospects, and the overall lack of a mental challenge. Don't get me wrong; sales is great for lots of people, but I wanted something deeper. Something that would challenge me outside of the quota chase.

I ransacked a handful of Facebook groups centered around IT, and was strongly recommended by a friend to take a stab at Forrest Brazeal's Cloud Resume Challenge. I looked through the Hall of Fame list, and I was immediately inspired by Cha'Diamond Moody's story - a woman who switched from HR to Software Engineering within a few months after completing the challenge. Incredible! Forrest's promise of attaining real world cloud skills was enough for me to take a look, but the bigger promise of cloud engineering career opportunities was enough to get me started as soon as humanly possible. These are the requirements for the challenge:

1. Get my AWS Cloud Practitioner Certification.

2. Have my resume written in HTML and styled with CSS.

3. Throw my resume into an S3 bucket and have it deployed as an Amazon S3 static website with a customized DNS domain name pointing to the CloudFront distribution. It also needed to be secured by HTTPS.

4. Include a visitor counter that displayed how many people have accessed my site, made possible via Javascript code. The site would need to be backed by a database (DynamoDB) for retrieving and updating its count.

5. Create an API that accepts requests from my web application to communicate with my database - all done using AWS's API Gateway and Lambda services. The Lambda functions were written in Python.

6. I also had to include tests for my Python code, to ensure that nothing broke during deployment if I were to make any changes.

7. Next, I had to define my back-end resources as code using IaC via an AWS Serverless Application Model (SAM) template. Once I set that up, it was finally time to set up CI/CD processes by establishing version control through GitHub and GitHub actions for continuous integration/deployment.

Sounds easy, right?
A ha ha.

Here's how it started..

AWS Cloud Practitioner Certified

All in all, this challenge took me 3 weeks to complete. One week to get the AWS Cloud certification (all studying done through A Cloud Guru) and two weeks to finish the rest of the challenge. I decided to become certified first, because I figured this would be a great way to get acquainted with AWS resources and its concepts, before actually getting hands on.

The FUN Front End

Onto the resume. As soon as I finished revamping my resume in HTML and styling it with CSS with the help of thingsthatarebrown's template , I went straight to AWS. I created an account, set up an IAM User in tandem to my root account with least privilege policies which assumed a Role to complete the necessary tasks. Once I finished my resume, I uploaded its files into an S3 bucket, set up a DNS using Route53, created a certificate in my CloudFront distribution using Amazon's Certificate Manager, and I ensured my site was not only up and running, but secured with HTTPS. I was cruising at this point..feeling pretty good! It seemed like my only problem at the time was figuring out how to reset my resume fonts and grids, so I could center my webpage properly. I can be vain. The next step in the challenge was to set up a visitor counter that kept track of how many hits I received on my page. Simple stuff, huh?

So what's the first thing that any Google search enthusiast would do, you ask? Well they'd search:

"How do you add a visitor count to your HTML website?"

I watched the first YouTube video that matched my Google search and went to work. Within 15 minutes, I had a visitor count up and running on my site.

But it was almost too easy...

I rushed over to grab my printed version of the Challenge steps and read steps 7-9. I realized at that moment that I re-used another person's backend javascript code using their API/database as my own. I felt like a fraud!

It was back to the drawing board...

The BLOODY Back End

I worked almost entirely through the AWS Console. It helped a ton to visualize what I was doing and why I was doing it. I started off by creating my table with AWS DynamoDB. I liked the concept of a schema-less database that had no fixed rules or attributes. I figured that'd be a useful tool in the future, but for the purposes of this project, I kept things simple. I created an API using API Gateway and figured out how to create a javascript code that made requests to it. Then it was time for some Python code. I had to create a Lambda function written in Python that would save and retrieve a value to and from my database table. Let's just say my daily facial routine was done in vain, because the stress of figuring out this code fired up the pimples.

After a few days, I had a working Lambda function, attached to my API which was retrieving values for my front end. Things were starting to unfold beautifully!

Automation & CI/CD

Now it was time for testing, building and deploying. This was where I immediately shifted from the AWS console and into the CLI. I did some research on how to test my Python code and eventually got the tests to consistently pass. I transposed my backend resources (the DynamoDB table, the API Gateway, the Lambda function) onto a SAM (serverless application model) template, otherwise known as infrastructure as code (IaC), and was onto version control and CI/CD via GitHub and GitHub Actions. I wanted to have each subsequent step in my workflow file dependent on each other, because I thought it'd be cool to see the cascading effect of my infrastructure building, including the front end! This had to have been hands down the best part of the project for me; however, I didn't feel that way when I hit this problem:

I was having permission issues on updating a stack I wasn't intending to update. I tried granting permissions to everything I could..but no avail. I was up all night. It got to a point that I was naming my workflow deployments "God" because I wanted Him to do something! What happened?

Then it dawned on me again: "Why am I trying to update a stack that does NOT need updating?" This is where I fell in love with the concept of IaC. If I worked backwards, and cleared my stack via CloudFormation, I could just rebuild it again using my already scripted SAM template. You can't update a stack that doesn't exist, right? So, I went to the CLI, rebuilt and redeployed my stack, pushed my changes to GitHub, and FINALLY...

To make sure it was really working, I made a minor change to my HTML file, pushed it to GitHub, and finally saw continuous integration and continuous deployment come to life right before my eyes. I was elated to finally say "Challenge completed."

Although there were many moments I wanted to cry inside, finishing the project confirmed for me that this was exactly the challenge I was looking for. I was able to put to practice an array of key concepts, like full-stack software development, version control, infrastructure as code, continuous integration and delivery, serverless/cloud services, application, networking with computers, AND networking with PEOPLE. And most importantly, it helped me understand the importance and impact of finishing what you start. The blind jump into the clouds was a good one, and I'm so happy to continue down this path.

Thanks again, Forrest, for extending this project to those with the audacity to start. My advice to anyone starting on this project/journey, DO. NOT. GIVE. UP. You'll hit a few walls, and it will feel like you're far from the answer, but trust me, it's at that point that you're SO much closer to the goal than you think. Feel free to ask me about my experience outside this blog.

Check out my resume/site at https://www.eleresume.com/