 All right, good morning. It's a pretty good turnout. Thank you so much for coming. My eyes are a little red and blurry this morning, not because I've been up all night drinking fine wine and Sonoma, but because I woke up with a slight eye irritation. So I got to have my slides here, my notes here so I could see them. And if at any point I'm no longer facing the audience during my talk, if you could be so kind as just to give me like a polite shout out and let me know where you're at, just kidding. This is not that bad. Anyway, I'm Austin Collins. I guess I'm an instigator of this serverless movement. In 2015, I created a very popular open source project called the serverless framework. And this is an application framework that allows you to build apps exclusively on serverless infrastructure like AWS Lambda. And I think that this framework in particular had a lot to do in showing the world kind of how powerful this technology and this trend can be. I'm also the founder and CEO of a startup called Serverless Inc. We're based in San Francisco. We make tools and services to help developers and teams build and operate serverless applications regardless of platform. And our company is also helping out with the standardization efforts happening within the CNCF around serverless concepts, which I'll dig into later in this talk. Anyway, this is serverless state of the union, special open source edition, special exclusive. In this talk, we're going to analyze what's happening in the serverless world. We're going to try and forecast what's going to happen next. And we're going to discuss leveraging open source to smartly adopt serverless today. So let's get started. Boom. Amidst containers, orchestrators, VMs, paths, out of left field, out of nowhere basically came this serverless trend. I don't think anyone was really expecting it. And it picked up momentum rapidly. It has won hearts and minds of developers, and it's not slowing down. We clearly have a trend here on our hands. And now, what's the big deal? Why is this trend catching on? Why is this important? So first off, to clarify, if you aren't already aware, serverless means that those servers exist. Developers don't have to think about them. It's not a very technically accurate term. It's about as technically accurate as the term the cloud, I'd say. But once you say that word to a developer and you see that enthusiasm, that it invokes, that emotional response, there's no reason why it's easy to recognize why this buzzword caught on, why it is the buzzword. Because it invokes all the right emotions. And it's all about using tools, using infrastructure that get out of your way so that you could focus on solving business problems. And this simple idea has been around for a long time and obviously has mass appeal. And this simple idea, a reason why this has become such a big trend is that, because first off, this does a great job of solving ancient problems. In our serverless framework, we have significant enterprise adoption. And when these users come to us, we always ask them, why are you here? What's so interesting about this to you? And they always tell us the same that they're looking to solve the same problems. That is, number one, they want to move fast. They want to reduce time to market. Number two, they want to increase innovation. They're saying, heck, our competitors are moving very fast. Our competitors are doing all these cool things. We want to do the same. And they also want to reduce operational overhead, of course, and reduce cost. And despite how far we've come with so much great change in innovation and IT, we still have not solved these ancient problems yet. And the serverless movement is kind of a testament to that. And it's why serverless has picked up so much momentum. At the same time, serverless solves new problems, problems that are just starting to come into fruition. And I don't know how to characterize these more concisely than to say the digital world is storming into reality right now. We've got internet of things, devices everywhere with sensors, collecting all types of data, generating big data. We've got machine learning, artificial intelligence infused into all this, building systems of intelligence, systems that can make decisions in real time, creating autonomous machines, self-driving cars. We've got computing running in the edge all over the place. Voice devices, technology is everywhere. And if you're a business, you have to pay attention to all this, because your competitors are. And amidst these ancient problems and all these new problems, one, of course, has to ask themself a very important question. And that is, do you really want to be running your own infrastructure? Is that kind of a good position for you right now? Is that going to be on the right side of history, that choice? And I think you could see where the people in the serverless movement stand. But they're very nervous about burdening themselves with this, especially in this era of upcoming hyper-innovation and hyper-competition. So serverless, a brief history. I'm not going to go into paths. I'm just going to start with the serverless trend starting back in 2014. This kind of got kicked off with Amazon Web Services when they came out with a new way to do compute in the cloud called AWS Lambda. And in the early days, they were kind of marketing this as glue code, as event-driven code. And it was very limited. The use cases were very limited. But at the core, there was a revolutionary way to do compute. And it was revolutionary because all you had to do as a developer was upload some code. And you'd write this code in the form of a function, enough code to perform one task, like save a user to a database or send out a transactional email. You'd upload that code to AWS Lambda's platform and that would create an AWS Lambda function, this independent unit of deployment. And this function would require very little to zero administration. The provider handles everything. And it scales automatically to meet massive levels of concurrency. And also, AWS Lambda had this pay-per-execution-pay-per-use pricing model that was incredibly efficient. And this cannot be understated. When people come, join the serverless movement, it's this pricing model that really brings them through the door. And then they kind of stay for, once they look at all these qualities together, they realize that there is a lowest total cost of ownership scenario here that is absolutely compelling. But this pricing model is super important. You're not going to get charged unless your code runs. And when you do get charged, you get charged at 100 millisecond increments. Very exciting. And lastly, this code is event-driven. These functions will spin up to handle any type of events. A lot of events mostly coming from the underlying platform. So when something happens in your AWS S3 bucket, it'll automatically trigger a function. Or when a record gets saved to a DynamoDB table, it'll trigger a function. Or an HTTP web request. In the serverless world, even these HTTP requests are being considered as events. So back in 2015, AWS Lambda, the use cases were very limited. I don't think it had great packaging. I don't think it had a great developer experience. And it certainly was not being considered as an application platform. And this is where kind of our company stepped in. We came out to try and define the application experience around AWS Lambda, because at the core, we saw that revolutionary compute service. And we basically wanted to use it for everything. And we needed some tooling to enable that. So we started working on this serverless framework mid-2015. And it solves a lot of problems that need to be solved if you want to build serverless architectures. Most importantly, when you build a serverless architecture, it's pretty complicated. First off, you have all these independent units of deployment, all these functions. And there are a lot of these. This is very much like a traditional kind of microservice architecture. However, the difference in the serverless world is that the overhead burden is not there with these serverless functions, because the provider is managing scale, managing all aspects of administration. And what happens, and what we see regularly, is that people who are doing serverless development could be one or two engineers. And they're provisioning hundreds of these functions. It's pretty awesome. It's all because that overhead burden is not there. So you have a whole bunch of functions, whole bunch of independent units of deployment. And all these functions have infrastructure dependencies. They need infrastructure to trigger the functions via events. And they also need infrastructure to perform their business logic, whether it's a database, caching mechanism, or storage. Anyway, so we looked at all this in the early days. We said, there's an application story here that's pretty compelling. And how could we express this in a simpler format so that people don't have to think about things in this very complicated way? So the one thing that I think the serverless framework did very well is they said, look, serverless is simply a story of functions and events. And that's what we presented to developers. We gave them a simple configuration file. You could list all your functions containing your business logic, and every single function in that configuration file could have an events property. And you could list there all the events that would trigger that function, all the events that happen in your digital business. And this whole experience was very, very compelling to users. All they'd have to do is type serverless deploy. And the serverless framework will go provision all the infrastructure necessary and wire it up so that it works together in this event-driven model. And the user and the developers wouldn't have to think about that as much. So again, I think this open source project had a lot to do and kind of show in the world the serverless architecture, introducing the serverless application to the world. And up next in 2016, given the massive success of AWS Lambda, a lot of the other public cloud providers took note and they started to offer very similar services. Google came out with Google Cloud Functions, Azure came out with Azure Functions, IBM came out with IBM Cloud Functions. And overall, these serverless functions, also known as functions as a service, they're a great way to use these cloud platforms. They're a great way to adopt cloud platforms. If you want to use a cloud platform and gain access to all the cool services that that cloud platform offers, stick a function there. It's auto-scaling, it's paper execution. It's a very, very trivial way to start leveraging that cloud platform. And this is exciting because I think that this is gonna enable more vendor choice and multi-provider capability in the future. In 2016, we also saw more open-source heroes enter the scene and they started coming out with open-source versions of serverless compute platforms, essentially. And these projects seek to give organizations the ability to make their own serverless computing platforms largely based on containers in Kubernetes. We've got great projects in this space like Cubeless, Oracle's FN project. There's OpenFaz and IBM's OpenWhisk and a lot more of these things are popping up a lot right now, there'll probably be two more by tomorrow. Now, in this scenario, you're still managing your own infrastructure, right? You kind of bring one of these into your organization. You have a few people operating this serverless platform and it's their job to expose it to developers so developers can focus on solving business problems with the least amount of friction. So is it serverless? I don't know. But what it does borrow heavily from the cloud experience is that application experience is emulated in these platforms. That's simple story of functions and events. These things can be perceived as past 2.0 and one of the biggest changes is simply this model of doing things. It's a simple story of functions and events. Now you could kind of self-host this anywhere you want and that's pretty exciting. In 2017, we started to see the serverless term continue to grow and all of a sudden a lot of cloud infrastructure beyond computing was being called serverless. Amazon kind of took the lead on this. They started referring to kind of their traditional SaaS products as serverless. So AWS S3, which has been around for a very long time, they started to call that serverless SNS. They're starting to call that serverless. A lot of their new services, like their Aurora database, is now being referred to as serverless. And a lot of these independent SaaS providers are kind of using the term serverless to refer to their products. Like Algolia, I've seen them do this, Auth0. And that's pretty interesting. I think it has some implications for the serverless application in general. And the serverless application now is kind of being perceived as using serverless compute and pairing it with infrastructure that has these serverless qualities, auto-scaling, you know, paper use. And combining these things together to make end results or applications that have extremely low total cost of ownership. They're paper execution, they're auto-scaling, they're almost like set it and forget it. And these applications are very efficient and very powerful. So that's what has happened. Here's kind of what's happening now and some things to pay attention to. There's clearly a collision happening between serverless computing functions as a service and containers. I think it's getting a bit awkward, actually. Traditionally, containers offered great isolation, you know, packaging portability, but not low latency provisioning or an efficient pricing model for running them in the cloud. Meanwhile, AWS Lambda offered low latency provisioning, runtime is ready to go, sub-second billing, and this simple kind of functional model. In the serverless world, people have been using both these things for different use cases. Containers have been great for asynchronous, long-running tasks, and functions are great for short tasks where you don't have to think, where you don't wanna have to kind of think about containers, only the business logic and if you wanna benefit from that efficient pricing model. But now containers as a service are looking more like serverless container platforms. Azure Container Service has a per-second billing model, you know, no virtual machine management. AWS has Fargate, you know, it's a managed container platform also with the per-second billing model. Both of these are gonna continue to probably collide and exist and evolve. And this is still the beginning of this story, but it's certainly something to watch. Furthermore, software as a service continues to expand. And this is important because SAS's value on top of serverless computing cannot be understated. In the early days of the serverless framework, we noticed amazing innovation and creativity coming from the users. And first off, it's because, you know, when you reduce operational overhead, you liberate a lot of productivity and you also liberate creativity. But a lot of this also came from simply pairing kind of serverless compute from pairing AWS Lambda with other kind of SAS, other serverless infrastructure. And we kind of realized that, you know, Lambda's only half the value. You've got to have other great serverless like infrastructure to pair it with to build these end results, these applications. It's a very exciting time because, you know, a lot more SAS is coming. The cloud providers are aggressively innovating new products with SAS models and so are startups. So, you know, Amazon, of course, has S3, DynamoDB, Lambda, they have the new Aurora, they've got Comprehend, their natural language processing service, they've got Transcribe for speech recognition. Meanwhile, Google has a ton of cool cloud AI products like cloud speech, translation, their vision API, video intelligence APIs. That whole cloud AI category I think is just going to explode, will continue to explode. And, you know, overall, this is exciting. This is like the golden age of software development. I mean, never has there been this like greater time to be able to use all these kind of, these pieces of infrastructure to make things faster, to make things at scale, to get your vision out there and make some type of meaning in the world. So, overall, this is, you know, a lot of stuff is going on, but it's all pretty exciting. Another big trend to look out for is serverless functions are kind of running everywhere now. They can clearly run in multiple cloud providers. Now that every cloud provider has a serverless experience, they're running on premise thanks to these open source serverless platforms. And they could also run in the edge. Cloudflare's got a great Cloudflare worker project. Lambda has Lambda at edge. And we're quickly entering this world where these functions can live all over the place. And that's great because events data is all over the place. So with all this stuff going on, there's a lot of change, a lot of innovation, a ton of options now and projects, how do we adopt this today? And here's kind of the most important lessons that we've learned over at Serverless Inc. First off, we talk to these enterprise organizations regularly and they're in a tough bind. A lot of them are kind of caught in this adoption challenge. They want to avoid lock-in, they also want total control and oversight. But at the same time, they want to move fast, they want to innovate. And many are choosing to kind of DIY their own serverless platforms. So we've seen several companies working on their own serverless platforms for a number of years now to avoid vendor lock-in and give them the control and oversight they need. On the other hand, we've seen the cloud providers unrelentingly add innovative services, serverless offerings to their whole platform. And we've seen a lot of companies embracing those and being very successful at delivering innovation at record pace. So how does one, how does an organization kind of navigate this? And this is where open source especially can save the day. So what we've learned of course and a big serverless principle is that first off it's all relative to the use case. Einstein actually said this, the second half just got cut off. But this is something that's very popular in the serverless community and it's just central to the serverless culture. And that is focus on the use case, focus on the outcome first, not infrastructure and platforms. Figure out what is most important to best serve that use case. Do you need to move fast? Do you need to be innovative? You need to capture the market or do you want to kind of avoid lock in and maybe some public clouds in general? And if you do that, if you run your own platform, what is the opportunity cost of doing that? The great thing about serverless is that lower overhead appeals to all types of use cases. It's often used for kind of critical data processing pipelines, backend services, but also equally used for marketing projects, internal tools, random event driven automation, business process automation. Do you really need to roll out your own platform to do kind of all this stuff? Maybe not. If the one platform approach is gonna block you from being able to solve a problem best, that's not super, that's not good. So you could do a serverless, a lot of different ways now and the best way will be revealed always by focusing on the outcome. So focus on that first. And what I strongly recommend is that before adopting any serverless platform, and again there's so many great options out there, whether it's AWS or one of these cool open source serverless platforms, I would absolutely prioritize investing in tools that offer vendor and platform choice and organize your strategy all around that. There are a handful of great tools that do this, like our serverless framework or Terraforms is another fantastic one, but these things are gonna give you options and that's of critical importance right now. And they're also gonna give you a single experience for using these options. And again, this is where open source especially has to play a big role. Open source communities have to come up with more tools like this because these big platforms have big biases towards their platforms. And if that future is running serverless functions everywhere, we need the tool link to help make that easy. So again, first focus on your outcome and then adopt the tools that will flexibly allow you to deliver on those outcomes best. The future is uncertain, change is constant, tools that give you options, a diversified approach should absolutely be prioritized. And further, serverless is all about moving up the stack to the application level. And we think serverless is gonna evolve these developer tools and infrastructure in general and infrastructure provisioning tools to focus more on the application level. And this is something that, this is a theme that we think about a lot at serverless Inc. We're always trying to figure out how to express this team. We think software tooling should be designed more around outcomes and apps and not infrastructure. And this is also what serverless is strongly about. We kind of started this with the serverless framework and we also have a new project which we're opening up in a beta in a few weeks. It's called serverless components. It's simply open source, reusable, vendor agnostic serverless building blocks. It's a packaging system for application features or entire applications, built using serverless infrastructure across all vendors. You can compose these building blocks together to rapidly build apps. And these components are very outcome focused, whether it's your data processing pipeline, the user's credit API, an SMS subscription service, subscription payment service, or an entire serverless forum or an entire serverless e-commerce application. You should be able to compose this stuff together to build end results with that serverless efficiency. We're opening this up as a standalone public beta. We're gonna incorporate it into our framework. If it's interesting to you, you could go to serverless.com and sign up for the newsletter. But again, focus on your outcomes and then adopt the flexible tools that will allow you to best deliver on those outcomes. And after that, lean on community driven standards. These standards, the harmonization conversations are just getting started in the serverless space. And it's exciting because it could solve a lot of problems. For example, making functions more portable so that they can move around to wherever they need to go or event data more consistent. The CNCF is kind of where these conversations are taking place. There's a serverless working group within the CNCF and we're meeting every Thursday, 9 a.m. Pacific time to talk about this stuff. The serverless working group recently authored a great white paper talking about serverless in general. And now they're focused on harmonizing these serverless concepts to give users vendor choice and flexibility. First effort of the serverless working group or the next effort is, we found that an uncontroversial starting point when it comes to harmonization was around events. And we're working on this concept called cloud events. It's a specification for describing event data in a common way. Again, serverless is a story of function and events. This is half that story. And event data is being transported across environments increasingly. And unfortunately, all the platforms that are publishing events, they're kind of ubiquitous, events are everywhere, but they're all publishing them in different formats which limits the ability to transform event data wherever you want it to go. So we think this might actually have a huge rising tide effect. It could be bigger than serverless events or kind of bigger than serverless at the end of the day. It might affect all of IT. But we're kicking this off in the service working group because it's part of the service story. It's an essential part. There are a ton of major industry stakeholders involved now and it's super exciting. So if you're curious about this, strongly recommend you jump in. To wrap up, whether you're adopting serverless or you're looking for a role open source has to play in the serverless space. First off, focus on outcomes, not infrastructure. That is an important serverless principle. Adopt tools to flexibly support those outcomes, not tools that kind of support a specific platform. And embrace standards when they mature or help us build them right now. If any of this sounds interesting to you, here's my contact info. You can learn more about the service framework at serverless.com. And if cloud events is of interest to you or the serverless working group in general, go to github.com slash cloud events. There's a ton of information as how you could join the effort and start contributing. Anyway, thank you all for your time. And next up we've got Dan Kahn, the executive director of the Cloud Native Computing Foundation who's gonna show you something special that they've been working on. Anyway, thanks again. Hi there. I'm Dan Kahn. I'm the executive director of the Cloud Native Computing Foundation. I wanna really thank Austin for that great talk and talking about serverless, which is really one of the most exciting spaces in open source right now. I also wanna thank him for donating three minutes at the end of his talk so I could just show you a cool project that we've been working on at CNCF. And I also do wanna thank him for his leadership with both the serverless working group but then particularly cloud events. So quick showed hands. How many people have seen some version of this document before? Okay, more than half. So this is the cloud native landscape. Many people have said that it's incredibly useful and valuable. It has also been referred to as the hellscape. And so we've gotten a little criticism for the tyranny of choice for seeming like it's too complicated. And so we went back and looked at how we could make this more useful for real enterprises and vendors and the end users and the developers that make up our cloud native community. And we decided to do two different follow on projects. So the first that we're launching is called the cloud native trail map. And this is one page, it's actually a portrait but it takes you through the steps of how you might approach cloud native. And so containerization and this real focus on continuous integration, continuous delivery which is arguably the area that's gonna have the very highest value, the biggest return, then talks about orchestration. And then as we go forward, you look at some of the other projects. So service meshes are incredibly hot right now and you have Envoy and Linkerd and Core DNS but that's not where you wanna get started in this space. And we'll actually have handouts for you of this at the next break and it's also available online. So that was the sort of the zoom out version of how can you just approach cloud native and begin thinking about it and begin learning about it. But then for the practitioners and the folks that are really eyebrow deep in it, we also wanted to have the zoom in version. And so that is the new interactive landscape that we're launching here at the conference. And you can actually pull out your phone or your laptop and try typing this in right now. It's l.cncf.io or landscape.cncf.io. And it will show you the 460 different projects and products that we're monitoring and following in this space. And so I will go ahead and I'm no Kelsey Hightower but just try and do a quick demo for you. So you can see that we show Kubernetes which Han Goldberg announced that we graduated yesterday, our incubating CNCF projects, our sandbox projects, and then a lot of other logos. This has been a project for the last couple of months and Jim and I and a few other Linux foundation folks were traveling through China three weeks ago, Beijing and Hangzhou, Shanghai, Shenzhen, Hong Kong in five days and I got the feedback of why do you keep staring at all these logos? But as I was dealing with data caps, this was the project that we've been working on. But the part that's particularly needed about it is the ability to actually zoom in and kind of think about it in different ways. So for example, here's open source projects by First Commit. And so we're pulling this data from GitHub and if I click in I can see that Postgres was actually started 22 years ago but their latest commit was today which is just such an extraordinary accomplishment of an open source project. MariaDB being a fork of MySQL are both 18 years old and I can click through and see a lot of other ones. And for each of these I can then pull up the Twitter info to see what's been going on most recently, the funding info that we're pulling from Crunchbase so you can see they've raised 10 and a half million dollars. And another view if I come here to open source projects by Stars I can see here's Kubernetes at number one with 33,000 Stars. But look at that, Austin's project serverless is here as the fifth entry and we're very happy to have them as a CNCF member and I'll point out their $3 million in funding according to Crunchbase. So any of the venture capitalists in the audience might wanna go up and talk to him. So I do encourage you to take a look and if you pop it up later today it's fun to click those example filters to look at your organization and see the projects that come up and then in any project this size there's gonna be errors in it. So we're really eager to accept pull requests. It's something you can do right from the GitHub web interface and we can approve it and get it live almost immediately. So this is really designed to be a collaborative editing project. And so we do have an updated version of the landscape with even more logos on it. We now list our Kubernetes certified service providers all of the 50 certified Kubernetes platforms and distributions and everything else. And we'll keep coming out with a new version of this every month that's gonna map to the interactive landscape. This is also the serverless version of it that was a project that Austin and everyone else in serverless work group worked on. So please feel free to tweet about this. If you have issues or questions or suggestions please reach out to me at my email and thanks again to Austin for giving me those five minutes. Thank you. Thank you.