DEV Community

Cover image for Good marketers are the roots of cloud computing solution
James Priest
James Priest

Posted on • Edited on

Good marketers are the roots of cloud computing solution

Hey everyone! My name is James Priest and I'm a digital and traditional marketer based in the Melbourne CBD area.I'm currently transitioning into the IT & serverless cloud industry and away from the proverbial trenches of driving engagement. Two totally different worlds with what I originally thought would have not much carryover, am I right? Wrong. Well, buckle up as I take you through my recent escapades and show you just how these two worlds collide in the most unexpected ways.

Since Cloud Computing continues to be a relatively new area, and is evolving rapidly, trying to find a tutorial that gives you everything you will want is a little daunting.
To simplify it a bit, I broke it down into three distinct components: Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS), this was traditionally how markting was being carved out.

As a marketer, I used to think that questions as simple as "How can I make a splash on a website?" were not worth discussing. After all, it's just text centered on a web page, right? My first reaction would be thinking “that is so simple, why are we having a discussion about this?” I realised that there was an implied understanding between the team of what the "right solution" or ideal system or organisation might look like and that most solutions generally focused on functional goals rather than a decision’s primary purpose.

But let me tell you about a recent marketing gig that opened my eyes. I was assigned to a small startup with some colleagues to tackle a common problem: lack of traction and market penetration, not uncommon for startups of this type in the industry. Upon investigation, we saw nothing objectively wrong and so we began the search, only to turn up empty-handed after talking with several teams. Analysing online reviews and conducting surveys, we identified the sources of the stagnation.

A few days went by, we conduct deeper analysis and find that the digital advertising campaign is contributing to negative reviews & lost capital, while the business has a strong online presence but isn't running any conversion based campaigns leading to a bottomless funnel. we got an idea on Monday by early lunchtime we recommended a two-pronged approach: work with the business to address the image issue directly and launch a targeted digital advertising campaign. The team and management agrees, and this helped implement the change and it brought about a significant reboot. As a result, online reviews improved, and customers started flowing in, fueling the growth we had anticipated. Needless to say, the problem was resolved, and life moved on. But what does this have to do with the wonderful world of tech?

One evening, after work, I received a link to a project created by a gentleman named Forrest Brazeal. He threw down the gauntlet and presented me with "The Cloud Resume Project."

Intrigued by Forrest's instructions, I decided to give it a shot. I had never dabbled in any cloud-related services before, so it was a thrilling adventure. Fortunately, I was already familiar with Amazon Web Services, thanks to a friend's recommendation, and had recently earned my CCP (Certified Cloud Practitioner) certification.

The Objectives:

Obtain the AWS Cloud Practitioner certification as a prerequisite.
Craft a resume using HTML, style it with CSS, and host it on an S3 bucket.
Secure a custom domain name via Route53 and ensure HTTPS using Cloudfront.
Incorporate a visitor counter written in JavaScript, backed by a database to track the count.
Develop a Python-based Lambda function as the backend for the database.
Implement an API to mediate interactions between microservices.
Write tests for the Lambda function to safeguard against potential future hiccups.
Build and deploy the backend section of the project using an AWS SAM template and the AWS SAM CLI.
Set up CI/CD through Github to facilitate future changes.
And lastly, write a blog post detailing our journey throughout the project, including my final reflections on what initially seemed like a "pretty simple" endeavor.

My Tribulation...I mean Journey!
First things first, I had to tackle the resume. I opted to write it in HTML right from the start, killing two birds with one stone. Once done, I dumped everything into an S3 bucket specifically configured for static website hosting. So far, so good. I was feeling pretty confident about my progress. Next up were Route 53 and Cloudfront, where I hit my first roadblock. Certificates and troubleshooting my record tables became a few hours' worth of challenges. But eventually, my site went and was officially live!

At this point, I was feeling great about the project so far, and unbeknownst to me began to fall in love with the Cloud. The practicality and potential implementations made my head spin! Unfortunately, duty called and COVID-19 had me tied up for quite a few weeks working in hospitals and clinics but this would not deter me from Forrest's challenge.

Once I got settled back in, I began work on DynamoDB and my Lambda functions. This part of the challenge took me quite a while, as I had no idea how to write code for services I had never used. After a few days, I had a working function, a working test, and a beautiful table (at least to me), and began to look into SAM. SAM was a huge learning curve for a few reasons in my case. Firstly, up to this point, I had provisioned everything through the console as I wanted to familiarize myself with how things worked. I assumed this would make things easier to understand when I reached the Infrastructure as Code aspect of the challenge. (I personally still feel this was a good choice for me and would recommend it to any beginner.) Lastly, SAM introduced CORs errors to me which nearly caused me to pull my hair out and this was where marketing met Cloud for me.
After days of struggling fruitlessly with CORS, solving one issue only to create another, I finally had an epiphany.

I decided to get a whiteboard.

I mapped out the project like I would on an business brief for a markting contract and began ruling out what could be the issue. I mapped out the entire project just as I would for a marketing campaign, systematically ruling out potential issues. You see, in the realm of marketing, it's not uncommon to encounter problems that are difficult to understand, don't make sense, or shouldn't even exist, there will be a coordination risk aspect to anything large and in marketing this is why a rule of 50% exists where there is an expectation around wastage. In those situations, we break down the entire journey into pieces until we narrow down the search to a few areas. Then, we troubleshoot until we reach a plan.

Python tests, breaking down code into manageable chunks for easier troubleshooting, and creating roadmaps for seamlessly integrating various services—all these principles align perfectly with how we troubleshoot marketing plans and systems. Let's circle back to my earlier marketing experience with the new market entrant.

Initially, the problem didn't make sense, just like CORS errors and our struggle to find a sound sales funnel. So we began the process of elimination, starting from the top down—just like writing code with proper spacing between modules and comments, allowing for step-by-step troubleshooting instead of tearing through the entire script. Then, we employed customer journeys and feedback to uncover the underlying problem, even if the approach seemed unorthodox. This mirrors how well-designed code tests can pinpoint the exact location of an issue. Sometimes, finding a solution or conducting a test requires thinking outside the box. Finally, we had to implement a solution swiftly to prevent backtracking for the businesses involved. In the world of the Cloud, the same principles apply. Even if you identify the problem, you can't bring everything crashing down to fix it—your clients or customer base always come first. This is why local testing and testing environments exist: to minimize problems that may arise in the real infrastructure and avoid downtime.

With all of this in mind, I got back to work on figuring out CORs and some other issues.

After bringing my laptop to work a few days, I got my stack deployed and working successfully. I knew at this point that I was home free, I set up my CI/CD with Github, put on the finishing, and reached out to Forrest to turn it all in.

There were several points in this project that made me internally scream but with the skills I brought away from this project like CloudFormation, Cloudfront, S3, Route53, DynamoDB, Python, JS, Serverless architecture, along with a plethora of other services and industry standards made it all worth it. This project reinforced my belief that my transition into tech is the correct one. Even more importantly it gave me a path to look into, and that is the beautiful world of Cloud.

Thank you Forrest Brazeal for creating this challenge, and thank you for creating the opportunity to meet the other takers of this challenge and network with like-minded individuals.

Top comments (0)