 I hate to disappoint you, but I'm not Frank, and I'm not a distinguished engineer, but I do work at Cisco, and apologies, Frank couldn't be here, he had the bug and couldn't get on the plane from Germany, so I stepped in. I'm Chris Flotner, and I'm actually in the edge group on the business side doing the product definition, but working on some of the products that actually are described here. So let's see if I can do justice to Frank's talk. If not, please don't boo, but feel free to ask questions, by the way. So if you've been in the industry for a while, you know that there's always a pendulum, sometimes people are talking about centralized computing, sometimes decentralized computing, sometimes the client is in the focus, sometimes it's the server, and this pendulum kind of goes back and forth every 10, 15 years, and there's a new kind of norm in the industry. Now, we think that this is actually happening now as well, at least a little bit. There's still a lot of momentum towards the cloud, but there are some users that are now swinging back towards the edge to solve certain problems that they think the edge is actually more suited for. We'll get into that, what type of problems these might be. But what's different here is that's not a paradigm switch, in a sense that people are expecting a lot of the goodness that they've gotten used to from cloud computing, but they now expect a very similar paradigm to actually exist for edge compute as well. And what are the reasons for this? Some are related to just costs, how much does it cost to actually move something to the cloud and move it back, and that's an issue in certain applications. Real-time performance, regulation, these are all kind of driving a migration towards the edge, but I would add one more to this, and in general, which is just about robustness. How do you actually come up with complex distributed applications that are actually robust and run partially at the edge, partially at the cloud, but delivering the right kind of user experience? So, the challenge now is not to actually completely detach from the cloud and come up with a new paradigm and kind of go back to the good old days of desktop computing, but rather take a lot of the learnings from the cloud and apply it at the edge and make distributed resources easy to use. The, I guess the key metrics for that are, can you make it easy? Can you hide the complexity that's actually inherent in the edge deployments? Can you do that quickly without having to set up a lot of the resources? Can you automate a lot of these processes? And can you make it very familiar to all those developers that have used to the convenience of the cloud and the tooling that actually they used day to day? But before we can get into that, we have to talk about which edge we're actually talking about. And if you go to edge talks, often it can be quite confusing. Some people mean data centers at the edge, other people mean tiny devices at the edge, but thankfully the Linux Foundation actually defined some of these in a easy to access image like this one. And they kind of approach it the following way. There are a set of edge technologies that are driven from the cloud out that are really trying to replicate cloud-like functionality edge devices. And then there are another set of technologies that are from edge in. They start with the end nodes and then push towards functionality that those end nodes benefit from at the edge. What we are interested in is primarily defined as a smart device edge. So it's and perhaps and the small side of the on-prem data center side. Very much an appliance view of the world as opposed to a general data center view of the world. So what is that transition about? So we used to having simple devices at the edge that are that could run maybe one application or two and now actually it was a single device, but actually what we see is a need for actual multiple devices that provides some level of redundancy, some level of scalability at the edge nodes. The, if you look at a lot of the existing edge deployments especially if you kind of go back to the IoT space you see a lot of custom solutions that are organized around verticals. I think what's actually happening in this new edge is that those are becoming much more horizontal. You don't have to think in terms of silos in terms of vertical solutions, but there's some degree of commonality between these solutions that can be factored out to enable scalability at the edge. And what we have to do is to move from a manual deployment model to automated as a service deployment model. And when I say manual, historically some of this stuff has been incredibly manual and done by people that were not computer scientists but they were actually in a construction engineers or building a lamppost and things like that and they were expected to do some level of manual configuration. Now you can kind of figure out what went wrong with a lot of those projects. But in this world what we'd like to do is to move to a completely automated system that can actually be done remotely but with the help of people that actually are at the edge. So a deployment scenario is on this picture quite simple really. You have a set of end nodes, sensors and actuators that communicate to one or more devices at the edge which then actually communicate with some backend in the cloud. What makes this use case complicated is not that part of it but the fact that you actually now have to multiply that in times and you want to actually make that work, want to manage them centrally and want to have a consistent user experience. So we call that edge native to play in words with cloud native. With the expectation you can take a lot of the technologies that you love on the cloud side and actually apply it to the edge compute model. And what does that look like? If you go back about a decade I think Heroku had these principles of how you ought to be building stuff if you want to make them robust. And it's a pretty good set of rules. Sorry there are 12 factors not 11. I can't remember which one I forgot but there's a pretty good set of rules that people have been following ever since. And I think most of these actually apply at the edge today with small twists on them and ones that I would highlight are the following. So at the edge you still care about dependencies and policies but some of those policies might be local to the site at the edge. So some of the policies might be centralized some of them might actually be bespoke based on where the application is running. The backing services that are coupled to the main service now could be remote because not everything that you do at the edge has to be at the edge. It's fine to actually rely on some services and storage in the cloud side, et cetera. Now concurrency is the bit that gets more complicated because we're used to kind of scaling things up by the processes or the containers and things like that. But here you actually have to scale the sites and that's a very large lever that you have if you go after large deployments. Now disposability is another key because if you're managing lots and lots of sites suddenly you can't afford to care about all of them all the time. So you should think about them as disposal of resources that can be brought up torn down, be started at will, and hopefully without much complication. Another area I would highlight is actually logs. So when they wrote this decade ago logging was the thing. I think if you're doing things at scale you suddenly have to start moving towards metrics because otherwise you just get lost in the noise of all the data that these computers are generating for you. So let's dig into these a little bit more. So if you look at the concurrency on the scale side the picture on the left just shows you the scaling if you're actually scaling processes you wanna run more of them, you scale up. And essentially the edge computing paradigm gives you another dimension of scaling which is the number of sites you have. You can also complicate this even further if you now actually have cross site redundancy and priorities and things like that. But even a simple approach just gives you another access that you have to manage and think about. So sites that I refer to are just an abstract notion of location and it's a collection of compute nodes that in a certain location. Now Frank actually points out that they don't have to be. It can be any collection. You can organize these sites in any logical way that you'd like but often it's a very useful thing to aggregate them based on where they are actually located. And the other key here is that these are multi-purpose nodes so the expectation is that they don't just run a single application dedicated to a single use case but these things can run whatever you'd like and you can change your mind about it later. So on the disposability point this is really driven by the user experience that we want to enable. Now one of the property of these sites is that it's very likely that there's no IT person there. There's no DevOps persons actually maintain these sites and the debugging process will be very much like we were used to on Windows and control all deleted when it doesn't work. Here somebody's gonna push the switch and the site needs to come back up if there was a failure and it better actually work right out of the box. That means that there's no debugging, very little involvement from somebody that's actually knowledgeable about the operation of that particular site. You just need to make it work and recover from failure and actually connect back if you wanna succeed at managing these things at scale. I think I've already mentioned the backing services in the Heruka model on the left. Those are attached to the deployments directly. In the model that we think works for the edge some of the obviously some of these backing services may not actually be at the edge so that you have to kind of worry about connections to them. That's okay it just gives you a little extra work to actually make sure that those connections can work as well. Now to enable this type of operations things have to be declarative and have to start from the edge in reaching to the cloud. The if you actually have another operation model which is pushing things out from the cloud side you often will run into problems when you have to deal with complicated network topologies and or misconfigurations. So the way in our view this actually works is that you kind of have to make it work in the common case, multiple NAT transitions and multiple screw ups along the way and try to make it robust. I've mentioned logs already and this is actually an interesting area of research. What do you do with the information that's contained in these logs? Now a lot of people just like to dump them somewhere and in case they need it and then analyze it. Now if you have a hundred sites and a hundred sites times five machines distributed over relatively slow links this aggregation becomes a hard problem and it may take forever to actually look at these logs. So what we think you need there is actually much better observability metrics that are actually smart about what information they communicate back to the cloud. And the transition to metrics is one thing but also what you'd like to do is not to treat each metric equally but really focus on the important ones. When something goes wrong, when something changes when something is out of the ordinary. This is actually an area that I think requires some innovation at the edge because it's a quite different model than what we're used to in the other side of the connection. So actionable information is gold and the question is how do you turn raw data into actionable information? The picture on the right is actually from a paper that Frank and his co-authors wrote that actually tries to do that. They're doing clustering algorithms on very highly dimensional data that they get out of metrics and they were trying to figure out actually when they should look. Is the machine working okay or is there some sort of a problem with it? And they found that actually it's possible to do this by doing some fairly sophisticated statistical analysis on it. If you're interested in this stuff there are two papers that actually describe this. I think this is actually the future of how we will be doing monitoring of these edge devices. Much more automation, much less communication overhead. So what does this look like from deployment and operations perspective? And if we, I mean, I probably don't have to explain it to you guys but Kubernetes kind of looks like this. There's a control plane, there's a bunch of workers, there's their cattle and interestingly these are chicken but they're pets that you really love and care about which is your cluster and then there are nodes in it that actually do the work which are your chicken. And this is kind of the model that we're advocating for the edge as well except doing it one layer above this. Now your sites are the chicken because they can go down, disappear, get rebooted and they should come back up and then there's a control panel that's actually for all of your sites together that has to exist and work so that when these sites come back up they know actually what to do. So the chicken or cattle can feel any time but obviously your collection of sites shouldn't. So I already mentioned that this should be based on some sort of a pool model there's a defined state that the site should get into and when they actually come up they should pull the information that relates to them. So it's very much a declarative model that we are advocating and driven by the edge as opposed to, edge in as opposed to from the cloud out. So here's a deployment example of the system we're building and again here's this blue guy that wants to roll out a new site and deploy an app. So that's the example I walk you through. So what are the three things that are in this demo? There are apps, there are the applications that are deployed to the sites. As I mentioned there are sites, I just groups of nodes usually geographically grouped and the app nodes in this case are small computers and you'll see it's just a Raspberry Pi. Oh, there it is. And that is indeed Frank's hand. So that's it. And the point of this is we actually, the prototype we have actually runs on much bigger computers and we're aiming at a lot of interesting machine learning workloads with this system but it can work on whatever we've got. So I'll show you how you define a new site, how you can add an app node and associate it with the site and then deploy the app on top. So let's see, okay started. So that's the user interface for GradeBear which is an edge management platform that we're building. And here you can see a few sites that have already been defined in Europe. So there one is Switzerland, France, UK and there's nothing in Cologne and Cologne is where Frank actually lives. So he's gonna show you how you can add a site right here and I think he's giving his home address here so please don't swat him. Or okay, no it's not his home address, it's somebody else's address. And then he's defined that site and then the next step along the way, and if I could actually see the screen, yeah there it is. You can add the Raspberry Pi and all you have to do is add the serial number and through all of this, through the software infrastructure, associate it with that site and it will get boost-strapped into the GradeBear edge cloud. So you can see that now it's actually scheduling and it's finally been assimilated. It's part of the Borg now. And then the next step will be to actually deploy an application on top. So there it is. We have a few applications already in this system that we've developed but obviously you can add in many more. And the example that we're gonna show you next is actually around event-driven displays, EDDs. So the application deployment itself is really quite simple. You just have to add in the required information about the secrets, you turn on some configurations and after that it'll be all okay. And you can see in this example, these are displays. So what he's doing there is turning on the VNC displays so that these edge devices can actually display something on a monitor connected to them. So quite straightforward. If you look at solutions today for that same type of problem, you will see a lot of bespoke, expensive and bespoke appliances that you can only use for that purpose. What we're showing here is a much more general purpose approach that you can actually then do, I should restart it, I don't understand. Yeah, general purpose approach to actually the same problem where you might have multiple applications, you might wanna change your mind what you use those devices for and in fact you might change your mind about which application you actually wanna run. So event-driven display will render some content and I just walk you through an example of actually how that works with Great Bear. You can use this for digital signage, video surveillance, just posting stock tickers, whatever you'd like. And, oops, sorry. And it works like this. So you actually, once you have your site set up, why is this so small? Sorry guys, my eyes are going and I find it quite difficult to actually see the size of this. Let me make it bigger, there it is, okay. So you see all the sites that have actually been defined in Great Bear. By the way, this can be done for every tenant separately. So in this SASS, you get to pick your own sites. You can share them with others. And in this case, it shows five sites across Europe. And the use case here is really quite simple. There are a number of displays connected to these Great Bear devices and we're gonna show www.cisco.com on the displays connected to them. And you get full control about what you show on each of them. Here we're gonna show the same webpage, but you can show whatever you'd like. And this is how you do it. So on the right are three sites, Budapest, Raleigh, and Cologne. Now you'll see a computer that was actually used during the demo and again, Frank's hand on the right, driving it, and what we're gonna do is actually deploy the application. So you get to choose where you wanna deploy, specify the content on the applications. In this case, the application was already launched. Now it just says send this new URL to them and you'll see very quickly that they start updating. The top two machines are actually beefier machines. It takes the Raspberry Pi a little bit longer to actually get the updates, but they're all in sync. They're all decoupled from each other and we managed to actually launch a simple application. Now, obviously this is not all what you can do with Great Bear, but the whole point here is that this is the kind of the foundational infrastructure part of something that you can use to build a large scalable and robust system. And it ties together a lot of underlying technologies built on Kubernetes that should deliver this and it has the operating model that was designed for robustness and scale at the edge. So we've shown you how we can actually deploy things very quickly. There are a couple of other points I wanted to make here about how easy it is to do this and how it's actually familiar with the cloud-related tools if you actually wanna use this system. And I guess the first point is how do you get some apps in? And some example of these apps that we run on these are related, we are actually very much interested in a lot of machine learning workloads so there's an edge AI component to this. But when you're actually moving something to the edge, you might have to massage the application itself. It might be too beefy to fit on the device that you have available at the edge. So in this case, you might actually have to shrink down those models or you might have to do federated learning because actually near the edge where you're trying to do some learning, people don't give you direct access to the data. Sorry, they give you direct access to the data at the edge, but they don't want you to actually take the data elsewhere so you deploy federated learning on it. To actually enable that, you need to manage the data flow between the application and then the local, the data sources. And sometimes you have to do, as I showed you earlier, some of the rendering in IO, take care of it just like you would on a PC. So here's an example of something you can do with edge AI. So you have an AI model which you'd like to deploy at the sites at the edge and you have a problem because you have two new models, one is a bit too large for the edge device and the other one doesn't run fast enough. And those are two things that can easily happen if you have edge devices. Unlike on the cloud side, you can't just specify a beefier instance. To have a beefier instance at the edge requires somebody to go out there, get a new board, plug it in, set it up. So here you actually have to adapt your application to the needs of the edge as opposed to the other way around. So why do you care about frame rates? In a lot of inferencing algorithms, it actually matters, it impacts the quality of the inference itself. In an example that we had, for example, depending on the, sometimes the inferencing engine would see five people, sometimes if you actually increase the frame rate, it would see six because it has more granularity on the images and it can actually pick up the six person that was obstructed earlier on. So what do you do if you're constrained by the resources available at the edge? There are a number of things you can do. You can actually apply hardware acceleration. Now, if you have that specialized hardware, you still have to figure out how to use it from software. So that's always a tricky thing. You could code design, but it's an option that you can do. The other thing you can do is model compression. You take a model and then you try to get the most optimal representation for the given device. There are a lot of tricks in the toolbox to actually do this and there are systems that help you achieve this and or you can use your own flow to actually massage the models in place. The point is you have to have some amount of knowledge to be able to do this. Or you might try to actually split a model across multiple edge devices. Now, all of these are things that you probably should do or must do depending on your application constraints. And the, how you actually do it is that there are a number of papers actually we've written but they're also in the research community that can actually tell you how to do this. You have to find kind of a part of this network that's easily cuttable and at the same time doesn't have bandwidth requirements that overwhelm the edge system. But that can be done by heuristics. You won't get a perfect, you're most likely won't get the most optimal setup but you will get something that allows you to actually cover the envelope and use the resources that you have available at the edge. So, again, the edge is similar to the cloud but it has different constraints and it requires different tooling to actually make the most of it. Now, one example of this is just the AI at actually getting a model to work there which you can do with some AI magic and running through the workflows. And as a result, you might take something that actually initially was around one frames per second and with some work, you can actually increase it to 2.4. Now, this is just an example of what you can do but this is kind of a factor of two to three improvements and a model inference is often possible with these tools. If you need a factor of 10, you probably should actually pick a different model to start with. So, you have to design for the edge in some degree but you get to leverage a lot of the tools that everybody else would be using on the cloud side as well. So, by splitting and distributing the model, we can actually maintain a given frame rate at the application layer and that can be good enough to get started even if it's using multiple machines but you need a toolkit of these ideas to actually leverage the edge. So, what about model training? I already mentioned federated learning as an interesting use case for ML at the edge and that comes from the simple recognition that a lot of people don't really want to give you access to the data that they have but they might give you access to an AI algorithm and they don't want you to take the data home but you can run the learning locally and actually extract some learnings from it. So, federated learning is a technique to achieve this and it kind of works like this. You have private data in three customer locations but you'd like to have a global model based on all the customers. So, you're trying to train a single model globally but we don't have global access to the data, you just have local access to the data. And the way this works is that you actually train three different models. These preserve privacy and then there's a methodology to aggregate it back to the global model on top. There's actually a project we've created open source called Flame that actually does this. This can be done very in, so you can do this today. There's a lot of interest in privacy sensitive areas for example in healthcare where people are trying to apply these techniques to extract information. So, federated learning actually kind of fits the principles of the edge native model. You pull the global model, you push the model updates and you keep the data private and local at each location. So, the summary is this. Edge native enables a cloud like experience at the edge and it enables a transition hopefully a smooth one as the pendulum swings back towards the edge from the cloud. The main trend that we see is that people have solved this with point solutions in, solutions aimed at different verticals but the edge native actually allows people to kind of combine these into a platform and have a horizontal solutions that can actually work across verticals so they can use one solution to address all of them. And this is the end. By the way, if you're interested in this, there's a blog post that you can read and I believe the QR code can lead you there for more information on edge native. Thank you very much. I'm not sure if we have any time for questions or are we done? Do we have any more time or is this the end? Okay, well we have two minutes. So, if you have any questions just ask me by the seat. Thank you.