In this article, we are going to talk about what a day in the life of a serverless developer on AWS looks like.

You may have thought that serverless developers strictly spend their days tweeting about the fall of containers and virtual machines, but I’m here to tell you that’s only about 2/3rds of the day 😅

This is not an extensive article and there are a slew of nuances with serverless development so treat this as a rough rule of thumb.

To kick things off, let’s talk about IAC.

Building IAC (Infrastructure as Code)

When it comes to serverless development, a large portion of your day will be spent writing IAC.

There are many popular frameworks such as:

• Serverless Framework and Serverless Components
• AWS SAM, CloudFormation, and AWS CDK
• Stackery
• Terraform
• Architect

Each one of these frameworks has pros and cons, but they all shine in their own ways. Typically, for serverless focused IAC, a serverless developer will be working with one of the following:

• Serverless Framework
• Architect
• AWS SAM
• Stackery

The other options typically lean more towards your wider cloud development needs. It’s also a good note to point out that these “serverless focused IAC” providers will compile to CloudFormation under-the-hood.

Stackery is a bit different as they offer a way to build out your IAC using a visual UI. Definitely, give them a look.

The AWS CDK is growing in popularity and so is Serverless Components, but it’s still early.

We frequently make content around the topic of IAC:

• Serverless Migration: Choosing a deployment framework
• How to build a REST API with Stackery
• Serverless: Zero to paid professional (FREE online course)

Browsing the AWS Console

Although, we’d like to keep the majority of our work in our text editor or IDE versus the AWS Console. When it comes to doing practically anything, you’re going to be heavily entrenched in the AWS Console.

Here are a few examples:

• Learning how any of this “cloud” stuff works or learning about 1/10,000 new cloud services being rolled out
• Confirming resources were created properly from your IAC
• Fidgeting with configuration before updating your IAC
• Debugging resources, application code, networking errors, etc.
• Manually testing your POC’s

Someone could give the following feedback after reading the above, “a few of these should not be done or handled with some third party tool”. The reality, third party tools have to constantly mirror functionality that AWS is releasing and can be significantly out gunned as they will be competing against an army of AWS developers.

However, that’s not a complete knock against third party tools, they’re actually invaluable when the use-cases are well defined. Recently, we’ve see a fair amount of companies pop-up which are building entire platforms around specific use-cases. These platforms will build an optimized UI wrapper over the AWS Console equivalent to streamline user experience and then sprinkle custom logic on top.

Balancing Local vs Cloud Debugging

When it comes to serverless development, there is often a lot of mixing local debugging with cloud debugging.

In practice, we may be developing our serverless applications locally, but then quickly hit issues which require flipping back and forth to the AWS console (as mentioned above).

This context switch is now being addressed by a few companies. Most notably, Serverless Inc. with their Serverless Components offering. Which is allowing serverless developers to avoid the trap of “emulating the cloud locally” and instead forcing the developer to use real cloud resources. This is possible due in part to faster deployments, powered by the aws-sdk and that serverless components can listen for changes and automatically push those changes live in real-time. Which if adoption increases, could lead to a world in which developers aren’t doing things locally. It’s still early days though.

From my view, a balance between local and cloud can be struck. This is how I think about the collaboration.

Leverage local testing for AWS Lambda and for everything else use real cloud resources.

We are able to test AWS Lambda locally because we can easily create a local server and route traffic directly to our AWS Lambda handler functions with a test event that mimics the real thing. If you use an IAC framework, this is even easier, as they have built in functionality or plugins which support local testing in this fashion.

For all the other AWS resources, I wouldn’t waste time trying to emulate the cloud locally and would opt to use real cloud resources. It’s quite a painful process, but when you have a solid IAC framework and only locally test the bare minimum, you will save yourself some headaches.

With all this being said, we definitely shouldn’t overlook unit testing with jest or mocha. Unit testing still allows you to easily test locally and quickly debug small issues in your code base before making deployments or leveraging more complex local testing strategies.

When you leverage unit testing you can also isolate core business logic using mocks which then can help you skip over the local vs non-local debate completely. Unit testing has the shortest feedback loop between writing code, executing, and debugging.

Note: If interested in unit testing with NodeJS, check out this article I wrote awhile back 💯

Actually writing application code

A large portion of a serverless developers day is writing application code. This application code will be hosted on one or many AWS Lambda functions. The AWS Lambda functions will be attached to event sources. The event sources will trigger our AWS Lambda functions thereby triggering the developers code. This is typically thought about as event-driven architecture and AWS Lambda is often thought about as “glue code” between AWS services as you can create powerful integrations with limited application code.

The AWS Lambda code which acts as the “glue” is slowly starting to be abstracted away and that will reduce code overhead significantly. This abstraction is being led by AWS. For example, take a look at AWS AppFlow, we made a video on this service a few weeks ago.

Documentation, GitHub issues, Twitter

Of course, I saved the best for last. When things go awry, you need to level up, you need to understand how to add things to your IAC or a specific IAC resource, or your deployments are breaking all of a sudden and you have no idea why.

Your going to move through a few sources:

• AWS Documentation — 90% of the time, broken up by service, easy to parse, consistent pattern, dense with information (scan it, it’s not a novel)
• GitHub issues — the beauty of the internet, when developers hit issues they will create a GitHub issue which has amazing Google SEO and is invaluable
• Twitter — when you’re looking to level up, check out Jeremy Daly, Yan Cui, Alex Debrie, and Nader Dabit

If all the above fail, you may be the first one to cross this issue and that’s pretty cool. Pay it forward by creating a GitHub issue then detailing with as much information as possible and the serverless gods, will provide you with a karma buff 🛡

Conclusion

Being a serverless developer involves a fair amount of IAC work, but thanks to all these great IAC frameworks and the cloud improvements made over the past 6+ years. We are now able to move fast with less overhead and less code.

If you’re thinking about starting to do some serverless development. Just Do It ✔️. The future of serverless development is bright and serverless is taking over the software development industry by storm. The skills you learn while becoming a “serverless developer” are also highly in demand!

If you don’t know where to start to learn about building serverless applications, check out our FREE 90+ lesson course, Serverless: Zero to paid professional on training.serverlessguru.com 🍻

And if you enjoyed this article and found it insightful in any way. Drop us some 👏 and if you want to find out more about Serverless Guru give us a follow on Twitter or send us a message directly.

‍