 All right. Good morning everyone and thank you for joining our session today So today, I'm going to talk about a cloud native VNFs and obviously in the space of NFV and I'm going to talk a little bit about the transformation that we are seeing right now in the NFV space obviously a lot of interesting perspectives coming from service providers a lot of you know know-how and that we've learned you know as as as Providing orchestration platform for for NFV, but also from the various other VNF vendors that we are interacting with so that's that's Primarily going to be the topic of the talk today So just so so that I would know who's in the crowd today So who's who's here from a service provider side of the story? All right about almost half of the room who's here from the VNF vendors side of the house Interesting split into two Kind of like the boys and the girls in third grade So I'm Arthur Bresen and director of product management for cloudify with gigaspaces and in fact I wear several kinds of hats within gigaspaces and Acting different kinds of roles So I'm also the project lead for for project Apache which for project area Which is an Apache social foundation project a new project that we've just started Several months ago to implement a pure vendor neutral Tosca based orchestration framework I'm gonna talk briefly about it later on and I also served as served as the TSC member as part of the open O community and part of the open O project now Coming together with with with E comp and and creating the own up community. So last week we had the first developer community Quite quite exciting times. I think for for the orchestration and for the NFV space in general. Okay so In a nutshell cloudify is a pure play orchestration platform I'm not gonna talk about cloudify today rather. I'm gonna talk about in cloud native VNFs But just in a nutshell so you would you know sort of see the perspective of us in the world So cloudify is a pure play orchestration platform serving both as a service and resource orchestration But also as a VNF manager Cable of orchestrating, you know the different kinds of VNFs and applications on on various multi-cloud environments Where the philosophy behind building the product? Oh, it's happening over there as well Thank you. Okay Not touching it anymore This was working looks brighter. All right. Let's let's go to try Yeah, hoping this won't Give you any flashbacks now So so cloudify is a pure play orchestration platform a Tosca based orchestration platform built build around the philosophy of of of the fact that technologies constantly change So to us, you know supporting multi-v multi-cloud type of environment is kind of a pre-built feature in the way cloudify was was built and Essentially, this is the perspective with been operating around with many Service providers, but also with many VNF vendors Wanting to use the capabilities of the platform to ship it for for their own, you know VNF needs and integrating them the VNF themselves into the platform using capabilities from the platform So we're gonna touch a little bit about Those points as well today So we're gonna talk about the transformation, you know, the VN the NFV 1.0 that started I think into years at year 2014 with the Etsy Etsy announcing the NFV Specification and right now we're seeing this huge transformation going into NFV 2.0 where VNFs are now much more native and and and Utilizing much better the environment than then right now Then then what they used to do in in the first iteration and touch bit a little bit on the open stack side of things And how can we better leverage open stack for that? So back at the day, you know Obviously, you know this side of the room is much aware that that's Onboarding a new service is a very costly process. It takes a long period of time to onboard a new service You know, you call your VNF you call your your vendor for specific service that you would like to onboard this whole process It takes a very long period of time. It requires a lot of manual integration within the existing services that the provider already runs and When you're finally done with that long process, it's it's statically bound to the environment So changing things and and and shifting, you know services to new needs that you expect your platform to provide is super challenging So, you know coming from this world where you have a lot of Appliances that are built into the environment So the first step to to to reach to you know to to the network function virtualization essentially to better utilize The commodity hardware that it is much cheaper and easier to set up So the first step there is is usually, you know taking the specific applications, right? taking the appliances themselves and Simply virtualize them, right put them as a virtual machines create maybe images or create some sort of a automatic process that maybe installs them and using obviously commodity Either using commodity operating systems for for providing that and creating the images using commodity operating systems or or Operating systems that are more well-suited for networking workloads, but again the main message here is that we are not, you know Obviously, NFV has given us a lot of Transformation in the way we think and consider about building our environment But fundamentally we haven't changed much the way we're Where delivering and utilizing the hardware we're just you know sort of boxing it around and making it a little bit simpler To onboard into environment now obviously this has a huge impact But this is just the first step Where we you know, we just take the suppliers and and and package and automate some of the processes around it So now instead of onboarding a new service now instead of you know spending it to about 18 months or two years and two and a Half years and these are you know the good cases that we've seen you know now it takes usually Contacting the VNF vendors and you know once the contacting is done and we've planned our integration It takes us about you know several hours or days or maybe weeks To onboard a new service, which is obviously by far much better than where we used to be Before NFV, but again nothing, you know fundamentally changes in this scenario We're still using the same software. We're still using the same software management and and and and the orchestration and automation capabilities that we've used to use before so we're using the same you know models to to shape the network and and to shift it to configure the network and Again, there's a lot of room for improvement here and obviously there's there's this nice little point that you know Obviously we virtualize things and we might make might make a better utilization of the hardware But still it's our you know We're running huge images huge virtual machines with full-blown operating systems and you know think of a physical server running 10 or or 15 Instances or virtual machines of the same operating system and on top of that running You know some layer of a software that we actually need to run our service, right? It's all about the service never about the infrastructure on the or or the pieces we we need to lay to to bring that service on board So still we have you know much room to to better utilize that in the hardware that we are planning here and We've seen you know a lot of evidence for all from all the major Service providers around the world, you know guys such as AT&T Vodafone and tell it to and Deutsche You know claiming. Hey, you know, we've done this first step of moving from Affliances from things that are statically bound into the environment to to having things virtualized Which is a obviously a major progress, but then again You know, we are still not utilizing as much as we need the environment that we have So we're buying about a bunch of boxes now think of a Certain service that we are onboarding now think of providing, you know that same service in a highly available environment a highly available configuration and Multi-region environment so instead of running a single machine. You're not running 15 instances of the same machine just to run a single service So this is still a little you know still a little crazy and still a lot of room for improvement Hence, you know the call for the cloud native VNF's so the whole point of cloud native VNF's is be much more efficient and you know to create the actual services to utilize the environment directly not to be bound to this transformation that we're making from Virtualizing the applications rather creating the services themselves in the matter where they natively Consume the infrastructure in the environments that we are providing it to do right so again think of you know SDN for example So we have now full control with software over our Over our network environment that we create, you know on the fly we can create networks, right? So now think of onboarding a new service that requires a network of its own for example So in this new environment, it's not just you know It's not just about providing the needed infrastructure to just shift the application from you know from one layer to another rather Utilizing the infrastructure and the software directly and you know realizing that now the services that we can provide are Essentially again can directly utilize can directly use the infrastructure for the service needs and not for the infrastructure that provides that extra layer and needed for the software and You know obviously that that also has a huge benefit from cost perspective because now and We're really running, you know our net our services that we're onboarding a Essentially consume much better the environment hence the costs of it become much much more Commodities So Now think of this this application that we have, you know Move the run from being physical to being virtual to being now cloud native now if we re architect that same application with With the notion in mind of utilizing the infrastructure directly rather, you know being bound to the virtual machines now This this this new notion actually allows us to reach, you know, hyperscale much much more easily again to us now a Services is a container which is scalable Which is you know natively utilizes for example the load balancers of the environment the software defined network that the environment can provide As etc. It's also architected for to expect failures again, you know Taking the lesson learns from the lesson learned from from Google, for example, who you know Building their soft engine as their their search engine algorithms Expecting there will be harder failures. In fact, they have you know very precise Statistics of how many server will experience failures out of certain amount So when they build their software they build it for failure and expecting failure will come Hence, you know the service that they're providing Would not expect service because that application itself is written directly with the environment and and expecting that failure now Think of you know from a from providing a network service from a service provider perspective, you know having those notions in mind When creating and building these these services So we're definitely you know in this paradigm of making this shift And I think it's we're still relatively in the early days now I think everyone more thinks of you know cloud native as you know just containerizing VNF and that's definitely an important step for for for that process and you know, definitely exciting times from that perspective now and So additional key element is the fact that we have you know access not only to the Overlayed networks that we are creating as service providers But now we have also direct access to the underlay networks and we can integrate between them So again think of you know in open-stack example, we have a rich set of plugins rich set of Software That provides these network services to open-stack itself now think of an application Consuming these kinds of capabilities directly or creating specific networks just for that application So now that once we have that you know that control again things are Much well integrated and obviously that has a huge impact over costs and you know One of the additional changes that this industry is going to to experience is you know the pricing models because right now Most VNFs essentially are being Charged the way they used to be before even we just had through it went through this transformation So right now think of a network service that we are onboarding and we're not you know just counting the number of Services servers or the number of appliances now we have to rethink about rethink the whole Financing model because right now we're spinning much more Instances of the same service in in in more locations to provide you know that resilience that have a ability that that fail that Failure expectation etc So that's another another element that we that we are seeing and we foresee that that would come And we definitely you know see a few very good examples of you know of the VNF vendors Early starting to think about this approach and starting to utilize The native at the native capabilities of the platform So you know versus is one good example, you know providing the VCP and SD one Everything's being fully orchestrated and automated on on any type of environment, right? So you can use multiple type of VIMs to it to use to run this software Which is obviously self-managed another example from it from a different different which takes a little different approach and Which is rockus wireless that provide, you know their their Wi-Fi services and having that Having a Software-defined management layer, which is you know provided to customers as a service So these you know two examples are really you know powerful and show showcasing, you know how a VNF vendor can utilize All the new capabilities that we are getting from the environment Not just you know making that that that that migration to virtual machines and in fact, you know this you know produces much much faster and Much faster way to deliver the services and and you know Allows them to to iterate through that software development cycles also much quickly. So again day as vendors being able to Utilize these services allows them to create their products much quicker and Essentially stabilize them and provide better better features So what a cloud native VNF looks like and as I mentioned earlier, you know today I think most of us think of climate native VNF's as just you know Consuming containers and obviously that's not not the only perspective that hit that we have to take care of so The first element is software defined. So again a network service is you know a piece of software that's architected in a certain way and Again by the fact that's architected by way that it's integrated into the environment and It can easily, you know Provision manage the environment and utilize the environment for its own needs and shape the environment based on its own needs Also designed for DevOps so We've learned a lot, you know from the DevOps community on on how to manage services and how to manage You know not necessarily network services from the DevOps side of things But how to deliver much quicker the services that organizations need So there's a lot of lessons learned from you know all these cycles and we're seeing you know many VNF vendors Taking this these lessons and putting them into practice when developing VNF's so right now You know you have you have showcases, you know, for example the ruckus example, right? So again think of providing a management layer for their software Using for example Jenkins and CI CD processes for delivering management capabilities Yeah, think of the agility and the think of how quickly it and easily it is for them to develop to deliver a bug fix For example for a certain major major, you know issue that they're there that a customer's experience it So and also monitoring Which also is a key element for for delivering, you know the close loop mechanism again, you know if something happens in the environment You have to respond to it in you know and then the at least the five nines Probability so we have to respond to it quickly and you have to have that monitoring piece Embedded as part of the application so the application itself should should monitor not only you know the components of the application but also should take on their account the Infrastructure that it usually utilizes to bring, you know the services that application needs So again, I will think of the closed-loop environment where you know eyes and application I'm aware that a certain region for example is down now and I can run a certain a certain Action to it to fix that situation either to change some rules in the in the load balancer For example and steer some of the traffic to another direction, right now think of that capability being Built in to the application itself not something as that I as an integrator I as as an operator have to now manually deal with When I have that failure So multi-tense is also a one key element for for for NFV Obviously, you know, we don't when we onboard a new service in many cases We just want to reuse the same service and want to make sure that this same service You know, we don't spin it up multiple times rather. We want to use the same service And for multiple customers, right? It would be much more cost effective So we already, you know, we have a certain region that we are providing services to We have this application onboarded to that region We just want to reuse the same one for multiple type of customers So that's also a key element and multi Veeam. So this is open-stack summit open-stack Obviously is you know the de facto Veeam layer for for NFV But again, you know some cases you would like to use Veeam where other cases, you know We already heard, you know, some service providers thinking and then starting and playing around and already surrounding some not mission-critical I think Services over public clouds. So we do hear, you know, those service providers utilizing AWS or Utilizing, you know, public clouds such as Azure To migrate some of the workloads to those clouds to be, you know, much more cost-efficient, right? So not in all cases. I would like to stand up my own private data center and bring up whole Private cloud on top of that and manage that or, you know, hire a managed service from from one of the Managed service vendors, which is perfectly fine. But, you know, being being able to choose Based based on what's cost-effective for me as a service provider. This is also a key element That's drives, you know, the the cloud native VNF development So as I mentioned, OpenStack, in fact, you know, what we've what we've hearing with discussions from most, I think service providers Today OpenStack is, you know, the de facto standard for implementing the Veeam layer, the virtual infrastructure management layer and to provide, you know, these Services on top of which the network services would run So the really cool part about OpenStack is that it's it's highly customizable and it's not, you know Take all or leave it, right? So you have multiple types of services and each of these services, in fact, are highly configurable So, you know, Neutron, I think it's a very good example, but it's true for all services So I don't have to use the open V-switch Implementation to do my to do my for example Overlay or overlay networks or my underlay networks, I can switch to another vendor now, you know Having that vendor being part of this ecosystem also allows me to utilize the additional services coming from that vendor and You know, I am as an application developer I can also utilize them to integrate these capabilities into my VNF that I'm providing So again, you know, think of the possibilities that I when I develop a software I can detect which kind of layer and which kind of capabilities my infrastructure provides me and Integrate them and utilize them on specific cases, right? For example, we have, you know, some hardware offloading capabilities coming from from from the hardware directly, right? I can detect the type of hardware and My my VNF can function in a certain way when I see that I can utilize these kinds of capabilities right, so another second Also very important a piece to that is that opens like itself Is coming with tons of services, right? So Neutron is the most obvious one and we are all familiar with that But you know, if I'm running for example containers, maybe courier would be interesting for me for my you know For my networking for my container environment I have designate firewall is a service load balancer is a service we try vitrage for for monitoring to have tons of services That open stack provides me and I can utilize them as part of integrating them into my my VNFs And it's not I take it a limited situation with open stack, right? There are tons of services and I can essentially pick and choose the best ones for my for my environment so and a Key element to all of this is to be able to automate and orchestrate and then manage my application right, it's not just about Doing that one-time integration project It's about being able to orchestrate it in any type of environment and in fact, you know separating the pieces the software pieces from my Infrastructure pieces from my cloud pieces and allowing me to to orchestrate them on multiple kinds of environments So in these cases, you know, the orchestration becomes very key becomes a key to success of such such NVA and VNF based environments where In the cloud native world, it's not just about, you know, the very, you know basic kinds of Services that we like to use it's also about making sure that they perform well. So for example, we have you know Projects such as the PDK and and FDIO for example, we have Intel EPA so have tons of projects That optimize all the layers needed to implement a VNF and again think of you know, and when you think of orchestration of These services, you know think of an orchestrator that that would be able should be able to recognize that this is my environment and should be able to optimize The VNF based on whatever is actually happening underneath it So again, you know think of the contrast of of coming, you know Of and migrate just migrating the application to a VM to where the application itself is is aware of what's happening underneath it so another and another Possible element that we are seeing actually from many VNF vendor Providers is the notion of having an embeddable orchestration platform and an embeddable orchestration layer So again think of an application and again think of of of an orchestrator is not something that that's that Solely operated by by the service provider Rather something that's the VNF vendor can take something. It's lightweight and the VNF vendor can take that and just embed That as part of his application And in fact treats all the components of His application as microservices where that orchestration piece that embedded orchestration piece is Capable of figuring out the environment itself Again think of you know one one example comes to mind is clear water. So again. I am s tons of services to to To enable that you know one network service that we want to provide to our customers again From an orchestrator point of view these are multiple Microservices or you know some of them are micro some of them are huge But the orchestrator should be able to to take care of them and make sure that all the endpoints of These microservices in fact interact successfully successfully with with one another So what makes an an open an embeddable orchestrator and the fact that I missed there was that you know open source is obviously a Huge key and a huge differentiator in what's actually happening in the environment itself again Open source a major driver behind what what what we are actually seeing in the end of the in NFV space So you know make it make making the orchestrator obviously, you know very easily to OEM it and white label it Making sure you know that we have Access to the source code is important again again think of a software developer that provides that network service And he doesn't know what kind of software he's he's delivering with with with his service Think of that he's not a not having a visibility into what's happening in his network service So open source is a key to that open governance is also very important there where you know The VNF vendors would like to not only be able to tell how the software runs But also be able to shift it based on whatever they're seeing with their customers again I'm a VNF provider. I would like if I'm embedding some sort of a project open source project as part of my software I would like to be able to Control it and to be able to To add to it to contribute to that and to you know do bug fixes to feature implementations that are coming from my customers again. This is something that is and Some something that is very you know close to the software that I'm writing for you know the service itself that I'm writing So two examples That that we that we delivered customers one is is cloudify is is a full-blown orchestration platform Does the full lifecycle? management of a service The other one is project area which we've launched several months ago when it's already been used in multiple projects also as part of Open know and on up that it's just forming now together Where there are areas essentially is this is a lightweight Framework for developing, you know, Tosca based products so essentially if you want to Something that supports Tosca can do Tosca deployment not just not the full lifecycle Orchestration so so so aria would be the way to go And we're seeing also a lot of efforts from the various, you know, standard standardization bodies To standardize the way we deliver these network services again, you know, right now we have a lot of different opinions from from the From the standard bodies, obviously, you know always is this shaping up Tosca in Tosca for NFE. We have Etsy defining Defining, you know, did the various ifa specs. We have math defining LSO and then, you know, the different APIs, but also we see a lot of Attraction from the open source projects implementing them. Some of them are more compliant. Some of them are less compliant, but you know In fact where the implementation goes It also shapes up the standard bodies So this is also an important element to do the VNFs themselves And you know, one key factor that we're seeing the common across orchestrators is Tosca So Tosca allows us to to separate, you know, their intent The what I want to build what my application looks like. What is that the apology of the application? What are the life cycle operations of each VNF component and Separate all those from the actual implementation of each of them So again, you know, just think of a service of a server or a virtual server instantiation, right? so when I define my application I want to Define the topology and and the the architecture of the application And then, you know, I want to separate that definition from the actual implementation of several pieces And then I can reuse several pieces or again, you know, think of of that part that actually instantiates the VM and Interacts with the opens stack API for example, right? I don't have to rewrite that code that Launches that does the Nova create API call, right? It's essentially the same one and I should be able to reuse that for every application that I'm building But it's it's it's not something that you know It's something that should be standard across the VNF vendors and I have VNF vendors should just define, you know Choose just choose the right architecture for the building blocks that I'm using for my application So this is you know, I don't I don't have time to go into the example today But this is an example of a cloud native VNF. This is just a quagga uses a quagga router Running on Kubernetes on a Kubernetes cluster, which is scalable We have a load balancer that uses engine X on on Docker swarm and again using Tosca We are defining the multiple relationships between these objects. This is you know, this is my whole application This is how my application looks like and then, you know A certain piece can take that architecture and orchestrate that on on an environment based on whatever the environment I'm using in my actual in my actual Production lab or in my lab in my actual production environment So I'll be happy to share the slide and you can just you know, go to the link and see The actual code and how it looks like how it operates, etc So one take away I would like you know for you to to live from this presentation is is a VNF lab that we're offering It's an on-demand lab that comes with with with an orchestrator and with an open stack environment So again, if you don't have the resources or you don't have servers for example to Launch a dedicated open stack environment just to play around with with applications So that's something that we you know, we're happy to to help with and and you know Happy to educate on how Model-driven orchestration works and then provide the needed environment for that questions So there are two mics over here. Yeah idea of lifestyle lifecycle management I Imagine is a pretty rich one. There must be a lot to it in terms of relationship between the manager the orchestrator and the and the Application itself. Can you can you talk about some of the issues you've seen in that area? So I can talk a lot about multiple types of issues. Could you like maybe point pinpoint me to certain areas that you're more Yeah, I'm afraid I'm thinking very broadly but I think you know it obviously has to do with the the installation the configuration and the monitoring and subsequently the continuous integration and then the you know the Eventually divorcing the service and replacing with something else entirely but a lot of bits and pieces in there I'm sure there's I don't know. I don't think there's a lot of standards Really available. So there's probably a whole area that has to be standardized And so today when you're dealing with something like this like what are your biggest single problems? Yeah, definitely So us, you know, we are providing a certain solution that you know that we are standing behind So we're making sure it works, but definitely there's a lot of work needed to be done to standardize. So we have a standard for Defining the topology. That's Tosca. We have a way to interact with the multiple components but the interfaces are Not well defined enough in Tosca and that's something that we probably should work as a community to better to improve So so we have you know standard lifecycle operations such as you know configure create start stop But you know, what about the day two operations? What about you know, specific configurations on specific on containers versus servers, for example, right? So there are multiple bits to the implementation that we you know We take care of as part of the implementation as part of the solution But we should better work on to standardize that as as as a ecosystem because it's not enough that we as cloudified just you know Offer that solution any more questions. Yeah, yes, I saw on your early slides you mentioned there's a DevOps for the AFV 2.0 So in your opinion, so right now for for service for the NFV vendors So they sell to the operators as they always has to package the software all they can do like the Dagger container like you mentioned on your slide. So so last week I went to AT&T there's a conference and They even create some kind of certification so that basically they have doing process So for the vendors trying to deploy on the production side So they have to go through the certain process, but on the DevOps basically that means you have to For when the software has to deploy to the production directly so for this kind of the Process or activity, how do you see in the future the industry is hitting? Yeah, so My wish is for a VNF to be as easily deployed as I install applications on an iPhone or an Android I should you know, I should have a catalog I should choose from that catalog catalog based on whatever, you know The specifications that I need maybe some of them would be specific to my environment and But but essentially, you know, the process should be as simple as that or at least, you know Coming close to as simple as that and you know, we have different tools and we're still far far ahead for from being You know there we can easily package them for but for specific solutions again You know from cloud of edge perspective we package application in a certain way and you know We're working with multiple VNF vendors to package their VNF and then with the service providers You know obviously a cloud of I being that centralized platform But we as an industry as always you mentioned you were last week at the on up developer summit probably right in New Jersey So right so from the on a perspective again There's a huge certification guide that talks through how to onboard an application and package that so I think we should have We have to have a standard way to deliver that Like our perspective on that is you know, we launched project aria Specifically to solve that problem to have a a certain way to to to a to which is thin enough And so that everyone could just consume very easily to and to package applications part of that That's project aria, but you know as an industry Let's see we will see how things go and if we definitely if we go to that direction or we won't be able to solve You know the challenges for that Any more questions? All right. Thank you very much