Last week, I joined an awesome lineup of speakers and serverless users in Tennessee for the inaugural ServerlessDays Nashville conference. This is what I shared.

Whether you help architect serverless applications at work or you’re just getting started in the community, chances are you’ve caught wind of a ServerlessDays event. Each one gathers members of a local community to talk about where serverless technology currently stands and where it’s going. The best part is that they are a true community event, built by and for serverless users. If there’s one in your area and you’re eager to meet people who share your passion, I highly recommend you register! ServerlessDays are representative of the communities hosting them and are both financially and physically accessible.

The community nature of these events was a big reason why I submitted a talk to ServerlessDays Nashville: smaller gatherings are a great place to connect with individuals who yes, want to hear from amazing speakers like Jeremy Daly, but also to meet the other folks in the area who can help motivate them to advance in their serverless education.

Good morning @ServerlessN pic.twitter.com/IjF9WVQ2x2

— Danielle Heberling (@deeheber) February 27, 2020

I wanted to share a bit about my journey to demonstrate that folks from non-traditional backgrounds can be successful serverless developers using my story as an example and maybe even motivation.

My Background

It’s always interesting how many of my “soft” skills from past jobs and experiences have wound up being incredibly relevant and transferable to my software engineering career. This is important because so many of the people who get involved in tech later are worried about starting from square one. I’m here to tell you that thanks to those “non-technical” skills, you won’t be starting from square one at all and they can be harnessed to make you a great engineer.

I grew up in a small town in SW Pennsylvania. I was always told that I had to go to a 4-year university to be successful in life and this is exactly what I did. I was 18 years old and didn’t even know what I wanted for lunch let alone what I should major in.

When I did have to pick a track, I focused on what I knew, which is that I loved playing music. I especially loved the creative and collaborative nature of being in a high-school band (— I played a ton of different things but my main instrument was the oboe). I got my degree in music education from Indiana University of Pennsylvania in 2007 and went on to teach soon after.

Hacking the mainframe

A few years in, I came to something of a crossroads: I loved music and helping my students, but I often felt I couldn’t truly be the kind of teacher I wanted to be in the public school system. I felt unable to bring my entire self to work or even do my best work due to incredibly tight budgets and that was draining.

I still wanted to be an educational advocate and opinionated community member with the goal of helping students but it was time to try a different path.

From tech support to Full Stack JavaScript development

The job I landed on was a tech support/supervisory escalation role. I loved it because every day presented me with a new challenge and furthermore, customers often used the product in ways I never imagined. This opened my eyes to the truly boundless nature of tech and gave me the opportunity to explore different points of view.

While working in tech support, I realized I wanted to go beyond answering a customer’s question and passing along a ticket to an engineer. I wanted to take matters into my own hands and be the person who logged in and fixed the issues or implemented that feature request. In short, I wanted to close that loop and code school was the necessary step to do that. After graduating with a certificate in full-stack JavaScript development, I got my first engineering job.

Enter serverless

In this first engineering position, I cut my teeth on React / Redux, NodeJS, Docker, and AWS (with an emphasis on Amazon ECS). It was exciting but in my code school program, we mostly focused on how to write code, not on how to ship it or deploy applications.

Being totally new to Docker, I found myself constantly bogged down by having to reference documentation. It was a frustrating time-suck that really begged a question in my head:

**How can I get back to writing the business logic code that sets our product apart? **

At the time, my boss happened to be experimenting with a serverless Slackbot and they asked me to review the pull-request. I was fascinated and had a million questions about this approach to software development which seemed to directly address my desire to focus on business logic instead of toiling with underlying infrastructure management.

Now, I’m a software engineer at Stackery and help the teams experience the benefits of serverless development every day!

Talking serverless with my colleague Farrah Campbell at AWS re:Invent 2019

The serverless mindset

Ben Kehoe says that, in the end**, “serverless is not even about particular technologies. Serverless is, instead, a mindset: make technology decisions that further your ability to focus on what differentiates you as a business.”**

This quote gets to the heart of what drew me to serverless in the first place. But my mindset had to shift in order to be successful with serverless and use it to its full potential.

The three areas that required the most shifting for me were:

Logs

When I used a cloud function for the first time, I literally asked where the logs were. Now I know that they are, in fact, in the logging service within your cloud provider. In my case, that meant they were in the CloudWatch Logs Managed Service. In my case, I was using AWS so they were in the Amazon CloudWatch Logs service. Log-storage is really different with serverless development and thus requires a daily shift in how you think about events/messages are organized.

Running your code

I come from a background in containers, so I was used to being able to just run a container locally on my machine, test and see how things worked, and push that container up to the cloud. With serverless, I no longer had such direct access to the containers where my code was running.

Pretty often when someone is just getting started with a serverless project, they wonder how exactly to run the code and test that it does what it’s supposed to. I certainly did.

What I discovered as I got up to speed with serverless was that the main options were:

a) Deploy changes to the cloud

b) Hack your function so it works locally

c) Mock the cloud services

d) The “cloudlocal” approach

I go with (a) and (d) but do what works for you.

Environments

i.e. “Where should I run my code??” This is an especially important mindset shift when doing serverless development if you are on a team. Otherwise, things can get messy really quickly.

From my experience with serverless, it’s best to have one cloud provider account for your development environment, one for staging, one for production, etc.

Since a big part of software development is breaking things (be it intentional or not), it’s crucial to sandbox your code to a development cloud provider account so nothing breaks for your customers while developers are active.

Since serverless inherently requires lots of managed services stitched together, environment-management becomes all the more important.

For example, at Stackery we have: 7 dev accounts, staging 1, staging 2, production, and one AWS account per environment

The bigger picture

Besides these practical shifts that need to occur for successful serverless development, the most valuable thing I can share with any audience is the opportunity we have in front of us.

Many people link the true beginning of serverless with the launch of AWS Lambda — and by that definition, the serverless community isn’t even 6 years old! We have the opportunity to build this community from the ground up how we want it to be. We are all learning and making mistakes, so let’s do our best to be welcoming to others who are interested in joining us in learning about this new technology. I can tell you firsthand that even the experienced serverless developers at Stackery are constantly learning new things, and that’s what makes a healthy, growing community.

---

If you’re interested in a solution that will help you develop, deliver, and manage serverless applications throughout their entire lifecycle, sign up for Stackery today!

Our free developer plan will get you started with options to scale when you’re ready to take your applications to a professional level. I’ll be one of the engineers on hand to help out when you have a question. In the meantime, connect with me directly on Twitter!