Subscribe
Share
Share
Embed
Serverless deployment is picking up steam in the industry, and Austen Collins has been leading the charge since 2015. In this episode, Collins talks about his work with AWS, building the Serverless Framework, and why it’s solving so many problems.
Screaming in the Cloud with Corey Quinn features conversations with domain experts in the world of Cloud Computing. Topics discussed include AWS, GCP, Azure, Oracle Cloud, and the "why" behind how businesses are coming to think about the Cloud.
Transcript
Speaker 1: 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.
Corey Quinn: 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’ve got 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 Word” 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.
Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined this week by Austen Collins, founder and CEO of the Serverless Framework and also AWS Serverless Hero. Welcome to the show, Austen.
Austen: Hi, Corey. Thanks for having me.
Corey: Thank you for joining us. One of the things I've always found fascinating about serverless was the learning curve on 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 Lambda... 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.
Austen: Yeah. Thanks for the positive feedback. Your story is the same story I had early 2015 right after I re-invent... right after they announced Database Lambda. I stumbled through it myself. in those days, it was still pretty raw. I mean, it just was very limited when it comes to features, and use cases, and documentation, of course. All that kind of inspired me to build the Serverless 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.
Corey: 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 a 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.
Austen: Yeah. It's certainty 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 to... 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 raise awareness about Lambda just within my personal network 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 kind of back then because there wasn't a big story around how you could put 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 a serverless... Not technically accurate. It's not 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, they've always wanted in a compute platform. Right?
Yeah. Now, it's a bit early. Now, it's a bit confusing. 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.
Corey: 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 CloudFormation. Although, you do distill down into CloudFormation 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, and 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, and 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 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, but it winds up being three of those dozen lines, and it just works.
Austen: Yeah. It's a powerful abstraction, and I don't... Looking back at the whole trend, and all the movement, and how people are talking about it, I'm not sure... I think Amazon absolutely all credit kind of goes to them, but 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.
Again, back in the early days, there was this great new compute service. They were kind of pitching it. Amazon is pitching it as a venture of encode as glue code, and when we saw that, we're thinking like... You can build all types of applications and use cases on this because the value prop is so compelling, and that is deliver a software and applications with radically less overhead, but there wasn't a clear story as to how you could put 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 could 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 and I... 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 meta-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 kind of remain focused on a workflow rather than the infrastructure?" I think that simple story of functions and events kind of helped 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."
Corey: 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.
Austen: Absolutely. No company sets their Q1 objective as to get a database provisioned, right? They want an outcome, and that's one of the strengths of the framework. I mean, you're really focused on more of the outcome level, which I think is a big reason for its success, and increasingly, as I look at the cloud and the direction the cloud is going, and it seems like more of a outcome-focused direction rather than infrastructure-focused.
Corey: I think that's probably the right answer. I think the tide is rising, and as I've talked about on the 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? 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.
Austen: Totally agree, and I'd 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 architecture is you're basically building applications on top of managed services and kind of gluing them together using this... Yeah, using functions and using events, and most companies are... 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 majority, vast majority of Lambda functions are being used with other managed services, and it seems like people are relying on more and more these managed services rather than building and maintaining their own versions of those increasingly at an unprecedented rate.
Based on kind of how we're using 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 going to 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?"
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 will 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 application shrinks significantly.
Corey: Oh, absolutely, and thanks to Serverless Framework and a few other things, I wound up having a developer recently working on something for me, and what 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 will leave 20 seconds later. Then, it's going to work at this end point, and I gave 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 quickly deploy to a particular branch, and that's a test environment. Worst case, I can go in and make some changes in there pretty easily if anything got broken, but over a two months' span, nothing ever did. It just worked.
Austen: Yeah. That's the beauty of the serverless architecture. It's not quite there yet, but it is getting closer and closer to... It's sort of a set-it-and-forget-it type of develop and model.
Corey: Absolutely. One thing I do and I asked you about is... Well, there are two directions to take this in. The first is we've talked 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?
Austen: 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 like 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.
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, and they even have some serverless services that are... have some compelling features over what AWS offers, but for the most part, absolutely, we see the whole industry largest 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, 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?" 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 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 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 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 land as they... to Fargate as well or a lot of interest in just like, "How do we just deploy a function to Google Cloud and Azure without having to change our mindset and become cloud platform experts?"
Then, also, we see a ton of interest in what I call vendor choice largely, and I think this is... 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. I think in the serverless and in the 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 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 like some of the mature serverless infrastructure services around, but we're really looking at Google's machine learning stuff, and now 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 of 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 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, again, without becoming that expert, so I think that is probably the thing to watch in the serverless era. 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... Most functions are being designed with proprietary code or they're being written around proprietary APIs, and so... but 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... As a very product-focused engineer, I empathize with it, right, 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 manual services that are higher levels of abstraction that solve every single type of business problem you have, I 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.
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 OS-Zero, AWS and maybe some Twilio, AWS and some Stripe.
Corey: 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 is also integration on the other side with SendGrid because SES is still not quite what I'd want it to be, and you go down this entire list. There's always going to be something else.
When we talk about multi-cloud, there are... You see things such as integrating things like PagerDuty. I mean, there's no under-the-hood service that AWS would offer something like that today, and so 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."
Austen: 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, again, without having to become platform experts because those platforms are huge?" Right? They want to be able to use all these things. Okay?
You want to build the best possible products? You should be free to use the best possible services, and where we're going, 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.
Corey: 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 appropriate part of Gartner's hype curve where we are 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?
Austen: Of course. 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 in the Lambda. Tons of use cases that aren't appropriate for Lambda all the time. Right? 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... Yeah. It's so astonishing to see all the creativity that's going into this, but on one hand, it's like, "Okay. This is kind of crazy. You shouldn't be having to warm up 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, 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, 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... requires the least amount of maintenance, and the fact that there's all this hype around it I think is... I get it for that reason because everybody wants that. On one hand, I want to say, "Yeah, it's crazy that there... that everybody is 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 to this stuff, waiting for the services to become more mature, waiting for them to get more hardened so that 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.
Corey: 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.
Austen: Mm-hmm (affirmative).
Corey: As a part of that, I migrated off of static site hosted in S3 with the land view Lambda@Edge functions and a bunch of other nonsense over to WordPress. Just standard WordPress hosted by someone else because I am still a responsible grownup 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, et cetera, et cetera, 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. 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?
Austen: I think you should focus on the business problem first and foremost. Right? I'm a big fan. I think techno- It's not about technology. 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?
It also depends on how you define serverless. I mean, is kind of WordPress as a service, is that serverless? Absolutely. Right? Serverless is kind of a notoriously vague definition, and I think it will get perhaps more vague here, but I'd say WordPress is a service solution. It's almost as serverless as it gets. Right? In general, absolutely. Solve your business problem first and foremost, and then second, of course, like Lambda... The serverless architecture. It's not the best fit for everything, and it may not be the best fit for everything.
It's naïve 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 to do the regulatory requirements for just policies. They need to have full control over everything. I completely understand that and empathize with that. I absolutely focus on the business problem, and I still think of a hosted WordPress offering or that outcome as a service is perhaps even more serverless than Lambda at the end of the day.
Corey: Yeah. 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... 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.
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% bill, which I 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.
Austen: 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 or at least currently to migrate to a serverless architecture. You're not just kind of dealing with this whole new architectural pattern, but also, there are other things like microservice design, just adopting... 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 pour it over your previous outcome on a serverless infrastructure without even really having to know about it. Right? 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. It can be fairly time-consuming because there's a lot to take in at once.
Corey: 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 have... 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 and 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? Secondly, what does it do?
Austen: Yeah, great question. Yes. Serverless Framework Open-Source came out 2015. I think it was July 2015, and Serverless Framework Enterprise just came out about a month ago, and here is why we came out with Serverless Framework Enterprise. Putting aside, yes, we're a business, we've been commercialized. 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 database Lambda in their organization. They will start doing a few kind of minor use cases, automating some part of their devops pipeline or something by putting some raw... 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 director, or something, and then they start looking at their first serverless use case.
I'd say like 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.
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 fantastic kind of development, deployment, kind of testing tool for serverless architectures. 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 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?"
They said, "In order to do that, here's what we need. We need 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." Right? They say, "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 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 security problem. Right?
It's all these things at once because you're talking about building out this microservice architecture-based and 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? Right? Every single one of these things has its own permission model and you want to make sure that none of those are overly-permissioned. Right?
Again, we look at all this stuff, and after kind of 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 integrative 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 at their... a better serverless platform for their own team or they're trying to kind of cobble together their own solution to this via like five other vendors. One for security. One for monitoring. All that stuff.
Our mission is like, "Hey, we just want to give you all this stuff out of the box right after you run a serverless deploy," and we think, especially with the serverless architecture, that this... 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 should 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 a 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 like, "What does that monitoring experience look like? What do the metrics look like? What do the alerts look like?"
We're so tempted to go kind of build this dashboard just filled with chart junk. Right? Just a whole punch of like flashing lights and lines zigzagging left to right, and I am... On the team, I'm kind of pushing them and say, "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..."
Corey: "We have a metric. We have to expose it to everyone."
Austen: Yes, exactly. I'm really prompting the team hard. I'm like, "How do we simplify this? How do we..." 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?" I think 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 like bringing all these other tools and like making your own kind of... 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 integrative 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. Every single time a developer deploys 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.
Corey: 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 say... 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. As we spend to scale, it looks like a phone number and everything in between.
Austen: Yeah. Absolutely. I'm pushing as 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, and 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 operation should be, and we'll... 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.
Corey: Absolutely. Austen, 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?
Austen: Serverless.com. That's everything that's going on with our company, and there's just a ton of material in general on serverless architecture, on the trend. A lot of great learning resources, of course. Tons of examples. We've got a brand new example to explore. I'm a big fan of starting with examples rather than going directly at the docs, and then I'm on Twitter, @austencollins. Austen 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. Yeah. I'd say serverless.com and my Twitter handle is a great way to stay in touch with all these things.
Corey: Perfect. Austen, thank you so much for taking the time to speak with me today. I appreciate it.
Austen: Likewise, Corey. Take care.
Corey: Austen Collins, CEO and founder of Serverless Incorporated. I'm Corey Quinn. This is Screaming in the Cloud.
Speaker 1: This has been this week's episode of Screaming in the Cloud. You can also find more Corey at screaminginthecloud.com or wherever fine snark is sold.
Speaker 4: This has been a HumblePod Production. Stay humble.