This is the intro to a two part series to help people new to AWS Lambda and serverless development. This includes everyone from experienced software developers to operations engineers who find themselves beginning to code more. The focus of this two part series is on efficient development processes and techniques over the code itself.
The pieces in this series are:
Read on below to understand why we wrote this.
A lot of things are easy in theory but are much harder in implementation and AWS Lambda, and serverless development as a whole, is no different. Understanding the architectural concepts behind building a serverless system is relatively easy. Just recently I wanted to build a service to publish AWS Health CloudWatch events to a Slack channel. It's relatively easy to picture as an AWS CloudWatch event that triggers a Lambda which publishes to Slack. But, how does one go from this simple idea to building and deploying it?
One question I’ve seen come up multiple times is what should an AWS development workflow look like? How do you build and iterate quickly?
Individual engineers struggle with this when learning new technology. Where do I start? What are the best practices? How do I solve tasks I already know how to do? And so on. (At the organizational level, organizations struggle to coordinate all their individual developers but that’s a blog post for another time.) I struggled with these issues too when I started with Lambda. Over time I learned more tools and techniques, and experimented with different workflows to make myself more productive. While building my first serverless training workshop to teach others I was forced to take a long look at what habits I had that worked, what didn’t, and define the best practices I had found.
What follows is a two part series of blog posts describing my development workflow when doing serverless development. I walk through how I start with an initial idea and finish with a completed service. I focus more on the process than the actual code. The series is split between what I do before I code and what I do after I code.
The pieces in the series are:
Many of these suggestions may elicit a, “Well duh, everyone knows to do this.” But the fact is, not everyone does know to do every step I walk through. I come from an operations background and my development habits are largely self-taught. Over the past several months I've focused on leveling up my development skills and these are the steps I've found useful.
You may be tempted to skip some steps but they’re discussed because I find the overhead up front pays off significantly later on. There are two primary frustrating parts of serverless development. The first is the need to adjust both application code and infrastructure code together. Second is the lengthened feedback loop due to limited ability to fully run a service on my local machine and therefore the time required to do deploys before I get feedback. I aim to minimize those frustrations.
Read along to see how to become a more efficient serverless and AWS Lambda developer. In this series I’m going to walk through building a service to send AWS Health notifications to Slack.
Building Your Own Applications
I published these services from this series to AWS Serverless Application Repository (SAR). You can deploy these services to construct your own serverless application to deliver AWS Health notification messages to Slack. In addition, if you write a service that can take in data and format it as a Slack message which is then published over AWS SNS, you can even reuse my aws-sns-to-slack-publisher service in your own very different application. You don’t have to bother building that! This is something that gets me greatly excited about serverless. Nanoservices are reusable code and infrastructure that can be versioned and deployed to construct usable applications. They’re a sort of a cross between a microservice and a programming library.
The two nanoservices are located here in SAR.
If you build something using aws-sns-to-slack-publisher then tweet using the hashtag #ServerlessSlackApp. At ServerlessOps we built another application involving our Slack publisher which sends tweets with that hashtag to our Slack! In a few weeks we’ll explain what we did in more depth and why.
Find what you've just read useful? Want to use serverless more in your organization? Have a look at the DevOps transformation and AWS cloud advisory services ServerlessOps provides.