The open source Serverless project, which currently has nearly 10,000 stars on Github, provides tooling around AWS’s “Function as a Service” ecosystem that includes Lambda and API Gateway. I recently had the opportunity to chat with Florian Motlik, CTO of Serverless, about his thoughts on serverless architectures and the future of the Serverless framework.
The following interview has been edited and condensed.
Forrest: Although AWS Lambda is less than two years old, we’re already seeing a robust tooling ecosystem appear around it, including the Serverless Framework. How did the Serverless project get started?
Florian: Austen Collins, our founder, started Serverless about a year ago. In his previous life as a consultant, he worked with AWS Lambda while building various applications. Austen saw two things about Lambda that made a huge difference for him. First, it enables you to build applications without having to maintain infrastructure. And as someone who had to maintain infrastructure in the past, he saw that was a really interesting direction for the industry to go. Second, Lambda enables an event-driven architecture, where you just react to events that can be fired from anywhere to anywhere. Austen also saw that although Lambda was very powerful, its lack of tooling made it hard for new users to get started. So, about a year ago he started building the Serverless framework. The project took off right away, and towards the end of last year, he decided that this is not just an open source framework; it’s something we can build a company around. So that’s when I was brought on as the CTO to lead our engineering team, and we grew from there.
Lambda has matured quite a bit recently, adding cool new features like scheduled functions seemingly every day. Now other cloud providers like Google and Microsoft have also entered the Function as a Service (FaaS) space. How does Serverless stay relevant in such a fast-moving technology space?
One of our big principles on the AWS side is that we want to go 80/20. We want to make the 80 percent of serverless use cases, that are basically the same, very easy to setup and implement. So setting up scheduled Lambda functions, setting up API Gateway together with a function, we want to make those things easy. And then the other 20 percent of use cases that are more difficult, we want to make them possible. We also want to make sure that we are staying up to date with all the new things AWS is releasing. For example, we moved to CloudFormation as the main source of our deployments. So now, anything new that AWS puts into their infrastructure, we can add easily, so that we’re basically future proof.
In the long term, do you want to completely abstract away the AWS infrastructure details from Serverless users?
We’re not trying to build an abstraction layer on top of FaaS providers. The providers are so easy – or rather, they already limit your options so much – that taking more options away and limiting users to the common denominator present in all FaaS providers would really be taking away too much from each provider’s functionality. So what we tried to do is have a common format for configuring them, but then expose access to the the full span of features that each provider gives you. All the time remembering that for the most common use cases, you want things to work basically out of the box, with good documentation for the rest of cases. So it’s not so much about building this “Serverless” thing on top of each provider. Instead we ask ourselves: How can we make each provider approachable, how can we make it easy to move between them, by making the configuration so clear and in the same place that we just have to exchange a couple of different parameters, so that you can move on easily?
Even without the abstraction layer, do you have a specific design pattern you’d like to see used across FaaS platforms?
We use a service-based model. We don’t really think about it as single functions, but as services composed of separate functions that have shared codebases, shared configurations, shared resources that they need access to. Think of the typical CRUD application. You don’t want to put all the CRUD operations in one function; you want to have it in four or five functions, but they all kind of belong together. Then you’re really just getting to a microservice architecture where you deploy services and functions independently with a shared naming convention. We see more and more companies, especially small to medium size companies and startups, leading the way in this paradigms, but some large enterprises too.
AWS recently released Chalice, which they describe as a “serverless microframework” for AWS Python Lambda functions. In the near future, as Lambda becomes more central to AWS and their business model, as they continue to improve their tooling around Lambda and API Gateway and their other FaaS offerings, does there come a point where Serverless as a product is harder to justify without straying into that “abstraction layer” that you talk about staying away from? How do you future proof yourself against AWS creating a native version of what you’re doing?
I’m all in favor of AWS making Lambda better in any way they can! But AWS has not shown so far that they really want to build cross-platform tooling. So because many of our users are working with multiple cloud platforms, we think this will really set us apart.
But for now, the Serverless framework only supports AWS, correct?
Yes, but we’re currently in the process of adding several more providers. We have pull requests from IBM and from Azure and we’re working with Google to get the cross-platform settings in place. So that is something that we’re working on over time. I think at this point, it’s also interesting for us to see how AWS specifically develops. One thing we’ve seen from past experience is that they haven’t had that good of a time building what we did with Serverless. That’s one reason Austen started the project, because the tooling wasn’t there and he didn’t see that it was going to be there, really. And so we’ll need to see how it goes. Obviously, if AWS jumps into this with more resources on top of Chalice, we’re looking forward to the competition to push us more, but ultimately AWS doesn’t have a track record of building developer tools on the level of Serverless. Also, remember that AWS is basically committed to integrating their new tools with CloudFormation, because if they introduce different tools at this point, a lot of their customers will have issues. So in that way I think we’re actually on a level playing field with AWS. Because we’re using the same APIs, the same tooling that they have to use, so we can compete on that front.
We’ve talked a bit about Serverless as a company and your philosophy and goals moving forward. Let’s expand out to talk about serverless architectures – with a lowercase “s” – in general. Can you give me a 10,000 foot view of what you see as state of the art in serverless systems? What are people actually doing right now in terms of real, production-grade applications that are built on Lambda?
In large companies and enterprises, we currently see two major classes of serverless projects. One is simple marketing pages where you want to collect people’s data and allow them to join in on some marketing activity. This kind of page needs to be running somewhere, it should be cheap, it should ideally never go down, and it should potentially be able to scale a lot. Users of the Serverless framework and other people that we talk to run large international marketing campaigns, and you really don’t want those sites to get overwhelmed. It shouldn’t matter if there’s 5 or 5 million people going to the page. We see this use case a lot in enterprises now because the engineering people on marketing teams can set this up on their own. They don’t have to have any operations in place. Perfect place to try Lambda. They just stand it up and it runs.
The second major use case is data processing. Lambda is great for asynchronous background tasks that crunch through some data and store it elsewhere. Here’s something really interesting that we hear from large companies: Lambda is penetrating large enterprises much faster than new technologies typically do, because it provides such high value at a low barrier to entry. Instead of continuing to manage their own infrastructure, these companies just move right onto Lambda. Contrast this with Docker. Lots of enterprises are setting up big Docker infrastructures, but at a higher barrier to entry because you have to rethink your current infrastructure. But if you’re already in AWS, you can throw some marketing processes or background jobs onto Lambda and just shut down your EC2 instances. That’s a relatively easy transition and it’s a step toward getting more and more into the serverless/microservice architecture that the Serverless Framework really promotes.
So, kind of as a follow up to that, one thing that I hear a lot from people who are not big fans of the idea of serverless architectures is that it’s still a bit of a toy or hobbyist thing. They feel like they can’t trust their mission-critical transactional stuff to Lambda. How would you counter that perception, and if there’s validity to the concerns, how do you see them being alleviated in the future?
There are definitely people out there who do massive mission critical systems and production data pipelines on top of Lambda, but in general when it comes to transactional web applications, I think that’s just something where the tooling needs to be there more and more. Over the last couple of months, we kind of re-implemented Serverless with exactly that goal in mind. How do we make it easy to build not just these marketing pages and background jobs, but go towards really building complex service-oriented architectures on top of Lambda? But even so,the kind of tooling that you need to make complex infrastructure with HTTP/API Gateway/Lambda to create a full-on architecture in a full-on application, it’s just not quite ready. We and AWS and others are working on this a lot to make it easier. Currently, Lambda from what we’ve seen, tends to be used a lot on the side, in trials, and in places that lend itself well to async background work or to processes that are relatively simple in terms of their architecture, but have to scale a lot.
Finally, what advice would you give to someone who is just starting to explore serverless architectures in their enterprise?
I think the tooling is starting to get there. It’s there for smaller services and some parts of your system. It’s still early, so people should look into it and grow with their experience. And give us and other tool providers feedback as you do, so that the ecosystem grows along with you. Remember, Lambda and API Gateway are still relatively young. The best practices aren’t established yet. So to say “use this for all your critical core applications tomorrow!” might be a bit early. But I think not looking into it and investing a bit at the beginning, especially if you’re already in AWS, would be a mistake. The onboarding is really easy. You can get started right away and replace existing production systems almost right away. We work with companies who are spending a ton of money on dev systems that should have been shut down by developers, but weren’t. So I think what I would start doing is take pieces of my infrastructure that are background, internal, asychronous and start making them over into serverless, asking: “Can we move this into Lambda? Can we connect this to SNS, or API Gateway, or Kinesis streams?” Because I think the upsides if it works for you – even if it’s just for a specific part of your system – are really, really high.