 Hello. Hello. Good morning. Good morning, Mark. Morning. Hey, Mark. Awesome. Do you think before we start, before we get into this, we could just recap the progress that all of you made on the last call? Sure thing. Great. Thanks. Clemens is here. Hi, Clemens. Hi, Clemens. Morning. Morning. Good afternoon. So whoever has the pen. Could probably put me on the attendee list. Please be ASS. V A S T E R S. Check the doodle to see who else was. You making it. So I'm listening. Doug Davis, Mark Fisher and plus station. All right. It's five after one. We get started with. Who's on. Okay. So Austin. You requested us to go over. Last week's. Yes. A quick recap would be helpful. And so we first off, we. Went down the list of people and. Chatted about. What, what projects are incorporating cloud events? How are they doing it? What can they provide? And. So we had a list of those. And then we started brainstorming a bit about what are the type of ideas we could come up with for. Showing the interrupt. Meaning that. How could we produce. Move. Cloud events by middleware and then consume them. In some interesting ways. We had some of those ideas. We. Did talk about the demo assumptions, which is so that if we did have a demo. We would. Not worry about some, some of the. You know, we put it together with duct tape and bailing wire. We wouldn't worry about some of the. Issues around security or authentication, et cetera. So. Feeds going. That would be sufficient for now, but. Longer term, we'd have to put more around it. And then for next steps. Sarah taken an action item to think about. Will it be a storage. A set of cloud events. And then. Clemens was also. Going to be looking at. Clemens. No, I was. Actually supplying things that we have in our cloud, but. Building any events. Okay. So Austin, is that a. Good enough overview of. What we discussed. Sure. I have just a couple quick questions though. Yeah. All these projects that are supporting this. And first off, this is, this is pretty good, I think. We're going to go announce this kind of event format. That could make data more liquid, more portable. And we have all these people already supporting it in this early stage. I think that that's going to really amplify that message. Are all these going to. What level of support are all these projects going to have by. By cloud native con, which is in like 20 days. I think that's somewhat. TBD, we didn't get down to specifics about. I think people are going back to research, what they may be able to do. I think some of this is hinging on. Whether Google and Microsoft could get some of their eventing. Get cloud event. Events generated. Because that's somewhat of a compelling demo. But it's up, you know, it's up to. Each individual to be able to stay what they can or can't do. So, so I can tell you from Microsoft. I sent email on Friday. Where I showed you what the mapping might be to from a particular event. The minimal thing we'll be able to do. Is write effectively a. A function. That will take our native events as we have them today. And kind of remap them into the cloud events format. Yep. That's the minimal thing we can do. So that we and that function. Basically gets it becomes a quasi subscriber. So you create a function. The kind of the function has a target. That it pushes to and then it gets an event from event grid. And basically goes doesn't translation and pushes that through. So we can build that in relatively short time. And so that's that I think from a, that's from a coding perspective. That's probably going to be our contribution. Is to say, give me your eye and I'm going to deliver an event for you. And the event is going to look this way. And the, the, how this event is going to look is effectively the. More or less the combination of the. HDP binding and the Jason binding that I have checked in. As, as PR. And the, the format that I posted on Friday, which is affected the remapping of our existing events into the, the Jason mapping. Great. That makes sense. It seems like anyone with a mature FAS offering would be able to implement something in that using that pattern as well. Absolutely. But they would have to understand. So, so the reason why I'm offering us, us building this, this function simply that we would, that we would take that upon us to go and do the mapping. And then we would further on deliver to whoever, whoever has a FAS offering. So I would not make it, it seems to be nonsensical in this context here to make anybody understand event grid events. So I would rather go and do the translation where, you know, I'm getting a URI to push to, or an HDP URL in a case or HPS, and then we're going to deliver the cloud events. And if everything goes, goes very swimmingly, then we might be able to do without that function and push straight from event grid. But that's early, early, early, early thinking. Yeah. Right. But the idea is obviously that we can go and get rid of that interim function as soon as possible. Yep. Okay. So that's what we would do. And then, and then from that point on, I hope that some heroes will step up and turn it into something demoable. So Clemens, are you talking about an Azure function when you say function, build a function? Yeah. Yeah. That's what I'm talking about. Okay. So effectively, if all that does is, is just takes our event grid event and beats that into the, into the cloud events format. And what would be the source of the events going into event grid? Ah, so the idea there would be that you can go and upload a, so if we go with the thumb nailing idea, which was one of the things that we have on the list, you would go and write an up, upload a file to a storage account. And we have some, we have PowerShell and or bash to Lee for that. And then as the file gets uploaded, it has been uploaded. You, that event gets triggered. Okay. So you're talking about blob storage. Is that right? Yeah. It's, it's, in that case, it's blob storage. Yes. Okay. So that seems, that seems the easiest. That's one of our canonical samples that we use. And that's something that will, that will work for our thing. And then we'll also similarly likely work for other platforms that you have this created event. That's why we picked it. And so that would be the proposal from our side. Like put you, someone pushes uploads a file into blob store. And then, and then even give stories. Was it, is it the expectation of everyone who's working on this, that they'd like to be involved in a, in a single demo? I'm, I don't think it's necessary to put it all in one roof. Right. Also be quite complex. Yeah, that's, that's, that's very many people in one, in one effort makes that tends to make things a little bit more complicated than it needs to be. Absolutely. So do I think. Okay. Yeah. Well, I'm trying to figure out how to do this. Would love to show some stuff off during the talk. Looks like we're going to have a lot of stuff to show off. If there's a way we could simplify it into, into one demo that I could do during the talk. That would be a lot easier, but as of right now, it's going to be hard to incorporate everyone. I think. The only thought that I have around being able to encompass multiple would be like a trace route type of capability where you would consume an event, add something, add text that made it to your event handler and then pass it on to the next one. But it becomes complex getting everything set up and getting into ordering. Yes. I saw that in here. I think that's going to be awesome. But I think it might be pretty complex to implement. For the conference. So what did you have any particular stereo in mind for what you wanted to do? Doing some examples using the pattern that Clemens suggested was exactly what I thought would be something that's kind of reasonable. Incorporating all these people is going to be difficult. It also depends on the use case. What use case are we targeting in this? What is this kind of multi-cloud scenario that we need to actually where cloud events would be helpful? I think that's going to speak a lot to users. Honing in on that, involving a few people in that, I think would be pretty good. So Austin, how far along are you in terms of implementing this in your event gateway? We support cloud events today. We have the event gateway working as a hosted service. The role it would play in this world is it would just be a broker or router across these clouds potentially. So you wouldn't have to map directly from Clemens Azure functions to whatever is receiving it on the Google side. You would kind of send it off from the Azure function to the event gateway. The event gateway could send it off to about three different providers potentially. That works for me. You mean three different consumers, is that right? Sorry, three different consumers, yes. On different clouds. So the offering we have, we could potentially be one of those consumers, I think, to receive cloud events from your gateway. And Louie, you're working on the Qubeless project, right? No, we have a product that essentially would run on a laptop described last week where we can actually, essentially allows you to run functions on your gateway. The cloud, essentially cloud functions or whatever you want to call them on your gateway to evaluate and test them. And what we can do is be able to receive events from the cloud, maybe say an event gateway and then process them and potentially hand them off, deliver them elsewhere. But essentially we can, fundamentally we'd like to be able to consume cloud events and do some processing on them. And maybe potentially be an element in a chain of events and do some trace routing, something like that. Great. Well, having one provider publish an event and then sending it through the gateway and then having multiple consumers react is certainly doable. Does everybody's FAS offering have HTTP support? Yes. Ours does. I know Google's does. Yeah, we could do that. Dispatch supports that. Right, so we're going to need to send the cloud events in the HTTP request body, I guess, and then each function will have to have something that extracts that body, which is pretty simple. Okay. I think we need to kill a use case. What do you all think? Yeah, use case is always good. And it looks like there's a lot of interest in storage around here, especially. Yeah, I think it's a very tangible one, right? So you can make a, you can obviously construct all kinds of workflow cases around files very easily. And the, I think what we discussed last week when you were in there is either, so taking a JPEG image and watermarking it, which you can take as a story of, let me see, I might have a. Yeah, I think one thing that we mentioned on the last call was that the whole thumb nailing scenario demo is getting a little dated and boring. And we were looking at watermarking, although something text based might be easier and have less requirements around that. So if I were doing something, I'm trying to find a slide that I made for something here. Welcome Doug. So there's a, we have a scenario that for something else where you upload, you snap a photo with a camera, you upload it into a blob from the blob, then you trigger, you trigger a function, the function that runs it through a computer vision API to go and classify that picture. And then it goes with that classification. It goes into a, so we move that blob into a picture inventory. The classifications get indexed and then it gets then you have it ingested, then you do an ingestion raise, you raise an ingestion thing, you make it available to your newsroom application. I mean, there's all kinds of, you can come up with a flow where you start with a picture of a journalist who's in the field with their camera and you know where they are. And then they kind of start from there with a flow that ends up on someone's news desk. And they can go and pick pictures for the event that they put on the website and you can go and make that all very event driven. So it goes from just a simple thumbnail scenario to something that's more, you know, simulates reality a little bit more for something that's very dynamic and needs to be pretty fast. Right. And then of course, once the journalist picks that, then you really need to have already the thumbnail sitting somewhere in your blob store so you can, as you use them, as you use the image for an article, all the thumbnails already there and can be referenced. It's just a tall order to build within two weeks without us having identified a resource who will do it. Yes. You could also think of, you could do it a different way, which is if you're giving an image, you do the classification and then you just do it quick while the market classification on top of the image and leave it like that. Yeah, I'm not, I'm just, I'm just giving an example of a thing that we, that might be doable. Yeah. It's just a question of how much, how much power do we have to go and do this given the time and giving resources, given resources because that's always the problem. Let me throw out a suggestion. How about, you know, one thing we see with our serverless framework all the time is that people are interested in other providers because they want access to cool kind of hosted managed services to do AI or machine learning stuff that another provider doesn't have. And we think that this would be a compelling story for cloud events in general. I mean, if you have something that happens on one provider and you want to do something with that data, whether it's an image or whether it's, you know, a statement of text or something like that, if you can be able to port it over to another cloud provider easily to gain access to a managed service that they're really good at, that maybe the other providers don't have, then that can be very compelling for users. So perhaps there's a story here where some image is uploaded somewhere and the event is kind of spread around to do all types of different processing on various functions located on different providers. But those functions on different providers should try and use some cool managed service that maybe they, that they offer that is kind of unique and great. And to do some type of processing to kind of tell a chapter of this story, whatever's happening with this image. I like Clemens' story a lot about this journalist taking a photo in the field. We could do something like that. The photo can go out to functions everywhere and a managed service can go do some cool processing on it. But that would be a cool way to show off, you know, not just kind of interrupt but say, hey, this is a means of gaining access to a lot of the cool services that the cloud providers are offering that not a single cloud provider is offering. What do you all think about that? Yeah, I think that that is a good nerve on it with respect to where we want to get being able to just use any cloud service using cloud events. Sorry, I like it. I agree. Okay. I think the way to do this is perhaps we have to figure out what that story is. And each function as a service provider who wants to be involved needs to make sure they support HTTP, of course, and then they have to figure out what they're going to do as part of that story in their function. Right. Okay. Does anyone else have any thoughts about this? Well, I think we should figure out who's going to be able to write a function that does something and we should figure out what that story is. We can even start with this story that Clemens put out there of a journalist taking a photo of the field. I'm not going to say yes from my side just because I'm overloaded with all kinds of other things. You have the build card first coming up too, so that's not helping. So you will be able to provide the function? Yeah, I will be able to write the function that translates the storage event. I will definitely be able to do that. Another great example could just be an inventory item, a photo for an inventory item. Nordstrom, there's a few people at Nordstrom who are working on this POC to build an event room in Nordstrom. They have a pretty neat workflow around just a new inventory item gets added. Someone receives an event to go take a photo. They take a photo with their phone. That's sent as a MMS message, which gets converted to an event saying that the photo is available. That event then triggers some functions to reduce the processing on the photo. But anyway, there's another story there I think that could be interesting. Okay, does anyone have any preference on what that story should be? I don't know that any of us have hard preferences on any of this. Okay. I think that's correct. Perhaps what we can do is during the next call on Thursday, we could say here's what we think the premise of the demo is. It's going to be the journalist takes a photo in the field or a new inventory item is added to an e-commerce store. We say, hey, this event can be sent out to any cloud provider, but it's up to you to figure out what you want to do in your function that's going to add value to that story overall. In some ways, I'm actually liking the thought of using a consumer or a person using their cell phone as opposed to a journalist because I think it makes more real for people. Yeah, when I saw that demo, I really liked it because it was an event-driven workflow that incorporated like a human element. This new inventory item was added and then an event was sent that the photo needed to be taken and the photographer could be on vacation for two weeks or something and come back and see these events and take photos. And while they're gone, of course, the event-driven workflow is paused, but as soon as they take that photo, it kicks off again and continues where it left off. I thought that was pretty cool. I love that demo, but doing anything with text messages or MMS might be a little bit more technically complicated. I'm just going to call that out. So the person would receive an e-mail or a text to take the photograph? Yes, I think it was either a text or an e-mail. Eric Erickson, who's joining the cloud service call from Nordstrom, he worked on that project, so he could describe it on Thursday if he's on the call. I'm sorry, I was distracted and I got in late. This is Doug. In the scenario you described, Austin, what would be the infrastructure that people would, in essence, I guess, subscribe to to receive the function event? The infrastructure that they subscribe to to receive the event, it could be it could be a direct it could be a direct HDP call from one of the other functions. So it could be a couple things. The benefit about our event gateway is you just publish it. The whole thing is designed to handle cross-cloud events and transport. But you could publish an event to that one place and it will broker it off to multiple functions via synchronous or asynchronous workflows. Right. Would you have time on your end to put together that gateway so that people can then worry about just focusing on how to get their functions and service working and then subscribe to your stuff and that way they can, in essence, just work on the back end and you handle the front end? Absolutely. We already have a hosted version of our gateway and a private beta right now which supports cloud events. So that thing is up and running and it can receive HDP and send it off to it can send it off to any fast provider that supports HDP right now. So interesting. So is it as simple as you tell us where that thing is and then we can I assume you could probably either open it up or give us the right credentials so that any of us could then basically push events to the gateway and then it would get the events would then get pushed out to anybody that subscribed to it and that way we can test this offline. Yep, absolutely. It exposes end points which you could send different events to and we could do it without off to not make it super complicated for the demo but it all depends on what story we're going to tell, what that what that compelling use case is and what I suggested I think right when you join the call is that an event comes from somewhere maybe it's related to a photo and that event is then sent into the event gateway which then triggers multiple functions on different fast providers who all do some interesting processing on that photo that kind of tells a chapter of that story and the story examples we laid out are there's a journalist taking a photo in the field or there's a new inventory item added to an e-commerce store. Right. Okay. Now it sounds good to me I was just thinking from a stepwise progression the easiest thing for the initial first step might just be to tell us where that gateway is so we can push events to it and subscribe to it and then we can work on, you know, get that basic flow of being able to push events, receive events and then figure out okay once you receive the event what is each provider going to do with that event to fill out the exact story itself but at least the infrastructure itself is in place. Yep and I can do that it's going to be pretty simple to emulate though it's just going to be a basic request. I think the cloud events will be in the request body so all the fast functions really have to do is expose some type of endpoint and then receive the HTTP request and pull out the cloud event from the event body so you have to write some code at the beginning of their function to do that. Yep. We can start setting that up, you know, right away so they could play with it. I think what's most important is just what that story is and what those functions are doing that's going to be compelling to users. Yeah. So I suggested we pitch this on the Thursday call we say here's what we think we're doing you know, whoever wants to participate can write a FAS function and figure out what they could do to support this story. I think it's going to be a bit over the top initially. You know, if we have several FAS providers involved in this I don't know if it'll be a real realistic use case. Who knows what could happen in the future but it can still be a pretty compelling demo which shows strong interop which I think is our goal and if we are showing developers especially that you could basically take events and react to them on any platform and gain access to anything that those platforms do via this event-driven means I think that would also be pretty compelling for developers as well. Yep, I agree. That would be kind of cool if we could at least show the non-story infrastructure piece working by Thursday too. Hey look, you could send an event to the gateway get it at the other end now we just need to turn out the business logic. Yeah, we could do that and of course we have a lot of integrations already with AWS stuff and I got a chat with them. I got to check in and see how they'd like to be involved but yeah we just have to figure out what that story is from but in the meantime we'll set up a partition version of the event gateway which we could use for the demo. Cool. Yeah, we'll have the I'm going to write that azure function and I'll put that into repo and then everybody can use it and we're probably going to have because I have to think about how to do the registration in an easy way, the push registration thing but I'll have that within the next two days. Clement, are you thinking that that azure function is going to be what's publishing in events or would you actually like to be on the consuming side and can we just send something directly into Event Grid on Microsoft? You can. Event Grid is let me think. Yeah, you can't send into Event Grid just yet. Because Event Grid needs to understand cloud events and it doesn't do that yet but I think us publishing the blob events for now is probably okay but let me think about whether we want to go and also consume something because I mean at a minimum we'll have some function that does something with it I mean we already have a demo that does the thumb nailing piece and I can easily rewrite that one to go and also deal with that cloud event so I think I'm going to have a repo that shows both of those things and then we can see how we can go and compose them. So there's going to be the translator to the cloud event and then there's going to be a version of our thumb nailer that understands cloud events. Yep, okay, great. And I don't want to add to the scope because this is already a lot but this translator or transformer that you're building I do believe that there's potential for a great open source project here which is just a simple library that knows how to transform common events from providers into cloud events. I'm not having something much more easier in mind that is not necessarily generic. Yeah, I hear you. It would be difficult to get this thing out the door before then. I don't want to go and framework it. I'm always tempted to framework these things but in this case I want to put some restraints on myself and not do it. I think that's a smart move. If we can talk about this as the next step. Awesome, one of the things that Dispatch is doing is providing drivers which will translate between events. So consume an event and then translate it into cloud events. Possibly some of the things that we're doing could help there. Right. Okay. For Dispatch would we just send the event into Dispatch and Dispatch can broker it off to various other services? It's really brokering for an internal function right now. I'm sure that we could as a function. That wouldn't be that difficult. Okay. I believe we need to get a couple of story ideas. We have two but we could keep adding them to the agenda doc. This is what we should present on Thursday. And then maybe we vote on something. Not sure how we want to do that, but we should try and pick something ASAP on Thursday. And then from there we should ask who wants to participate. Who wants to write a FAS functions and say the criteria is you have to be able to receive HTTP request, post request and get the cloud event in the event body. And hopefully we can get some participants by Thursday. Yeah. All right, so I updated the for next steps, Clemens to build an event grid function in the next couple of days and publish their repo. Austin, look at a private version of event gateway for people to look into and all need more brainstorming on scenario, user storage, presenter feedback. Austin, I assume when you get the gateway stood up you'll send that a note to us so we know what APIs to call to publish events and we'll send it to you. Thanks for that. Thanks for that. Thank you. Can you send it out so we could maybe start testing that? I'm probably going to need until end of the week, but not sure. Might be able to send it out sooner. But again, it's just going to receive it's just going to receive an HTTP. It's just going to send out an HTTP post request. It's going to be able to mock it pretty easily. What the event is is what we need to figure out and what the event is is going to be dependent on the story that we want to tell, the use case that we want to tell. So that might be the bigger blocker for you right now. Okay. Well, this is going to be a pretty incredible demo if we could pull this off. I'm going to be praying to the demo gods. I should start doing that right now because there are several sacrifices or something. This is ambitious. But I like it. I will say that just looking over the list of people and projects or companies and projects that are supporting this right now, it's a pretty compelling list and I do think we're going to make an impact. Even if we don't get the demo for whatever reason, just by showing off how many people are looking to support this, I think it's going to create a picture of possibility and layouts. Just show people what the future could potentially look like with all these people joining already. I agree. Yeah. Exciting. Okay. That sounds like a plan. Anything else we should discuss regarding this? No. We have to do some brainstorming about that killer use case or that killer story though. Yeah. One thing we can use is your Slack or email as well to be able to put things out there. We don't need a call to have us all talk about it. Yes. If you have an idea, we should just post them in Slack. Okay. If you're all using the new fangle thing, then I will do that too. New fangle thing, yes. You know. Okay. I think that's it. Have a good day. Thank you everyone. Bye.