AWS Lambda and the power of code
The Serverless Superheroes Series featuring Eric Hammond
Welcome to “Serverless Superheroes”!
In this space, I chat with the toolmakers, innovators, and developers who are navigating the brave new world of “serverless” cloud applications.
In today’s edition, I chatted with Eric Hammond, a blogger and AWS Community Hero who has been using serverless services like AWS Lambda from the very beginning. The following interview has been edited and condensed for clarity.
Forrest Brazeal: Thanks for taking the time to talk, Eric! You’re known for your contributions to the EC2 community over the years, as well as your awesome AWS-focused blog at Alestic.com. How did you become an early AWS adopter?
Eric Hammond: Software and systems development has been my passion since 1980, and I’ve had more fun than anybody deserves, getting the chance to experience first hand and to take advantage of many amazing technology advancements in the last four decades.
I started using EC2 in 2007 and fell in love with the idea, experience, and benefits of allocating servers from the command line, throwing them away when I didn’t need them any more, and paying only for what I use. These innovations fundamentally changed how I approached technology development and allowed me to tackle challenging projects that I would not have dreamed of previously.
In the early years, I published community Ubuntu AMIs for others to run on EC2. In the spirit of “automate everything”, I wanted instances to configure themselves on startup instead of requiring an ssh session, so I created the technique of user-data scripts in my AMIs, where any EC2 user-data starting with “#!” was run as a program on first boot. I was delighted that Canonical supported this when they took over the Ubuntu AMI building, and AWS also included user-data script functionality when they released Amazon Linux AMIs.
Having benefited so much in my life from the work of others, it has been a joy to give back just a little here and there. One of the ways I do that is on my blog (Alestic.com), sharing tips I learn about AWS and tools I build with AWS.
With all that background using cloud servers, what were your reactions the first time you used AWS Lambda? How have your impressions of it changed over time?
I had a chance to try out AWS Lambda a bit before it was introduced, and my reactions are captured in my first AWS Lambda tweet, seconds after the public announcement at AWS re:Invent 2014:
I feel the same way today. There are, of course, the oft-repeated benefits of AWS Lambda: we don’t have to maintain the servers it runs on, it scales seamlessly, security features are integral, and the pricing is per fraction of a second. However, I still think the biggest benefit is what I referred to in the above tweet: AWS Lambda integrates with many other AWS services and Amazon is continually adding more integrations.
The true power of AWS Lambda comes from the abilities to trigger functions from a constantly growing number of AWS events and to employ the ever increasing number of AWS services from within the functions. Code is power, and AWS Lambda lets you inject code throughout your AWS architecture.
I did not expect Amazon to embed AWS Lambda into services like Kinesis Firehose, CloudFront, and Greengrass, but these show the vision Amazon has for letting customers apply the power of code everywhere, without worrying about the obsolescent concept of servers.
I’ve read a bit about your TimerCheck.io service, which uses a completely serverless stack. What are a couple big takeaways you learned from building and maintaining this service?
The most surprising thing I learned from building TimerCheck.io was: If designed well, it is possible for some products built with services like AWS Lambda, API Gateway, and DynamoDB (often categorized as “serverless”) to require zero technical maintenance! The public, free TimerCheck.io microservice API was released in July 2015 and I have never had to do anything to keep it working or to scale it, with one notable and unexpected exception.
The only time I had to do work on TimerCheck.io was when Amazon declared that AWS Lambda support for Node 0.10 was being phased out. If my code base had been larger, it probably would have been easier to simply upgrade to Node 6.10, but I decided instead to rewrite the function in Python 3.6. It has continued operating smoothly since.
As part of the rewrite, I also took advantage of one of several good AWS Lambda deployment tools that have arisen to fill what was an important gap when Lambda was launched. I chose Amazon’s open source chalice tool for this project, and was thrilled with how it eliminated all the work of setting up an API Gateway, a formerly daunting task.
The TimerCheck.io service has had a few short outages over the years, but they were always due to region-wide problems that AWS experienced, and AWS resolved the issue without me having to lift a finger. Even with a lot of work and expense, I could not reproduce that uptime. Letting Amazon operate my service infrastructure more reliably is well worth the cheaper price.
Speaking of expenses, I’ve been pleasantly surprised by the cost-effectiveness of the AWS services used by TimerCheck.io. I wrote an article that broke down the operating charges for December, 2016 which came out to $11 for 2.1 million API hits. I just checked, and in August 2017 it had grown to 4.8 million API hits for about $20 (“blended price” makes it difficult to calculate exactly).
I had no idea that the TimerCheck.io usage had more than doubled, because I never have to think about scaling the AWS technologies used to build this service. However, I do recommend putting cost alarms on AWS accounts, just in case.
What are some “hidden gotchas” of serverless on AWS that you have encountered?
It can take a while to come up to speed on new AWS services and features. I find that a combination of reading the documentation and hands-on experimentation works best for me. Others might take advantage of webinars, third party video tutorials, user groups, or formal training.
Some services, like API Gateway, are far more complicated, difficult to use, and expensive than I expected before trying. Other services, like Amazon Kinesis Streams, are simpler, cheaper, and far more useful than I expected.
AWS IAM gives an amazing level of security control over how resources can be accessed and how they are allowed to interact with each other, but creating effective roles and policies from scratch can be challenging or impossible. I find that I always need to look at examples and templates to find the optimal structure of policies, especially for new services.
Though I prefer to use automatable tools like aws-cli and CloudFormation to manage AWS, I find myself trying a new service or feature in the AWS Console first, just to see what IAM roles and policies it conveniently creates for me. Then I replicate this with an automated approach.
What do you think is a current immaturity of AWS’s serverless offerings? What’s at the top of your wishlist to fix?
My twitter account is a prolific contributor to the #awswishlist hashtag whenever I think of features that could be added or improved, but in practice, I focus more on what I can accomplish with the tools available than what I can’t.
One service I would like to use more is AWS Step Functions, but there currently aren’t many AWS events or services that can trigger them. I #awswishlist Amazon would wave a wand and make it possible to run a step function easily, anywhere an AWS Lambda function can be invoked.
Many of the other important entries that were on my #awswishlist have already been taken care of by Amazon: ways to customize AWS Lambda functions at create time (environment variables), a place to keep secrets (SSM Parameter Store with KMS), the ability to proxy all paths through an API Gateway to AWS Lambda, auto renewing SSL/TLS certificates for API Gateway, and auto scaling for DynamoDB tables.
Any final thoughts? :)
How about a plug for my daughter’s Alexa skill, since it is useful for AWS developers and runs on AWS Lambda. Not having to worry about infrastructure, maintenance, or scaling makes development easier for large corporations and for teens.
If you have an Amazon Echo, say “Alexa, enable the Cloud Status skill” then “Alexa, open Cloud Status”. Alexa will summarize the live AWS Service Health Dashboard for you, highlighting where there are any current or recent issues.
Check back soon for another edition of Serverless Superheroes.
