Michelle Brenner

Senior Software Engineer

I am a lazy engineer. If I have the option to copy, reference, or install a tool to get my job done faster, I say thanks and move on. I started my tech career working in entertainment, where you don’t have sprints or quarters to finish tools. Studios need the work done yesterday, because they want to get the best art possible before the release date. As an engineer, I know I can solve any problem, but I’ve realized that I can have a much greater impact using available tools.

Most of us are not working on groundbreaking technology; we’re solving problems for customers. I want to focus on delighting my clients, not fiddling with a problem a thousand engineers have already tackled. It is a common misconception that cloud computing is just servers in someone else’s warehouse. While you can get that bare-metal setup, there are so many other features that no single person can know them all. If you can define a problem in a general way, such as log in using social accounts, store information securely, or scale service to meet demand, you can find a cloud tool to do it.

As a backend engineer, I was building APIs and designing databases. Learning cloud technologies meant I could get my own code live faster, more easily, and more reliably. A colleague was not always available to help me improve the deployment pipeline or debug production problems. Learning how to make these changes myself made the whole team more efficient and effective. Expanding my skill set opened doors to career opportunities and made it easier to accomplish personal projects.

Before I got started in cloud computing, I often abandoned personal projects because deploying them seemed so daunting. But after gaining a sufficient understanding of the systems involved, not only could I complete projects, I could even use them to help with seemingly unrelated ones, like hosting a podcast. I knew that most podcasts don’t make money, so I decided that if the costs started to add up, I would not continue. After doing some research, I realized that hosting costs for podcasts had three main features:

• Hosting the public files (audio and images)

• Formatting an XML file for the podcast aggregators

• Tracking episode playbacks

Why would I pay $10 to $15 a month for that when Amazon Simple Storage Service (S3) can host my files for pennies? Hosting myself also meant I did not have to worry about a third party handling my content or data. I set up a public bucket for the audio and image files. Then I wrote up my XML file for the aggregators and put it in the same bucket. To track playbacks, I added logging on those files and analyzed them using Amazon Athena. I learned that I don’t have many listeners, but that’s OK since my AWS bill is less than $1 a month.

Now that I have you completely convinced to become a cloud engineer, here is some rapid-fire advice I wish I’d gotten before I got started:

• Turn on billing alerts before you do anything else. It’s possible you could follow a tutorial, not really knowing what you’re doing, and suddenly get a huge bill. Hypothetically.

• Get as many free credits as you can. Your provider is competing with other cloud-hosting providers for your business. Make them earn it.

• The documentation often focuses on features rather than user stories. Independent content creators are great for filling in those gaps. Dev.to is your friend.

• Change only one setting at a time.

• No one understands identity and access management (IAM).

Finally, if I have inspired you to learn and create something new, I’d love to hear about it. Learning new tools will increase your impact, but teaching others how to use them will expand it exponentially.