Screaming in the Cloud - Episode 64: Serverless Runs on Serverless Framework with Austen Collins

Episode Date: June 12, 2019

About Austen CollinsAusten is an entrepreneur and software engineer located in Oakland, CA. He is also the founder and CEO of Serverless, Inc. and the creator of the  Serverless Framework, an open source project and module ecosystem to help everyone build applications exclusively on Lambda, without the hassle and costs required by servers. He describes himself as a product-obsessed, software engineer who is focused on making meaning, business value and great customer experiences. Links ReferencedServerless.comtwitter.com/austencollins

Hello and welcome to Screaming in the Cloud with your host, cloud economist Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud. This episode of Screaming in the Cloud is sponsored by GoCD from ThoughtWorks. The worst part of trying any form of CI or CD tooling is getting it up to speed to test it out in the first place. You've got to configure it. You have to hook everything together.

Somehow now you're 80 steps in and for some reason step 81 is that you need to tame a wolf. GoCD knows this better than most of us. That's why they've got a new test drive option to get up and running with their tooling in seconds. Download their binary, run it locally, and set up your first pipeline in your browser. Think of it like a demo, but rather than some arbitrary hello world app that looks nothing like what you're running, instead it's being done with your own application. Give it a try. Stop getting bitten by wolves. Learn more at gocd.org. That's G-O-C-D dot org. My thanks to GoCD for their support of this ridiculous podcast.

Welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined this week by Austin Collins, founder and CEO of the Serverless Framework and also AWS Serverless Hero. Welcome to the show, Austin. Hi, Corey. Thanks for having me. Thank you for joining us. One of the things I've always found fascinating about serverless was the learning curve of what it takes to get up and running. When I built my first Lambda function, it was a two-week long process of stumbling my way blindly in the dark with an ax, hoping I wasn't going to lop off a major limb that I cared about. It was a bunch of guess and check, a bunch of iterating forward, and it never really got easy for me. Then months go by, it

becomes a little bit more understandable. And then I discover a few bits of tooling, including the serverless framework. My last application that I built using serverless took about 15 minutes, also because I'm a terrible developer who doesn't know how tests work. But it's really sped development fantastically. So first, thanks for building it. Yeah, thanks for the positive feedback.

It's that your story is the same story I had early 2015. Right after reInvent, right after they announced AWS Lambda, I stumbled through it myself. In those days, it was still pretty raw. It was very limited when it comes to features and use cases and documentation, of course. And all of that inspired me to build the Circlos framework in the early days. So yes, I empathize with your pain and hopefully we're building a solution that can help people get through that more easily. For folks who have not yet dipped their toes into the serverless waters, I feel first we should probably disambiguate a few things. AWS Lambda is a function-as-a-service offering, which has been part of a movement that has been defined as serverless.

That is not to be confused with the Serverless Framework, an open source project that you started, and Serverless Inc., the company that you now run that does things around the Serverless Framework. It's a bit of a namespace collision, but I've got to say, great SEO for you folks. Yeah, it's certainly an interesting position to be in these days. I won't deny it certainly has its benefits, but it also comes with a lot of confusion. Going back, it's a bit hard for people to understand now, but in the early days of 2015, there wasn't a serverless trend. There wasn't a huge buzzword. It wasn't like a major category. And it wasn't clear too that this was going to be such a big deal, right?

To be honest, I was in the Bay Area, I was working as an AWS consultant at the time, and I was trying to kind of raise awareness about Lambda just within my personal network. I'm saying like, look, this could be the future of how we run compute in the cloud. It's got everything that I've always personally wanted. It's like this convergence of great ideas of our time. It's microservices, paper execution, auto-scaling, event-driven. But there wasn't as much excitement back then because there wasn't a big story around how you could build a lot of use cases around it. And certainly there wasn't this great buzzword that developers love. And so in the early days, it was all a lot of speculation, like, hey, this might be, this seems like the thing we should call

it. All I knew at the time was serverless, not technically accurate, it's about as technically accurate as the cloud, right, as a term for describing something. But when you say that to a developer, and I had the same experience when I saw the word for the first time, the emotional response that you get out of the developer and that I had when I first read it is significant. As a developer, it's just music to their ears. It's everything they've always wanted in a compute platform, right? So yeah, now it's a bit early.

Now it's a bit confusing. And there's a lot of other people trying to cram a lot of other things under the serverless definition. But in the early days, it wasn't the case. It was kind of a big speculative bet. And it's just surreal how things change over time, especially if you've been there from day one. For me, one of the big value propositions behind serverless when I first got into it was it was sort of a dual revelation for me the framework itself namely that first i could build something programmatic without clicking around in the console and creating disasters for myself in the future and secondly i never even had to look at cloud

formation although you do distill down into cloud formation templates which is how you run programmatically under the hood i mean that alone is worth a lot to me because CloudFormation, at least for me, doesn't resonate with how I tend to think about infrastructure or how I tend to think about configuration. That's probably my own failing, so don't send me emails, folks, if you're a big CloudFormation fan. First, I'm sorry, there are pills for that. Secondly, it's just not how I tend to operate. From my perspective, the value of serverless framework was that it provided an intelligent wrapper that got rid of a lot of boilerplate. A few entries in a YAML file and I would wind up effectively being able to compress down a 200 line CloudFormation template in about a dozen lines of YAML that were extremely

straightforward and every line did something that I could understand. That was transformative for how I started to think about this. API Gateway even more so, given that that thing is impossible to understand when you're looking at it, but it winds up being three of those dozen lines and it just works. Yeah, it's a powerful abstraction. Looking back at the whole trend and all the movement and how people are talking about it i'm not sure i think you know amazon absolutely all credit kind of goes to them but i think it's i think it's that configuration file in the serverless framework that really helped kind of prove out or at least

show the world like how to think about a serverless application or a serverless architecture in general so again back back in the early the early days, there was this great new compute service. They were kind of pitching it. Amazon was pitching it as event-driven code, as glue code. And when we saw that, we're thinking, you could build all types of applications and use cases on this because the value prop is so compelling. And that is deliver software and applications with radically less overhead. But there wasn't a clear story as to how you could build all those applications and use cases on top of this. And that is something that I spent a long time kind of scratching my head over. Like, what is the developer experience you could wrap around this great new infrastructure as a service to make it accessible to developers

and maybe people who don't necessarily have a lot of cloud knowledge, which has worked pretty well now. We actually surveyed our user base and about 25% of our users have never even used AWS before. But we can chat about that a bit later. But it's that simple kind of, it's a simple story of functions and events. At least that's how I think of it. When you go into that configuration file, you're really just thinking about, okay, what's my business logic? What's my task? Let me declare that in the least amount of configuration as possible and then wire it

up to events that trigger it to run. The framework, our focus is how do we make that configuration minimal, keep it minimal, and have it actually remain focused on a workflow rather than the infrastructure. And I think that simple story of functions and events help propel the serverless framework and the serverless architecture to the mainstream. And it still resonates incredibly well with developers today because they're not thinking about all the infrastructure components behind the scenes that need to get provisioned and wired up

in order to work correctly together. They're just thinking about a workflow. Here's my logic, and when this thing happens, trigger this logic to run. And that does become something that is profoundly transformative. It effectively lets you run, just worry about the code and the application that you've built, not the infrastructure underneath it, not patching, not continuing to have to worry about things that are, frankly, not central and core to what your company is attempting to achieve.

Absolutely. No company sets their Q1 objective as to get a database provision, right? They want an outcome. And that's one of the strengths of the framework. You're really focused on more of the outcome level, which I think is a big reason for its success. Increasingly, as I look at the cloud and the direction the cloud is going in, it seems like more of an outcome-focused direction rather than an infrastructure focus. I think that's probably the right answer.

I think the tide is rising. As I've talked about on this show repeatedly with other folks, as cloud tends to wind up removing a lot of the things that we used to have to do in every company, there's a need to focus on the future. What are we building? What is the point of our companies? And that's not replacing hard drives anymore. Increasingly, it feels like it's not even going to be provisioning instances. It's going to be about writing application code and everything else gets handled for us. Totally agree. And I question the amount of application code we'll be writing in the future too at the same time. Because it's one thing we see a lot. The way we think about serverless

architectures is you're basically building applications on top of managed services and kind of gluing them together using functions and using events. And most companies, it's usually never just about the functions. It's about the other managed services that you could use with the functions. And we see every day the vast majority of Lambda functions are being used with other managed services. And it seems like people are relying on more and more of these managed services rather than building and maintaining their own versions of those,

increasingly at an unprecedented rate. And based on kind of how we're seeing the cloud, the big public cloud providers react to all this, it seems highly likely that they'll hit the market with a whole bunch more managed services in the future, higher levels of abstraction where you won't be asking Amazon for a virtual machine anymore, you're gonna be asking Amazon for a solution to a business problem like, hey Amazon what's in this image? Or can you take this audio file and transcribe it?

And this whole model of building applications where you're just kind of gluing all these higher order services together via functions and events is fantastic. I mean, you're able to produce more meaningful outcomes and use cases as a result and of course write less code because you're outsourcing that code to more and more services. So it'll be interesting to see how this unfolds, but I am kind of questioning how much code people will be writing in the future because already we're seeing the percentage of custom code that people are writing

in their applications shrink significantly. Oh, absolutely. Thanks to serverless framework and a few other things, I wound up having a developer recently working on something for me. All I said, because I didn't want to go through all the pain and process of teaching a contractor how necessarily to work with the intricacies

of serverless stuff, I just told him, cool, edit this script and then commit it and push it to master. Whenever it's pushed to master, it'll be about 20 seconds later, then it's going to work at this endpoint. I gave him an API gateway URL and it worked almost like magic.

Under the hood, that was just a code build tied to serverless framework doing a quick deploy on a particular branch. That's a test environment. Worst case, I can go in and make some changes there pretty easily if anything got broken. But over a two-month span, nothing ever did. It just worked. Yeah, that's the beauty of the serverless architecture. It's not quite there yet, but it is getting closer and closer to a set-it-and-forget-it type of development model. Absolutely. One thing I do want to ask you about is, well, there are two directions to take this in.

The first is, we've talked a lot about AWS, but one of the distinguishing characteristics of serverless framework is that it works across multiple providers' serverless offerings. GCP, Azure, and I'm sure there's one or two other things in there that I'm not thinking of. Personally, I haven't played much with any of those other providers. I've been doing all of the serverless stuff that I do in the AWS ecosystem. Is that fairly typical?

Are you seeing broad adoption industry-wide of multiple providers? First off, AWS, strong credit goes to them for being such innovators in the cloud space in general, then all over again in the serverless space. Right from the beginning, I was fortunate enough to work with just the Lambda team in the very early days, and it was very clear how focused they were on investing in this and maturing it and kind of pushing it forward as the next kind of mainstream cloud architecture. And they were just all in from the beginning, moving really quickly in that direction.

It was pretty incredible to watch. And as a result, they've really come out with some of the best in class serverless offerings right now that are the result of years of investment and fine tuning and hardening. And so they have that going for them. Now the other cloud providers are certainly catching up, but they even have some serverless services that have some compelling features over what AWS offers. But for the most part, absolutely. We see the whole industry at large is kind of favoring AWS in general.

I mean, they already kind of had that going for them and then they invested so aggressively in the serverless stuff. It's been pretty easy for people to just adopt serverless on AWS in general because a lot of the pieces are there. You need to build a lot of use cases. So we definitely see a lot more AWS usage in the framework. Now, when it comes to other vendors and multi-cloud

and questions around portability and stuff. We get a lot of questions about this and people ask like, hey, what does this look like? How are people leveraging different clouds, different cloud providers? And we also have all this kind of thinking coming from the container era where you just lift and shift stuff around that doesn't necessarily fit within the serverless era because serverless is a totally different beast i mean you're building applications on top of proprietary cloud services because you've made a conscious decision to just take advantage of those cloud services because they offer a great managed experience out of the box so they reduce your overhead and that you could deliver

something to the market much faster with the least amount of overhead and cost now so we don't see people kind of lifting and shifting serverless architectures it's very rare that we see that we see a lot of people you know looking to be able to easily basically have a similar application experience across the providers and across different services so we see a lot of interest in kind of deploying stuff as easily to Lambda as they, to Fargate as well. Or, you know, a lot of interest in just like, how do we just deploy a function, you know, to Google Cloud and Azure without having to change

our mindset and become cloud platform experts. And then also we see a ton of interest in what I'd call vendor choice, largely. And I think this might be the interesting trend to watch in the serverless era. Some people call it serverless, some people call it serviceful, because you're composing all these services, cloud services together to make meaningful outcomes. And I think in the in the serverless and in this serviceful era especially, a lot of people don't want to be limited to specific platforms in order to take advantage of the services they need to build the best possible product. I think if you're a developer, if you're an organization, you want to build the best the best products, you want to

be able to leverage all the services, the best possible services to do so. And so what we hear almost every single day now is, yes, we're using a ton of AWS. They've got some of the maturest serverless infrastructure services around, but we're really looking at Google's machine learning stuff. And we're kind of looking at this Spanner thing. And is there a way that we could have the same application experience and build serverless use cases on top of Google, on top of Azure, just to take advantage of some of these interesting services that they might need to use for one reason or the other without having to, again,

become like a platform expert? because obviously platforms are super complex and there's just so many dimensions of complexity to each single platform. That's the beauty of like a great vendor agnostic abstraction, right? Without having to necessarily become a platform expert, you could build serverless use cases, take advantage of super powerful services on each cloud provider, you know, again, without becoming that expert. So I think that is probably the thing to watch in the serverless era. You know, lifting and shifting these architectures is a huge challenge. Again, it's not just about the functions, it's about the services you use with the functions and all, you know, most functions are being designed with proprietary code uh or they're being written around proprietary apis and so but this this thing about

being able to use services on different platforms i think is certainly interesting we're hearing the demand for it and i you know as a very product focused engineer i empathize with it right because when um because when you want to build great stuff you don't want to be limited to a specific platform. And furthermore, if these cloud platforms keep kind of hitting the market with more and more managed services that are higher levels of abstraction that solve every single type of business problem you have, I'd say you especially don't want to be limited, right? You want to be able to use all those things to build the best possible outcome and in fact i would say a lot of the serverless applications that are using our framework today i'd probably say the vast majority of them aren't exclusively aws

now that does not mean that they're aws and google and azure but it does mean that they're highly likely that they're aws and some auth zero aws and maybe some Twilio, AWS and some Stripe. Oh, absolutely. I take a look at everything I've built. There's almost always going to be some other third-party API, Pinboard or Pocket for a couple of things that I've built. There's also integration on the other side with SendGrid because SES is still not quite what I'd want it to be. You go down this entire list, there's always going to be something else.

When we talk about multi-cloud, you see things such as integrating things like pager duty. There's no under-the-hood service at AWS that's going to offer something like that today. At some point, being multi-cloud does not mean that it becomes a suicide pact. It just usually takes the form, at least in the experiences that I've had, of being focused on this is the central core of what we do. And then we loop in other things in an ancillary basis where appropriate. Absolutely. And that is where we see the most of the demand on the framework. On our end, it's like, how do you give us this great vendor agnostic abstraction

so that we could use all these things, you know, again, without having to become platform experts, because those platforms are huge, right? And they want to be able to use all these things. Again, you want to build the best possible products, you should be free to use the best possible services. And where we're going this, you know, this serverless, serviceful era, it seems like it would be a wise decision to leverage something that gives you access to all that. But on our end, it's a ton of work, right? Because to build that vendor agnostic abstraction to deliver that experience, it's not easy. But we've got some pretty cool plans around that in a potential serverless framework version two, which we've been working on for at least a year. One thing I do want to cover, though, is I guess I've started to feel a little uncomfortable

recently with the level of hype around serverless as the architecture of the future. Now, I'm very much a proponent of using it. I think that it makes an awful lot of sense for an awful lot of use cases. The concern I have is where you start to see this with any technology at the appropriate part of Gartner's hype curve, where we're now seeing people half listening to part

of a problem description and then chiming in with, oh, serverless is the answer. Serverless is the answer. And I find that to be worrying. Do you see any of that? Oh, of course. Well, look, here's kind of how I think of it. We certainly see it. It's par for the course with any major exciting technology trend, right? There's always kind of these devout believers. And we see people cramming use cases into Lambda, tons of use cases that aren't appropriate for Lambda all the time, right? And it is incredible the amount of kind of hacks and workarounds that they're implementing just to be able to use Lambda, right? I'll never get over just the,

it's just, it's so astonishing to see all the creativity that's going into this. But, and while on one hand, it's like, OK, this is this is kind of crazy. You shouldn't be having to warm up, you know, all these functions all the time. Right. On the other hand, I look at it and I get it. Right. I mean, going back to the why, you know, why is this such a big deal? It's the promise to deliver software with radically low overhead. And everybody wants that. It doesn't matter if you're a large enterprise or an SMB, it's it's the promise to deliver software with you know radically low overhead and everybody wants that doesn't matter if you're a large enterprise you're an smb you're a startup or you're kind of a lone hacker in your mother's basement right everybody wants to be able to

deliver software that has like that requires the least amount of maintenance and the fact that there's all this hype around it i think think is, I get it for that reason. This is because everybody wants that. And on one hand, I want to say, yeah, it's crazy that everybody's implementing all these workarounds and these hacks to warm up their functions and get around database performance issues. On the other hand, I think you could also interpret it as possibly a signal of the pent up demand that is just waiting to take more and more advantage of this stuff, waiting for the services to

become more mature, waiting for them to get more hardened so they can appeal to a wider variety of use cases. And I think that's going to happen. Based on our conversations with AWS and Google and Azure, everybody is working to almost transform a lot of their cloud services to be entirely serverless. And I think today, yes, it looks a little bit crazy, but I understand the motivation.

And I think it's a good signal for how the market will move in the future. I agree with you. But I also wind up seeing people pushing back against various decisions that I've made, for example, whenever they learn what's under the future. I agree with you, but I also wind up seeing people pushing back against various decisions that I've made, for example, whenever they learn what's under the hood. Recently, you may or may not have noticed that suddenly my crappy 1998-style web design now has a giant platypus on the top of it and has, I guess, a more cohesive visual aesthetic, for lack of a better term.

As a part of that, I for lack of a better term. As a part of that, I migrated off of a static site hosted in S3 with a few Lambda at Edge functions and a bunch of other nonsense over to WordPress. Just bog-standard WordPress hosted by someone else because I'm still a responsible grown-up and running WordPress is something I'll never do again myself. On the one hand, it feels like a bit of a regression and people get very upset when they

hear that I've done that because I'm moving backwards, I'm not paying attention, etc, etc. But the reasons that I had to do that are very in line with the underlying theory of serverless. When I'm paying someone else to run the entire thing for me, I don't care that it's WordPress. I have people working on that. I know that when I need to bring in a developer to build a thing, I can find WordPress developers for far less effort, time, and better availability

than I can finding someone who's up to speed on the latest serverless technologies. And for what I do and the business needs that I have, it's very much the right answer. And that's one example of a workload that was not appropriate for serverless, given the constraints that I tended to have. Where do you stand on that type of thing? I think you should focus on the business problem first and foremost, right?

I'm a big fan. It's not about technology. It's about vision. It's about the outcome. It's about vision. It's about the outcome. It's about the problem you want to solve, right? The reason I got into the serverless stuff and why I was so obsessed with Lambda and working nights and weekends on this framework in the very early days is because I think technology should enable vision and then get out of its way. Absolutely, right? So it also depends how you define serverless. I mean,

is kind of WordPress as a service. Is that serverless? Absolutely. Right. There's, you know, serverless is a kind of a notoriously vague definition. And I think it'll get, you know, perhaps more vague here. But I'd say a WordPress as a service solution is almost as serverless as it gets. Right. right but in general you know absolutely solve your business problem first and foremost and then second of course like you know lambda the service architecture it's it's not the best fit for everything and it may not be the best fit for everything it's naive to think that a single technology will be able to accommodate all possible use

cases right there are a lot of people who really value and need, you know, due to regulatory requirements or just policies, they need to have full control over everything. And I completely understand that and empathize with that. So, you know, I absolutely focus on the business problem. And, you know, I still think of a kind of a hosted WordPress offering or that outcome as a service is perhaps even more serverless than Lambda is at the end of the day. I think you're very right as far as looking at this from a larger context of solving business problems rather than focusing on the hype cycle.

Sorry, rather than focusing on the true religion that is serverless. That tends to be one of those areas that is fraught with peril. And continuing to barrel down that, in some cases, it's not going to be viable. I mean, what I do for a living is I fix horrifying AWS bills. But there's never going to be a story where I look at what someone has built and the response becomes, well, you can save 80% of the bill, which they could, by rewriting it all using serverless services, which they could, and it will only take you 18 months of doing nothing else to get there. Also true, also something virtually no company in the world is going to do with an asterisk next to it. Because that's not easy. That's not straightforward. That's not something that is going to add

significant differentiating business value for an awful lot of companies out there, given what other constraints they have to work with them. Yes, we see that a lot. The majority of serverless architectures being built today are greenfield. There aren't a lot of migrations because it's a lot to handle at once, at least currently, to migrate to a serverless architecture.

You're not just dealing with this whole new architectural pattern, but also in there are other things like microservice design, just adopting it. You have to have a lot of knowledge about the cloud. And so it's a lot to take on currently. In the future, I think that there will be a better migration story, something that looks like you should just be able to port over your previous outcome onto serverless infrastructure without even really having to know about it.

But until then, until that stuff comes out, I think it's certainly, trying to figure out how to migrate these things over to a serverless architecture can be fairly time-consuming because it's a lot to take in at once. It very much is.

One thing that I wanted to bring up with you, normally at this part of the show, I would be asking, is there anything you want to promote? But you are effectively the CEO of a startup, which means you always have something to promote, and it's always generally the same thing. So rather than asking you, I want to turn this into a question on my end. Namely, you've raised two funding rounds publicly that have gone reasonably well. You've raised a fair bit of money. You certainly have a whole lot of buzz going around this,

but my relationship with your company comes down to the open source community serverless framework, and that's awesome. You've been talking a bit lately about the serverless framework enterprise or the serverless enterprise framework. There are three words in there. I'm not sure quite the order they go in. First, what is the order? And secondly, what does it do? Yeah, great question. Yes, serverless framework open source came out 2015. And I think it was July 2015.

And serverless framework enterprise just came out about a month ago. And here's why we came out with serverless framework enterprise. Putting aside, yes, you know, we're a business. We need to commercialize. We've been focused largely on community growth for the first few years. But at the same time, when we walk into kind of like an organization and they're serious about adopting serverless, which is where I'd say a lot of the

market is at right now. I think the past few years have been around doing some POCs, kind of playing around with it. Usually a developer will kind of bring serverless framework, AWS Lambda in their organization. They'll start doing a few kind of minor use cases, automating some part of their DevOps pipeline or something by putting some low risk task in a Lambda function. And then they'll start doing a couple more functions. They'll start to attract attention from maybe the team lead or a director or something. And then they start looking at their first serverless use case. I'd say the market has kind of done all that now

and they get the value prop of serverless. Again, deliver software with radically less overhead. And they want to do two things. They want to bring on more serverless developers. They want to kind of build out the number of developers on their teams doing serverless development. And they want to focus on more mission-critical use cases with the serverless architecture. So that's kind of where we're seeing the market is at right now. And when we kind of walk into organizations, and I talk to at least two organizations every single day that are doing this,

they all say the same thing. They say, look, serverless framework open source is this fantastic kind of development deployment kind of testing tool for serverless architectures. And it really helped our developers get our first few serverless use cases up in the cloud. But now we want more developers doing this. And now we want to focus on more missionless use cases up in the cloud. But now we want more developers doing this. And now we want to focus on more mission critical use cases. Can you help our entire team get into production as easily as you helped kind of those initial couple developers build out those first serverless use cases

with Serverless Framework Open Source. And they said, in order to do that, here's what we need. We need a monitoring, we need a better monitoring solution. We want a better testing solution. We want to make sure that our developers are following organizational policies. We want to make sure that there's oversight for all this and that this jives well with the ops team." They said, could you give us all this stuff out of the box with the serverless framework? We thought about that for a long time. We've kind of experimented with a few different products over the years.

And this one certainly kind of makes the most sense, I think, because the serverless architecture, yes, incredible value, but it's a different architecture, right? It is kind of a whole new thing, and it introduces changes across the entire application lifecycle. This is not specifically a deployment problem. It's not specifically a testing problem. It's not specifically a monitoring problem or a security problem.

It's all these things at once because you're talking about building out this microservice architecture based on all these functions as a service. Every single one of those has infrastructure dependencies. A function needs something to trigger it to run. A function needs some infrastructure to complete its business logic, like a database, for example. How do you monitor all these things? How do you test them all? How do you collaborate across them?

How do you share access to all them? How do you monitor the security landscape? Every single one of these things has its own permission model, and you want to make sure that none of those are overly permissioned. So again, we looked at all this stuff, and after trying a few things behind the scenes, Serverless Framework Enterprise, a single solution that could really handle every single phase in the application lifecycle in one nice integrated solution made a lot of sense, especially for developer teams that want to take this more seriously. A lot of them are usually

trying to build a lot of this by themselves on AWS, like a better serverless platform for their own team, or they're trying to kind of cobble together their own solution to this, you know, via like five other vendors, you know, one for security, one for monitoring, all that stuff. So our mission is like, hey, we just want to give you all this stuff out of the box, you know, right after you run serverless deploy. And we think, especially with the serverless architecture,

that this is a bigger opportunity than ever, right? Because the whole premise of serverless was like, yeah, we need to lower overhead and reduce maintenance as much as possible in the software we deliver. And you shouldn't actually need, if we're successful at this, I'd argue you don't need to have

a separate monitoring product for this or a separate security product. In fact, I think that if we do end up needing all these things for serverless, I'd say that something has gone horribly wrong. And I'm the first one, I do drive our team nuts with this because we are doing serverless monitoring features and stuff right now within Serverless Framework Enterprise. Every single time you do serverless deploy, you get monitoring, you get metrics, you get

alerting, all automatically configured for you out of the box with zero config. And we're talking about what does that monitoring experience look like? What do the metrics look like? What do the alerts look like? And we're so tempted to go build this dashboard just filled with chart junk, just a whole bunch of flashing lights and lines zigzagging left to right. And I'm on the team, I'm kind of pushing them. I'm saying, you know what? Like I personally got into serverless to get away from dashboards like this, to get away from all this stuff. Like how can we simplify?

We have a metric, we have to expose it to everyone. Yes, exactly. So I'm really prompting the team hard. I'm like, how do we simplify this? Like, how do we, you know, we'll go through some creative prompt exercises. Like, what does serverless monitoring look like without any charts? Like, what if you just had to take all that stuff away? Like, what would that look like?

And I think, you know, the answer that's in there and in those questions, I think, is more true to the spirit of serverless than having to go through this exercise of bringing in all these other tools and making your own kind of, you know, cobbling together your own solution for this. I just think, again, if we have to do that, something has gone horribly wrong in the serverless trend. So we're on a mission, again, to simplify all that stuff and provide a single integrated solution for developer teams out of the box that's serverless framework open source paired with serverless framework enterprise.

And in about one to two weeks here, serverless framework enterprise will just be included in serverless framework open source. So every single time within a freemium tier. So every single time a developer, you know, deploys for the, you know, for the first time their serverless architecture, they'll have the metrics, the alerting, they'll have testing capabilities, all that stuff just out of the box in a dashboard

right after you run serverless deploy. That is absolutely going to be a significant value. It almost feels on some level like it's a bit of a misnomer. When you put the word enterprise on something, I hear expensive, which, great, awesome. We all need to make money, and I don't think any of the VCs behind your open source project are doing it as a charity. But by the same token, that's something that's incredibly valuable for folks all across the spectrum, from small businesses like mine to giant enterprises like companies that actually make money.

At Dependence scale, it looks like a phone number and everything in between. Yeah, absolutely. I'm pushing us hard to change the enterprise naming. like companies that actually make money. At Dependence scale, it looks like a phone number and everything in between. Yeah, absolutely. I'm pushing us hard to change the enterprise naming. I think that there's a place for that, but right now we're very much focused on developer teams. So we might adjust that name in the near future here. But yeah, this stuff will all be given to you out of the box. This is kind of our vision for how serverless development

and operations should be. And, you know, we've got like 10% of our product roadmap completed, but right now there's a ton of interest. I mean, everybody, like if we, as soon as they see that you get all this stuff out of the box right after your first serverless deploy, it's a pretty magical thing. Absolutely. Austin, thank you so much for taking the time to speak with me. If people want to hear more about what you're up to, where can they find you? Serverless.com. That's everything that's going on with our company. There's just a ton of material in general on serverless architectures, on the trend,

a lot of great learning resources, of course. Tons of examples. We've got a brand new example explorer. I'm a big fan of starting with examples rather than going directly into docs. And then I'm on Twitter, at Austin Collins. Austin is spelled A-U-S-T-E-N, so it's a bit different than usual. But yeah, those are the two places to watch. And we've got a ton of announcements coming out this year.

I mean, we're both trying to cater to the serverless architecture challenges today, right? That is, again, brand new architecture. It introduces differences in every single phase of the application lifecycle. And we're determined to solve all those with serverless framework open source and serverless framework enterprise.

And then we have a handful of kind of more progressive ideas that we're playing with, like serverless components. We have event gateway. We have an event specification that we kind of pioneered back in 2017 called Cloud Events, which has since been adopted by the CNCF, and a lot of people are working on that. So yeah, I'd say serverless.com, and my Twitter handle is a great way to stay in touch with all these things.

Perfect. Austin, thank you so much for taking the time to speak with me today. I appreciate it. Likewise, thank you so much for taking the time to speak with me today. I appreciate it. Likewise, Corey. Take care. Austin Collins, CEO and founder of Serverless Incorporated. I'm Corey Quinn. This is Screaming in the Cloud.

This has been this week's episode of Screaming in the Cloud. You can also find more Corey at screaminginthecCloud.com or wherever Fine Snark is sold.