WEBVTT 00:00.000 --> 00:13.680 Okay. Hello. My name is Modelliniag. I'm product manager for the 5GNH at OpenEblast Systems. 00:13.680 --> 00:20.240 And today I would like to present to you a few skates related to the highly distributed cloud architecture 00:20.240 --> 00:28.560 for Telco and VD deployments. I split my presentation in three parts. Firstly, yeah, representing 00:28.560 --> 00:35.600 OpenEblast Systems and talking about OpenEblah. I need to introduce these notions to you. 00:35.600 --> 00:43.840 After that, I would like to enter more in that related to these use cases. And in the end, 00:43.840 --> 00:55.120 I will present a very easy example on how we manage to test these use cases. Firstly, 00:55.200 --> 01:01.760 OpenEblah is the product. OpenEblah Systems is the company. OpenEblah Systems has developed and 01:01.760 --> 01:08.720 supported OpenEblah since 2010 and is a European open source technology vendor. Headquartered in Madrid, 01:08.720 --> 01:15.360 but also having offices in Brussels, Bruno and USA. And yeah, we are a widely spread team across 01:16.000 --> 01:24.800 Europe, US and Central America. This is a success story that has emerged from new innovation programs 01:24.880 --> 01:31.200 arriving nowadays to be the leader in several innovation projects like cognitive cloud or advanced 01:31.200 --> 01:36.960 5G, playing the key role in access forums here say and sharing the U cloud alliance and EPSIC's 01:36.960 --> 01:42.400 industry facilitation group. We are also members of Linux Foundation, cloud native computing 01:42.400 --> 01:50.320 foundation, Linux foundation edge and silver. That is about the company, now related to the product. 01:51.280 --> 01:57.920 We are handling the virtualization layer, offering a simple and simple solution and a light profile 01:58.960 --> 02:04.320 ensuring an extensible architecture and supporting multi-tenancy and multi-VM's. And art so 02:04.320 --> 02:10.160 is DevOps friendly. It supports virtual machines, system containers, and on top of virtual machines 02:10.160 --> 02:16.880 Kubernetes clusters. Talking about Kubernetes, we have our own distribution called one key 02:17.520 --> 02:24.080 and insights that distribution we have different add-ons. All those in order to support cloud 02:24.080 --> 02:31.760 edge continuum applications. We have multiple advantages trying to combine simplicity and agility 02:31.760 --> 02:38.720 of public cloud together with the performance and security of the private cloud. We try to bring 02:38.720 --> 02:45.360 the real freedom to your enterprise cloud, letting you to control as you wish your cloud, 02:45.680 --> 02:53.280 having customer approach to security privacy and management. We give the freedom to choose 02:54.160 --> 02:58.800 the infrastructure, offering a parallel choice of infrastructure and cloud providers, 02:58.800 --> 03:05.920 but also the freedom to change, avoiding vendor location. We support any kind of application. 03:07.440 --> 03:11.200 We measure Kubernetes and virtual machines. We deploy manage and provision those, 03:11.280 --> 03:15.840 any type of infrastructure across cloud edge continuum and any type of cloud. 03:16.880 --> 03:25.120 Saying those, let's get closer a little bit to our use cases. One H5G is a Spanish project 03:25.120 --> 03:32.080 that brought us in the telco and 5G world. And from this project, we were able to shape 03:32.080 --> 03:38.480 better our priorities, bringing intelligence and automation for the operation of distributed edge 03:38.480 --> 03:45.120 systems and beyond 5G infrastructures. We started focusing on 5G, but nowadays of course 5G 03:45.120 --> 03:51.600 being deployed, we have to shift our focus to beyond 5G or 6G how it's called. We need to satisfy 03:51.600 --> 03:56.640 the demand for opening European technology for beyond 5G telco cloud. We need to integrate the 03:56.640 --> 04:01.920 functionality of beyond 5G to improve the cloud continuum and to expand it, making use of open 04:01.920 --> 04:11.920 solutions to manage a moment of private and widely spread beyond 5G networks. As said, we need to 04:11.920 --> 04:17.760 expand the cloud edge continuum to new beyond 5G infrastructures and to facilitate the distributed 04:17.760 --> 04:23.280 management of cloud edge continuum for business and users. All those in order to create an 04:23.280 --> 04:28.640 ecosystem of research and innovation of advanced beyond 5G networks for next generation cloud edge. 04:29.200 --> 04:39.360 Talking about top priorities, as I said, we started as or we are the result as multiple European 04:40.160 --> 04:49.040 projects and we continue to support European Commission in all its ideas and diverse or initiatives. 04:49.040 --> 04:57.120 One of them is to enable the European Union started to have 10,000 climate neutral 04:58.080 --> 05:05.280 highly secure edge nodes. Here we are to what means highly distributed telco networks. 05:06.800 --> 05:12.800 If you look in the digital decade policy program for 2030, you will find this picture going from 05:12.800 --> 05:19.920 own device to cloud that can go thousands of kilometers away from devices and yeah, sovereign 05:19.920 --> 05:30.080 edge initiative will try to put all the European in-house initiatives in this big idea of 05:30.080 --> 05:39.840 European Union and to try to bring the cloud in a huge house cloud to this idea. 05:40.560 --> 05:47.040 Open Nebula Systems is committed to support this through multi-country large scale projects dedicated 05:47.040 --> 05:53.680 to data infrastructure, 5G communications, high-performance computing, AI farms, public administration, 05:53.680 --> 06:00.560 digital innovation hubs and to ensure that 75% of cloud update by EU enterprises in 2030. 06:01.600 --> 06:06.400 Also, we try to support the European SMEs willing to explore innovative business models. 06:08.320 --> 06:14.800 Another example of what means highly distributed cloud architecture is when operators are having 06:15.200 --> 06:25.680 very distributed network beyond the borders of a country or when new business solutions are appearing on 06:25.680 --> 06:33.600 the market, offering services across multiple countries or even multiple continental continents. 06:37.840 --> 06:44.000 Pricewaterhouse cooperates defined last year. This kind of new business models highlighted 06:44.000 --> 06:52.000 in the right table and what happens when we have a company that is solution co-platform co and 06:52.000 --> 06:57.600 net co developing solutions and products for business customers as convention services, 06:58.240 --> 07:02.400 bringing orchestrating and brokering services among multiple network companies and 07:02.400 --> 07:09.600 wholesale buyers or owning and operating fixed or mobile network that sell access and capacity 07:09.600 --> 07:17.440 to telecom as multi-asset world seller. The things are getting much more complicated to support 07:17.440 --> 07:23.520 those and we need to deal with long-fat networks that are having very high latencies and 07:25.440 --> 07:33.360 small throughput. Besides that, the target architecture should support new and very complex 07:34.320 --> 07:40.800 VM-based workloads such as firewalls, load balancers, routers and other non-generic compute services. 07:43.760 --> 07:47.200 In order to support this kind of initiative, so this kind of business models, 07:48.080 --> 07:54.160 we've in openable assistance, we try to adapt openable or with or better said, we try to map 07:54.160 --> 08:00.960 openable out to different initiatives. First of them talking about visualization is of course 08:00.960 --> 08:08.960 it's in a VMAM. I'm using here I think a release three picture and but the purpose is to say 08:08.960 --> 08:16.240 that openable is a VM in this context. Being robust and flexible, being designed for heterogeneous 08:16.240 --> 08:24.800 infrastructure, managing the software images, the virtualization resources, the performance, 08:25.360 --> 08:32.160 the NAV acceleration capabilities, but also ensuring the orchestration of usage and provisioning 08:32.160 --> 08:39.440 of the virtual infrastructure. Having a northbound interface towards VMFM and NVVU, but also a 08:39.440 --> 08:48.240 southbound interface to the NAVIs elements. In the same time, or in this context, as I highlighted before, 08:49.040 --> 08:53.280 it's not enough only to talk about virtual infrastructure manager, but also run infrastructure 08:53.440 --> 09:01.920 manager, which is a VM a little bit more particular. A second initiative to which openable 09:01.920 --> 09:10.640 a tries to map itself is infrastructure and service, openable assistance being a general sponsor 09:10.640 --> 09:16.400 of Linux Foundation in Europe City. Through that we are trying to ensure unified infrastructure 09:16.400 --> 09:21.040 as service layer, supporting a deployment of 5G networks over cloud edge continuum, 09:22.080 --> 09:27.600 and to that to easily and efficiently scale the networking computing capacity servers and 09:27.600 --> 09:32.960 or storage resources to their cloud tailored for every specific use case. We want to bridge the cloud 09:32.960 --> 09:37.520 edge continuum to the containers and service platform and in the same time to deliver the optimal 09:37.520 --> 09:44.400 performance for the services built on top. I mentioned before that we have one key distribution 09:44.400 --> 09:51.600 as well, that can act as a container as a service, but that will be led for a later phase. 09:51.600 --> 09:56.960 Anyhow, I just want to mention that is offered by ourselves to telecom actors benefiting from 09:56.960 --> 10:07.520 the control and orchestration down via a cap. Another flavor that open-nebula can fulfill in this context 10:07.520 --> 10:13.600 is the facilitator of the revitalization. Last year, Gardner brought to everyone's attention 10:13.600 --> 10:19.120 to the concept of revitalization, practically being a virtual to virtual migration. 10:20.240 --> 10:28.960 And of course, that means that arises from the idea to address a viability or commercial risk. 10:29.680 --> 10:34.160 It's a concept at its peak, being applicable to 5% to 20% of the companies. 10:34.880 --> 10:43.040 This has been on the market since more than 10 years, but now it's as its peak, as I said. 10:43.120 --> 10:49.200 And open-nebula systems supports this. And in the same time, tries to avoid 10:49.200 --> 10:54.240 devirtualization. That's a very big risk for the virtualization in this moment. 10:55.200 --> 11:02.720 And open-nebula has a very particular approach mapped on the advantages that open-nebula can offer 11:03.440 --> 11:11.520 what also on the projects where it participates. It offers a unified management for a single control 11:11.520 --> 11:17.600 pain. It ensures an easing migration from VMware, including dedicated feature and workflows. 11:17.600 --> 11:22.720 So we have developed that. We have developed those specifically for this use case. 11:22.720 --> 11:27.120 We try to enhance the security using open source solution for both VMs and containers. 11:27.840 --> 11:35.120 We ensure the scalability, helping to adapt VM container workloads to meet dynamic network demands, 11:35.120 --> 11:39.120 but also ensure the coexistence and seamless integration with other platforms. 11:39.120 --> 11:46.240 Because, of course, migrating from one virtualization platform to another cannot be done like that. 11:46.240 --> 11:49.360 In its time, so the coexistence is much needed. 11:51.600 --> 11:53.840 Coming back to this kind of example. 11:54.880 --> 11:58.720 Of course, we have to simulate that once we enter in this kind of project, 11:59.280 --> 12:04.240 the things will go smoothly. And for that, we perform an exercise with our partner 12:04.880 --> 12:12.080 and we try to simulate the long-fat networks. I mentioned them before and I would like to come back 12:12.080 --> 12:19.040 to them as I said. We have latencies that are over 200 milliseconds and the throughput is limited 12:19.040 --> 12:26.480 even to 100 megabits per second. Moreover, our partner said, we don't care about the infrastructure. 12:26.480 --> 12:31.040 We don't want to focus on that. That's your job. We want to focus on the functionality of the VMFs 12:31.040 --> 12:37.680 and those have to work without interruption. We want to avoid putting too much effort into 12:37.680 --> 12:46.480 underlying layer. And on top of that, we need to ensure that the coexistence of VM and containers 12:46.480 --> 12:56.640 can work. The points of presence that our partner had were resource constraint and more 12:56.640 --> 13:02.880 over they wanted multi-tenacity. So we entered in a very long exercise with them and that's still 13:02.880 --> 13:10.080 continuous. Ensuring that we have different types of points of presence, here I'm highlighting 13:10.080 --> 13:17.760 only two of them, a central one and a remote one, gathering storage networking, management, playing 13:17.760 --> 13:26.000 APIs, webgoos and, of course, open-nabla.net manages everything. And open-nabla is there to ensure that 13:26.080 --> 13:32.640 the migration of the VMs from one virtualization platform to another can be fulfilled. But also helps 13:33.520 --> 13:41.120 our partner to grow its basis or to why it's network in other locations as well. 13:43.120 --> 13:48.160 And yes, the tests were oriented towards virtual infrastructure manager because that was the language 13:48.240 --> 13:56.720 that our partner speaks. And we had to have a tailored test scenarios to showcase open-nabla's 13:56.720 --> 14:03.680 advantages. We started, of course, with VM-based features like host aggregation, back-apply recovery, 14:03.680 --> 14:11.200 long-fat network support, authentication, access control mechanism. The second step consisted 14:11.200 --> 14:17.760 into validating the VM-advanced features like tenant management, multi-image data store exposure, 14:18.560 --> 14:24.960 automatic, and manual host placement, manual installation of VM movement and relocation 14:24.960 --> 14:32.240 infrastructure usage and conception. And in the end, we showcased also the networking and enhanced 14:32.240 --> 14:38.720 platform awareness features like, obviously as the PDK SRI or the PCAPT in Numa awareness, 14:38.800 --> 14:44.320 your based Numa scheduling and Numa higher affinity, huge pages and CPU trading policies. 14:45.200 --> 14:49.920 All those to ensure that automatic and demand deployments of points of presence of 14:49.920 --> 15:00.560 bar metal support, bar metal servers are giving hypervisor is supported. We can use the existing infrastructure 15:00.560 --> 15:07.040 and we can add the PDK SRI before enhancing the performance. We can ensure that the central 15:07.120 --> 15:13.680 multi-tannent add-driven node management can exist and can support the whole deployment. We can 15:15.600 --> 15:20.880 use efficiently the infrastructure that we have at node and points of presence that I'm 15:20.880 --> 15:28.320 ensuring that open-nabla uses minimal hardware and everything else. Every other workload is using 15:28.320 --> 15:35.040 the available hardware efficiently. And in the same time, we avoid locking, increase flexibility, 15:35.040 --> 15:42.800 and we minimize the costs for our partner. Thank you very much, that was all, and that's 15:42.800 --> 15:47.600 I said, everything started from this project and we move forward with that one in order to 15:49.040 --> 15:55.120 map customer demands on our functionality and vice versa. Thank you very much. 15:55.920 --> 16:01.920 Yes, please. 16:10.560 --> 16:16.000 Epsices. Networks slices. We are not involved in that one. 16:19.040 --> 16:24.800 We can talk about that. I presented only two flavors. My colleagues will come later and we 16:24.800 --> 16:31.120 present another flavors. Some of them may be related to this one. Epsices, for example, which is 16:31.120 --> 16:36.480 the biggest European open source project and that can be also another flavor that can be mapped 16:36.480 --> 16:43.600 on clouded continuum and one of its sub-initiatives like Virtuaera that will be also presented. 16:43.600 --> 16:53.440 Yes, please. So, both those European governments are around 5G on top of open stock and governance 16:53.440 --> 17:00.880 on top of that. So, how do you position yourself? I mean, where do you see the market? 17:00.880 --> 17:06.800 We are also as an alternative to top of stock. And we are, all types of stuff, I know, 17:06.800 --> 17:13.440 are key are key things up and stuff. And we are in a place where the end of funders 17:14.240 --> 17:20.720 are going to Kubernetes, right? Yes. I'm very sure for example, and if you prefer to have 17:20.720 --> 17:29.280 their own Kubernetes and cluster, so I'm just thinking how you can, you know, how open the 17:29.280 --> 17:38.800 Google can position in this market, but it's already top out. We are a recent, yes, sorry. 17:40.080 --> 17:46.080 The gentleman here asked about how open, able, can be positioned in the 5G framework, 17:46.080 --> 17:50.560 taking to account that most of the operators are using open stack for the virtualization layer. 17:50.560 --> 17:58.400 And on top of that VNFs and moreover that operators are willing to move towards Kubernetes clusters. 17:59.520 --> 18:06.800 From open stack. Well, as I said, we are as an alternative to open stack and a lot of operators 18:06.800 --> 18:12.000 we like to migrate from that one, because when you deploy open stack, you need an army behind. 18:12.000 --> 18:21.280 Here is a 5 minutes deployment. And it's not really, not really. Not really. 18:21.840 --> 18:25.280 Not really. I read recently about a study that 18:25.920 --> 18:32.560 looking at the 5G stand-alone. There are very few operators that are using that. And 5G stand-alone 18:32.560 --> 18:40.960 was built for cloud-nated or having cloud-native in its base at its bases. Here, open-enbular 18:40.960 --> 18:46.160 arrives. We are supporting a green field virtualization. We are supporting Kubernetes on top of 18:46.960 --> 18:52.560 infrastructure service, on top of VMs, and also ensure the regularization, as I said. 18:53.120 --> 18:59.760 It's not only about VMware, it's also about open stack. And we have had few successful projects 18:59.760 --> 19:06.720 showcasing this kind of things. So it's not too late for us. On the contrary, we just arrived 19:06.720 --> 19:16.320 on this market and we are coming with a huge package of features that can help operators transition 19:16.400 --> 19:24.800 and make this kind of 5G deployments much smoother, easier to handle, easier to maintain. 19:24.800 --> 19:30.880 Is anyone currently using it? I mean, I asked my question, but I'm more here with y'all 19:30.880 --> 19:33.760 in conversation about it. I've got my hand out to you. Yes, please. 19:33.760 --> 19:34.160 Yes. 19:34.160 --> 19:39.360 What's the state of arms support? Have you seen the man for arms service in a few decades? 19:40.080 --> 19:49.280 Yes. The gentleman here asked about the state of the arm and if we saw the demand of arm on the 19:49.280 --> 19:56.640 market. Well, yes, we are on the verge to support it and express it through our EPSIC project. 19:56.640 --> 20:03.200 We'll bring that on the market. And we see some of our potential customers requiring this kind of thing 20:03.200 --> 20:09.360 because, as I said, we are supporting multiple types of clouds. And if we are getting closer to 20:10.160 --> 20:17.280 this, to the device or to on premise, we say the need for supporting this kind of low resources 20:17.280 --> 20:20.320 environments. Yes, please. 20:20.320 --> 20:27.280 I was talking about an appla. Our video is also allowed like IC and occupation, for example, 20:27.600 --> 20:34.560 when you call a border and you don't interrupt the connectivity one border and another one company. 20:39.600 --> 20:45.680 Yeah, the gentleman here asked about if open ebola supports this kind of transition moving from one 20:45.680 --> 20:55.280 country to another, crossing the border. I think that's what roaming is about, right? So you 20:57.440 --> 21:03.760 was the boy and you don't lose the connectivity? You actually lose the connectivity? 21:03.760 --> 21:10.880 Well, that for sure has to be handled at a higher level. It's not as the low level. We 21:10.880 --> 21:17.440 managing the cloud edge continuum. We do not have this kind of capacity to handle this with the 21:19.360 --> 21:25.280 upper layer messages between the coordinate work and the device for the for the telco. We ensure 21:25.360 --> 21:32.320 that all the resources are met for the 5G or 6G workloads. And through that, after what's happening 21:33.040 --> 21:37.360 at the upper layer is not all business anymore. Yes, please. 21:55.280 --> 22:06.160 Yes. Very good question. The lady behind us does about what kind of workloads we have 22:06.880 --> 22:16.160 on top of open ebola. And if we met this kind of picking us of different vendors, which we are 22:16.160 --> 22:24.400 cooperating. Yeah, that's not so public yet. We have multiple projects. If you look on our website, 22:24.480 --> 22:32.480 you will see a rise from Sweden that is public and uses multiple types of vendors on top of open 22:32.480 --> 22:42.800 ebola enabling different types of workloads on top of our product. But open ebola being so flexible 22:44.080 --> 22:52.000 hasn't created any issue for the moment, really regards to this kind of vendors. They works very 22:52.080 --> 22:59.200 well. And our partners who took open ebola handled that complexity for us if exists. But 22:59.200 --> 23:12.320 to our knowledge, it was some kind of like plug and play. Yeah. Any other questions? 23:12.320 --> 23:18.960 Thank you.