 So, hello everybody and welcome to our talk, an event handling system for serverless platforms. I'm Jules, not the award-winning Jules, the other Jules, and I'm working for IBM Cloud for almost two and a half years now, and I'm in the Cloud Foundry team. And yeah, what is this talk about? So this talk is a story about bringing two technologies that are considered as two distinct technologies together, which has a positive effect when working with serverless platforms as a developer and it may have positive effects on the costs when working with serverless platforms, depending on the use case. Okay, so we'll first go through the fire exit announcement. Please note the location of the surrounding emergency exit and located the nearest lit exit sign to you. In the event of a fire alarm or other emergency, please calmly exit to the public concourse area. Emergency exits, stairwells leading to the outside of this facility are located along the public concourse. For safety in an emergency, please follow the directions of the public safety staff. Okay, let's come to the agenda. So first, Simon will give you an introduction to platform as a service and function as a service and the motivation behind this project. And I will tell you more about the problem that we're facing here and example how we try to solve it and what we actually implemented and finally give a conclusion. Okay. All right, that's my kickoff. So thank you. So my name is Simon. I'm also working on the Cloud Foundry team. I'm kind of leading the Cloud Foundry efforts inside of IBM to some extent. And the motivation for this talk really, for this work, a body of work was that on the IBM cloud, and I'm pretty sure it's similar for other vendors that are out there. We do have a separate set of technologies that a customer can use and mix and combine in order to accomplish certain use cases. About a year back, we kind of started looking into a scenario where we have, it was originally driven from a pure serverless standpoint. So we wanted to have an application that was constantly emitting events and those events were coming out of the sensor and it was kind of like it was a student implementation to some extent. It wasn't really industrial strength at the time, but the problem that it really surfaced at this stage was that the serverless platforms themselves, they just execute whatever you give to them. There's no filtering. There's no nothing. And of course, that's in the true nature of what a serverless platform does because it is reactive to events. You send it an event and you do something, whereas Cloud Foundry or platform as a services are more for, let's say, long running, always on kind of applications. So I'm guessing that everybody in this room knows this picture, at least I'm hoping when you're here at the Cloud Foundry Summit, I'm not going to talk a lot about it. But basically, the key thing is Cloud Foundry provides support for long running applications and as well as tasks, but in our case, we really focus on long running applications. It has automatic health management and cloud native programming model where you only worry about your code and nothing else and so on and so forth. And the functions as a service, the way how this works is a little bit different. I'm using the model from a project called Apache OpenWisk, which is another open source project, that the IBM Cloud is actually building its serverless offering on top of. So the way how this works is a little bit different than Cloud Foundry. There is this concept of a trigger and then you have a concept of what is called an action, which is basically a thing that will get executed when the trigger gets pulled. So that action can, of course, also be implemented in a variety of programming languages. It could be a Docker image, it could be like a Cloud Foundry application, some kind of a function, that sort of thing. But what happens is whenever the trigger gets killed, the action engine picks up that action and actually starts running it. And that might mean it will provision a container on demand, execute that action as part of that container, the whole nine yards. That has a bunch of side effects, right? So first and foremost, it actually introduces an event-based programming model. An event occurs, something happens, event occurs, something happens, event occurs, something happens. When nothing, no event occurs, nothing happens, which has a cost benefit at the first side at least, right? It has a cost benefit that says, oh, if I'm not getting traffic through the night, I'm not going to pay for my application that's run, or I'm not going to do anything, you know, I don't have to pay for idle times, I don't have to pay for these kind of things. The second advantage that the serverless platforms claims are saying it's inherently scaling. If I have a lot of events coming, it will inherently scale, whereas for example in Cloud Foundry today, you have to build a management function to do that. It's not that you cannot do that, you can, but you have to build a management function that does exactly that, right? Say, okay, I define a threshold, more than 3,000 requests per minute, then give me another instance, like scale it up, it's a management function. For a serverless platform, that's not really needed, because it just happens on demand, yeah, and then, of course, it has some, well, apparent cost effective, a cost effect, because you only charge for what you need, like if you have no traffic on your app, you're not going to pay anything because nothing is running, right? At least that's what it looks like at first sight, right? So then we said, okay, is this really the case, and basically, there is this scenario that is called an event storm, and let me quickly do a show of events, who understands what an event storm is? Well, Andrew, you don't count, anyone else? Okay, so there is a scenario called an event storm, and I'm just going to talk about this. What we are going to show in this talk, it's an artificial example where we try to artificially create an event storm, and then try to bring those systems together in order to see how do they best mix and match, and all the magic that has happened, which is what it's going to do. Okay, thanks, Simon. Okay, so what are event storm scenarios? An event storm scenario appears when a set of IoT devices or any other events source is generating a large number of events in a small period of time. And when you think about how many smart devices we today have, it's usually, it could be the case that such a scenario appears, right? And what's the problem, actually, with an event storm scenario in case of serverless? Well, so today we have the event source, and if an IoT provider, for example, uses serverless, all the events are facing directly on the service platform. And this could potentially lead to a system overload, which slows your system down, the execution time increases, the customer gets charged for that, and so on. So a lot of downsides on that level, on the technical level. And what about all these events that are coming directly to the serverless platform? Are they actually relevant? So in many cases, not in most cases, it depends. They may be just not relevant and can be ignored. They're just noise. So let's just say a simple example. You have a dog and you have a GPS sensor and you want to make sure he doesn't leave a specific area. So you're just interested if, so the GPS sensor is sending all the time events to the service platform and you always check in your function, hey, is the dog still in my area? Yes, don't do nothing. Is it still in my area? Yes, do nothing. Now the dog leaves the area, then you check, does he left the area? Yes. Now you want to inform the customer, maybe, hey, your dog just left the area. And that's actually the only event that you are really interested in. And that's what you need to cover today in your function. And of course for all these unnecessary function invocations, you also get charged to pay for them. And that's what we try to avoid. So what is our example solution? So we want to do a cloud platform based solution. And most of the cloud providers today offer both, they offer platform as a service and a function as a service, but they run next to each other. So what we want to do, we want to combine those platforms to handle those events from scenarios. And on the platform as a service side, we want to have an event handling system which is filtering all the incoming events and stripped them down to an amount of just relevant events that are triggering the serverless platform so the developer at the end can just focus on what he really wants to do in his function. And yes, such a system needs the ability to scale it definitely. And it should be able to filter, de-tuplicate and all that stuff. So that's the target state that we want to reach. Maybe before you go on, Jules, so the event storm itself is something that you can, you know, obviously comes with scale, right? So think about every morning at six o'clock when everybody in America gets up, you would have an IoT device that sends out whenever the light bulb or the, you know, the light gets turned on in all of the houses, right? So this is like all of a sudden you get a lot of events and if you want to process them with a serverless platform, that's just probably too many. And most of them are if you, particularly if you're looking at some kind of an alerting scenario, you're not interested in them. This is not what we used. We actually built a cool car, but Jules is going to do that. Okay, so we had a target state that we want to have and what we did, we started a student cooperation project and we're free students including me. So I did my master's beside my full-time job at IBM and one of the students built that nice car and applied a bunch of sensors at it and like a temperature, a humidity sensor, infrared sensor, gyro sensor, a compressor, pressure control. So a lot of stuff. There was some adenos inside and respiratory pipes, a really cool thing. And yeah, so the motivation for that was actually the automotive and smart cars, connected cars. So that's why we built that. And we had to, we wanted to build a proof of concept. So really an MVP based on a specific scenario. And in that scenario we had this product car which was generating different types of data and it sent that data directly to the IBM cloud and from there we used the IoT service as IoT gateway and we consumed all the incoming events in our event handling system which was based on Cloud Foundry to filter them and strip them down to really just relevant events that are actually triggering the serverless platform. And the serverless platform has functions that give a feedback back to the car. So that overall was like a feedback loop. And we'll come to that later, you will see a demo what we actually did. Okay, so let's take a look at the event handling chain and how it looked like. So we had events, we had the X position, the Y position, the Z position, temperature, the main unit temperature and so on. But we were really just interested in the Y position, so in the gradient of the car. And then we had a filter and applied a filter rule which said, okay, I want to include all Y position events which has value greater or equal to X. And just, and after the filter we had a correlation which said, okay, I want just those events that are hold for a specific period of time, let's say like five seconds. If we have an events with the Y position of equal or greater than X or let's say five seconds, then we will trigger the serverless platform which will compensate the gradient of the car. Okay, so let's take a look of an example. Let's say you have like 100 million events monthly and you apply a filter, you may halve them, so you just have 50 million events monthly. And if you apply the correlation rule, you only have 10 million events monthly. So that would be like 90% saving, yeah, you stripped them down to 90%. And which could be quite a lot in specific scenarios. So let's take a look at numbers. So on the IBM cloud, if you have a standalone serverless platform, you would pay for with a basic rate of 0.00017 cents within, and you have an execution time of let's say an average execution time of one second with 100 million execution, so 100 million events means 100 executions, that would be like $425. And if you now have this event handler, which is a microservice architecture of 10 instances, and let's say each has 512 max of memory, you get charged a per gigabyte hour with 7 cents, that would be like $225, but now you would have only this 10 million executions and that would be just $42 on the serverless platform side. And sum this up, you would be at $268, which would be a saving of let's say 40%, which in specific scenarios like events and scenarios could be quite a lot. Okay, so let's take a look at a demo that we, so at the demo with the prototype car and what we actually did, let's start the video. So we had a UI where we could set up the event correlation chain, and we had the filter and we could say, okay, I want to apply a specific filter rule, so include or exclude something, events based on a threshold, and we also could apply the correlation rule based on the time that we want to have, and then we hit the activate button and we are ready to send data to the IBM cloud. So here the car stopped to move, to change this gradient, and we had the main unit which was sending all these events to the IBM cloud. And in the IBM cloud, we could see the locks in the UI of the specific components, and here we see all the coming events that are sent by the prototype car. And here for example, we have the filter locks. We could see how many events were excluded. Here are the correlated locks, which showed the events that actually triggered the event-based platform. And finally, in the service platform dashboard, which was in this case OpenWISC, we could see also that events that triggered the service platform. So then we had like a small dashboard in our event-based platform, and that red bar shows all incoming events, and the blue bar shows all outgoing events. So it visualizes how many events you actually filtered out. And you can also see the numbers above. So here. So that ran for a few minutes. Let's let it run a little bit. So I actually cut it a little bit. So now you see it went up to 149, let's go a little bit back, there we go, 149 incoming events, and only 10 events actually triggered the event-based platform. And that's more than 90% that was actually filtered out when we run that scenario. And finally, the functions in the service platform compensated the gradient of the car, and that was the feedback loop. Okay. Okay, so how our microservice architecture looked like. So we had, so all these blue color components were actually CF instances that were the instances that we developed ourselves. And we used different technologies like Golang for the back-end and Node.js for the filter and the correlation, and AngularJS for the front-end. And we also used services on Cloud Foundry for the message bus and the IoT gateway, that's actually the yellow ones, and the green one is the serverless platform. And as you can see, that's the 10 components that we needed to implement this system. And yeah, let's go to the conclusion. So first of all, we had a higher cost efficiency, right? In case of events from scenarios or if you know that you produce a lot of noise and you know that you can ignore most of your events. And the second thing is that we have a more efficient handling of events because now we have a specific component that's just there to handle events. Of course, we have a reduced network load on the serverless platforms and improved performance too. And another important thing is that we have a combination of the best-fitting programming models, so that was the thing that the programmer of the functions doesn't have to concentrate anymore on how he handles those events in the function itself. He can just focus on what the function needs to do. And just to add to that very last sentence, because I think really this should be the takeaway message from this session, right? So whenever you get confronted these days, and I mean, I personally do get that a lot, we probably do too, like having something like a pass platform or Cloud Foundry and having something like a serverless offering, in neither case is an either or, right? It is always an and. And it's because a lot of the customers that I talk with, many of the times it's like, oh, should I use serverless or should I use pass for this kind of stuff, right? And the question itself, obviously, is not really smart, but I think this talk or this conclusion really shows that if you pick the right tool for the right job, you can actually combine the strengths and get things moving forward. And I think that's really what the takeaway of this talk should be for those who have not realized that. And hopefully we made it a little bit transparent with the demo. Yeah. So we have like five minutes left. So of course, if you have any questions, this is the time. You mean as like the filtering function as part of the OpenWiz platform, maybe, I mean, this is kind of what it's a natural thinking to have such kind of like an event correlation or event filtering mechanism as part of a serverless platform today to the best of my knowledge. I don't think any of the serverless platforms today have anything like that. I might be wrong, but I don't know. If we would push it back to OpenWiz, it kind of defies the purpose of our talk to so that you can actually combine the two, right? But yeah, I mean, it's a valid request. At this point in time, I'm not 100% sure whether, like, there's no active work going on to push this into OpenWiz, but I'm not ruling this out at all. Of course, I mean, for, this is just the, like, I mean, the attention of this exercise was really to say, can we combine this and what are the things that make sense and combine them both from a technology standpoint, fair, as well as from a, you know, financial economical pricing standpoint. And yeah, of course, coming from Pivotal, if you want to implement, like, you would have probably implemented that correlate or some way of your spring platform. That's a natural and obvious choice. Sure, you can do that. Do the math and see. Yeah, I mean, do the math and see if it works out, if it makes sense and what the right, what the best solution would be. Yeah, it's, I mean, I think it really heavily depends on the signal-to-noise ratio that you would have for the serverless platform. Because you're right, I mean, we cheated a little bit on the math, right, in the sense that we did not count how much investment it takes to actually write that correlation application and, you know, there's a development cost associated with it that if you really do it properly, you should have probably accounted for. So we cheated on that piece, but so no, we don't have, like, we didn't, we just try to exemplify this as a thing, but my gut feel is as soon as you have something like a higher than 50% signal-to-noise ratio, it's probably paying off. But this is not scientific evidence. This is my gut feeling, right? More questions. Okay, then thanks all for attending and enjoy the rest of your Friday afternoon.