 Okay, we are going to get started. Hello everyone, thank you very much for joining us for today's CNCF webinar, Building Edge as a Service. My name is Jerry Fallon and I will be moderating today's webinar. And we would like to welcome our presenter today, Dr. Bin Ni, excuse me, CTO at WangSue Science and Technology and CD Networks. Just a few housekeeping items before we get started. During the webinar you are not able to talk as an attendee. There's a Q&A box at the bottom of your screen. So please feel free to drop your questions in there and we'll get to as many as we can at the end. This is an official webinar of the CNCF and as such is subject to the CNCF Code of Conduct. So please do not add anything to the chat or questions that are in violation of the Code of Conduct. Please be respectful of your fellow participants and presenters. Please also note that the recording and slides will be posted later today to the CNCF webinar page at cncf.io slash webinars. And with that, I will hand it over to Dr. Ni to kick off today's presentation. Okay. Thanks for the introduction of Gary. Hello everyone. And first of all, no matter where you're located in the world, I hope you and your family are staying safe and sound. My name is Bin Ni. I'm in charge of the research and development of CD Networks. From its name, for some of you to guess that we are a CDN company, AKA Content Delivery Networks. So if you're not familiar with CDN, I will give a very brief intro this presentation. But for now, you just need to keep in mind that it has a lot to do with the edge. So although edge computing has been relatively new, it has been in the heart for a few years, but a CDN is a business that has been dealing with it for more than 20 years. And in the last few years, we have been working on a lab. We provide edge computing as a service to application developers in a way similar to cloud computing. Yeah, so we had a lot of thinking we made up during this process. So for example, how to make this platform flexible and powerful in the meantime, not overly complicated and hopefully easy for us to maintain and for the customers, for the users to use. And what changes the application developers need to do on their application to take full advantage of the edge computing platform. So today I'm going to share some of those ideas of us. Okay, so since we are talking about edge computing, we first need to answer this fundamental question. So what is the edge, okay? Because today when you are doing edge computing, you may get a different answer from each of them. So they have definitely different definitions of the edge. So here I listed a few places that someone can deploy their applications listed from the distance to the end user. I think the main benefit when people talk about edge computing is the latency to the end user and also the bandwidth. So here, these five locations, the first one is just the central data center. Okay, so in old days, you just put all your applications in that one data center. Usually no people would call it the edge. Actually, it is the opposite of the edge. So the second one, the cloud data centers, what I mean is the conventional cloud. It's like AWS, sure. So they usually have 10 or 20 data centers all over the world. So if you want your app to have a good coverage of the end users, the developer may probably replicate their application logics in multiple data centers all over the world to try to minimize latency to the end user. And the latency is usually in the order of 100 millisecond. And the third one is CDN data centers. I will show you a picture, give you more idea of how the CDN data centers the distribution looks like. But usually CDN data center usually tries to cover every country usually has at least one or more pops in the most populous countries and all the major data, all the major ISPs on the order of a global CDN company usually has at least 100 pops all over the world. To have a good coverage. And the latency is usually at the order of the 10th of milliseconds. And the fourth one I listed here is a mobile carrier, MEC. They call multiple access center. Mobile, usually it means that you just put your application developer just put application servers very close to the mobile, the cell phone towers. So as you can imagine, there are probably thousands of them in one country. And globally, there can be either millions of them. Of course, it provides a, even reduce the latency of the CDN centers. But the problem is that both the benefit and the problem is that there are just too many of them. And even Verizon today, they only provide this kind of service in a few U.S. So it's because there are so many of them. So it becomes very difficult to manage the huge number of pops. So it will be even very difficult to cover even one country. So maybe this is the start of this technology. So at least now they can only cover a few cities within the U.S. And the last block I listed here is the end user devices. For example, your mobile phone or a security camera in people's house or business. So in a lot of edge computing, in a lot of edge computing, people are calling those devices as the edge. And of course, that is really the edge in some in strict sense. Because that is the end user. The latency will be, you can't beat the latency if you define that to be the edge. So each of those definitions, obviously from left to right, you will get smaller and smaller latency to the end users. But in the meantime, you will have a higher complexity. It becomes more and more difficult to manage. And in the meantime, the resources are lower on the right-hand side. Usually the end user devices will have a very limited computing power and storage compared to servers in data center and the mobile MEC compared to regular data centers. They usually have a limited space and power. So these are the possible locations people can define their edge. And from our point of view, we need to have a very good trade-off and we believe that the CDN data center should be the way to go. And I will, because of the reason I just introduced, we believe this CDN, the distribution of CDN data center provides a very good balance between the latency and what people want from the edge computing and also from the complexity from the manageability point of view. And this page gives you, hopefully can give you some more idea about how the CDN edge look like. So each of this red dot represents a CDN, one or more CDN pops. So after this is the CDN networks, CDN network, edge network. So as I just mentioned, the CDN network is built trying to reach all the most populous areas in the world. And the selection of the pops also depends on the network connectivity of the region and also the population. And you probably noticed that we have a pretty dense distribution in China. It's because the different ISPs in China has pretty poor connectivity. So we had to build a pop in every major cities. So that's why we end up with, I think, around 500, 600 pops in China. And the rest of the world, because BGP can be widely used and connectivity between different ISPs are better. So we don't need that many number of pops, for example, to cover US. And I think most of the CDNs have about 20 to 30 pops to cover the US. And a global CDN company usually at least 100 or 200 pops. And CDN networks, we have about 1000 pops all over the world. And this page hopefully can give you some brief idea about how CDN works. So the goal is to accelerate the content of a website. So on the far right hand side is the origin server set up by the CDN customer or a web developer. They can put their website and their download maybe a web page or some download website for their apps, pictures, images. They just set up a web server for that purpose and put the content on that server. But if it's just one server, it will be very difficult to serve the end users from all over the world. Because usually, even if we put it into a data center with the best connectivity, they will always be a part of the world. That will be difficult to reach that data center. But how CDN can help with the widely distributed Edge network I just showed you in the previous page, the CDN servers can simply on the origin server. And so the content will be replicated to all those servers I just showed you all over the world. So whenever a end user, no matter where they come from, the end user will be directed by our GSLB to the closest edge pop to that user. So the latency will be very small and the user, because the content is cached very close to the end user. So the end user will be able to get the content very, very quickly. The user experience can be improved a lot. Yeah, this GSLB actually, I wanna mention is that this GSLB also plays a very important role in the CDN. And in the Edge computing platform I'm going to describe because although we have a widely distributed network, but if we can't really direct the end user to the closest server, that network is basically useless. So how this GSLB works is that the GSLB is basically a smart DNS system. So the website for CDN, they usually expose their service through a host name. So when the end user's browser or the client trying to reach that website, it needs to go through the DNS revolution process to get the IP address of that host name. So those, we would ask the CDN to update the DNS record. So that DNS record will be C named to an edge host name provided by our GSLB, which is an authoritative DNS platform. So it will based on, so every DNS request will eventually go to our GSLB and the GSLB DNS server would analyze the people's IP address and based on geo-mapping and our own probing result and smartly find the closest edge server that will provide the end user the best possible experience. And in the meantime, in the past, in all the states, the CDN servers only provides the storage, the caching to the end users. But in recent years, the CDN companies are adding more and more functionality to the edge servers. So to expand its capability to do just caching. So for example, a lot of business logics can be implemented in the CDN edge servers. For example, some user access control algorithms can be easily implemented on the CDN edge servers. So the client does not nearly, the origin servers does not have to do all those algorithms. So the pressure on the origin servers can be greatly reduced. And here are some data regarding the performance of the CDN edges. So this data comes from a company called Citrix. They are basically a third-party performance monitor company or the company and the cloud services. Here, I'm showing the median latency of all the major CDN networks in US and Indonesia. China. So as you can see, this column, the latency for CDN networks, for CDNs are usually around 20 in the US. And in the US, you can see that this is a very, the numbers are really tightly packed. So we are located at number 17, but the difference between the number one is very small. It's just three milliseconds. So, yeah, the idea is that it's all around 20 milliseconds. And in China, the number is even smaller. The reasons I mentioned, we have to build, the CDN companies have to build a lot more paths in China. And so because of that, the latency in China is even smaller. It's usually around 12, 13 days a second. By the way, I see that CDN networks is the only major CDN company that doing well in both countries. Oh, yeah. And Quantil is a sister company for CDN networks. So this gives you some idea about the performance of the CDN edge networks. Let's see how we can use it. Yeah, so this page gives you another comparison between the conventional cloud, meaning AWS Azure Google Cloud versus the CDN POPs. The first one is the number of POPs, number of POPs globally. As I mentioned, the conventional cloud usually have 10 or 20 data centers all over the world. And CDN has over at the order of 1,000 POPs. 100 times more than your conventional cloud. However, as a result, the size of the POP is much smaller. The cloud would have easily have millions of CPU cores in each data center. CDN usually a few thousands. So of course, you cannot get both, right? You cannot have 100 times more POPs, but you have the same number of POPs. You have to sacrifice something. And the total bandwidth, the CDN should be also a few orders of 10,000. It's not per POP. It's the collectively combined bandwidth of all the POPs. So CDN is usually at the tens of terabips. So some of our customers can actually fully use more than 10 TBPS, some of their peak time. And cloud, the bandwidth can provide it to each user. It's usually capped at a few hundred GBPS. Yeah, it also depends on the connectivity of the end users. Okay, the latency as I just showed, the CDN latency is around an order of 10 milliseconds. And the cloud is usually around 100 minutes. The single, another thing I want to mention is that I want to emphasize this POP availability. And for conventional cloud, of course, they have to have a very, very high availability for each of their data centers. And there is usually an infinite number of nice. Point nine, nine, nine, nine, nine, nine, nine, nine. But for CDN, since we have a larger number of POPs, as you can imagine, it's very difficult to maintain, to guarantee high availability of each POP. Usually it's around, I will say 95%. And each path can be shut down with any notice at any time, maybe because of a power outage or maybe because of network maintenance or hardware failures. So because we have thousands of paths, it's almost impossible to guarantee the single path availability. But overall, the CDN network can still achieve a very high availability because of the GSLB I just mentioned. Imagine if one path goes down, the GSLB will be able to sense it immediately and stop directing end users to that path and directing those requests to some other nearby paths because we have so many paths all over the world. End user will hardly feel the difference. And the services provided by cloud and CDN is also very different. On cloud, they have a whole lot of services. CDN usually also provides caching. And it can also provide security and also dynamic acceleration. But compared to cloud, it will be very limited. And that is not the goal of CDN. So the CDN has a large number of paths, much smaller latency. And there's no guarantee of the availability of each path. But overall, it can still achieve very high availability. So how can we utilize this existing CDN to provide edge computing service? So there are some basic thoughts we have. So the first one is that the edge computing should not be cloud computing with lots of paths. So as I mentioned in the previous page, the cloud computing, they provide a lot of different services, including database, virtual machine, VMs, containers, all sorts of different services. All sorts of different services you limit. But for edge computing, it's technically impossible for us to make sure each of our paths can provide all those services. So the first one I want to mention is that edge computing should not be cloud computing with lots of paths. They have to be, each path has to be simple and easy to maintain. So the second one is that the high availability should be achieved through GSOD collectively using all the edge paths. So we shouldn't, or the application should not rely on high availability of each path. And the third one is that each path may go down at any time. So this is something that application designer need to keep in mind. And we believe that this shouldn't be a problem at all. So I want to talk a little bit more about the stateless. So what I'm saying here is that the module running on the edge should be stateless. This does not mean that the application, the entire application has to be stateless. We understand that each application will definitely need to save some states about the business. So we are just saying that the application needs to divide into different models. Only the module running on the edge should be stateless. So the state can still be stored on a conventional cloud or even stored in the end-users device. So some people may say that my application, for some reason, my application really need to have state on the edge. So what should we do? So my answer is that that is fine. But you have to be aware of the consequences. So it sounds scary. But what are exactly the consequences? The consequence is basically that because you need to have those persistent data on the edge, that means if that edge goes down, so some of the end-users will be seriously affected. Because those states are not stored on the other edges. So we cannot use a simply redirect that those users requested to another edge to quickly recover the service for those users. So maybe it will take some time to rebuild those states on the edge. So the service resumption won't be seamless. And also another case is that if the user is moved, so if the logic on the edge is stateless, so when the user moved from one region to a different region, now the service can be seamlessly switched from one of our edge pop to another edge pop quickly. But if you have to have state on the edge, that means this kind of a handoff will be very difficult or impossible. This is another trade-off. We suggest that the app developers can divide their application into different modules and run the stateless part on the edge. How to call for the edge? So that's another critical question. So in our implementation, because we believe that Kubernetes has been very widely used nowadays by a lot of application developers, and it's very convenient to manage and to develop. So we decide that we will just leverage Kubernetes. So in our implementation, we are deploying the Kubernetes on every edge pop but managed by a central console. So the customer or the app developers, what they do is they build the pods in their own Kubernetes. They can test in their own environment. When everything is done, they just upload the YAML file on the console. Our system would distribute the pods to every pop, all over the world. And then in time, they should expose the service through a domain name, such that the GSLB will be able to route the end users to the fastest pop for the end users. So this is our view of how an edge service should look like. So this is another picture showing that what we believe how an edge as a service platform should look like. So you can see it's very, very similar to the previous picture of the CDN. So basically, the application should also have a central server, for example, to save the state for data. And also probably also run the stateful part of the logic. And the application should run the stateless part on the edge servers, what we call edge application servers. And between the edge servers would still communicate with a central server, the bandwidth, compared to the edge bandwidth, should be much smaller. It's pretty similar to the CDN case. And the end users would be able to reach the closest edge server through the GSLB. So the client can send or receive a large amount of data between the edge servers. But the edge servers should not define in a way that the application should be designed in a way that the traffic between the edge server and the central server should be minimized. To be minimized in a way such that it's the central data center handle does not need to be very small. If the cloud data center can support 100 gbps, 100 gbps is fine as long as the central data center and the central server can handle it. But here, I usually go above 10-terra bps. So here is what the application should do to take full advantage of any edge computing platform. I have already mentioned most of them. So first, we expect that the application should be modularized. So the high bandwidth and latency sensitive and relatively low computation in a stateless part should be deployed on the edge computing platform. Then high bandwidth, latency sensitive. I will show a few examples later. And the low bandwidth latency, insensitive high computation stateful part should be deployed on the conventional cloud. So edge computing is not supposed to take over the conventional cloud computing. They definitely need to work with each other. And some other parts of the app, for example, the UI and the low computation part and also the stateful part can be stored on the device, such as the mobile phone. And since we have this large number of POPs, and we believe that for different POPs to communicate and discover each other, we can create a central service, some kind of a directory service for each POP to register themselves and discover each other, synchronize data directly. So now I'm trying to show a few applications and also non-applications for ECP. ECP is not supposed to do anything, to do everything. I also want to give some examples of non-application. OK, the first possible very good example is cloud gaming or edge gaming, if we use edge computing. So the module partition can be that the process, for a gaming application, there is a lot of control signals between the console and the server. So those processes, those controls, 3D rendering, basically the UI, 3D rendering and video compression can be deployed on the ECP, the edge computing platform. And each player's programs and those data and those data and also analyze the user's data can be deployed on the conventional cloud. Those are considered the state for data. The volume of high computation requires a lot of storage in the CPU. So those can be deployed on conventional cloud. And those logics are not really sensitive. It does not affect the user's experience. And on the device, we need to do video decompression to display the videos and also send the control signals to the edge servers. So a significant part can be deployed on edge computing, which does not require state. The edge servers can reach the conventional cloud to get the state for data. It does not really need to save it locally. This is mobile gaming. And in the multiplayer case, we only support players in the same geographic region. But it depends. But for most games, especially those latency sensitive games, it does not make sense to support multiple players in very different regions across the Earth. Because the latency is still always determined by the speed of light in our mother nature. If that latency is too high, it does not really make sense. But for edge computing, the pops can easily find the pops close with the players in the nearby geographic regions and still be supported. Another typical example, we believe, is the artificial intelligence intelligence. For example, Google Lens or the Apple Street. And from those applications, you usually just take an image, take a picture, or you record a video. And you send those multimedia files to some cloud server to analyze to run some AI algorithms and then return results. And we believe that this part, this first part, can be a very suitable application for edge computing. And especially if the application is latency sensitive. For example, in the case of Siri, when you say something to your phone, you would expect it to respond to you in a very short time. You don't want to wait for 10 seconds for Siri to answer your question. And that part is AI inferencing. And in most cases, the computation requirement for AI inferencing should be very suitable to be deployed to edge servers. But the AI models need to be continuously updated. So the machine learning algorithm and updating the neural network can still be deployed on central cloud because of the large amount of computing resources. And on the device, of course, we can collect an image, record audio, display the results. It should still be deployed on the end user's device. Another good example should be augmented reality, AR. So in those applications, you shoot a video and you superimpose some 3D models on those videos. So the first part, so receive, the mobile device will take a video and live stream it to the edge server. So the edge server will receive those video and does some AI inferencing and generate and superimpose the 3D object to the video and compress the video, send it back to the device. So that part is, again, requires a lot of data exchange and requires low latency, but the computation is not very high and it's completely stateless. So it's another very good example to be deployed to ECP. Again, the machine learning part updating the neural network can still be done on conventional cloud and taking the video, display the result, it will be done on the end device. So the last one is what I call a non-application. So when people are talking about edge computing, a lot of them are talking about IoT. Here I just want to say that an IoT application does not automatically mean that ECP, the edge computing, should be used. For example, if we need to analyze the real-time data of 1,000 sensors in a factory, because we believe that the edge computing is designed for geographically distributed applications. So if it's just a whole lot of sensors in one factory, it's still geographically concentrated. It does not really benefit from edge computing. So the conventional infrastructure should still be used, the conventional cloud, either in data center or on premises, should be still a better solution for this kind of application. But IoT does not automatically mean ECP. OK, this is the last page I have. And thank you for your attention. I'm ready for some Q&A. Thank you very much, Dr. Ne, for a wonderful presentation. We have about 12 minutes for questions. So if anybody has any questions, please feel free to drop them into the Q&A box. And we will get to as many as we can before the hour ends. OK, we have a question here. What was the reason that China has more POPs compared to other continents? Oh, it's because the ISPs in China, they usually have worse interconnectivity between them. For example, China Mobile and China Telecom, for some reason, they don't want their customers, or they don't want their networks to have very good appearing between them. They only appear at a few designated places. And the bandwidth is usually pretty limited. So if we set up a server, for example, in China Telecom, in general, we cannot use it to serve and use it in China Mobile because the connectivity is very bad. For that reason, we have to set up a POP in each one of those ISPs. And even for some ISPs, across different, the connectivity across different province sometimes is also very bad within the same ISP. I believe that they are doing that on purpose for some commercial reasons. They believe that they are maximizing their benefit. So we have to make sure that we really set up a POP in at least in every province. China has 30 provinces and each province has some provinces that have a few very popular cities. So that means we, so all over the country, we probably need to set up POPs in at least 100 cities. And each city has at least three or four major ISPs. So you multiply 100 by three or four. So that's easily amounts to 300, 400 POPs. But versus in the US, the connectivity between different ISPs are pretty good. BGPs, so a lot of use. And the purine bandwidth is usually pretty decent. So we don't need to set up a POP in each data center. In each ISP, we just need to make sure the POPs are geographically well distributed to cover the populace regions. Usually 20 to 30 is good enough to cover US. Excellent. Do we have any other questions at all? I see another one. OK, it's a comment. And if there's no other questions, I want to talk a little bit more about the cloud versus CDN. And here I listed some of the major differences. And I want to mention that we have a lot of CDN customers who are using AWS, for example, AWS S3 as their origin. And use our CDN to distribute the content they stored on S3. So why they end users to build directly to S3 to fetch the content? I think that's a very good example of the difference between cloud and CDN. Because S3 does not offer the low latency the customer expected. S3 probably is only located in a very small number of data centers, usually probably just one data center. So it's very difficult for us to solve the world to reach to that one S3 data center to get the content and the connectivity from different places of the world to that data center may not be all good. Some areas may even be able to reach that data center. So this is how CDN can be helpful. And even S3 will not be able to support tens of TVVS. But CDN, we easily support that. So we believe that today's application, although most of today's application are deployed on those central cloud services, but when the application evolves, when they have more widely geographically distributed end users, and when the demand for bandwidth and latency increases, the conventional cloud will not be able to meet the requirement of those applications. So those applications will definitely have to move to the edge. It should benefit a lot from moving to the edge to support those bandwidth and the latency requirements. But to be honest, but today, I don't think any application would really require 10 GBPS of total bandwidth. So probably that's the reason that we don't see really a boom of edge computing. We believe, eventually, that they would come. And so today, I think it's more like a chicken egg problem. Because app developers, they probably don't know that there's such a platform that can support tens of TVVS of total bandwidth. So no one probably would even think about to design an app that requires that much bandwidth. Basically, their imagination is limited by the capability of the conventional cloud. So I think that's why we want to share our ideas through this platform. To let more people know that more app developers know that such kind of a platform actually exists. So we believe that once this message is out, more developers would be more brave, would be brave enough to design more apps that can take advantage of the large bandwidth and a small latency provided by the edge networks. We have another question here. 10 BPS is shared among all users. Perhaps per user can still be limited. What could be a reasonable bandwidth for a developer to target? 10 BPS, if you feel 10 BPS is not big enough, I would say that. Because first of all, not all users will connect it to a server. We'll use the service simultaneous. So actually, 10 BPS is probably the maximum collective bandwidth we have seen in our CDN business. And in that application, they also have millions of users downloading at the same time. And the bandwidth of each connection mostly still depends on the connectivity of the end user. But based on our measurement, it can easily reach more than 10 meg BPS. Do we have anyone else with a question? And anyone at all? We're not having any other questions. Dr. Ni, since we don't have any questions coming in, Dr. Ni, do you have any closing words for today's webinar? As I said, I hope that people can help to pass this message to more developers so we can, as a community, we can make this Edge Access Service a reality. More and more people will be aware of it and take advantage of it so we can build more powerful apps to serve the end users. Excellent. Well said. Well, that just about does it for today's CNCF webinar. I would like to thank Dr. Ben Ni for a wonderful presentation and for taking time out of his day to join us. I'd like to thank all the attendees for taking time out of their day as well for attending today's webinar. Everyone take care and stay safe. And we will see you at the next CNCF webinar.