An Army Vet and a Respiratory Therapist Walk Into a Cloud
Tags: cloudresumechallenge, aws, serverless, resume
Published: 2022-06-06 18:51:55

# A who and a what now?
I was hoping that would grab your attention! I'm Daniel Henson, a former [cryptologic linguist](https://www.military-ranks.org/army-mos-occupations/35P-Cryptologic-Linguist) and sergeant in the United States Army and more recently a [Registered Respiratory Therapist](https://www.gmercyu.edu/academics/learn/what-do-respiratory-therapists-do) working on the healthcare front lines during the COVID-19 crisis. Now, with some planning and the support of my amazing wife, I'm working on moving into the wide world of information technology. 

That might seem like a strange jump to make. After all, at first glance neither of those seem to be some kind of precursor to modern cloud computing. At first glance, you might be right. That said, let me give you a few details about my former worlds. 

Right after my nine weeks of basic training, I spent my next 93 weeks in the military studying Mandarin Chinese. Yup, almost two years! Six to eight hours a day, five days a week, with the occasional holiday, I studied a language that I had never consciously heard prior to signing on the dotted line. Let me tell you: you can learn a lot of things when the alternative is failing out of language school and being at the mercy of "we'll put you where the Army needs you." I didn't much care for the idea of peeling military issued potatoes, so...I learned Chinese. Syntax, vocabulary, structure, the rules of a language you didn't know yesterday...can you see where this is going? Now, if I'm being perfectly honest, learning Chinese _felt_ easier to me than learning to code, but it certainly gave me the foundational ability to look at and parse something like Python or Javascript. Also, learning to learn is a valuable skill, and one that I have carried forward since. 

Sure, you might be saying, language. Got it. But health care? Yep! I wanted to continue my service to others, and so I went to school to learn respiratory care. Want to know how we break down and study the human body? Systems! The human body is one of the most complex system architectures you can find. The ankle bone connects to the leg bone, sure, but did you know that breathing is one of the main ways that we maintain our blood chemistry within the range necessary to facilitate life? That your lungs and kidneys dance a careful waltz to maintain the pH of your body within a nice happy range? Learning these systems, their components, and how they interact was critical to my success as a respiratory therapist. Being able to collect data and diagnostic samples, analyze them, interpret the results, and synthesize that information with the rest of the data collected by the health care team to assist in clinical decision making gave me _tons_ of experience in delving into a system, finding out what was wrong, and making and implementing plans to correct the errors. Now is it sounding familiar?

You may still be wondering how that led me here. That's fair. For my last several years in health care, I had been struggling with work-life balance and the odd hours and schedule necessary in the field. Conversations about this with a good friend in the SRE realm often ended with him chiding me for not making the switch to tech. "You're a systems thinker, your attention to detail is fantastic, and I know you already know a ton of this stuff. You'd be great at it." So I began looking around the field. "Pure" coding, web dev, systems administration, these were things I knew about and while interesting to me, they didn't strike sparks. Then he told me more about what he did in the DevOps and SRE worlds. He encouraged me to look into infrastructure, automation, and systems architecture. Sparks flew, and I began my journey toward the cloud. 

# The Cloud Resume Challenge
After being fascinated enough by Kubernetes to get my CKA, I went looking for more things to learn. I was chatting with some folks in a DevOps/SRE Discord server when someone mentioned Forrest Brazael's [Cloud Resume Challenge](https://cloudresumechallenge.dev). I looked into it, and immediately saw the value in having a structured project toward which to continue learning more tools and practices that would serve me well going forward. After all, I had written some scripts, built a few small projects with Python, I had my CKA, I knew the how and what and why of containers, but I hadn't yet really built anything that required making several technologies work together toward a purposeful end. 

Briefly, the project spec is: Build a web based resume that's hosted on and utilizes several cloud technologies that can be automated and kept up using modern IaC and CI/CD practices. I made a new project board on Trello, started throwing up cards, and moved a few to the _Doing_ column. 

![Trello board for my cloud resume.](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/fppl0peq3vdm8o22r6iw.png)

I began by writing up the basic front end. I had built a few static sites in the past, including the front end for a player registration and donation tracking system some friends and I used for a local charity event, so I knew I could fly through some HTML and CSS. As Mr. Brazael suggests, this is indeed the "easy part" of the entire endeavor, and I completed it fairly quickly. Once the website was hosted from S3, distributed by CloudFront, and pointed to by Route53, it was time to start moving into much less familiar territory. It was time to learn about DynamoDB, AWS Lambda, and API Gateway. It was time to build...the visitor counter. **#dramatic_musical_sting!**

As suggested in the project outline, I began in the AWS Console. Immediately I was fascinated by just how much you could accomplish in such a simple interface. I knew that automation was coming later in the project, but seeing it all take shape as I worked on each component was definitely a great motivator, and it really helped me to visualize what I would be doing with IaC a few steps down the road. There were stutters, frustrations, the pulling of hair, sure. But with every error solved, with every new concept understood, I began seeing the raw potential behind these tools. I began to make mental connections between this small project and so many of the massive web services and application we all use on a daily basis. I felt like I was seeing the man behind the curtain, and I was going to pay attention to him. 

With the website and backend in their basic functional state, it was time to move into what Mr. Brazael calls out as the true heart of this challenge: get your hands dirty with IaC and CI/CD. As much as building the backend using my now familiar combination of VSCode, GitHub, and the AWS Console taught me, this is where I really had to knuckle down. I had fed a Helm chart into Kubernetes, and I had a decent _conceptual_ understanding of templating and IaC, but I had yet to really put it into practice from a blank page. 

So I started with some IaC using AWS SAM and CloudFormation, neither of which were exactly old friends of mine. So I started reading docs, trying some lines of code, watching as the AWS Console reported that it had failed to create my resources because I hadn’t thought of yet another IAM permission...you know, the usual! And then, success! A whole and functioning backend consisting of a RESTful API, a Lambda written in Python/boto3, and a DynamoDB table just humming along doing their jobs! Outstanding! It was truly a “throw both of my hands up in the air, jump out of my chair, and make my wife ask why I was doing that stupid dance” moment! (She works in tech, so she understood perfectly, of course. I’ve watched her do the same when some complex query finally retrieves the result she’s after.)

Then I arrived at a crossroads. The challenge suggested several possible tools to get some CI/CD in place. This was the penultimate step of the original challenge, with only the writing of this very post to remain. Two tools jumped out at me: AWS CodePipeline, since it was another cool AWS tool with which to experiment, and GitHub Actions, which just seemed natural since we all know what a great resource and toolset GitHub continues to be. So I decided to use both! I built a relatively simple pipeline in the AWS console to automatically replace the static files hosted from S3 when they were updated in the GitHub repo and was impressed with the simplicity and power of doing so in CodePipeline. Then I moved on to getting the backend similarly automated using GitHub Actions. I check in my code, and BOOM: my SAM application is built and deployed without missing a beat. I might have done another silly dance at this point, I’ll never tell. _(Narrator: he did another silly dance.)_

![Architecture diagram for Daniel Henson's Cloud Resume project.](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/4y33vewrq9e9n5tee0y5.png)

To say that I learned a lot while working on this challenge would be a ridiculous understatement. The technologies I used directly, the number of AWS services with which I needed to become familiar, writing Python to do something more than output to the console, and the experience of doggedly troubleshooting a project will all carry forward with me. I’ve gained valuable insight into the complexity and intricacies of not only the architecture of even a relatively simple cloud based service, but also the mindset, persistence, and organizational skills necessary to take a project from spec to MVP. 

With that said, I invite you to check out my cloud resume at [https://resume.somedaniel.com](https://resume.somedaniel.com)!

I want to thank Forrest Brazael for creating the project. A huge thanks also to the members of the associated community for their willingness to share their own journeys and insights along the way, especially Chris Nagy, whose code helped me immensely in  understanding unit testing in this paradigm.