 Okay Good afternoon So my name is Jeff Arnold. I'm an open-stack architect at Cisco and Cisco has been involved in OpenStack since the very beginning I can remember some of the very early design summit sessions back a way back where we were arguing over how to do what turned into quantum and then neutron and of course you expect Cisco to Be involved in defining the networking technology and creating technologies creating plugins to support our networking products What you probably don't know is that Cisco is also a global cloud operator and This is an increasingly important part of business Cisco's business and the guy who has the responsibility of defining That cloud service for our customers and building out is my colleague Dave Lidley. So take it away Dave. Thanks, Jeff so As Jeff said, we've been involved in OpenStack for a long time But we've been involved as an operator outside of IT much more recently And so if I if I look at sort of, you know where it started It started with the fact that when you look at Cisco's businesses take all of our big core software-oriented businesses Cisco whether it's video Collaboration security network management device management Analytics etc. All of these software businesses are transitioning towards a cloud-based delivery Model and all of them are looking for how to build and how to develop their own their own cloud And as you looked at that the applications a few different patterns started to emerge These are sort of common patterns across all of the different applications one data lots and lots of Data and whether that data is coming from things because it's you know data from sensors or you know It's energy data from Devices you know routers switches etc or whether that data is things like raw video So actually I recycled a little bit of this chart from a talk I did at one of the cable tech shows a couple of years ago around cloud DVR So how do we deliver video from the cloud again data and lots and lots of data and Generally that data tends to want to be closer to the edge whether it's closer to the source if it's data coming from sensors Or whether it's closer to the sink you know if you're doing on-demand video out to In customers more efficient to keep that data closer to the the edge because the other aspect That has come in a lot of these applications is latency and the effect that latency has on the overall customer Experience for a lot of these cloud-delivered services and applications great example is the Comcast X1 service That one's running out of cloud running out of OpenStack I'm sure you guys either saw it talked about either at this session Or I know it was talked about a lot in San Diego and some of the other sessions If you've got Comcast X1 Every time you press a button on your remote that's going back up into the cloud It's going back up into the cloud to then figure out what you need to render on that set top box screen I think it was part of a lose talk yesterday We had some of the folks in Cisco's video team talking about you know what they're doing in cloud based You know video and the model is sort of turning on its head Whereas you know today in most set top boxes the majority of the processing work functions Etc. are done in the set top. There's a little bit back in the the data centers And that's really flipping on its ears with with cloud Which is most of the works being done out of the cloud and even a lot of the data plane Not just the control plane, but now a lot of the data plane is coming from cloud as well latency absolutely Matters and you know latency matters In terms of the quality and the types of the networks that that data is running across and of course How close those data centers enough close that data it resides third key aspect is that a lot of these workloads are very Peaky very bursty. They're not constant state workloads There's a lot of things that really happen all at once again video a great example of this You know everything happening especially in video-on-demand Friday night Saturday night is when the vast majorities are happening There's really big peaks in a lot of these applications and it's really tough to try to build all the capacity for just one application for your peaks when the Majority of it's going to go sit and idle for the vast majority of the time elsewhere And so how can we start to to share that and monetize that as well? Then the other aspect is that everything moves really really quickly Once you move into to cloud and so you know again I'll keep using video as a good example because it's one that I've been in for a long time from a market perspective The set-top box experience hasn't really changed that much in the last decade the pace at which you have to develop set software for the set-top box and Then qualify it test it roll it out to all of your set-top boxes because that's running and resident on the set-top boxes It's often a 12 to 18 month process at at bass And so it takes a long time to roll out new services and capabilities But Netflix on the opposite extreme they could change their experience literally every other day If they wanted to because the experience is owned and lives and runs up in the the cloud Comcast another great example is they can modify their X1 user experience And in fact just in the time that I've had my X1 box at home. I've gone through two or three different user experience changes and I've seen a lot of different applications rolled out onto that because They can do it in cloud and because they have to do it in cloud And so that's the other aspect that's that's driving this is you know Not only is that our faster pace enabled by cloud But because the competition for a lot of the existing businesses whether it's collaboration Security network and device management video all those software businesses at Cisco the competition is a cloud delivered model And it's a cloud delivered model that moves much more quickly Then you know Traditional groups have been able to do writing traditional software that then sell to enterprise And so all of this is moved towards a We need to be developing on top of and for cloud as the the Cisco application groups and so You know then the choice was all right So what cloud do we build what cloud do we use because there's lots of different models that are out there? And and a lot of you guys probably know sass isn't cloud right software is the service in cloud Not the the same thing and so as each of the different groups was looking at you know How do I deliver my application and more of a sass like cloud like model? They all started down different paths. Some of them were looking at just you know dedicated hosting and gear That they would run their application on others were looking at how do I leverage existing public clouds that are out there? Others were looking at how do we develop our own cloud to run in our own cloud open stack was often chosen But there were even multiple different iterations of open stack that were chosen But ultimately when we took a step back from a Cisco perspective and said We need to take a little bit better control over our own destiny In the software market and in the cloud market and it is core to our success It's core to our strategy to own and leverage that core cloud component And so when we looked at the different options that were out there as a company the company chose open stack as that platform for software development and and sort of a few reasons but the main one is again go back to that previous chart of speed the main one is Speed we need to be able to develop quickly We need to be able to have everything be automated everything be accessible via an API another key aspect of Cisco strategy is a Combination of both a public cloud deployment model and a private cloud deployment model and so our application developers You know I'll take collaboration as an example Want to be able to deploy some of their applications and assets up into a public-facing cloud where their Applications and services are available over the internet others may need to go on-prem in major enterprises They don't want to have to develop the two different applications with two different operating models two different architectures for public cloud versus private cloud so we can leverage open stack as a common open standard space model that we can use either on-prem or off-prem Then we have a single development environment that we can use for our application So much better from an application developer standpoint if we can Develop to one set of standards and have both public and private models And so you know everything automated everything via API is everything developer centric So I have to to the IT guys, but it's not necessarily funneling through IT work order requests and service catalogs, but it's You know order compute out of a catalog You fire off an API which spins up a server and you're using it. There's no order There's no approval process for that order. This is actually one of the interesting things that Has changed in how developers and others consume cloud is there's a lot of products that are out there Especially in the sort of the enterprise space the IT space that are very service catalog like and this whole concept of I'm gonna go to my portal and I'm gonna pick my services out of a service catalog and I'm gonna order those services it's very contrary to how Developers want to do things developers want to be able to just spin up a server or use it All right, I'm done Let me you know spin it down turn it back off And so it's less of a order something former from a catalog and more of a use and consume services And so you know for that give a bit of term now what developers are quote-unquote ordering from the catalog is they're ordering an empty box Here's an empty box. You can put whatever is in that box. That's available You can put it together in whatever way that you want available And we're just going to measure what goes into that box and comes out of that box And at the end of the month you're going to get a bill for how much you consumed out of that box So you're ordering the capability as opposed to ordering the individual services And so that's greatly increased the agility of a lot of our developers And the other reason why we needed to build our own cloud Is you know some people call it drink in their own champagne, but we'll go back to the the original statement here Which is to eat your own dog food so? Cisco strategy has been for a long time now developing technology For enterprises service providers, etc to build clouds We've been in the open-stack business for a long time What better way to help drive our own internal products whether they're the switches servers Software etc to be ready for a cloud model Then by running a massive scale multi-tenant cloud at scale Ourselves we can be you know our own best customer sometimes their own worst customer Depending upon the situation But you know we're certainly use case number one when it comes to a lot of those new products and new services That are being built into to cloud and so you know helps our developers back on the hardware side You know at Cisco sometimes the you know enterprise markets not the same as the service provider market Sometimes you know even the service provider market for a private cloud is different than what a service provider would need to be able to Build something at global scale and so it's very important for us You know to build this cloud using our own products help drive our own products to be better in cloud So it's really kind of a sort of a back-and-forth relationship Inside at Cisco which is you know we're both the operator, but I'm also the operator using Cisco kit so I'm building all of this cloud on Cisco UCS on Cisco You know Nexus it's it's all Cisco kit that sits in the back end and then it's you know Generally a bunch of open source software some commercial software etc. That sits you know sort of on top of an and around it But you know we've talked a lot about you know a global cloud But you know let's rewind two years ago when we first really started this this cloud and it was really Only a couple of spots so we had you know one region in Texas one region in North Carolina This was this was our starting point. This is where we started a couple of years ago So not terribly global in nature to start, but everyone's got to start Somewhere and the services that we started with were you know all the the core services that you know Everyone here that you know sort of goes to all these open stack sessions that you'll know and love so you know Nova based compute services We've got cinder based storage services swift based storage services keystone for authorization We've got heat capabilities for orchestration Solometer now for you know alerting capability Obviously a lot of neutron functionality within our cloud at Cisco private networks load balancing firewall Floating IPs other capabilities on the networking side But you know it's the sort of the core base building blocks that most developers are you're looking at and leveraging and using today So you know we're working on higher level services. We're working on adding things like database capabilities big data capabilities You know more advanced networking functionality things like that into the cloud But you know again you start with the basics and the basics in cloud means you know starting with core, you know compute storage Etc. But the one thing that you know we certainly found out rather quickly as we started building this this cloud is that You know there's the open stack services and capabilities and that's great for that for you know set of services You know it's now I can spin up VMs and things like that But when you want to offer an actual service based on open stack There's a lot more work and effort that goes into offering a service based on open stack Then just the open stack components themselves and so you know again. I've seen people wearing you know shirts is You don't see any here in the audience though. It's well it worked on dev stack And it's you know sort of one of those common things right which is you know I downloaded dev stack I got it up and running my service it worked on dev stack Why is it not working in the the bigger cloud and there's there's a lot more to cloud than just the base Open stack services and even the behavior of some of the services are a lot different when you try to run them You know at a much larger scale and in a multi-tenant environment than than than otherwise And so whether it's things like monitoring and all the software that has to sit around the cloud to monitor the cloud There's not you know a core open stack project for that yet Although you know, I know there's work there cloud pulse. Is that right Jeff is one of the new projects? Manasca so there's a couple of new projects there they're up and going in the monitoring space the whole software life cycle of How do I deploy it? How do I maintain code? How do I merge in updates to code and how do I maintain you know all of this and be able to do continual upgrades? Lot of work that gets spun around open stack for how do I automate the deployment of not just the open stack components? But all the rest of the components and the system as well open stack Scott authorization Capability with Keystone, but you still need some sort of an identity management system that's sitting behind it And if you're just you know internal in an enterprise you can you know tie it in via you know LDAP or active directory to your AD system But again if you're trying to do something that's you know multi-tenant federated etc You need much more that sits next to it and behind it to be able to make all of that work Metering and billing capabilities if you're going to do something in a multi-tenant Environment you need metering and billing capabilities so that you can start to look at not just the services in open stack How many hours was excuse me this instance on versus you know how many gigabytes per month of storage that I use here? But you know also how much network traffic? Was passing back and forth so you need to be able to meter and bill for services that sit outside of open stack And then you need to be able to onboard customers And so you know something needs to sit there that says create this customer You know in open stack you've got the concept of a project that lives within one region Well customers think a little bit differently than that as well I mean I've got a customer and I have an account and my account I may spin up projects in multiple Regions, but I still need that level of hierarchy and again that doesn't exist within with an open stack today Or at least it didn't when we started Down this road a couple of years ago so lots of stuff is progressing but at least when we got started a lot more involved in Building and running a cloud service based on open stack than just the core open stack services themselves, and so You know if I go back to you know word we start with that footprint And where are we going one of the things we found was that as we started talking to more and more Service providers that are out there in the market you know whereas Cloud was core to what we were doing some of the service providers. We were talking with decided you know what I need to offer Cloud services, but actually building and operating a cloud, especially a global cloud Isn't necessarily core to my business And so that's where we started partnering with service providers And so Telstra was the first service provider that we announced a partnership with we announced it when we First launched this service and talked about it almost a year ago about a year ago at this point Deutsche telecom was the the more recent one that we've talked about now in and out So they're the only two that we've publicly talked about there's multiple more that are I hope you've able to talk about here Very soon, but the premise here is it's not a typical Cisco premise of I'm gonna sell Telstra gear Maybe I'm gonna sell them a full reference architecture Maybe I'll sell them the full set of software that we run and then they run and operate the cloud the premise here was again Telstra was saying to us Cisco it's not our strategy to be the builder and operator of an open stack based public cloud service I need that service and capability as part of my portfolio as part of my overall cloud strategy to offer my customers But I don't have the the skill or expertise to be able to you know build and run it and Compete on a on a global basis Cisco you guys are building a global cloud Can we partner with you? And so you know as we looked at it as Really a strategy started to cement itself is as we can partner with service providers around the globe We can deploy regions of our cloud into their data centers So we've got regions were up and running in Telstra's data centers today. We're installing those regions we'll have them up and running in Deutsche telecoms data centers in Germany later this year We've got the same hardware the same architecture the same services software Etc. Now deployed in multiple data centers around the globe. And so if you look at where this footprint goes You know now I've got multiple regions up and running in the United States We've got a couple of regions up and running in Europe and we're adding more before the end of this year So have multiple regions running in Europe Again, the some of those are with Deutsche telecom in Germany We've got regions up and running in Australia with Telstra We'll have more regions coming up later on this year in Asia as well. So now we've got this global presence being built in conjunction with our service providers and being built in conjunction with their facilities Not only on the data center side, but their facilities on the network side as well So we start being able to leverage a cloud deployment that is in service provider networks closer out to The edge of the infrastructure closer out to the edges of their networks So closer to their customers closer to where those data those sensors etc. Lie for you know Interactive things in order of everything type applications. So a significant amount more footprint being deployed again This is only with the first couple of partners that we have deployed many more partners are coming and you know our strategy here is less around sort of maybe more like a Google or an Amazon strategy, which is How do I build the smallest number of massive data centers that gives me a reasonable sort of latency reach policy? globally our strategy is not the opposite of that, but it's certainly more towards the other spectrum which is Especially when you look at data centric capabilities network centric Applications lots of data coming in from you know sensors and you know data and things and stuff like that on the edge of the Network that data tends to want to live out closer to the edge of the network the applications tend to want to be deployed further out in the network closer to Where the end customers that in data goes the applications the virtual network services tend to want to live Further out towards the edge of the network near the edges of the physical Infrastructure so I can spin up virtual firewalls or virtual BRAS or virtual VPNs or virtual other Services that sit out in the edge of the network and so now it's more about how do we build more regions in More countries because by the way data sovereignty is also a key part of that that aspect by building more regions in more countries Attached to the edges of more service provider edge locations now we start to build this you know global Cloud and even ultimately global federated network of clouds if you start to bring in you know partner clouds and on-premise private clouds As well that has the same underlying platform really spread out across the entire globe So from an application developer standpoint now I can develop my application You know one time and I have a much larger footprint of where that application is going to go Where that application could be deployed much better profiles in terms of reaching some of those smaller regions out that if I'm deploying an app into you know one of the major global public cloud providers I may have a choice of six to eight maybe a dozen regions that can get deployed in Ultimately as we deploy more locations with more service providers will have you know 50 60 plus Locations around the globe where you can start to put this in and again think back to one of the reasons why we chose open stack as a cloud is The open aspect of it open standards and the ability to now extend that cloud out On-premise or maybe you're extending that cloud or extending some of the the core compute and storage capabilities You know out to devices that live on-prem or maybe they're you know in you know really small racks of Equipment that sit next to the edge routers in service provider locations Maybe they're blades that sit inside the routers themselves if I can leverage an open source cloud Platform as a way to gain access to compute and storage and That compute and storage is tied in together with network Now I can start to do a lot more interesting things and so You know sun set a long time ago back in the 80s the network is the the computer And I think it was I think it's probably more right now than it was then we've had a lot of stuff Sort of come to be and I think it's been right to varying degrees over time but if you look at where we are now and the amount of Computing power that you have that you can get you know even on to very small things You know that computing power is very distributed very distributed across a network And now even use a lot of hype and talk these days about even fog computing right which is you know There isn't so much the cloud But it really starts to extend out closer to the edge into more devices more on-prem You know this is one of the things that's enabled through Open source and open standards and being able to drive with with open stack And so this is one of the reasons why again We chose open stack is that platform that we want to build on because we have this Community that we can leverage that's helping to develop services and this community of partners and other providers That are spinning up open stack based clouds while they're not Cisco's again same Core software same core services same set of standards and if we can start looking at how do we unify things around? You know API so that we can start to federate between disparate clouds This is where things really start to become interesting from an open stack a perspective And so you know as we look at where we are today You know there's some still some challenges in terms of getting to where we need to go There's challenges on the Federation up front, you know Jeff over here He's got a blueprint a working group that spun up around How do we look at and start addressing some of these challenges around Federation you've got? Multi-provider clouds, you know, so just take the cloud that we're building Is you know sort of one cloud but sold through multiple providers in multiple providers network with different identity systems There were different networks that it high has to tie in together to and that's just with the one cloud that we're doing the You know sort of continuous development and deployment of software to now think of all the other Service providers or cloud providers that are building open stack based clouds think of all the on-premise Enterprises that are building open stack based clouds. How do you enable? Federation such that I can easily put parts of my application in one versus the other or even across both Put them into different ones multi-provider multi-tenant multi-network and Networking at scale is one of the other big challenges that still remains And this is obviously a key focus for us here at Cisco not so much in my group But in some of the other groups at Cisco from us solving these problems, you know Major issues, especially when you start to look at multi-tenancy And open stack and when you start to look at the layer two and layer three forwarding Capabilities all the way down into the hypervisor, you know, how do I offload some of those to the NICS? So the NIC can take on some of them How do I do things like ARP suppression so that I can you keep the broadcast traffic more localized instead of spreading? And so there's some talks I know this week and the developer side around the work that we're doing with ACI our application Centric infrastructure and open stack and the plugins there There's other talks that are going on around a group-based policy and how we start to think on application level policy And how that gets implemented not only in the virtual networks But in the physical networks underneath as we look to scale a lot of focus and effort on IPv6 And again think back to one of the drivers as to why we're doing this Why we chose open stack and why we chose to build our own cloud is around building a platform for the Internet of everything And the Internet of everything has lots of things that are sitting out there and every one of those things needs an address And you know every one of those addresses can't be an IPv4 address. So IPv6 is going to become crucial I'll go back to my video example again Video is just one of the early examples of that think of every set top box that's out there and every set top box There's multiple in every house as those set top boxes are really sort of extensions that are connected back into the cloud Again IPv6 from an addressing perspective becomes key for those those set tops And as we move from set tops to sensors to you know wearables and everything else That's going to have some sort of an IP address, you know again v6 becomes becomes critical DNS Actually, that's a typo. I should have said DHCP, but DHCP is another Another key one another key challenge that we've hit and if you had asked me two years ago when we got started in In building the the open stack cloud What's the major source of frustration? I was going to have sort of year one as we built this out I would not have predicted that it would have been issues with with DHCP But you know one thing that we've found in an open stack and this sort of leads into the the next challenge is Just because it works Just be just because it's in a release of open stack doesn't mean it works. Sorry, unfortunately Just because it works Doesn't mean it works in a multi-tenant environment And just because it works in a multi-tenant environment doesn't mean it works at a multi-tenant environment at scale And so you know DNS was or sorry, I keep saying that I've got DNS on the brain DHCP was just one of the the early Examples there. There's a whole lot of examples another one. My favorite one is to use this is Celerometer So Celerometer has been around for a few releases now. I think it came out in Grizzly Is really where it first started, but you know even now in the the latest releases It's still possible to essentially do what amounts to a denial of service attack against a lot of the tenants By doing your own user to find metrics within Celerometer because there aren't a lot of ways to clamp down on the multi-tenancy capabilities when you start having multiple folks in there and so again, the last challenge here is you know a question I often get and it ends up being a rather frustrating question is So what release of open stack are you running? and and my Depending on my mood flip it answer is why do you care? You shouldn't care what release of open stack. I'm running because the reality is I'm actually running sort of a hodgepodge of multiple releases I may have some core stuff that's ice house because it was you know deployed when we were based on ice house and is You know been stable and been rock solid other stuff I may be running the Juno brace version other stuff I may pull in some stuff off of off of kilo to be able to backport some fixes from there But it ends up being you know sort of this hodgepodge of multiple things and again just because a feature exists in a given release Doesn't mean it works and doesn't mean we offer it from a cloud perspective So asking what release what version of open stack you're running is really kind of the wrong Question to be asking the better question to be asking is what features and capabilities? Do you support and if you do need to ask what release of something the key thing there is what version of the API? Are you running because that's the thing you're gonna talk to you're gonna talk to those API's and you need to know the version of those API so You can make sure that you're talking the same version with the same controls But you don't need to know what release of open stack someone's running You know rack space they don't advertise there's there's nothing written on rack spaces, you know websites on you know We're running kilo or anything else like that You know there they're based on something underneath, but they have a lot of stuff underneath same with Cisco open stack private cloud It's based on a particular release, but then there's a lot of work that's been done throughout the process And then the other challenge is When it becomes what release? And I know the opensack community is working on this, but what's a release of open stack even mean? These days and so for me to be running Juno or me to be running, you know kilo Yet, there's lots of new things that I need to put in How do we start to decouple the various open stack services so that it's less around what release of open stack? Am I running but now what release of? Horizon or what release of neutron what release of neutron with what release of OVS with what release of you know These these more individual silos matter significantly more than what release of open stack And so you know how we deal with that from a reality perspective of sort of software deployment code deployment Nova and neutron tend to still be very coupled With each other from a deployment perspective such that changes in one you can have a dramatic impact on the other So how do we more loosely couple these different projects so the different projects can move at their own pace So that's more the technical side But then there's the business side and the business sort of questions again Around compatibility and what release are you running and what's it mean to be an open stack a cloud? Doesn't mean you need to be having to run the actual code doesn't need to mean you need to run the certain Apis at a certain version. What are the core services? So there's a lot of other aspects that sit into that as well and the reason this is important is Because Developers want a hybrid model to be able to deploy their applications on hybrid cloud is is less and less meaning I have VMs on-prem with a layer 2 tunnel to VMs off-prem You know that's sort of what a lot of people used to call hybrid cloud was I've got my enterprise And I'm running you know some sort of a cloud here or some sort of a virtualization platform here And I'm extending my on-prem enterprise environment up into a cloud Really these days hybrid deployment is more about how I deploy my application Across multiple cloud platforms, and it may be across two different public clouds That's a hybrid model. It may be across my on-prem open stack and my off-prem Public open stack cloud as well, but developers want to be able to develop their application Such that it can be deployed into different environments with different You know for different control reasons or compliance reasons security reasons, etc There's a reason why some data needs to live on-prem and some data can live off You know you start thinking about where your data lives versus where your processing lives versus where your presentation front-end Lives some of that I may want in a public cloud close to the internet backbone providers with you know Better DNS and routing and performance, etc But I may want to keep a lot of that data back On-prem and so hybrid deployments end up taking on sort of a a different connotation When suddenly I have a common development environment that I can leverage across all of those because you know It's probably a lot of the folks in this room or developers You all understand the more permutations you need to test and support The harder it becomes and this is actually another one of those reasons that You know it doesn't really matter what release of open stack Given provider is is running because you don't need to think about multiple releases anyway Whatever whatever they're running and exposing is the latest that they're running and exposing and so even the concept of something like You know release notes is you know as a cloud provider You don't need a release notes for Juno and then a release notes for for kilo because You're not just deploying Juno and then waiting and deploying kilo and while that region's running Juno And this region's running you know kilo and so look at your look at your release notes It's it's more of an ongoing continuous iteration and process of what are the new you know pieces of functionality features capabilities Etc that we just introduced what are the open issues that you know sort of exist right now It's a much different process a much different mental model than than used to than used to exist so You know back to eating our own dog food Some of the announced services that are running on the platform today Cisco spark You know aspects of it are running on top of our cloud today our energy management That was from our acquisition of a company called Julex a little while ago That's more of an internet of everything type application. We're getting energy Data from devices and now you're doing analytics and processing around that mobility IQ This was launched at Mobile World Congress a couple of months ago This is again collecting Sensor data from wireless LAN controllers and access points things like that and being able to provide you know more real-time Analytics for you know folks that are looking at doing events. I you know, and I think that might be might be Madison Square Garden It's a it's come to have a stadium It's around all right. Where are the high wire are the hot spots right now from a Wi-Fi perspective? You know, where's everyone hanging out? Where are they going? What are they doing again? A lot of this becomes around how do I gather a lot of that data? How do we do analysis on that data then how do we present that back up in a way that's that's sort of Useful for others to to consume so just a few of the applications that are running on our cloud today But again think back to those sort of common patterns that were emerging that I talked about at the beginning Whether it's you know lots of data, you know peaks in usage whether it Whether it is a latency profiles for being out close again Collaboration very latency Sensitive tends to be yeah kind of peaky energy management is less around peaks more about lots of data the mobility IQ Tends to have lots of big peaks as certain events are running and I'm getting a lot more data than when events You know aren't running, but there's also massive amounts of data So all these applications that are running on top of the Cisco cloud tend to have a lot of the same in same common Characteristics and there's people running standard web apps, you know on our cloud as well You know standard web applications run just fine. We've got the same compute storage, you know Networking capabilities is just about everyone else's is public cloud out there But that's not what we're building the cloud for if all we needed was basic compute and storage There's you know lots of ways and reasons That we could get that or other people that we could get that from the the core to why we're building and operating a cloud and Why we chose OpenStack is on looking at those set of applications and why we partner with service providers by the way It's looking at those applications that are more network centric latency sensitive jitter sensitive Generating significant amounts of data that wants to live out closer to the edge closer to you know Where those devices where those those customers are? And so you've probably seen this if you've been to a few of the Cisco sessions or you've been to a booth You've sort of seen this this tagline You know build OpenStack use OpenStack connect OpenStack and and really kind of what we're doing in CIS is kind of that combination of all three is we're leveraging a lot of the groups inside of Cisco that are building capabilities around OpenStack We're doing code contributions and back into the community ourselves as we you know see issues and fix bugs things like that We're obviously using OpenStack. We're a full public operator of OpenStack You know, I should say you can't go to cloud.sysco.com and enter your information a credit card and sign up That's you know, we're not a retail cloud provider. Doesn't mean we're not a provider of public cloud services If you happen to live in Australia and have an Australian business number You can go to Telstra's website sign up with a credit card and get going because there are a retail cloud provider to their customers But you know Cisco's not at this point So no cloud.sysco.com that you can go to but we are a major user of OpenStack And again for those Cisco applications and services and then how we connect all of those together So I think we probably have a couple minutes here at the end. You guys are kind of a client group Through and didn't ask any questions, but we've probably got a couple more minutes here at the end if anyone has any questions I was either really thorough or Yeah So interesting talk, I'll throw you a question You talked a lot about doing the federated inter cloud thing for presumably managing The Federation of cloud infrastructure being able to manage where things are pushing things to the edge Do you see in your customer base the need to federate? Services and resources at the application level. Do you see that from your users? And the second part of the question is for all of the machinery that you've built so far for managing what you do have Do you think that's also applicable to managing user level federations? Yeah, it's a good question when you look at sort of federating services and applications That's a lot of where we're going is and how do we make Services are above the infrastructure layer. So not just compute and storage but services that sit above Maybe it's you know messaging or database or maybe it's specialized, you know Analytics and being able to make those federated for applications and for users that want to keep some of their data in a particular Geography and have some of it sit, you know resident elsewhere So certainly Federation up in an application level is another key part of what we're doing That's less and what we're doing in my group and more what you know some of the groups that sit above us that are developing applications are looking at in terms of the same infrastructure for User Federation was that same part of your question? Yeah, I mean in what I've looked at You know you can try to generalize the infrastructure Federation and it generalizes to actually being able to manage, you know everything assuming that you have the right You know metadata and service catalogs and you know all that kind of stuff an agreement across all the different organizations that Yeah, federating across well fed and Federation stuff, right, especially at a service provider Levels which is why what we're what we're not doing initially is you know Deploying some stuff for Telstra and some stuff for DT and some stuff for service provider AB and C And then if you want to deploy across those service providers You have to go sign up with Telstra and sign up with DT and sign up with because that's that's a Federation model That's like a mobile and it's not even more of a mobile roaming model But it is kind of a Federation model where you have different business propositions with different providers You know what we're doing is is more one of whoever you sign up with let's say you're a customer of Telstra Then you'll have access to all the regions that are that have been globally deployed You don't have to go do separate contracts with each one of those because that's one of those business problems that that makes it tough Federation and service providers is kind of tough service providers Don't really peer with each other terribly well on a whole lot other than sort of you know transit IP packets and sort of mobile minutes today You know they you know didn't get there when people were trying CDN Federation Which was a big thing of not too many years ago It's been a lot of things that that hasn't sort of gotten there yet So you know our model is sort of sticking a little bit closer and maintaining a little bit more in the middle here To to help this concept then up purely everything to everything federated model I think we'll get there, but to be honest I think the business challenges in Federation are greater than the technical challenges But come see Jeff because he's we he's working on exactly those issues Hey, I'll be hanging out around here if you guys have any other follow-up questions. Thanks very much