 I want everyone to put down your large electronic devices, look up from your cell phones. We have some special emergency announcements up here. And we know from this week that it's very important to pay attention to these. Just wanted to point that out. There are no cards in front of the back of the chairs, so just make do. All right, we're here to talk about dispatch, which is a serverless framework. It's something that we started at VMware about a year ago. And what we wanted to do was think about what would an enterprise class FAS look like. And we really thought about it and went, there's a lot of open source FASs out there. And one of the things that we focused on was not re-implementing a FAS, but look how we can take existing technologies and wrap that and work around that, embrace and extend open source. So first off, we're going to talk about why it functions, why serverless, et cetera, very quickly. Go over that. Berent is going to be talking more about what is dispatch, and then go through a demo integrating into open service broker, which is very exciting. So why functions? As you look at where we've gone through our journey of compute, we've gone from bare metal servers, VMware helped revolutionize the virtualization market. We've seen that occur with public cloud using virtualization as well. And then a couple of years ago, containers hit the market, became the latest hot thing. And now functions are starting to appear. We saw AWS Lambda appear on the public clouds. There's functions in public clouds and a lot of open source projects around FAS solutions. So why are we doing this? Because it makes it a little bit easier for developers to not have to think about the infrastructure. As you look through the continuum here, you are spending more time on your business logic than on the infrastructure itself. So it makes a lot of sense to, you know, get more value out of the code that you're writing and the time you're spending on it. Now, do I think that it's going to be the end all? No, I think that every cloud native architecture is going to have a combination of VMs, instances, containers, functions, and services, and be able to then build out your applications like that. But it is a very important piece of what we want to do as cloud native architectures. And why is that? Well, these functions are event driven. So, you know, depending on the number of events that are coming in, which you can't always predict, you won't now be able to react to those. You, the functions are inherently stateless. So you tend to do something very quickly, they're short duration, and then send the state off to back end stores, give a response back to, if it's an HTTP endpoint. I mean, there's a lot of good uses for this. And the very best thing about it is that it's inherently auto-scaled. As the events come in, we all of a sudden will expand the number of functions running, and we can handle the demand coming in. Now, lower cost is more of a public cloud. I don't know. What's that? Property. So, you know, when we're looking at it from a VMware point of view, we think about, okay, how can you run stuff on-prem? You don't necessarily get the cost benefits of no cost at idle. But I think it's still very important to have on-prem and public cloud having the same type of functions being able to run. Some of the use cases run the gamut. A lot of what we've been seeing is not necessarily people implementing applications with functions as a service, but more looking at it in terms of DevOps, ITOps, automation. And I think in terms of the IoT space, looking at edge computing and how to best handle some of these burst loads coming from IoT devices will be very important. I think serverless could handle any of these, but we're just seeing that as people are starting to embrace it, they're focused on certain attributes of this. If you wanna find out more about just what is happening within serverless and the serverless landscape, we had a CNCF serverless working group where we created both a white paper and landscape around what is currently happening in serverless land. We then, after we shipped that as a 1.0, went on to start talking about thing called cloud events, which today we just released a 0.1 specification. This is where we're looking at the commonality of, looking at how event sources can have more commonality, be able to specify what they look like such that we can transit events between services. So very important work going on there. And without, I'm gonna let Barron take over. All right, so I guess, yeah, seems to be working. So I'm gonna talk about what is dispatch, so what have we built? So Mark alluded to earlier that we are not building the actual FAS, we're not building the function executor and scheduler, but rather we're building a stack of services around the FAS that we think makes it more appropriate for enterprise production deployments. And so what are those services? So one of the things that Mark just alluded to was this cloud events thing. So FAS's functions are event-driven and in order for you to drive these functions, you need events. The public cloud has it easy because like AWS has a whole suite of services, they run on a common event bus. Public cloud or the private cloud doesn't have that same thing. We don't have a common event bus and we have a very disparate set of services. So dispatch includes what we call an event manager with an event driver interface, which allows you to very easily sort of build drivers, which are just small processes, which can import events from effectively any service, translate that into a cloud event, and then push that onto the dispatch event bus, which effectively makes it a trigger for any event that you want to subscribe to that particular, or any function that you want to subscribe to that event. Currently we have an event driver for vCenter and we're working on event drivers for public cloud so you can ingest public cloud events. Secondly, current open source FAS is effectively a single user one role experience. And we think in the enterprise that doesn't make a lot of sense. You need roles for developers and you need roles for administrators. And so we added IAM or Identity and Access Management on top of the FAS, all managed by dispatch. Also we alluded to we are not building a FAS, so we have an adapter interface to the underlying FAS. So this allows us to work with either open FAS or RIF today, and in the future, we will be able to run functions on the public cloud as well, and it might not just be an or, it could be an and, so you can schedule functions in the environment that is most appropriate for that function, or for instance, burst to the public cloud. And lastly, functions, 80% of functions in Lambda, I heard the stat recently, are triggered from an API gateway, namely the Amazon API gateway. We want that, and so I think that's sort of a common thing across functions, very easy way to interface with them. But current FAS doesn't ship with a real API gateway, generally speaking. And so we've wrapped Kong in dispatch, which Kong is an open source API gateway that's pretty widely adopted and has a lot of plugins. And we've also, we talked to Edith Levine from SoloIO today, and she's got a project called Glue, which might also be appropriate in this space. So this is a pretty simplified view of what dispatch actually looks like architecturally. The big fat bar, the control plane, it's actually a whole suite of microservices that do the various management pieces. We've got our IAM that connects to your existing, like OIDC or OAuth2 compatible identity provider. We've got an image registry, currently we just kind of use the internal Docker registry, but this could be let's say Harbor, which is a VMware open source product. It could be any Docker compatible registry. We store our state in Postgres, we store secrets and Kubernetes secrets. All of this is managed by dispatch. And then we've got the API gateway. What I haven't talked about yet is the pieces to the right, which are the new pieces. This is our integration with the open service broker API, and it allows us to bind functions to services such as databases, which effectively allows you now to build applications as opposed to just stateless functions. So this is effectively what our integration with the open service broker is. So through dispatch you're gonna be able to list the available services and I'll show you. We're gonna create a DB instance and create a binding, which is then stored in dispatch via secrets. We're gonna create a function which uses this binding and then we'll execute it and we'll do a little bit more too. Anyways, so let's actually do the demo. All right, so let's start off. So I should say, the first thing we're gonna actually do is do that a little bigger. First thing we're gonna do is create a runtime image. So a function, this is all gonna be done in Python, but a function needs a runtime in order to do anything. Dispatch itself has a notion of base images and images. So the base images contain effectively your OS and the runtime. What dispatch allows you to do is create images which are effectively an extension of the base image and allows you to layer on, let's say runtime dependencies, which is in fact what we're gonna do. This is a little bit different than for instance like Amazon, which the only way you do this is by tearing up all your dependencies and pushing that up. And it's also a bit different from, let's say OpenFaz or Riff or any of the other open source faz which the developer is managing the Docker container itself. So let's create an image. So first create image, give it the image name, base image name, and then the dependencies. If we wanna look at the dependencies, environments, here's a list of them, right? They're pretty standard Python dependencies, gives us access to Postgres and a little bit more. So we've got an image. Next thing we're gonna do is create a Postgres database, copying, pasting this one because I don't remember at all. If we wanna look at what services we've made available, so dispatch. So the service classes are the types of services that are available. And I've associated dispatch with a Azure service broker, which is why you're seeing a bunch of Azure services. And the one we're interested in right now is the Azure Postgres SQL service. This is gonna provision a Postgres server on Azure and also create a binding which it stores in dispatch as a dispatch secret, which then can be injected into our function without the credentials needing to be checked in or even the developer knowing the credentials. Anyways, so we're gonna create this service instance of one of these service classes. So the command is somewhat straightforward. Service instance, we give it a name, give it the service class itself. We're giving it a plan, which is an open service broker API thing, which, well, not that important. And then a bunch of parameters. Parameters, you can discover, there's a schema for the parameters, which is available, but we'll not go into that right now. Anyways, it's created, it's gonna go provision, it's actually gonna do it. It's also gonna take about 10 minutes, so we're just gonna leave it here and we're going to use one that I've already created. So get service instances. All right, so we're gonna use this Azure PG-1, which is already ready, already bound, and ready for us to use. Anyways, so what I'm gonna do first is create a little echo function. And the reason for doing this is so that I can show you exactly what this service binding does. So I've created this echo function, all the echo function does is echo the function context. Context is one of two parameters that make up a function signature, and it's where service bindings, API, context, secrets get injected into the function. So anyways, I've created the function already, so dispatch, get function. Let's make sure it's ready, it's ready. Dispatch, exec, echo PG, wait. All right, so that gave us a whole bunch of output. The important bit right here is the context. So this is one of the two things that gets passed in the function, and more specifically, we've got service bindings, and we've got our Azure PG service binding, which includes the credentials to the database. And I should say, the way this was associated with this function was this flag right here when I created the function. Anyways, so that works fantastic. Oop, gotta get my ordering right. So I guess I forgot to start with what we were building. So what we're gonna build, and this didn't show, scaled wrong, what we're gonna build is a little notes app. And so I've got the front end for the notes app, but as you can see, it's just getting 404s, the back end's missing. So that's what we're creating. We're creating the function, the database, and the API endpoints to back this app. So we've got a function here. Let's, maybe we should look at the function before we create it. So this is the function, all notes. And it handles both creating and getting back notes. Notes are small, effectively rows in a Postgres database. The handle function is the entry point for dispatch. So this is the function signature. It's very simple. We've got the context, which we just showed what it contains, and the payload, the payload's gonna be any of the input parameters, query parameters to that function. First thing we call is setup. Setup takes the context. It extracts the service bindings, creates the database connection, and the table. The table is this object right here. I'm using a small ORM called Peewe because I didn't wanna write raw SQL. Thought it'd be a little bit nicer to look at. And then I'm looking at the HTTP context. So the HTTP context is injected via the API gateway. And we can use this to determine whether or not the request is a post or a get. And based on that, call the appropriate function. So if it's a post, we're gonna call this add note, which is gonna create a note into our database. If it's a get, get notes, so we're just gonna list back all the notes. Pretty simple function, pretty simple service. So here we go. Here we're gonna create this, or no, that's not the function we just created that one. Let's create the right one. That's the API, don't need that yet. Let's create the function. So we just created it, same story. Create function, we give it the image name. So this is our image that contains our Postgres dependencies. All notes is the name of the function we just created and a path to the function file, and then we're associating it with the Azure PG service. Let's see if it's ready. Dispatch, get function, now we can just list them all. And there it is, all notes, it's ready. Perfect. We can even call it now. So dispatch, exec, or don't need that. All notes, wait. First time it runs takes a little longer because it's instantiating everything. The next few times it'll be faster. Output, empty list, we have nothing in the database, so that's not a surprise. Everything works though, great. All right, next thing we're gonna do is create an API endpoint. So that's this command. Again, pretty simple, so create API. All notes is the name of the API. All notes is also the name of the function we're binding to this API. We're not doing any auth, so public. We're associating it with both the get and post method. We're assigning it to this path slash note and we're adding cores so that the browser's happy. Cool, dispatch. And that's ready too, so can we check that out? Let's do it, so it's a curl, looks a little better when we pipe to JQ. But again, it's empty still because we don't have anything in our database. But can we create something into our database? So you see how currently we're just getting, we were getting 404s. Now if I reload this, oh, better, no 404. So let's create a title to this. Hello CFSummit, boot dispatch, let's create that note. Hello CFSummit, welcome to dispatch. If anyone wants, they could even go to this. It's cfsummit2018.dispatchframework.io. And that's the demo. So I guess, all right. So anyways, we just added the service integration to dispatch. We're still a pretty early stage product or project I should say. We just released our 0.1.11 release which doesn't really mean anything but we are releasing weekly. We're adding features pretty regularly but we can always use help. Currently we have event sources from the API Gateway and vCenter and soon we'll have public cloud. We have language support for JavaScript, Python 3, PowerShell and as of maybe today I just saw a poll request come in for Java and I think Clojure as well. We support OpenFaz and RIF. That list might expand as well. We've got IAM support with per user policies. We run on effectively any Kubernetes and yeah, you can see us at dispatchframework.io, see us at Twitter, all that good stuff. Go for it. So we would love to have people come and join us in the community, work with us to add some of these features, look for how we can do integrations of dispatch into potentially more of the Cloud Foundry ecosystem where you can bring your expertise, you can leverage us to be able to provide a functions as a service into the Cloud Foundry family. So please come to our GitHub, take a look at it. There's some great docs talking about how to get started in it. They'd love to have all of you to help us out with. Here are some additional links where you can find us on GitHub, documentation. We have of course a Twitter feed. If you go to the VMware Code Slack channel, we have the Slack team, there's a channel that we have there to talk about dispatch. And then we also have a couple of links for some of the technologies that we're using, OpenFaz, RIF, and Kong at this time. So any questions that anyone has, I'll leave the link slide up. So I got one question there. In the demo, I saw you attached your function to a service. Can you attach to several services as well? You can. So that context has a key for each service. And so you can, and that command will take as many services as you want. So as long as you've created that service instance ahead of time, you can go ahead and bind it. It'll be available to the function in the context. Cool, follow up question. If I add a different service afterwards, how can I bind that to my functions afterwards? So I mean, you'd effectively just update the function. So when you update the function, you're creating a new image. And I mean, in this case, you're just creating a new association which dispatch would take care of. So no problem at all. But your code would probably change. Yeah. Perfect, thank you. Yeah. Any other questions? Great. Thank you, everyone.