 Good afternoon everyone My name is Vanessa little. I'm the director of NFV ecosystem architecture over at VMware I'm going to be speaking to you today about open source orchestrators What's out there? What are they doing a little bit of comparing contrast? I'm not going to touch on all of the open source orchestrators because there are quite a few especially in the research community but I am going to focus more on the big four as I call them and And then I'm going to leave a little time at the end for some questions and discussions So the first question of the day is why even bother with orchestration for NFV? And the problem statement as I've defined it here is the virtualized network services are becoming more and more complex These these service infrastructures are getting larger and more difficult to manage with more and more moving parts And as we virtualize the entire stack it becomes more difficult to deploy these services and Maintain the life cycle of these services and so a certain level of automation is required and that's why That's why the whole Mano movement sort of rose up because it becomes untenable to manage all these workloads manually the way It used to be managed when they were all physical appliances And so as the complexity increases the time to deployment now also decreases And so in order to stay competitive Orchestration becomes a key component in in NFE deployments Mostly because It's not possible to take six months to deploy new service anymore Previously service providers could take that time to do that kind of burn-in Rack and stack that equipment Test everything work with their vendors to make sure everything was properly integrated and then finally bring a service to market And now that six months is being shrunk to six weeks and getting even closer to six days and so With unless you could throw an army of people Had building out these services to accelerate that Orchestration becomes an absolute necessity and so when you look at the open-source Orchestrators versus the commercial solutions. There's pros and cons on both sides For open source the pros are All the requirements are community driven and so all the participants get to actually say which features are going to appear in this Orchestrator and have those features appear in a relatively quick manner at least within around six months The ability to stay a vendor agnostic and integrate what's needed when it's needed and so By being able to pick and choose those components that you need because you're the one contributing the code you have all the control That's that's one of the great things about open-source communities And that's one of the reasons why conferences like this even exist because those communities are very effective in doing that some of the cons are community development can be difficult to manage if you have two very large contributors that have very opposing viewpoints about an architectural decision or A feature set that they'd like to see integrated that really diverges the project that can create some tensions and friction and really stall the project and And and generate some code that's perhaps not as effective for the whole community But really only benefits the people that are contributing yet We've seen this happen into some some other open source communities where they're really region impasse and they're forced to fork The code and go two different directions But eventually it seems to work out The biggest con about open source Development and and and open source Mano solutions is the lack of commercial support and so when you look at the NFE landscape the biggest consumer of this are service providers telcos these are companies that have that are bound to SLAs on their services and so they look to Commercial support models to be able to provide those SLAs to their customers They need someone that they can get on the phone That's going to help them fix their problem when something goes sideways When you're using open source software, this is not this is not viable And so that type of support needs to be brought in-house And so instead of having that that one throat to choke or that one 800 number to call You now have to have these resources brought into your your own company to be able to do this this kind of commercial Level support and achieve those level of SLAs that you've been providing to your customers so far Then on the commercial side The pros are that you end up with a fully supported solution It's been pre-tested and pre-integrated and a lot of people have spent a lot of time and effort into making sure that the solution Works right out of the box before you install it at your premises the cons are Commercial vendors are going to build things that benefit their solution And so a lot of the orchestrators that are That work with with commercial solutions Are more tightly integrated with the vnf's that those companies also provide So if you look at the the network equipment providers like no key and Erickson They have great orchestration solutions that work really well with their own vnf's when you try to integrate other vnf's It's really hit or miss There's there's a significant amount of development work that has to happen or professional services That that needs to happen to integrate other vnf's and keep that vendor agnostic Landscape it ends up being quite expensive to do so which speaks to the point of changes required costly professional services And so in a commercial solution if you wanted to bolt on new capabilities add new features that are specific to your company's needs It's going to cost a lot of money to be able to do that with that commercial vendor some vendors don't even have the capability to add those those features on and so You're really locked into what their roadmap is able to provide And and if that doesn't necessarily suit your business needs Kind of you're kind of out of luck and then finally The vim and the vnf and the infrastructure options are limited because these companies can only test with so many different combinations of them vnf and hardware providers and so You either run the risk of running an untested solution or You're locked into a certain a certain vendor paradigm or certain group of vendors because that that is the only Configuration that can be supported by that commercial vendor and then there's the data model war that's still still very alive And well in the open-source orchestration community Tosca versus Yang and It does at times feel like a real battle of the Rockham Sockham robot robots When you look at Tosca and Yang and I'm not going to go too deep into this because we could spend Hours just talking about the differences and the pros and cons of Tosca and Yang One of them comes from cloud orchestration and focuses on things like application orchestration and management and It's designed for modeling enterprise cloud workloads and Describes the workloads as a topology template and then on the other side you have Yang which has roots in network design and network architecture And it was really focused on network deployment and configuration and The model and models the network services and the configuration state data So when you look at NFV your requirements for orchestration are really kind of a Venn diagram of the intersection of the two Tosca doesn't do everything that you need and neither does Yang but there are workarounds to make each of them work for your needs there are a lot of NFV purists that would argue that the best solution is both Tosca and Yang integrated together Unfortunately, the orchestration community doesn't really implement them that way. They really do one or the other There are methodologies to be able to do Tosca embedded in Yang or Yang embedded in Tosca or shell scripts embedded in either But then that really becomes more of a custom one-off solution and not a repeatable model and so When we look at the open-source orchestrators We really see two factions those that have a lot have aligned with Tosca and those had that have aligned with Yang and We're starting to see a bit of a convergence where people are getting a little more open-minded And when I get into the feature sets later on you'll see that there are some orchestrators that are willing to accept both Tosca and Yang but they prefer one of the over the other a lot of orchestrators have extended Those data models away from the industry standards to be able to achieve some things that aren't accounted for in the standards just yet and so Even though there are standards for Tosca and Yang you end up with proprietary solutions even in the open-source orchestration community that align with both Tosca and Yang and so The four that I'm gonna I'm gonna discuss today are the big four as I like to call them an open-source orchestration and that's own app OSM Cloudify and Rift There are obviously other other orchestrators open-source orchestrators a lot of them are led by research projects or university projects And a lot of those those orchestrators are exactly that they're the research projects And that's why I didn't really I'm not going to go too deep into those today Because in my opinion they need a lot of work before they could really be a production grade solution and right now They're really very useful for things like research projects and university projects So let's dig a little deeper into each of these So own app is a Linux foundation project and is now part of the Linux Foundation Networking Fund As of January 2018 when they did their reshuffle in their consolidation of the networking projects and it was founded in mid 2017 when we saw a convergence of open-o and The open e-comp projects from AT&T So the first release was as recently as November of 2017 that was the Amsterdam release and they're now on Casablanca Which is the third release? I think that comes out next week Or later this week it comes out mid November The key players in this project are AT&T in China mobile China telecom China Unicom and am docs There are a number of number of other large contributors VMware being one of them But I the key key players that are really driving this project driving the main requirements and And driving the direction are those that have listed here the core focus of own app is Sort of this all-encompassing master orchestrator to be able to Integrate with OSS and BSS on the north end and be able to integrate with multiple different types of VIMs and SDN solutions on the south end To be able to build a fabric an orchestration fabric that can that can more or less do everything Pros about this solution is that it's very future rich cons about this solution is that it's really big and a bit of a challenge to install those people that just want to just want to take a swing at it and and Play with it a little bit. You need a significant amount of infrastructure. This is not something that you can just you can deploy in a home lab This is something that you need to be really serious about testing and be able to put the resources in the time behind actually building it that said own app is really built to be modular and The idea is that not everyone is going to deploy the entire solution You're gonna pick and choose those components that make sense for your infrastructure and build and deploy those ones And we've already seen some success with companies like Bell Canada being able to pick and choose a few of those components and And start to production allies them The next is open source Mano or OSM This is an Etsy project. And so there's a lot of Unfounded press around the friction between the two projects open source Mano and and And own app There's this perception that they need to somehow be enemies because one's an Etsy project one's a Linux foundation project Where in reality, there are topologies that are actively being worked on that include them both Because OSM's core focus is more on the VIM and SDN layers down and being able to do really good Service orchestration and modeling and day-to-life cycle operations. There were topologies that make sense where you could have own app as the master global orchestrator and OSM relegated to more of a regional orchestrator and have them working together because of OSM's Etsy Sol five standardized northbound API These types of topologies are actually really simple and an elegant to throw together and so I May be a little bit biased in saying this because I happen to be the technical steering chair for OSM But I just want to dispel any rumors There is no animosity between OSM and own app if anything We're actively collaborating and looking at ways that we can work together to achieve integrated topologies because the two orchestrators really address different needs and So OSM found in April 2016 the first release was in May 2016 Which we called release zero because it wasn't really a formal release. It was more of a demo and a proof of concept The current release is release fives coming out in early December and The key players in in that project the key drivers are really telephonic up British telecom teleanor and sprint They're the ones who really set the road maps and and push a lot of the the higher level requirements There's also a really significant academic presence in OSM because most of the Participants are based out of Europe There's a significant amount of funding in Europe for research projects in this space And so there are a lot of academic communities that participate and contribute a significant amount of code to OSM and so in that respect the innovation is is Really happening at a breakneck speed in OSM because it's it's coming from the academic community instead of just being driven by vendor or CSP requirements Originally this project was really thought to be the realization of those at C standards and sort of a proving ground to take those Take the standards that are being divided be are being designed by at C And apply them that was really the initial idea behind OSM, but in practice what we're seeing happening is those standards are being sort of cherry-picked and There's there's this really beautiful feedback loop that happened as a result of this project spinning up where OSM will look at those at C standards Consume as many as possible and then feedback the the reasons why they couldn't consume the whole standard and add those features That they think are missing from the standards and so there's this really nice loop That's happening between the people at Etsy making the standards and the people working on OSM To really drive the rapid improvement of those standards instead of them just being this academic holy grail That's sort of pushed down to the community without anyone really weighing on on whether or not they work or they're valid Up next we have cloudify So this one is not a Linux foundation or an Etsy project. These guys are independent They were founded in 2012. They're based out of Israel And their first release was in February of 2012 the current release is 4.4 Their key players are independent investors. So These guys are a little bit unique in that Their core roadmap is driven internally by the cloudify staff They take feedback from their partners and from their customers but it's not a Community-driven open-source project in the traditional sense of the word While they do contribute the code and have it having a patch of two license and have it available for other people to play with they also offer a commercial version of The cloudify orchestrator that has a few additional features Cloudify's core focus was originally nothing to do with NFV at all their core focus was orchestration of all cloud workloads things like looking at dev stacks and web stacks and and Just being able to automate any kind of thing that you would need to virtualize that was cloudify's original core focus And they came to the NFV party later than some of the other players and they've done it very well So they approach the open source they approach the orchestration paradigm more from the cloud end of the spectrum as opposed to the network end of the spectrum and so They're more feature rich on the cloud side whereas someone like Rift approached it from the other angle so Rift is also an independent company that their roadmap is driven entirely by independent development They're privately held company. And so they have private investors They come at the open-source orchestration realm from the network end of the spectrum And so things like doing complex layer three models and integration with physical network functions These are things that that Rift came at first and sort of looked at more of the cloud type orchestration and day-to-life cycle operations as a secondary thing and so it's kind of interesting to see such such similar companies And two such similar open-source orchestrators come at it from two completely different angles and sort of arrive around the same spot in the middle So Rift's first release was in May of 2016 and their current release is 5.3 And they recently rebranded as Rift. They were formerly known as Rift IO but the product itself is called Rift where and similar to cloudify they have Their open-source Apache 2 version that you can download and play with as much as you like and their commercial version that has a few extra features and extensions That you can buy a commercial support contract on And as I mentioned their their core focus started from the network side of the house A lot of their employees initially were ex Cisco and ex-Pyron employees. And so they they had a lot of knowledge around being able to build complex networks and optical networking And then translated that into the NFV space and So here this slides a bit of an eye chart and I believe you'll be able to download my deck So you can go over it later on your own But this is sort of a comparing contrast side-by-side feature comparison summary So the first thing I have listed on here is the Etsy standards adoption And you'll notice here that not one of these orchestrators has complete Etsy standards adoption I'm just gonna pause there and let that sink in Because Etsy is such a huge driving factor in all of these orchestration activities and all of the NFV activities and all of these open-source projects that are popping up Yet, no one project can say that they align with Etsy 100% And there's two reasons for that one because those standards are a moving target and they're constantly being improved and and two a lot of these orchestras all of these orchestrators have made some very tactical decisions to have something that's useful in market today Without waiting for the standards to catch up and so what we're seeing is more and more adoption of the Etsy standards as Those Etsy standards are being ratified by the people trying to use them So it's it's the sort of this this cyclical behavior that that's happening in the standards community Which is actually very beneficial because what we're in the end result is Standards that are actually very useful by the community as opposed to standards that are very academic The data models between the the different orchestrators Oh and app uses Tosca and heat OSM has Yang models Cloudifies a Tosca based orchestrator rift can accept Tosca, but is mostly a Yang based orchestrator They're all different They're all doing something different and none of the data models are portable which is unfortunate for those of us That would like to be able to build a descriptor and then try it out with a different orchestrator Unfortunately building descriptors for each of these Orchestrators is a unique exercise and a unique effort where you have to start from scratch and pretty much none of the components are portable Vim support for open stack everybody has a cross-support Vim support for AWS everybody has that across the board Vim support for vCloud director. Everybody but own app has that virtual machine EPA support Where the VIM supports it all of these orchestrators are able to to model that and push that down to a VIM Kubernetes support everybody but rift currently both Kubernetes support, but Just between us they all have varying degrees of Kubernetes support and Kubernetes integration. Some of them are able to Connect to the Kubernetes API's and do everything you could ever want to do to a Kubernetes cluster Some of them are able to build that Kubernetes cluster before you actually administrate it But but for the most part everyone but we have both Kubernetes integration being able to deploy Kubernetes based workloads alongside the M base workloads The community size and activity own app is huge there are a ton of members There are a ton of people contributing code the code base is massive OSM is smaller than that, but still somewhat large with over a hundred members This is in a significant code base. That's been ramping up over the last two and a half years It's a very active community Cloudify's community is very small because their community is cloudify. There are some people that might do Data models or descriptors and then contribute them back to the open-source community, but everyone who Contributes to the core code base of cloudify is a cloudify employee and the same goes for rift And so in that's in that sense those two communities are actually quite small Physical device provisioning and PNF integration I've listed partial support for own app and OSM They both have ODL connectors and the ability to manipulate open flow type devices But I wouldn't call that Complete feature rich for physical device provisioning. There are physical devices that one might need to orchestrate that Don't happen to speak open flow. They do exist And so I'm calling these as partial support cloudify and rift haven't haven't built that kind of integration But you can achieve physical device orchestration with those two orchestrators But bolting on some scripts in your data models So it's not entirely fair to say it's completely unsupported But to get support for it. It's it's a bit of a workaround Multi-site multi-vim support own app and OSM both both stat cloudify. I've listed as partially supported Just because of of the way you need to deploy cloudify and the number of instances you need to be able to have Multi-vims connected to the same instance of cloudify. It's it's a little bit Unusual let's say but it but it does work and then rift is able to have as many vims as you'd like to connect to it policy management So this is a broad term policy management can mean a lot of things For on app and OSM policy management specifically speaks about the ability to set metrics and monitoring for all of the the monitoring F caps integration Cloudify and rift also have these capabilities, but they're implemented somewhat differently and monitoring enough caps integration own app is I've listed as partially supported, but I think we could safely say it's it's properly supported They have a great module that integrates with Monitoring both the vim layer and the vnf layer to be able to do closed and open loop service assurance OSM as of release for both that capability as well cloudify also has great monitoring enough caps integration Rift less so they do have some very preliminary Rudimentary integrations, but I wouldn't call it as feature riches as any of the other guys And finally the commercial support model own app and OSM Don't have it there They're truly open-source communities and while there are companies that are sniffing around saying that they'd be willing to provide an open Full commercial support model if a customer wanted to buy it No one has formally announced one yet No one's no one's listed no one has a price list that says this is how much is going to cost you to get support on these Open-source orchestrators and so I've listed these both as a not supported But cloudify and rift as I mentioned Have full commercial support models you can buy support contract for the orchestrator from them You know exactly how much it's going to cost and what you're going to get For what you what you've paid the for So that said Where do we go from here? Are these orchestrators production ready and if so why isn't anybody running them in production yet? Cloudify and rift do have commercial deployments today But we're not seeing huge deployments We're not seeing those those tier one massive NFV deployments that we all kind of envisioned And the question is why is Is it because of the support model? Is it because these companies are small? Is it because there's there's this view that open source is not really production grade The answer is all of the above If you ask any any specific service provider Why haven't you deployed an open-source orchestration solution yet that would all give you a different answer one is We don't really need orchestration yet because we only have a few bnfs deployed and we can handle it manually another answer is We don't want to spend the money on it yet until we've seen somebody else prove it out And we've seen somebody else, you know try and fail a few times with it and really refine it The list goes on and on I think it's really just a matter of time before These open-source orchestrators are really deployed and it's going to take someone to take that big leap of faith It's going to take an AT&T or a telephonic. It's really announced the world. Yes We deployed it in production and nobody died And until that happens, I think we're going to we're going to see some very hesitant adoption We're seeing a lot of POCs. We're seeing a lot of demos But so far no real large commercial deployments So that said We have a few minutes left for questions Or comments. Yes Why was open baton not mentioned? I Can repeat the question So the question was why was open baton not mentioned and is it what is it because it's more intended for smaller scale deployments? The answer is because it's more of an academic project and the likelihood of that project of getting commercial support is a long way away I've really identified the the linchpin for Open-source orchestrators turning into production grade orchestrators as that commercial grade support. That's that's the key Factor that needs to be addressed before these these orchestrators can really become Viable solutions and so with open baton because it is a cool orchestrator. It's it's very effective, but it's an academic project So the question was how about tacker. Is it because it only works with open stack as the Vim? Partially yes And partially because tacker doesn't account for a lot of the features and use cases required by NFV And so tacker in its own right is a great orchestrator for cloud workloads But when you're looking at NFV workloads and being able to do complex modeling of layer three services Being able to define SDN overlay as well as a networking underlay Tacker really falls down there because it doesn't have the features to do that And that's why I didn't include this I didn't include it in this presentation because it's not really ready for NFV and given the the lack of support for tacker in In in development and how small that community is getting now I don't have a lot of faith that it's going to get there and that's just my personal opinion and feel free to disagree with me but We've seen a sharp decline in participation in the tacker community in the last few years And so I'm starting to lose faith that they're going to add the features that we'd really need for NFV So I'm really curious The use cases or that the orientation if cited so far is mostly telco based What about big banks say that are running large data centers themselves? Are they interested in adopting any of these? Yes, actually, there's a major bank in in Canada. I believe that's using cloudify as as their production orchestrator So so when we say NFV, yeah, I'm speaking almost specifically about telcos and service providers, but NFV for enterprise workloads is a viable use case and and yes, a lot of this applies to those use cases as well Yeah, and that that's really important to point out So cloudify is a really big participant and heavy contributor into own app just as rift is a big contributor into OSM And so you're seeing this intersection of open source orchestrators for for different use cases And it's making sense for This collaboration to happen How would you compare the four you mentioned with the hashicor Terraform? How would we compare the four that we've mentioned with Terraform? That's an excellent interesting question and that brings me back to the network service orchestration Terraform has a lot of great features and yes, you can achieve network service orchestration with Terraform But it's done in a totally different way than people have been thinking about it when you look at how the Etsy standards are Defined and you know, here's a little box that says Mano and here's what Mano is supposed to do and here's what that interface is supposed to look like Terraform does something totally different Not that that's something totally different is ineffective. There's a lot of people having huge success with Terraform I'm personally a big fan of it but when you look at the Mentality behind Mano and the expectations of Mano and how that's been defined particularly by the standards community Terraform doesn't fit very well into that little box That said the features in Terraform are actually very comparable to the ones we've we've discussed here today any other questions Comments high-fives hugs One more question, okay I was it was interesting to see that you mentioned monitoring as a row in your comparison chart Can you speak a bit to that because I find it an essential thing if you want to have an orchestra to become successful That's a very important consideration. How well you allow monitoring to happen after the services deployed Yeah, that's that's a great great comment So monitoring is an essential part of orchestration because when you think of orchestration Don't just assume that you're talking about that day zero get that thing deployed That's only part of the equation Part of the responsibility of orchestration is not just get the thing deployed, but then what do I do with that thing afterwards? what do I do day two and So having monitoring as component of orchestration being able to integrate with monitoring components not necessarily become a monitor But being able to integrate with those monitoring components and get at least a summary of that telemetry To be able to make intelligent decisions You need that to be able to do closed loop and open loop service orchestration And so think of think of a scenario like this where you have You have a network service that has 15 different components Some of them are physical some of the virtual some are some of them are containers Some of them are VMs or across different data centers and you have a monitoring system That's monitoring the health of all these different things That monitoring system needs to be able to tell the orchestrator this service is unhealthy and I need and I need it restarted Or I or the service is under load and I need it scaled out or the services not under load I need it scaled back in to reserve some resources That interaction between monitoring and orchestrator is essential There's no way you could do that without that that that interface and so that's why I listed Monitoring integration as a key part of an orchestrator's capabilities It's one that was traditionally kind of left behind as an afterthought, but I think people are finally realizing Orchestrators really need to know what's happening to the infrastructure After the service gets deployed All right anyone else? All right. Well, thanks everybody. Thanks for coming and enjoy the rest of the conference