Serverless Champions

Ryan Scott Brown

Ryan Scott BrownAnsible

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 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.

Interview with Ryan Scott Brown

Tell us about your background. How did you get into programming?

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.

How did you get into serverless computing in general? Can you reflect upon your serverless journey over the years?

My first encounter with "serverless" was with’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.

You have been a contributor and an evangelist for the Serverless Framework for a long time. When did you start using the Serverless Framework?

JAWS (JavaScript AWS) was the earliest name for the Serverless Framework, and I ran across it in the then-very-small serverless community on Hackernews. I contributed the first version of Python support, and a few smaller features like function versioning.

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.

Talk about a service or an application that satisfactorily made you believe that serverless architectures is the way to go. What did you learn from that experience and what do you think is the biggest challenge in developing serverless applications today?

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.

Which cloud provider do you deploy to the most? Have you used multiple cloud providers? What is the top item on your wishlist for your cloud provider of choice?

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.

What are your views on the maturity of tooling, service ecosystem and developer experience in the serverless space today?

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.

What are your thoughts on what is keeping serverless architectures to be adopted widely by organizations?

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.

You are embedded in the serverless community and we love it. What is the most asked question you get from developers?

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.

With your experience working with large distributed systems and being involved closely in the DevOps community, what are your views on solutions around serverless architectures? What are the use cases that are not ready for primetime? Performance?

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.

Anything else you want to add that is significant that no one is talking about yet...

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.