Hello Serverless

Beautiful divider with lightning bolt in the middle

Over the past few years, the majority of my work in the serverless space has been working with people newly adopting serverless. I really enjoy this phase of serverless adoption because I enjoy watching folks learn and grow as engineers. I’m personally more interested in the engineering talent I help produce than the actual systems built. However I have found it difficult to find introductory serverless material with both adequate depth and breadth.

So I introduce you to the series I call Hello Serverless. This series addresses the common conceptual and tactical questions that occur during the serverless development and operations lifecycle. It’s intended for the individual or team of developers that is building their first serverless application and attempting to do so in the span of a few weeks. The series doesn’t cover everything but covers enough to deliver a basic serverless application. This series will focus on concepts and practices that will be reused when building subsequent serverless applications.

Why Create This Series?

In searching for material for helping those newly adopting serverless I’ve either had to search topic by topic and question by question for scattered material, or the material is consolidated in a very good but very dense source that requires a significant time investment to get through. I’ve had a hard time finding something in between. 

The aim of this series is to be that something in between by answering the common conceptual and tactical questions I have seen people ask over the past few years. These questions span from “How do I reason through this problem?” to “How do I implement this?” Also where possible, this series addresses common pitfalls by introducing certain serverless development practices early in application development whose usefulness will become evident in later development.

Here are some of the questions you should be able to answer once this series is complete:

  • What architecture patterns and AWS services should I use for this case?
  • How do I properly structure data and use DynamoDB?
  • How do I structure a project and its code?
  • What are common failure modes and points in my application?
  • How do I know what my application is doing?
  • How do I test this?


This series assumes not everyone adopting serverless is familiar with Amazon Web Services (AWS), building cloud native applications, asynchronous and event-driven architectures, or building and operating distributed systems. Most developer’s knowledge is constrained by what they have primarily built, such as MVC applications and RESTful web APIs, and by what the expectations are of them by their organization. Most importantly, this series assumes that we are asking developers to do less code development and more systems engineering which may be new or less familiar to many developers.

You may (or may not) be surprised by these assumptions, but they’re absolutely valid ones to make. What I have described is a fairly typical developer. And if we’re going to grow serverless adoption we need to meet people where they are at and not where we think they should be.

The Hello Serverless Application

When deciding what to build for this series, I wanted to build the simplest application that would also be flexible enough to demonstrate the most serverless concepts. I wanted the code to be simple so people would be less likely to be tripped up by or dwell on it. I also wanted the functionality and use case to be plain and straightforward but also versatile enough to explain differences in engineering choices.

Design Philosophy

What I came up with is a CRUD (create, retrieve, update, delete) application for managing and retrieving messages in a datastore. The data the app uses is JSON and the message value is simply “Hello World”. The code for the application is here on GitHub.

{ "message": "Hello World" }

The application may seem boring but it’s flexible and relatable. The application allows for easily answering serverless engineering and development questions as well as adding interesting features down the road. Plus it’s easy to build a narrative of the application, its features, and requirements that will drive some of the decision making around the application’s progression. We’ll take a deeper dive into the application in a coming post.

The application is also relatively small and simple. It could be a single piece of a much larger application system. Its requirements are clear and we also don’t have a lot of questions about any other dependent systems. I would suggest starting with a similar sort of application for a first serverless application. You’re going to have many questions about the serverless aspects of the application which will take up a fair amount of time. Adding additional questions will give you less time to spend on answering serverless questions. Plus, the cost of having to pivot architectural decisions will be much higher in the early days of learning.

Building Hello Serverless

This series is structured so that we’ll walk through the gradual development of the application just as any individual or team would. This starts with clearly establishing what we’re building and its requirements. We then iterate through multiple architectural designs beginning with a familiar non-serverless design and gradually move through multiple serverless forms until we reach a final serverless design.

From there we address typical questions around non-functional requirements for building a production ready serverless application, or adding new feature requirements that require us to rethink previous choices. To keep the application simple and changes clear, these chapters are mostly self-contained and don’t build on previous ones. As a result, by the end of this series we won’t end up with a production ready final application. But we will have walked through the different areas that you will need to address when building your first serverless application.

Tools Used

Here are the tools that we use to build the application. The cloud platform is Amazon Web Services and where possible we use AWS managed services. To manage the development of the application we use AWS SAM and its CLI. Lastly all the code is written in Python. These choices are not to imply they are better than other choices. Instead, they just happen to be the tools I am most familiar with.

Hello Serverless The Series

This series is not intended to be a tutorial for building a running application. This series is also not intended to be a deep dive into serverless for becoming an expert. This series falls in the middle of that. It is aimed at the individual or team that is building their first serverless application for a limited scoped and well-defined use case that should be delivered over maybe 2-6 weeks; something I highly recommend as a first serverless application over a project expected to take months to complete.

Here's what's coming in the series to start!

Contact Us

Looking to get in touch with a member of our team? Simply fill out the form below and we'll be in touch soon!