DEV Community

Marc B
Marc B

Posted on

Cloud Resume built for a challenge

I have been working in the technology, software, and applications realm for about 10 years, supporting many different platforms and languages. Recently I decided to commit to pivoting into a development related path. My brother introduced me to the Cloud Resume Challenge and I finally took the step to complete it and join with several communities focused on Cloud, DevOps, software development, etc.


Background

I have worked in several different industries since before high school while pursuing different interests and goals. Recently I decided to shift into a software engineer or DevOps role having spent the previous 10 years doing application support, tech analyst, and working along side Java developers. It was time for me to take the next step and use all the skills I have acquired.

The project itself was a challenge by Forrest Brazeal who works in the cloud and DevOps realm. He was challenging people to build from scratch a simple static website. Most of the hard work would be in the infrastructure needed to support the features which made up this site. This involved choosing the cloud provider you wanted to work with. I chose AWS since I already had a good amount of familiarity and I had just completed the AWS Certified Cloud Practitioner exam.

Using our chosen cloud provider, we are challenged to build an S3 bucket hosted website using Route53 and Cloudfront to make it secure. A requirement was to create a visitor counter for the page using Lambda, DynamoDB, APIGateway with a Python application. More AWS components went into the mix, such as DNS configuration, certificate manager, and others.

I was excited to dive into this!


Plan of attack and realizations

I purchased the book which Forrest provided to go along with the challenge for some initial direction. This was fortunate as it laid out some recommendations for which pieces to work through in a specific order.

I decided on using an Infrastructure as Code (IaC) platform from the beginning so I could quickly deploy and re-deploy the infrastructure and site as much as I desired. This was ultimately a good call, as I ran the Terraform deployment many times to work through issues and learn some best practices.

A discovery I made was I am already familiar with much of this technology and I knew more going in than I gave myself credit for. This realization bolstered my confidence a bit which helped me dedicate more hours to finishing a few of these pieces.


Diagram built in Draw.io:

Summary diagram of AWS service stack

Not too long into the project I realized that it would take longer than I initially expected to complete. This seems to be one of my opportunities, I can get better at estimating time required to complete work. I was distracted at times, shifting focus to learn more about a language or discover details about another IaC platform or many other shiny new technologies. It took effort to re-focus my attention on just the items that would move the project forward.

Onward I worked!


Terraform's built-in diagramming:
Terraform diagram

The above image is created from Terraform's output from the terraform graph command, filtering out some items using grep. The right side of the diagram shows the DB table definition, as well as the api-gateway and api integration, and the Lambda which they call and the role and policy the Lambda function is provided. The left side of the diagram shows the Route53 record and Cloudfront distribution using the AWS Certificate Manager (ACM) certificate and applying it to the www and root S3 buckets hosting the files.


Working through the issues

Several times a roadblock would appear and I had to find a resolution, as these particular issues were unique to my code, environment, decisions, and stack. Troubleshooting was a critical skill which I had developed for years and was imperative in this project. One noteworthy issue was versioning in the IaC code. I was unexpectedly getting some S3 bucket creation errors when running the Terraform deployment which were not occurring the day before.

I found that an update in the Terraform S3 arguments caused this, and I decided to lock my IaC code to a specific version for this project. You can see the differences between v3.74.3 and the next version v4.0.0. This update in Terraform's CLI application just happened to take place in the middle of my work on this project, and I had to debug to find this out. This was an eye opener and from then on I was very conscious of how the pieces of the system were configured to work together.


Fuel for growth

With this entire project finally complete, about 2 weeks longer than what I had planned, it is absolutely a catalyst to drive me deeper into the cloud ecosystem and specializing in a few pieces within the overall cloud environment. I have a great mentor who provides insight, suggestions, and guidance for powerful topics to know in the DevOps and Serverless area.

This is not the only personal project I plan to partake in for learning. As everyone in engineering or DevOps says, "just keep building", and that's exactly what I plan on doing. My next project will likely be an app written in Python, hosted in AWS, and using a public API to grab some data. I have several more ideas that I hope will turn into projects as well, which I will continue working on.

Thanks for reading.

Top comments (0)