Ryan has been building out cloud infrastructures since 2010, and currently focuses on automation tooling and Infrastructure-as-Code practices. He’s both a contributor and user of Ansible and the Serverless Framework, and loves building in the open as much as possible.
Beginning with the Lambda developer preview, Ryan has built event-driven behaviors into infrastructure/deployment pipelines with Python and Lambda. Early on, he started sharing successes (and failed experiments) on ServerlessCode.com to help others and push for a common set of practices. One of those practices is the Serverless Framework: a common language spec for multiple providers to smooth the way from idea to implementation.
I started in a Systems Administration degree, and was introduced to programming via Perl and bash scripting. I picked up a Software Engineering minor and got familiar with Python for web applications—Django, Flask, etc.
My first Open Source contribution was to Boto, the Python AWS SDK, and since then I’ve been building or using tools for cloud infrastructure nonstop.
My first encounter with "serverless" was with Iron.io’s Iron Worker service, where you could bring code and hook it up to the Iron MQ messaging service to respond to events. I never used it beyond playing around, but when AWS Lambda entered Developer Preview I could see that the event-driven model for cloud functions was maturing.
Lambda started out pretty limited in what was available, and I mostly used it to add dynamic features here and there on top of static S3 sites. API Gateway really supercharged my Lambda usage, because I could hook up to *any* webhook or event.
That was about when I met Austen, and learned about what was then called JAWS.
I used it at first just for web apps on Lambda, but with the 1.0 release and introduction of CloudFormation native support I started using it for just about any Lambda-related project—frontend webapps, infrastructure glue, data processing/ETL, most things Lambda supports can be expressed in serverless.yml or orchestrated with Ansible.
I’m a "seeing is believing" type of person, so what sold me was refactoring a Django+SQL service to a Lambda+API Gateway+DynamoDB, and getting rid of the custom auth and ORM in the process. The amount of code in the backend was cut roughly by a third (more if you count using less libraries), and performance was comparable.
For new developers, the challenge is knowing where to start. There's loads of services that aren't all easy to understand, and choices on the frontend compound the confusion.
I primarily work on AWS, but I’ve tested out the Azure Functions support. For me, data locality/network transfer costs make multi-cloud apps less feasible, because you have to pay for public transit if an Azure service calls into your Lambdas to get some data or other.
The tooling for serverless apps is top notch—I think this is a result of all these services being so new. Providers understand that developers want to use services with great APIs, then automate them.
There are now a bunch of companies making strides in second-line tools like graphical infra builders, and AWS itself is working on tools like Cloud9. There's *plenty* of tooling, and it's improving all the time.
The ecosystem of developer practices is the area I think needs to mature the most right now.
There are still plenty of projects that are starting with Express-on-Lambda or similar, and not taking advantage of all the services like Auth0, Cognito, AWS WAF, and such that remove responsibility from your own code/framework. You don't need a whole framework like Django with auth, middleware, and everything built in because so much of that can be found as a service.
Lots of developers aren’t looking to switch stacks, and organizations have processes and shared tooling around their existing architectures. The tooling is there, and there are companies like iRobot betting big on serverless architectures.
What we don’t have yet is a critical mass of skilled developers that companies can draw on.
Most questions I get come from people who hear about the benefits, and understand the value proposition, but just aren't sure if XYZ use case is possible. Often, the answer is in building a bridge between legacy systems and a serverless-enabled event source.
They might get emails from clients today, and need to know how to take those emails and make them an event source for Lambda. With the catalog of services in AWS as big as it is (and growing) education is the #1 barrier. They just don't know that SES can take in emails and invoke Lambdas, or that they can use API Gateway as a webhook receiver.
Add to that the number of third-party services and you have a really hard ecosystem to get started in because of the preponderance of options.
Hard low-latency requirements (trading, ad bidding, etc) are still blocked by the problems most providers have with guaranteeing response times.
AWS doesn’t have a strong response latency SLA for Lambda, and other providers are in the same boat. There’s also plenty of applications out there that could be serverless but aren’t because it would require big architectural changes.
Take for example an ETL application that today loads the whole dataset, transforms it, and stores it somewhere. That’s not going to fit in a 5 minute max execution time for Lambda, but if you rearchitect it to do small portions in parallel it’s possible.
The question for most of these use cases isn’t "will it be possible?" but rather "is the cost of change low enough?
For existing apps, that change cost is high and can be risky if a system isn’t well-tested today. For new applications I take the serverless-first approach: try it, and fall back to traditional architectures if it’s impossible.
It’s not news, but monitoring and automation are both hard, and both critical to success.
When you start out, get set up with a good automation/deployment tool, and a good monitoring system as soon as you possibly can. Future you will skip a lot of frustration if you start out with a good foundation.