 Yeah, everyone I think Vinay said he should be on to facilitate. If not, I will. I can do that. Is it me or is Google Docs down again? Not just you. It's having some trouble. I feel like it's just like whenever we have a meeting, it goes down for five minutes. They know it's us. It's on purpose. Hello everyone. Good morning. Moderators lead to the party. Sorry about that. No worries. Google Docs is waiting for you. So as is customary, we'll just give it another minute and we'll get started here. Got a very interesting presentation on tap. So while we're waiting, I'd love to maybe ask for some contributors to be scribes for today. I can be described. Awesome. Thanks. No worries. I'm happy to do it as well. Thanks Alex. All right, let's get started with with our housekeeping items. I'm going to go through and first thing is I see a lot of members on the call today, but if you haven't already added your names, please do so. And if you'd like to bring up any items that you'd like to talk about, please make sure to include that next to your name so we can make sure we discuss that. So as I go through, I don't see any updates from the group at this time. With that, I'll just also quickly make sure is Doug, Doug's on the call. Hello. Maybe and then get started. I don't see any updates from the group today. So in that case, without further ado, let's get started. I'm very pleased to introduce Doug Davis from IBM. He's also been, you know, leading the charge on all things serverless with the CNCF. He leads the serverless working group and has been, you know, working very, very hard. And I was privy to a lot of the early discussions with the, the cloud events work that's being done. I don't want to take Doug's thunder but Doug very happy to have you here present to us about the status of the serverless working group. And, you know, as we start off today I just thought maybe I'll just give provide one particular input. There's been a lot of debate on what exactly serverless is and what constitutes serverless. So it would be great if you could also, you know, sound out on that and give your perspective as to what exactly is serverless. I have my thoughts. With that, please take it away Doug and thank you for being here today. Thanks for having me. So when Sarah approached me to talk to you guys. She gave me some guidance in terms of what you wanted me to talk about but not a whole lot so I wasn't sure what to put together in terms of preparation for this so please do not hesitate to stop me and ask me to some questions or to go in a different direction because I was guessing what to put together in this presentation. Okay, so just don't hesitate to to spend us on a different track if that's the way you guys want to go. Okay, so one of the things she's mentioned is something you were just asking about you know what is serverless. And I think from the serverless working group's perspective the best way to think of it is to first start out with what is a function. And typically those are operations that are or their their processes you know like workloads or applications what do you want to call you know something that's sitting there waiting to do work. They're typically event driven. Each request is typically short duration typically stateless. And with the goal of hopefully being lower cost because you're breaking up the monolith into either even smaller pieces than just what microservices right these are supposed to be tiny little bits of thing to get your job done. More like, I tend to look at is like a whole bunch of like you little utility classes or functions right they they're there to one particular task and then stop and something else, possibly bigger from orchestration point of view is looking at the overall flow. And when you think of it in that way, obviously then a function is something relatively small like this little sample here. And what's interesting is, for most people a function doesn't even deal with the HTTP or transport aspects of things right. So if you look at this little, this little sample right here. Everything talks about, you know how to take in parameters how to process the parameters and then return something. It doesn't deal with the HTTP or transport aspect of things that's supposed to be sort of managed by the infrastructure that's hosting your function. Now, that's the way most people tend to look at it. However, there are some environments take, for example, Knative, where the user is responsible for managing the HTTP aspect of things right so they had to inject an HP server into their little JavaScript code here. Just to get things up and running or let the JavaScript framework do a form but either way, they have to sort of set that up themselves. Now that's not true for everything like Lambda will do it for you. I just want to make it clear that there are some environments where you have to do that yourself manually, but that doesn't change what a function is from this perspective of it being a small little utility class to get one particular task done and that's about it. Okay. So obviously when you look at this from an event driven process thing right you have your function executing someplace. You can have an event producer or event source generating events that gets sent over to your function to do some work. And as I said, typically these functions are meant to be stateless. So they have to talk to some back end service often to store the persistence or to get access to a database or something like that. But what that allows is for these functions to not only just be stateless but then to be also scalable right that way they can come and go as they need to, based upon the workload, but all the real data stored back here in the back end. So that allows them to be stateless. Okay, any questions so far. Okay, hopefully none of this is actually new. So what is serverless then relative to functions well the way I tend to look at it is serverless takes function to service one step further. Okay, because function by itself. As I said if it's just a small little unit of work. Notice what I didn't talk about something that is very popular with serverless environments things like auto scaling of the function based on the man, even down to zero right. So to me the difference between functions and serverless is that serverless adds a bit more of the orchestration and management layer around it right functions just small little micro micro service. Serverless says okay now let's do auto scaling based upon load or CPU or some other metric, including scale down to zero because one of the popular aspects of serverless well it's not that's true for all of them it is very popular. So that when it's not being used it scales down to zero, so that if you're an environment where there's a cost associated with it, it's going to be zero cost when it's not being executed. Okay, so overall you can think of serverless as not need to worry about the managing the infrastructure, but then service is meant to actually invoke functions under the covers. I'm just going to point out though that there are a lot of people who use the term serverless outside of functions in the sense that they don't think of what they're hosting as a function so for example, if you look at something like cloud foundry. No one's going to say that the functions of service environment. Those are typically web apps, maybe micro services, but they also could be rather large things. Now one thing that that cloud foundry is missing is the scale down to zero part but it will do auto scaling up from one right. So if you could add the scale to zero to me. Cloud Foundry could be a serverless environment from that definition of it's just there to manage the infrastructure for you you give it the source code you give it your deployment artifact whatever it is. And it manages the rest for you. Okay, that's to me what serverless is all about it's just the most popular use of it is for functions. So, with all that as a background, let's talk about the serverless working group. So the serverless working group in the CNCF was started I think around June 2017, mainly because the TOC wanted to understand what to do with serverless if anything at all. At that point in time serverless was still relatively new thing from a community perspective, obviously things like landed had been out there for a while. But it really hadn't taken off in terms of a broad open source community kind of a thing. And so they want to know okay what do we do with it, and in order to make that kind of recommendation or analysis, we first had to do what I would call sort of background work right figure out what is serverless. And kind of, you know what I just, what I just talked about in the first four slides right, what is serverless what's the state of the technology state of the ecosystem and stuff like that you know what is out there today, both from an open source perspective, as well as a proprietary perspective. And so we basically did that we came up with a white paper, explaining all this in wonderful gory details, along with the set of recommendations in terms of what to do next and I'll get to that in a second. But the other thing we created was a landscape and I, if you go to the serverless working group pages or get a repo, you will find a link to I think it's a Google spreadsheet that tries to list out all the popular serverless frameworks out there, what each one does the languages they support what kind of backend services they have stuff like that it's not necessarily the completely up to date, but at least it gives you an idea of sort of the general shape of what the community has out there today. Okay, now, in terms of recommendations. We did come up with some interesting things and I remember correctly a lot of them were things like look for other or look for serverless frameworks in the open source community that we can encourage to join the staff to start building up an ecosystem within the CNCF around serverless, also trying to look for education opportunities and explain what is serverless why it's so great and stuff like that. But one of the biggest things is we want to look at where we could help out the community relative to adoption or interoperability. Because, while there were some, or, while there were and still are a whole bunch of different serverless frameworks out there. There really wasn't much of interoperability between them. So for example, there are some that run on Kubernetes and that's great. They all run Kubernetes, but the way you interact with them, or was completely different right they each have their own set of API is and stuff like that. So was there some sort of interoperability project we can come up with just to make life easier within the serverless domain. Now, one of the things we realized though is because we had lots of different ideas of things we'd like to be able to do because we're all developers and we love interoperability and standards and all that other stuff. But we realized it's going to get really, really political, right because there are existing things out there and asking anybody to change their, their implementations or their API is is just asking for trouble. So what we did is we identified something that's sort of off to the side, and we realized when you think about functions and serverless. As I said, a lot of them are then driven. So we said okay well is there something we can do in the event space. And we realized that one of the pain points that people experience with events is not so much processing the events but routing of the events, meaning, how does an event get from the producer to the consumer. And today, the way that usually works is, especially if it's going through a piece of middleware is that middleware has to understand the event coming through it in some way. Even at a meta level just understand how to send it to the next destination it has to know what the destination is so maybe it has to read some issue better or something like that, or whatever. Even at that level it has to look the message in some way. However, most of those intermediaries need to do more than just simplistic proxying type stuff. A lot of them actually want to do routing based upon the event itself. So for example, maybe it wants to do routing based upon where the event is coming from. Maybe it wants to do routing based upon the type of the event right maybe creates go to one destination while it wants to go to a different destination that kind of stuff. Okay. Well, in order to make that kind of determination that middleware has to now understand the event flowing through it. And I don't mean necessarily has to understand all the business logic, but at least has to understand things like how to parse it to know what field to look at to do that routing. So we decided well what if we try to help in this space and that's how we came up with cloud events. Okay, what cloud events is meant to do is to help in the routing from from the source to the destination by defining common metadata attributes. And I'll give you an example in a minute. Well actually let me go ahead and jump there right now it's easier to talk about that. Okay, so let me look at me show you this example right here. You see this, this HTTP post, and you ignore these four attributes, the rest of it is just what you might see from an event flowing through or flowing over HTTP, right, you have the, in essence, so basically the URL is being sent to. The host name, the type of data, and then the data itself. Okay now in order for some sort of piece of middleware to route this message appropriately based upon the fact that it knows it's a new item type of action or event. You have to understand that this is Jason, how to parse this to look for a field called action and then take some, some behavior based upon that value. Okay. So what cloud events does it says well wait a minute, what if you just add a couple of extra HTTP headers to this message. Ignore this for a minute because that just tells you what cloud and specification spec version we're talking about. And this is just a unique ID for the event every event has a unique ID. But these two bits of information tell you where the event came from, and the type of the event. So this is a new item. Okay. So what this allows a piece of middleware to do is to without understanding them the event whatsoever. It can look at this metadata and make some very basic determination in terms of what it wants to do with it relative to routing. Okay, this is a rocket science you may even look at that and say oh my gosh what what the heck can you do with that it's so simplistic and to some extent that is true. It's not sexy it's not glamorous, but believe it or not, this actually solves a significant pain point for many people, right this little bit of extra metadata being outside of the event itself. Whoops, actually has been a real lifesaver to a whole bunch of people I had many customers come up to me and say thank you for creating this because we did exactly what I just mentioned. We had to create middleware, and every single time there was a new event with a new schema, all the middleware had to change to understand how to parse it and know what to do with it. This makes the life so much easier. Okay, and to be honest if there are other properties that people don't, or don't see today that they want to add to it, they can extend this themselves but the point is, much like HP headers in this example, we're providing a well defined location for where these extra bit of metadata supposed to live, so that you can use it for whatever purpose you want, much the same way in a server itself doesn't understand what's in the body, most of the time, it routes it to the proper web app based upon an HP header. Okay, same concept. Now, that's what we call the binary format, the structure is the exact same thing, except people come came to us and said you know this is all great but what if I don't even have an event that's currently being sent, we're not creating something brand new. Can you guys give us an event wrapper that we can just use. And we, and so we did, and that's what we call the structure side of things right so basically just said okay let's create an adjacent. And you can see the exact same data, except instead of HTTP headers, it's in since out of the body, and the data is the exact same. So this serves two purposes one, give somebody a well defined wrapper if they don't already have one because we do not want to have another common event format that was not our purpose, but if they don't have one and they want one recommended will give it to them. But then there are also other cases where people say you know this is great, but I don't want the data CP headers. I want it in the body because I want to just to be able to take this entire chunk of Jason, stick it into a database, and then let the next step in the process deal and if it's in if that information is as a CP headers that I need to extract HP headers and create some sort of global wrapper myself to have all the information there. So, it serves multiple purposes have the structure side of things, and that's what we did. Okay, so anyway, that's what the service working group decided to work on first was to attack that particular problem. Now, while we're working on that, we did think about other possible things in terms of next steps to work on. And one of the things that came up was serverless workflow, and I'm not going to talk a whole lot about that but you can kind of imagine what it is right it's orchestration of functions right so events coming into the system, you react to those events you do some processing, and maybe it's a multi step process, and each step can only process or can only get kicked off. After a previous step is already done, who's going to manage that orchestration and who's going to realize or to manage that one event needs to get sent to five different processes, and then they come back together at the end kind of a fan and fan that kind of thing. That's what serverless workflow is supposed to do for you, and that's itself as a sandbox project in the CNCF today. Okay, I should have pointed out that the cloud events is now an incubator project I came or when that happened I think it was about a year or so ago. So that that's in the CNCF as well. So summarize the status of cloud events. We did ship 1.0 the spec in 2019. We have at one point in time, we've had pretty much, I think, every major vendor out there in the cloud in the cloud native world show up at our meeting at one point or even AWS, which I think is a big win for us because AWS while they do do a little bit of open source stuff they don't do a whole lot right so they were there for a while. You know honesty though they've they've they've sort of backed away, not I think because of anything's changing AWS other than the person who was there left AWS and so we need to go back and ping them and see if they want to rejoin with a different person, but they are supportive of the idea of cloud events. I just don't think they've adopted it yet because they they have their own way of doing things as of right now, but they did admit that if we came up with the cloud events. Several years earlier they probably would have adopted that instead of doing their own thing. So anyway, we have several different SDKs and several different languages to help you with the creation and processing of cloud events from the center and to the center side. But the most, the most interesting thing from the latest status perspective is, if you think about cloud events, it's great for helping you get the event from point A to point B. But there's lots of other things involved with just managing the event the life cycle itself. In particular, how do you discover who sets who sends a particular type of events, or what type of events they actually do send. So you know what does you want to subscribe to. Okay, we decided we're going to start looking at a discovery API spec so that a consumer can go to one or multiple discovery endpoints and find out who generates what. Okay, obviously, once you figure out who generates the thing you're interested in, you may want to then subscribe to it. So we're going to create a subscription API spec that will try to standardize, at least for the protocols that don't already have a standardized way. Like for example, ACP. How do you actually do a subscription, right? How do you tell it what events you want, what filters you want, where to send the event stuff like that. Now, there are many eventing protocols that already have this defined and it is not our goal to reinvent the wheel. For those go use what's already defined. But for things like ACP for web hooks and stuff like that. Every producer has their own way of doing it. So we're trying to see if we can get some interoperability around that. And finally, we're also looking at a schema registry. This was created because one of the properties inside cloud events is a pointer to the schema of the event itself. It's an optional attribute people can include if they really want to. So what's missing is the definition of how to talk to schema registries, right? Because normally when you're given the URL to a schema, your natural connections and say, okay, how do I do it, you know, I'm going to do an ACP get to that URL and you'll get the information back in some format. But there really isn't a standard way of actually talking or managing schema in a schema registry itself so you can get some interoperability, not just on the reading side but on the creation or update side. And that's what the schema registry is looking to do. Okay. In terms of priorities, I would say probably discovery and subscription are coming first and schema registry last just because I think more interest lies in these two as of today. And that's pretty much all I had I would say have some links here if you guys are interested and follow those information. But let me go ahead and stop there and see if you have any questions or different areas you want me to sort of zoom in on. I want to give you a compliment and give the cloud events. Like, by the way, it's a great presentation. Something with Falco, for instance with cloud events, the group that the one of the contributors Scott Nichols came in and really explained it and the way that it could be used it's super super useful for useful for eventing and like you can trigger things like he built a cloud events integration for Falco sidekick that will trigger like based on a rules violation to multi multi cloud I mean it's it's it's really really cool definitely you all should check it out. It's a very good common place to you know for the event thing and scheduling but like server list itself in terms of Knative and the working group is doing such a fantastic job so kudos to you and the team. Yeah, well I'm glad Scott was able to talk to you guys he's a good guy. So I'm glad that that worked out cool. Any other questions. I have a question. So you talked about, you know, you made the distinction between functions and then serverless right and maybe once again I fall in prey to that distinction, if there is one there. But you know, what are the examples of fuzz. Without the context of serverless right because you know when you talk about AWS lambda or Azure functions or, I don't know cloud run, you know, they you what are the application I mean it seems like you can't have one without the other for any kind of a realistic application. Is that a fair assessment or incorrect. That's hard to. Okay, let me have to ramble a little here because I think it depends on your perspective right to some people functions and serverless are the exact same thing. There's there's no difference between them whatsoever and a lot of people use the terms interchangeably. I think if you try to step back and look at it from a purely abstract or puristic perspective. I think that's what I tried to lay out here on this chart, which is technically a function. I think to a lot of people, if you if you actually try to draw a separation, a function is just a smaller microservice. Right. It's really all it is. And so if you if all you have is a small microservice. Well, that could be something that never scales, but it's still a function. I mean, it's only when you add in, at least to me, some of the management around it, the auto scaling the scale to zero zero cost when it's not running. That to me is what's make it serverless because it's about not managing the infrastructure or anything else that goes around it because so so go back for a minute to the function side right. I can have a function, but still be forced to manage the entire bit of infrastructure myself. So I can do functions on Kubernetes today, and that works just fine and I could, I could and all in all honesty and all purity say yes, that is a function, but I still managing all the infrastructure myself and Kubernetes is not easy to use for a novice right. So no one in the right mind would say Kubernetes is serverless, but does it support functions. Sure, it's just an application is just a pod. Actually, that might also be helpful for this group, I think is, and maybe it's a good to have for to talk about the serverless work is, but when you talk about a function in the context of Kubernetes, but you still have something that it needs to run in and the context as a container. You are how do you say abstracting away the delivery transport. Is that fair. Is that the word to use, because you still have a function I mean function is always a function but it has to run in some context, and in the context of Kubernetes. It's a container, but in the context of lambdas, it is whatever lambdas I mean how they actually facilitate it maybe containers in the back end. Is that the right way of looking at it. So you are not you don't think about the, the running environment, but when you talk about functions. For me personally, the reason I'm struggling is because I think the answer depends on your perspective. I think I think some people would agree with you that even in a function environment, you should probably you should not have to think about the hosting side of it. Right. For me personally. I, I'm not sure I would agree. Right. I would still say it is perfectly legal for someone to claim that they are a fazz, but still require you to understand the infrastructure in some way. I could be wrong. Right. It's just my perspective but I think I think it depends on how you're looking at it because I think if you're going to claim that a function is going to hide the infrastructure from you, then I think you're probably in the mindset that says functions and serverless are almost one in the same. And I think it's a valid way to approach it. I just have been beat over the head so much with the abstract and and puristic model that I tend to separate the two, even though I'm perfectly comfortable also interchanging the words depending on my audience, right. So, I think it depends on that. Yeah, I mean, I'm going to say purity versus practical maybe. Thank you. Yeah. Just from that, extending that point, would it be fair to say that the server less or sorry, the functions are somewhat more of a stateless but the server less is more of a stateful. Is it meaning. No, I think I think most people would agree that serverless is meant to be stateless as well. You could do some stateful things inside your serverless stuff but the minute you start talking about things auto scaling, especially scaling down to zero. You almost have to assume that they're stateless at the end of the day. Now that doesn't mean they couldn't persist something because you're going to reuse the container so therefore you don't have to reload the cache every time and stuff like that. But I think in the most puristic form, I think serverless is supposed to be stateless as well. Right, without the users context, I agree with that. But I think once you inject the user and are taking the serverless as the substitute for servers. Wouldn't you say that you have to preserve some states in that context of that function that you were going through. I mean, when you say opposed to just the functions itself, because functions itself you probably don't need to have any. Well, so there's two different ways of that. Well there's two different ways. I kind of perceived your question. One is, you're, you're making distinction between functions and serverless relative to the code itself inside the application. You should make a, you draw a distinction there. Right. So if something's going to be stateless in functions, that same bit of code is probably going to be stateless and serverless and vice versa. Right, so I don't think the difference between fast versus serverless changes the deployment artifact itself. Okay. Now, relative to state though, I, I, my mind is still stuck in this mode of. Yes, you may need to persist things between invocation of either your function or your serverless function, but that's not typically saved inside the, the, the running artifact itself. Those are typically saved in some remote system some sort of database or even just a disk that's on a shared file or something like that right, because you want to be able to scale down and still persist that information. Importantly, you also want to be able to scale up so that multiple instances can share that data. Right. So I really think that that the fast versus serverless aspect, I don't think plays into the stateful versus stateless thing. I think that's a separate side discussion. Okay, I see your point I think you're saying for the scaling purpose you have to separate the states from the. Yeah, and like I said though that doesn't mean. Yeah, and like I said, I don't think that doesn't mean you can't do optimizations right so for example there are some environments where they scale or the function when it's not being used scales down within milliseconds. Persistent and that you know that that that's valid. But some sort of persistence store there inside the container doesn't make a whole lot of sense. But if your runtime environment or your, your container lives on for maybe a minute before it gets scaled down. Then maybe it makes sense to have a little bit of persistence store between invocations or between incoming events, because that way as I said, you don't want to necessarily repopulate your cash or maybe you can do some optimizations and, and you know, let's go back to the database every time because maybe that's expensive. Right, you can do some optimizations there but that's strictly or that that's usually just for optimization purposes it's not going to break your flow if you don't do it. Good. Okay. So so I had a kind of question about the cloud events stuff that you don't mind moving to the slide so kind of I have to kind of security perspective questions one is related to cloud events the other ones related to kind of generically the programming model but it seems like even now that you're you kind of when I see this reminds me a bit of like, you know, all what's top 10 in the series of things that right it seems like there are certain considerations that also need to kind of have best best practices off with regards to you know the metadata they're putting over here is that is that something that you think needs exploration. For example, over here is there any restrictions in the sauce ID ID is confidential piece of information and things like that do you think it's an area that needs to be exploited a little bit more. So, the, the, the cloud events working group very purposely avoided anything having to do with security. Two reasons. One is, it's a very, very complicated topic. There are many different ways to get it done. There are many existing standards out there that tell you how do you, you can secure messages already, and we didn't want to reinvent the wheel and nor did we want to necessarily pick a winner. Right, so we figured okay you can layer on security and signing and encryption and all your other stuff, you know yourself. The other really, really big reason we decided not to touch it is because we realized that the minute we touched it we'd never ship a spec. It would, we would get bogged down in trying to make those those answer those questions that that we would be there for years trying to settle it. To avoid some of this, some of the pitfalls that that someone was ran into in the past with like WS security and stuff like that right so we decided at least initially make 1.0 go out with no security whatsoever. People can layer it on themselves later and we can always look at it again later and in fact, just recently somebody in our working group proposed a extension mechanism to sign the cloud events. And so we are going to be, you know, it's a valid it's a valid proposal so we're going to be looking at it, we may very well adopt it, or we may reject it and say nope sorry we're still not going to touch security we don't know. But it is definitely something that people will want us to explore. I just don't know where it's going to land, but we decided to go out with 1.0 with with just the bare bone minimum of how to get the metadata across. Yeah, yeah that makes sense. I asked the thing you mentioned that this was going into incubation was that. Yeah we're already in incubator status so there's you know there's sandbox incubator and then put it what's the final one. Graduation graduated thank you graduate yeah. Yeah. Yeah so we're an incubator stage and I got us with you I haven't gone back in a while to check and see what graduated status means. I don't know what the criteria is. Maybe we should be going for graduated status I just I came with the criteria is yet. But to be honest, the status doesn't mean a whole lot to us I know that maybe more marketing s or anything else. But we should probably look at that but I don't think it changes what we do because we're pretty happy with the current state of things and no one's complained about it or found major bugs yet so I think we're good. I'm just wondering because that probably means that we have to provide some recommendation for security as well so we may have to take a look at this one. We may have a bit more work to do. So what you're saying is if we want to if we want to throw more work on your plate we need to go for graduated status is that what you're saying. We just farm it over that we just farm it out on trace. There you go. Yeah. Sorry. Sorry, good friend. So so the other thought that I had was like moving towards service. A lot of the traditional security controls can be done in the way that people are used to. So the kind of is that being asked for certain, you know, exposing certain inner workings of it or creating different abstractions so that people can control, you know, where the data that's coming from with excessive data with this reuse of the same compute nodes for different functions and things like that. Just make sure I understand the question this is more generic question for serverless and not about cloud events in particular right. Okay, yeah. Okay. So, I think in general, there probably is a desire for some level of inner ability in the serverless runtime itself, whether it's the security aspects that you're talking about or whether it's something as simple as, Hey, can we at least standardize on what your function signatures look like, right there's always good people that want that. And we've had lots of conversations about getting into those types of topics. But we've kind of shied away from that for the same reason that we landed on cloud events. The minute you do that it's going to get very very political, because people have existing things and asking them to change it is going to be a real nightmare. And the best way to answer your question is, we may eventually get there, but I think it's going to take some time. And in particular, I think we need to wait until the serverless working group and the CNCF has had more success stories put it that way to show that we're not just creating things out of the blue. We are not just trying to take one, one vendor solution around everybody's throat, but we actually have a success path or success story. Of producing things that actually are interoperable and provide benefit to the community in a very neutral way. And I think once we've done that with some of the things like cloud events, the subscription API discovery type stuff. I think once we have those under our belts, then we'll be able to tackle the things that are slightly more political, because people will see that we're not in this for any nefarious reason other than to actually help out our customers. So I think the short answer is yes, but not yet. But yeah, thanks. Yep. Question on detection. Are there any standards that you're working on in terms of what all should be logged for availability failure scenarios and etc, etc, in terms of data and metadata. The short answer is no, I haven't heard that topic come up as a possible work out of me yet. If you could actually, if you think that's an area of interest, if you can send me a note or something, just giving a little more descriptions of what that area is I can definitely stick it into the backlog of potential things to look at in the future. I know we're always looking for new ideas. Yes, both both in the builds and run phase, and I think there, there are visibility and controls that are needed, especially in regulatory environments. Imagine you're updating stock prices or something using functions. There is auditability requirements that financial organizations have to meet. So just wondering from that perspective. Yes, we can work around and we can build all that as a separate function to capture from other functions but still it's very complex and having a standard in terms of how what attributes what data and what metadata we need to capture to get a complete visibility of a function that'll be free. Yeah, that might like I said if you can send me a note with that information to be really cool because otherwise I'll forget. Just one word of sort of warning about that. I'm going to phrase this right. There may be some nervousness of getting into defining what payloads look like. Right, because I'm sure if you've been around a long enough, you recognize things like common event format or something like that right someone says hey you know what I'm going to create the one event to rule them all and it's all the metadata you could possibly want and it's all going to be standardized format and that's all wonderful. And we've had a gazillion of those. Right. And so the idea of trying to force one particular schema on everybody even if it's in one domain is a challenge right let that domain. Let those domain experts be the ones to do that right so if it's all if it's about one particular type of government compliance or regulation kind of thing. And folks who are experts in that go off and do that if they want. From the, from our perspective as of today anyway we've, we tend to focus more on the, the abstract solutions you know just how do you get that specific payload, whether it's standardized or not from point A to point B, right. Well I'm not saying it's not possible for us to one day say hey look this is just a big problem we need to help the standardization in this one particular area around the schema format, I'm not saying we wouldn't do it for sure. It's just, just a warning it may be a little, you may be nervous by getting into that. Just, just to worry. I will send you an email. Thank you. I'm kind of staying on the same topic I think it's not so much that we want to impose the semantics but we're looking for a mechanism where an existing framework could be leveraged so when I was trying to understand what you've been by metadata. We're in the security world so we're thinking about something like the ontology from mitre attack, or some other, you know variation smaller variation of that. So, you know, whether that's a plugin thing or a traceability thing which was just alluded to as an audit function that's kind of what we mean. I don't think you have to pick a winner but the whole. The thing that gets me excited about this is that there's a mechanism where in some abstract amount of metadata then can be what decompose to this to the level of a function mesh and that's that's really the winner I think. Yeah, so if I understand what you're saying there correctly. What I think you're describing is more like some sort of hook mechanism, whether it's an inbound or outbound thingy on a particular implementation of a serverless framework, or whatever framework you're using to host your application. And I can definitely see value in that. The only reason I'm hesitating is because up until now, the serverless working group has for the most part been focused on writing specs, not implementations right. So, we obviously have SDKs but those are SDKs around the specs themselves and they help to prove the spec out and stuff like that. But so far the working group has not necessarily say we're going to go off and create a new project whose sole purpose in life is to write code. Right. And that's why I'm a little hesitant to say yeah hey that sounds like something we should get into because we haven't gotten into that and we and, and we'd rather, at least as of now, focus on writing standards around apis and stuff like that, and let multiple implementations go off and adhere to those apis. But it's definitely an interesting topic I can understand that perspective. It's the same issue with API building right though the old API first design. Was that maybe three years old now, I was beg the question will you stick the metadata in the API or do it some other way. Yeah. Yeah, I agree. Great topic so thanks this is really relevant for us for this community to look at. Yeah, sure. And thanks for all the questions are good questions. Any other questions, yeah. Yeah, I have one question there. Are there any concerns related to open source libraries being used by those like serverless functions. None that have been brought up as part of the working group itself no because as I said for the most part, we kind of stay out of the implementation of these things. Okay. And if there were issues as part of the SDK development, I'm personally not aware of them but I to be honest, I, I'm not too heavily involved in the SDK side of the house. Okay, sounds good. Thank you. Yeah. Yeah, I'm not sure if maybe I lost an extended extension of that question to Magnus is, I think, where I look at a security implication is of course it's still code you have a lot of open source packages that you're building on top of. And, and obviously there is a need to have visibility into the vulnerability posture and then those go back into compliance kind of regulations and having visibility to make sure those are being addressed as well. I mean I think that threat dimension is extended across all of those applications tax right with his VMs containers and serverless. Anyway, so just a comment there. Any other questions from the group for Doug. Great. Well, Doug, thank you so much. This was a fabulous presentation. I think, you know, it really clarified some of the nuances for us as we think about. I know that, and just for the broader team, you know, as leading an effort to talk about, you know, the security in the context of serverless so this is incredibly helpful. And hopefully we can lean on you for your expertise as we progress through that project as well. And thanks for having me I really appreciate it. Thank you so much really appreciate it. Thank you very much everyone. See you all next week. Thank you so much. Thank you.