Don't Always Throw Code At A Problem
Yesterday I just had one of those "Aha, I get serverless" moments that really extends your serverless understanding beyond just Functions-as-a-Service:
Don't code if you don't have to.
I had a simple task, check the state of a resource and send an alert if the value changed. We've all done this before because it’s a very common operations task. While I started off with an idea of what I needed top code, the more I looked at the problem the more I realized the less code I needed.
Let’s Get Building
I started building a Lambda function to check a resource’s state and then alert PagerDuty if the state changed. For the PagerDuty part, I immediately went to the API documentation and then looked at their Python module. I was all set to write some code for publishing to the PagerDuty web API.
But when I looked at the PagerDuty alert’s integration setup, I noticed I could just use AWS CloudWatch. I read some more documentation and realized I didn't need to write code to alert PagerDuty. All I needed to do was create a CloudWatch alarm or CloudWatch event rule, and send those events to an SNS topic with an endpoint, given to me by PagerDuty, subscribed to it.
My code is so simple now, it just records a state change to CloudWatch. And the event generated by that travels through resources I set up in CloudFormation, all the way to PagerDuty where it alerts me.
I'm staring at the simplicity of what I just built and that is my aha moment. Why spend time with third-party API docs and handling web requests when a simple AWS CloudWatch API call and AWS services setup with CloudFormation would take care of all I needed? To solve my problem I only needed extremely simple code and a pipeline of cloud services configured to function together.
This simplicity is an advantage for operations people who have minimal code experience. This simplicity can make approaching development even more accessible than I realized before. The code to solve your problem doesn’t have to be all that complicated. And if it starts becoming complicated, perhaps take a step back to see what your cloud provider’s services can do for you. All this is also contrary to the mantra that operations people need to have sophisticated coding skills in order to be valuable too.
If you’re someone who’s comfortable with DSLs, like CloudFormation, and understanding how third party services work then you can probably do well with serverless. The less you want to code the more serverless you can go!
What I’m realizing today is I’ve still been in the regular mindset of building serverless apps similarly to how I would have built microservices. I 1:1 map old patterns to new services. Yesterday was the first time I did something actually different.
Going Serverless Is Multiple Leaps
The first leap to serverless is understanding how to deliver functional and reliable applications code to an infrastructure without servers. The next leap is learning how to deliver less and simpler code.
(By the way, I’m also wondering how many companies should be offering more than just a webhook URL and also an SNS topic subscription endpoint.)
What's been newly announced by AWS and other companies in the serverless space?
Here's some of the coming serverless events for you to catch. Have an event you'd like to promote? Then drop an email to us.
This Week's Links
In this week's edition of Cold Start we have links on:
- Deep diving into serverless architectural patterns
- Understanding CloudFormation operations
- Rotating API keys with AWS Secrets Manager
- and more...
Have a blog post on serverless you wish others to see? Maybe you want to write for our blog as a contributor? Shoot us a message.
I'm Tom from ServerlessOps and we provide a range of services around DevOps transformation, AWS migration, serverless training, and startup cloud operations. See our services to learn more.
Also let us know what you think of this week's Cold Start using the 👍/👎 links at the end of this email!
Tom at ServerlessOps