>> From every ISV to solve the problems. You want there to be tools in place that you can use, either open source tools or whatever it is that help you build it. And slowly over time, that building will become easier and easier. So my question to you was, where do you see you playing? Do you see yourself playing to ISVs as a set of tools, which will make their life a lot easier and provide that work? >> Absolutely. >> If they don't have, so they don't have to do it. Or you're providing this for the end users? Or both? >> So it's a progression. If you go to the ISVs first, you're doomed to starved before you have time for that other option. >> Yeah. >> Right? So it's a question of phase, the phasing of it. And also if you go directly to end users, you can demonstrate the power of it and get the attention of the ISVs. I believe that the ISVs, especially those with the biggest footprints and the most, you know, coveted estates, they have already made massive investments at trying to solve decentralization of their software stack. And I believe that they have used it as a hook to try to move to a software as a service model and rope people into leasing their infrastructure. So if you look at the clouds that have been propped up by Autodesk or by Adobe, or you name the company, they are building proprietary makeshift solutions for decentralizing or hybrid clouding. Or maybe they're not even doing that at all and all they're is saying hey, if you want to get location agnosticness, then what you should just, is just move into our cloud. >> Right. >> And then they try to solve on the background how to decentralize it between different regions so they can have decent offerings in each region. But those who are more advanced have already made larger investments and will be more averse to, you know, throwing that stuff away, all of their makeshift machinery away, and using a platform that gives them high performance parallel, low level file system access, while at the same time having metadata-driven, you know, policy-based, intent-based orchestration to manage the diffusion of data across a decentralized infrastructure. They are not going to be as open because they've made such an investment and they're going to look at how do they monetize it. So what we have found with like the movie studios who are using us already, many of the app they're using, many of those software offerings, the ISVs have their own cloud that offers that software for the cloud. But what we got when I asked about this, 'cause I was dealt specifically into this question because I'm very interested to know how we're going to make that leap from end user upstream into the ISVs where I believe we need to, and they said, look, we cannot use these software ISV-specific SAS clouds for two reasons. Number one is we lose control of the data. We're giving it to them. That's security and other issues. And here you're talking about we're doing work for Disney, we're doing work for Netflix, and they're not going to let us put our data on those software clouds, on those SAS clouds. Secondly, in any reasonable pipeline, the data is shared by many different applications. We need to be agnostic as to the application. 'Cause the inputs to one application, you know, the output for one application provides the input to the next, and it's not necessarily from the same vendor. So they need to have a data platform that lets them, you know, go from one software stack, and you know, to run it on another. Because they might do the rendering with this and yet, they do the editing with that, and you know, et cetera, et cetera. So I think the further you go up the stack in the structured data and dedicated applications for specific functions in specific verticals, the further up the stack you go, the harder it is to justify a SAS offering where you're basically telling the end users you need to park all your data with us and then you can run your application in our cloud and get this. That ultimately is a dead end path versus having the data be open and available to many applications across this supercloud layer. >> Okay, so-- >> Is that making any sense? >> Yes, so if I could just ask a clarifying question. So, if I had to take Snowflake as an example, I think they're doing exactly what you're saying is a dead end, put everything into our proprietary system and then we'll figure out how to distribute it. >> Yeah. >> And and I think if you're familiar with Zhamak Dehghaniis' data mesh concept. Are you? >> A little bit, yeah. >> But in her model, Snowflake, a Snowflake warehouse is just a node on the mesh and that mesh is-- >> That's right. >> Ultimately the supercloud and you're an enabler of that is what I'm hearing. >> That's right. What they're doing up at the structured level and what they're talking about at the structured level we're doing at the underlying, unstructured level, which by the way has implications for how you implement those distributed database things. In other words, implementing a Snowflake on top of Hammerspace would have made building stuff like in the first place easier. It would allow you to easily shift and run the database engine anywhere. You still have to solve how to shard and distribute at the transaction layer above, so I'm not saying we're a substitute for what you need to do at the app layer. By the way, there is another example of that and that's Microsoft Office, right? It's one thing to share that, to have a file share where you can share all the docs. It's something else to have Word and PowerPoint, Excel know how to allow people to be simultaneously editing the same doc. That's always going to happen in the app layer. But not all applications need that level of, you know, in-app decentralization. You know, many of them, many workflows are pipelined, especially the ones that are very data intensive where you're doing drug discovery or you're doing rendering, or you're doing machine learning training. These things are human in the loop with large stages of processing across tens of thousands of cores. And I think that kind of data processing pipeline is what we're focusing on first. Not so much the Microsoft Office or the Snowflake, you know, parking a relational database because that takes a lot of application layer stuff and that's what they're good at. >> Right. >> But I think... >> Go ahead, sorry. >> Later entrance in these markets will find Hammerspace as a way to accelerate their work so they can focus more narrowly on just the stuff that's app-specific, higher level sharing in the app. >> Yes, Snowflake founders-- >> I think it might be worth mentioning also, just keep this confidential guys, but one of our customers is Blue Origin. And one of the things that we have found is kind of the point of what you're talking about with our customers. They're needing to build this and since it's not commercially available or they don't know where to look for it to be commercially available, they're all building themselves. So this layer is needed. And Blue is just one of the examples of quite a few we're now talking to. And like manufacturing, HPC, research where they're out trying to solve this problem with their own scripting tools and things like that. And I just, I don't know if there's anything you want to add, David, but you know, but there's definitely a demand here and customers are trying to figure out how to solve it beyond what Hammerspace is doing. Like the need is so great that they're just putting developers on trying to do it themselves. >> Well, and you know, Snowflake founders, they didn't have a Hammerspace to lean on. But, one of the things that's interesting about supercloud is we feel as though industry clouds will emerge, that as part of company's digital transformations, they will, you know, every company's a software company, they'll begin to build their own clouds and they will be able to use a Hammerspace to do that. >> A super pass layer. >> Yes. It's really, I don't know if David's speaking, I don't want to speak over him, but we can't hear you. May be going through a bad... >> Well, a regional, regional talks that make that possible. And so they're doing these render farms and editing farms, and it's a cloud-specific to the types of workflows in the median entertainment world. Or clouds specifically to workflows in the chip design world or in the drug and bio and life sciences exploration world. There are large organizations that are kind of a blend of end users, like the Broad, which has their own kind of cloud where they're asking collaborators to come in and work with them. So it starts to even blur who's an end user versus an ISV. >> Yes. >> Right? When you start talking about the massive data is the main gravity is to having lots of people participate. >> Yep, and that's where the value is. And that's where the value is. And this is a megatrend that we see. And so it's really important for us to get to the point of what is and what is not a supercloud and, you know, that's where we're trying to evolve. >> Let's talk about this for a second 'cause I want to, I want to challenge you on something and it's something that I got challenged on and it has led me to thinking differently than I did at first, which Molly can attest to. Okay? So, we have been looking for a way to talk about the concept of cloud of utility computing, run anything anywhere that isn't addressed in today's realization of cloud. 'Cause today's cloud is not run anything anywhere, it's quite the opposite. You park your data in AWS and that's where you run stuff. And you pretty much have to. Same with with Azure. They're using data gravity to keep you captive there, just like the old infrastructure guys did. But now it's even worse because it's coupled back with the software to some degree, as well. And you have to use their storage, networking, and compute. It's not, I mean it fell back to the mainframe era. Anyhow, so I love the concept of supercloud. By the way, I was going to suggest that a better term might be hyper cloud since hyper speaks to the multidimensionality of it and the ability to be in a, you know, be in a different dimension, a different plane of existence kind of thing like hyperspace. But super and hyper are somewhat synonyms. I mean, you have hyper cars and you have super cars and blah, blah, blah. I happen to like hyper maybe also because it ties into the whole Hammerspace notion of a hyper-dimensional, you know, reality, having your data centers connected by a wormhole that is Hammerspace. But regardless, what I got challenged on is calling it something different at all versus simply saying, this is what cloud has always meant to be. This is the true cloud, this is real cloud, this is cloud. And I think back to what happened, you'll remember, at Fusion IO we talked about IO memory and we did that because people had a conceptualization of what an SSD was. And an SSD back then was low capacity, low endurance, made to go military, aerospace where things needed to be rugged but was completely useless in the data center. And we needed people to imagine this thing as being able to displace entire SAND, with the kind of capacity density, performance density, endurance. And so we talked IO memory, we could have said enterprise SSD, and that's what the industry now refers to for that concept. What will people be saying five and 10 years from now? Will they simply say, well this is cloud as it was always meant to be where you are truly able to run anything anywhere and have not only the same APIs, but you're same data available with high performance access, all forms of access, block file and object everywhere. So yeah. And I wonder, and this is just me throwing it out there, I wonder if, well, there's trade offs, right? Giving it a new moniker, supercloud, versus simply talking about how cloud is always intended to be and what it was meant to be, you know, the real cloud or true cloud, there are trade-offs. By putting a name on it and branding it, that lets people talk about it and understand they're talking about something different. But it also is that an affront to people who thought that that's what they already had. >> What's different, what's new? Yes, and so we've given a lot of thought to this. >> Right, it's like you. >> And it's because we've been asked that why does the industry need a new term, and we've tried to address some of that. But some of the inside baseball that we haven't shared is, you remember the Web 2.0, back then? >> Yep. >> Web 2.0 was the same thing. And I remember Tim Burners Lee saying, "Why do we need Web 2.0? "This is what the Web was always supposed to be." But the truth is-- >> I know, that was another perfect-- >> But the truth is it wasn't, number one. Number two, everybody hated the Web 2.0 term. John Furrier was actually in the middle of it all. And then it created this groundswell. So one of the things we wrote about is that supercloud is an evocative term that catalyzes debate and conversation, which is what we like, of course. And maybe that's self-serving. But yeah, HyperCloud, Metacloud, super, meaning, it's funny because super came from Latin supra, above, it was never the superlative. But the superlative was a convenient byproduct that caused a lot of friction and flack, which again, in the media business is like a perfect storm brewing. >> The bad thing to have to, and I think you do need to shake people out of their, the complacency of the limitations that they're used to. And I'll tell you what, the fact that you even have the terms hybrid cloud, multi-cloud, private cloud, edge computing, those are all just referring to the different boundaries that isolate the silo that is the current limited cloud. >> Right. >> So if I heard correctly, what just, in terms of us defining what is and what isn't in supercloud, you would say traditional applications which have to run in a certain place, in a certain cloud can't run anywhere else, would be the stuff that you would not put in as being addressed by supercloud. And over time, you would want to be able to run the data where you want to and in any of those concepts. >> Or even modern apps, right? Or even modern apps that are siloed in SAS within an individual cloud, right? >> So yeah, I guess it's twofold. Number one, if you're going at the high application layers, there's lots of ways that you can give the appearance of anything running anywhere. The ISV, the SAS vendor can engineer stuff to have the ability to serve with low enough latency to different geographies, right? So if you go too high up the stack, it kind of loses its meaning because there's lots of different ways to make due and give the appearance of omni-presence of the service. Okay? As you come down more towards the platform layer, it gets harder and harder to mask the fact that supercloud is something entirely different than just a good regionally-distributed SAS service. So I don't think you, I don't think you can distinguish supercloud if you go too high up the stack because it's just SAS, it's just a good SAS service where the SAS vendor has done the hard work to give you low latency access from different geographic regions. >> Yeah, so this is one of the hardest things, David. >> Common among them. >> Yeah, this is really an important point. This is one of the things I've had the most trouble with is why is this not just SAS? >> So you dilute your message when you go up to the SAS layer. If you were to focus most of this around the super pass layer, the how can you host applications and run them anywhere and not host this, not run a service, not have a service available everywhere. So how can you take any application, even applications that are written, you know, in a traditional legacy data center fashion and be able to run them anywhere and have them have their binaries and their datasets and the runtime environment and the infrastructure to start them and stop them? You know, the jobs, the, what the Kubernetes, the job scheduler? What we're really talking about here, what I think we're really talking about here is building the operating system for a decentralized cloud. What is the operating system, the operating environment for a decentralized cloud? Where you can, and that the main two functions of an operating system or an operating environment are the process scheduler, the thing that's scheduling what is running where and when and so forth, and the file system, right? The thing that's supplying a common view and access to data. So when we talk about this, I think that the strongest argument for supercloud is made when you go down to the platform layer and talk of it, talk about it as an operating environment on which you can run all forms of applications. >> Would you exclude--? >> Not a specific application that's been engineered as a SAS. (audio distortion) >> He'll come back. >> Are you there? >> Yeah, yeah, you just cut out for a minute. >> I lost your last statement when you broke up. >> We heard you, you said that not the specific application. So would you exclude Snowflake from supercloud? >> Frankly, I would. I would. Because, well, and this is kind of hard to do because Snowflake doesn't like to, Frank doesn't like to talk about Snowflake as a SAS service. It has a negative connotation. >> But it is. >> I know, we all know it is. We all know it is and because it is, yes, I would exclude them. >> I think I actually have him on camera. >> There's nothing in common. >> I think I have him on camera or maybe Benoit as saying, "Well, we are a SAS." I think it's Slootman. I think I said to Slootman, "I know you don't like to say you're a SAS." And I think he said, "Well, we are a SAS." >> Because again, if you go to the top of the application stack, there's any number of ways you can give it location agnostic function or you know, regional, local stuff. It's like let's solve the location problem by having me be your one location. How can it be decentralized if you're centralizing on (audio distortion)? >> Well, it's more decentralized than if it's all in one cloud. So let me actually, so the spectrum. So again, in the spirit of what is and what isn't, I think it's safe to say Hammerspace is supercloud. I think there's no debate there, right? Certainly among this crowd. And I think we can all agree that Dell, Dell Storage is not supercloud. Where it gets fuzzy is this Snowflake example or even, how about a, how about a Cohesity that instantiates its stack in different cloud regions in different clouds, and synchronizes, however magic sauce it does that. Is that a supercloud? I mean, so I'm cautious about having too strict of a definition 'cause then only-- >> Fair enough, fair enough. >> But I could use your help and thoughts on that. >> So I think we're talking about two different spectrums here. One is the spectrum of platform to application-specific. As you go up the application stack and it becomes this specific thing. Or you go up to the more and more structured where it's serving a specific application function where it's more of a SAS thing. I think it's harder to call a SAS service a supercloud. And I would argue that the reason there, and what you're lacking in the definition is to talk about it as general purpose. Okay? Now, that said, a data warehouse is general purpose at the structured data level. So you could make the argument for why Snowflake is a supercloud by saying that it is a general purpose platform for doing lots of different things. It's just one at a higher level up at the structured data level. So one spectrum is the high level going from platform to, you know, unstructured data to structured data to very application-specific, right? Like a specific, you know, CAD/CAM mechanical design cloud, like an Autodesk would want to give you their cloud for running, you know, and sharing CAD/CAM designs, doing your CAD/CAM anywhere stuff. Well, the other spectrum is how well does the purported supercloud technology actually live up to allowing you to run anything anywhere with not just the same APIs but with the local presence of data with the exact same runtime environment everywhere, and to be able to correctly manage how to get that runtime environment anywhere. So a Cohesity has some means of running things in different places and some means of coordinating what's where and of serving diff, you know, things in different places. I would argue that it is a very poor approximation of what Hammerspace does in providing the exact same file system with local high performance access everywhere with metadata ability to control where the data is actually instantiated so that you don't have to wait for it to get orchestrated. But even then when you do have to wait for it, it happens automatically and so it's still only a matter of, well, how quick is it? And on the other end of the spectrum is you could look at NetApp with Flexcache and say, "Is that supercloud?" And I would argue, well kind of because it allows you to run things in different places because it's a cache. But you know, it really isn't because it presumes some central silo from which you're cacheing stuff. So, you know, is it or isn't it? Well, it's on a spectrum of exactly how fully is it decoupling a runtime environment from specific locality? And I think a cache doesn't, it stretches a specific silo and makes it have some semblance of similar access in other places. But there's still a very big difference to the central silo, right? You can't turn off that central silo, for example. >> So it comes down to how specific you make the definition. And this is where it gets kind of really interesting. It's like cloud. Does IBM have a cloud? >> Exactly. >> I would say yes. Does it have the kind of quality that you would expect from a hyper-scale cloud? No. Or see if you could say the same thing about-- >> But that's a problem with choosing a name. That's the problem with choosing a name supercloud versus talking about the concept of cloud and how true up you are to that concept. >> For sure. >> Right? Because without getting a name, you don't have to draw, yeah. >> I'd like to explore one particular or bring them together. You made a very interesting observation that from a enterprise point of view, they want to safeguard their store, their data, and they want to make sure that they can have that data running in their own workflows, as well as, as other service providers providing services to them for that data. So, and in in particular, if you go back to, you go back to Snowflake. If Snowflake could provide the ability for you to have your data where you wanted, you were in charge of that, would that make Snowflake a supercloud? >> I'll tell you, in my mind, they would be closer to my conceptualization of supercloud if you can instantiate Snowflake as software on your own infrastructure, and pump your own data to Snowflake that's instantiated on your own infrastructure. The fact that it has to be on their infrastructure or that it's on their, that it's on their account in the cloud, that you're giving them the data and they're, that fundamentally goes against it to me. If they, you know, they would be a pure, a pure plate if they were a software defined thing where you could instantiate Snowflake machinery on the infrastructure of your choice and then put your data into that machinery and get all the benefits of Snowflake. >> So did you see--? >> In other words, if they were not a SAS service, but offered all of the similar benefits of being, you know, if it were a service that you could run on your own infrastructure. >> So did you see what they announced, that--? >> I hope that's making sense. >> It does, did you see what they announced at Dell? They basically announced the ability to take non-native Snowflake data, read it in from an object store on-prem, like a Dell object store. They do the same thing with Pure, read it in, running it in the cloud, and then push it back out. And I was saying to Dell, look, that's fine. Okay, that's interesting. You're taking a materialized view or an extended table, whatever you're doing, wouldn't it be more interesting if you could actually run the query locally with your compute? That would be an extension that would actually get my attention and extend that. >> That is what I'm talking about. That's what I'm talking about. And that's why I'm saying I think Hammerspace is more progressive on that front because with our technology, anybody who can instantiate a service, can make a service. And so I, so MSPs can use Hammerspace as a way to build a super pass layer and host their clients on their infrastructure in a cloud-like fashion. And their clients can have their own private data centers and the MSP or the public clouds, and Hammerspace can be instantiated, get this, by different parties in these different pieces of infrastructure and yet linked together to make a common file system across all of it. >> But this is data mesh. If I were HPE and Dell it's exactly what I'd be doing. I'd be working with Hammerspace to create my own data. I'd work with Databricks, Snowflake, and any other-- >> Data mesh is a good way to put it. Data mesh is a good way to put it. And this is at the lowest level of, you know, the underlying file system that's mountable by the operating system, consumed as a real file system. You can't get lower level than that. That's why this is the foundation for all of the other apps and structured data systems because you need to have a data mesh that can at least mesh the binary blob. >> Okay. >> That hold the binaries and that hold the datasets that those applications are running. >> So David, in the third week of January, we're doing supercloud 2 and I'm trying to convince John Furrier to make it a data slash data mesh edition. I'm slowly getting him to the knothole. I would very much, I mean you're in the Bay Area, I'd very much like you to be one of the headlines. As Zhamak Dehghaniis going to speak, she's the creator of Data Mesh, >> Sure. >> I'd love to have you come into our studio as well, for the live session. If you can't make it, we can pre-record. But you're right there, so I'll get you the dates. >> We'd love to, yeah. No, you can count on it. No, definitely. And you know, we don't typically talk about what we do as Data Mesh. We've been, you know, using global data environment. But, you know, under the covers, that's what the thing is. And so yeah, I think we can frame the discussion like that to line up with other, you know, with the other discussions. >> Yeah, and Data Mesh, of course, is one of those evocative names, but she has come up with some very well defined principles around decentralized data, data as products, self-serve infrastructure, automated governance, and and so forth, which I think your vision plugs right into. And she's brilliant. You'll love meeting her. >> Well, you know, and I think.. Oh, go ahead. Go ahead, Peter. >> Just like to work one other interface which I think is important. How do you see yourself and the open source? You talked about having an operating system. Obviously, Linux is the operating system at one level. How are you imagining that you would interface with cost community as part of this development? >> Well, it's funny you ask 'cause my CTO is the kernel maintainer of the storage networking stack. So how the Linux operating system perceives and consumes networked data at the file system level, the network file system stack is his purview. He owns that, he wrote most of it over the last decade that he's been the maintainer, but he's the gatekeeper of what goes in. And we have leveraged his abilities to enhance Linux to be able to use this decentralized data, in particular with decoupling the control plane driven by metadata from the data access path and the many storage systems on which the data gets accessed. So this factoring, this splitting of control plane from data path, metadata from data, was absolutely necessary to create a data mesh like we're talking about. And to be able to build this supercloud concept. And the highways on which the data runs and the client which knows how to talk to it is all open source. And we have, we've driven the NFS 4.2 spec. The newest NFS spec came from my team. And it was specifically the enhancements needed to be able to build a spanning file system, a data mesh at a file system level. Now that said, our file system itself and our server, our file server, our data orchestration, our data management stuff, that's all closed source, proprietary Hammerspace tech. But the highways on which the mesh connects are actually all open source and the client that knows how to consume it. So we would, honestly, I would welcome competitors using those same highways. They would be at a major disadvantage because we kind of built them, but it would still be very validating and I think only increase the potential adoption rate by more than whatever they might take of the market. So it'd actually be good to split the market with somebody else to come in and share those now super highways for how to mesh data at the file system level, you know, in here. So yeah, hopefully that answered your question. Does that answer the question about how we embrace the open source? >> Right, and there was one other, just that my last one is how do you enable something to run in every environment? And if we take the edge, for example, as being, as an environment which is much very, very compute heavy, but having a lot less capability, how do you do a hold? >> Perfect question. Perfect question. What we do today is a software appliance. We are using a Linux RHEL 8, RHEL 8 equivalent or a CentOS 8, or it's, you know, they're all roughly equivalent. But we have bundled and a software appliance which can be instantiated on bare metal hardware on any type of VM system from VMware to all of the different hypervisors in the Linux world, to even Nutanix and such. So it can run in any virtualized environment and it can run on any cloud instance, server instance in the cloud. And we have it packaged and deployable from the marketplaces within the different clouds. So you can literally spin it up at the click of an API in the cloud on instances in the cloud. So with all of these together, you can basically instantiate a Hammerspace set of machinery that can offer up this file system mesh. like we've been using the terminology we've been using now, anywhere. So it's like being able to take and spin up Snowflake and then just be able to install and run some VMs anywhere you want and boom, now you have a Snowflake service. And by the way, it is so complete that some of our customers, I would argue many aren't even using public clouds at all, they're using this just to run their own data centers in a cloud-like fashion, you know, where they have a data service that can span it all. >> Yeah and to Molly's first point, we would consider that, you know, cloud. Let me put you on the spot. If you had to describe conceptually without a chalkboard what an architectural diagram would look like for supercloud, what would you say? >> I would say it's to have the same runtime environment within every data center and defining that runtime environment as what it takes to schedule the execution of applications, so job scheduling, runtime stuff, and here we're talking Kubernetes, Slurm, other things that do job scheduling. We're talking about having a common way to, you know, instantiate compute resources. So a global compute environment, having a common compute environment where you can instantiate things that need computing. Okay? So that's the first part. And then the second is the data platform where you can have file block and object volumes, and have them available with the same APIs in each of these distributed data centers and have the exact same data omnipresent with the ability to control where the data is from one moment to the next, local, where all the data is instantiate. So my definition would be a common runtime environment that's bifurcate-- >> Oh. (attendees chuckling) We just lost them at the money slide. >> That's part of the magic makes people listen. We keep someone on pin and needles waiting. (attendees chuckling) >> That's good. >> Are you back, David? >> I'm on the edge of my seat. Common runtime environment. It was like... >> And just wait, there's more. >> But see, I'm maybe hyper-focused on the lower level of what it takes to host and run applications. And that's the stuff to schedule what resources they need to run and to get them going and to get them connected through to their persistence, you know, and their data. And to have that data available in all forms and have it be the same data everywhere. On top of that, you could then instantiate applications of different types, including relational databases, and data warehouses and such. And then you could say, now I've got, you know, now I've got these more application-level or structured data-level things. I tend to focus less on that structured data level and the application level and am more focused on what it takes to host any of them generically on that super pass layer. And I'll admit, I'm maybe hyper-focused on the pass layer and I think it's valid to include, you know, higher levels up the stack like the structured data level. But as soon as you go all the way up to like, you know, a very specific SAS service, I don't know that you would call that supercloud. >> Well, and that's the question, is there value? And Marianna Tessel from Intuit said, you know, we looked at it, we did it, and it just, it was actually negative value for us because connecting to all these separate clouds was a real pain in the neck. Didn't bring us any additional-- >> Well that's 'cause they don't have this pass layer underneath it so they can't even shop around, which actually makes it hard to stand up your own SAS service. And ultimately they end up having to build their own infrastructure. Like, you know, I think there's been examples like Netflix moving away from the cloud to their own infrastructure. Basically, if you're going to rent it for more than a few months, it makes sense to build it yourself, if it's at any kind of scale. >> Yeah, for certain components of that cloud. But if the Goldman Sachs came to you, David, and said, "Hey, we want to collaborate and we want to build "out a cloud and essentially build our SAS system "and we want to do that with Hammerspace, "and we want to tap the physical infrastructure "of not only our data centers but all the clouds," then that essentially would be a SAS, would it not? And wouldn't that be a Super SAS or a supercloud? >> Well, you know, what they may be using to build their service is a supercloud, but their service at the end of the day is just a SAS service with global reach. Right? >> Yeah. >> You know, look at, oh shoot. What's the name of the company that does? It has a cloud for doing bookkeeping and accounting. I forget their name, net something. NetSuite. >> NetSuite. NetSuite, yeah, Oracle. >> Yeah. >> Yep. >> Oracle acquired them, right? Is NetSuite a supercloud or is it just a SAS service? You know? I think under the covers you might ask are they using supercloud under the covers so that they can run their SAS service anywhere and be able to shop the venue, get elasticity, get all the benefits of cloud in the, to the benefit of their service that they're offering? But you know, folks who consume the service, they don't care because to them they're just connecting to some endpoint somewhere and they don't have to care. So the further up the stack you go, the more location-agnostic it is inherently anyway. >> And I think it's, paths is really the critical layer. We thought about IAS Plus and we thought about SAS Minus, you know, Heroku and hence, that's why we kind of got caught up and included it. But SAS, I admit, is the hardest one to crack. And so maybe we exclude that as a deployment model. >> That's right, and maybe coming down a level to saying but you can have a structured data supercloud, so you could still include, say, Snowflake. Because what Snowflake is doing is more general purpose. So it's about how general purpose it is. Is it hosting lots of other applications or is it the end application? Right? >> Yeah. >> So I would argue general purpose nature forces you to go further towards platform down-stack. And you really need that general purpose or else there is no real distinguishing. So if you want defensible turf to say supercloud is something different, I think it's important to not try to wrap your arms around SAS in the general sense. >> Yeah, and we've kind of not really gone, leaned hard into SAS, we've just included it as a deployment model, which, given the constraints that you just described for structured data would apply if it's general purpose. So David, super helpful. >> Had it sign. Define the SAS as including the hybrid model hold SAS. >> Yep. >> Okay, so with your permission, I'm going to add you to the list of contributors to the definition. I'm going to add-- >> Absolutely. >> I'm going to add this in. I'll share with Molly. >> Absolutely. >> We'll get on the calendar for the date. >> If Molly can share some specific language that we've been putting in that kind of goes to stuff we've been talking about, so. >> Oh, great. >> I think we can, we can share some written kind of concrete recommendations around this stuff, around the general purpose, nature, the common data thing and yeah. >> Okay. >> Really look forward to it and would be glad to be part of this thing. You said it's in February? >> It's in January, I'll let Molly know. >> Oh, January. >> What the date is. >> Excellent. >> Yeah, third week of January. Third week of January on a Tuesday, whatever that is. So yeah, we would welcome you in. But like I said, if it doesn't work for your schedule, we can prerecord something. But it would be awesome to have you in studio. >> I'm sure with this much notice we'll be able to get something. Let's make sure we have the dates communicated to Molly and she'll get my admin to set it up outside so that we have it. >> I'll get those today to you, Molly. Thank you. >> By the way, I am so, so pleased with being able to work with you guys on this. I think the industry needs it very bad. They need something to break them out of the box of their own mental constraints of what the cloud is versus what it's supposed to be. And obviously, the more we get people to question their reality and what is real, what are we really capable of today that then the more business that we're going to get. So we're excited to lend the hand behind this notion of supercloud and a super pass layer in whatever way we can. >> Awesome. >> Can I ask you whether your platforms include ARM as well as X86? >> So we have not done an ARM port yet. It has been entertained and won't be much of a stretch. >> Yeah, it's just a matter of time. >> Actually, entertained doing it on behalf of NVIDIA, but it will absolutely happen because ARM in the data center I think is a foregone conclusion. Well, it's already there in some cases, but not quite at volume. So definitely will be the case. And I'll tell you where this gets really interesting, discussion for another time, is back to my old friend, the SSD, and having SSDs that have enough brains on them to be part of that fabric. Directly. >> Interesting. Interesting. >> Very interesting. >> Directly attached to ethernet and able to create a data mesh global file system, that's going to be really fascinating. Got to run now. >> All right, hey, thanks you guys. Thanks David, thanks Molly. Great to catch up. Bye-bye. >> Bye >> Talk to you soon.

>> Narrator: From around the globe, it's theCUBE. Presenting Accelerating Automation with DevNet. Brought to you by Cisco. >> Hello and welcome to theCUBE. I'm John Furrier, your host. We've got a great conversation and a virtual event, Accelerating Automation with DevNet , Cisco DevNet. And of course we got the Cisco brain trust here. Cube alumni, Susie Wee, Vice President, Senior Vice President, GM, and also CTO of Cisco DevNet and Ecosystem Success CX, all that great stuff. Mandy Whaley, who's the Director, Senior Director of DevNet Certifications, And Eric Thiel, Director of Developer Advocacy, Susie, Mandy, Eric, great to see you. Thanks for coming on. >> Great to see you, John. >> So we're not in person >> It's great to be here. >> We don't, can't be at the DevNet Zone. We can't be on site doing DevNet Create, all the great stuff we've been doing over the past few years. We're virtual, theCUBE virtual. Thanks for coming on. Susie, I got to ask you because you know, we've been talking years ago when you started this mission and just the success you had has been awesome, but DevNet Create has brought on a whole nother connective tissue to the DevNet community. This ties into the theme of accelerating automation with DevNet, because you said to me, I think four years ago, everything should be a service or XaaS as it's called (Susie laughs) and automation plays a critical role. Could you please share your vision because this is really important and still only five to 10% of the enterprises have containerized things. So there's a huge growth curve coming with developing and programmability. What's your vision? >> Yeah, absolutely. I mean, what we know is that as more and more businesses are coming online as, well I mean, they're all online, but as they're growing into the cloud, as they're growing in new areas, as we're dealing with security, as everyone's dealing with the pandemic, there's so many things going on. But what happens is, there's an infrastructure that all of this is built on and that infrastructure has networking, it has security, it has all of your compute and everything that's in there. And what matters is how can you take a business application and tie it to that infrastructure? How can you take, you know, customer data? How can you take business applications? How can you connect up the world securely and then be able to, you know, really satisfy everything that businesses need? And in order to do that, you know, the whole new tool that we've always talked about is that the network is programmable. The infrastructure is programmable, and you don't need just apps riding on top, but now they get to use all of that power of the infrastructure to perform even better. And in order to get there, what you need to do is automate everything. You can't configure networks manually. You can't be manually figuring out policies, but you want to use that agile infrastructure in which you can really use automation, you can rise to higher level business processes and tie all of that up and down the stack by leveraging automation. >> You know, I remember a few years ago when DevNet Create first started, I interviewed Todd Nightingale, and we were talking about Meraki, you know, not to get in the weeds about you know, switches and hubs and wireless. But if you look at what we were talking about then, this is kind of what's going on now. And we were just recently, I think our last physical event was at Cisco Europe in Barcelona before all the COVID hit. And you had >> Susie: Yeah. >> The massive cloud surge and scale happening going on, right when the pandemic hit. And even now more than ever the cloud scale, the modern apps, the momentum hasn't stopped because there's more pressure now to continue addressing more innovation at scale because the pressure to do that, because the businesses need to stay alive. >> Absolutely, yeah. >> I just want to get your thoughts on what's going on in your world, because you were there in person. Now we're six months in, scale is huge. >> We are. Yeah, absolutely. And what happened is as all of our customers, as businesses around the world, as we ourselves all dealt with, how do we run a business from home? You know, how do we keep people safe? How do we keep people at home and how do we work? And then it turns out, you know, business keeps rolling, but we've had to automate even more because you have to go home and then figure out how from home can I make sure that my IT infrastructure is automated? How from home can I make sure that every employee is out there and working safely and securely? You know, things like call center workers, which had to go into physical locations and be in kind of, you know, just, you know, blocked off rooms to really be secure with their company's information. They had to work from home. So we had to extend business applications to people's homes in countries like, you know, well around the world, but also in India where it was actually not, you know, not, they didn't have rules to let people work from home in these areas. So then what we had to do was automate everything and make sure that we could administer, you know, all of our customers could administer these systems from home. So that put extra stress on automation. It put extra stress on our customer's digital transformation and it just forced them to, you know, automate digitally transform quicker. And they had to, because you couldn't just go into a server room and tweak your servers, you had to figure out how to automate all of that. And we're still in that environment today. >> You know one of the hottest trends before the pandemic was observability, Kubernetes microservices. So those things, again, all DevOps and, you know, you guys got some acquisitions, you've bought ThousandEyes, you got a new one. You just bought recently PortShift to raise the game in security, Kuber and all these microservices. So observability super hot, but then people go work at home as you mentioned. How do you (chuckles) >> Yeah What are you observing? The network is under a huge pressure. I mean, it's crashing on people's Zooms and Web Ex's and education, huge amount of network pressure. How are people adapting to this in the app side? How are you guys looking at the, what's being programmed? What are some of the things that you're seeing with use cases around this programmability challenge and observability challenge that's such a huge deal? >> Yeah, absolutely. And you know, going back to Todd Nightingale, right? You know, back when we talked to Todd before, he had Meraki and he had designed this simplicity, this ease of use, this cloud managed, you know, doing everything from one central place. And now he has Cisco's entire enterprise and cloud business. So he is now applying that at that bigger, at that bigger scale for Cisco and for our customers. And he is building in the observability and the dashboards and the automation and the APIs into all of it. But when we take a look at what our customers needed is again, they had to build it all in. They had to build in. And what happened was how your network was doing, how secure your infrastructure was, how well you could enable people to work from home and how well you could reach customers. All of that used to be an IT conversation. It became a CEO and a board-level conversation. So all of a sudden, CEOs were actually, you know, calling on the Heads of IT and the CIO and saying, you know, "How's our VPN connectivity? Is everybody working from home? How many people are connected and able to work and what's their productivity?" So all of a sudden, all these things that were really infrastructure IT stuff became a board level conversation and, you know, once again, at first everybody was panicked and just figuring out how to get people working, but now what we've seen in all of our customers is that they are now building in automation and digital transformation and these architectures, and that gives them a chance to build in that observability, you know, looking for those events, the dashboards, you know, so it really has been fantastic to see what our customers are doing and what our partners are doing to really rise to that next level. >> Susie, I know you got to go, but real quick, describe what accelerating automation with DevNet means. >> (giggles)Well, you've been, you know, we've been working together on DevNet and the vision of the infrastructure programmability and everything for quite some time and the thing that's really happened is yes, you need to automate, but yes, it takes people to do that and you need the right skill sets and the programmability. So a networker can't be a networker. A networker has to be a network automation developer. And so it is about people and it is about bringing infrastructure expertise together with software expertise and letting people run things. Our DevNet community has risen to this challenge. People have jumped in, they've gotten their certifications. We have thousands of people getting certified. You know, we have, you know, Cisco getting certified. We have individuals, we have partners, you know, they're just really rising to the occasion. So accelerating automation, while it is about going digital. It's also about people rising to the level of, you know, being able to put infrastructure and software expertise together to enable this next chapter of business applications, of, you know, cloud directed businesses and cloud growth. So it actually is about people, just as much as it is about automation and technology. >> And we got DevNet Create right around the corner, Virtual, unfortunately, won't be in person, but will be virtual. Susie, thank you for your time. We're going to dig into those people challenges with Mandy and Eric. Thank you for coming on. I know you've got to go, but stay with us. We're going to dig in with Mandy and Eric. Thanks. >> Thank you so much. Have fun. >> Thank you. >> Thanks John. >> Okay. Mandy, you heard Susie, it's about people. And one of the things that's close to your heart, you've been driving as Senior Director of DevNet Certifications, is getting people leveled up. I mean the demand for skills, cybersecurity, network programmability, automation, network design, solution architect, cloud, multi-cloud design. These are new skills that are needed. Can you give us the update on what you're doing to help people get into the acceleration of automation game? >> Oh yes, absolutely. You know, what we've been seeing is a lot of those business drivers, that Susie was mentioning. Those are what's accelerating a lot of the technology changes and that's creating new job roles or new needs on existing job roles where they need new skills. We are seeing customers, partners, people in our community really starting to look at, you know, things like DevSecOps engineer, network automation engineer, network automation developer, which Susie mentioned, and looking at how these fit into their organization, the problems that they solve in their organization. And then how do people build the skills to be able to take on these new job roles or add that job role to their current scope and broaden out and take on new challenges. >> Eric, I want to go to you for a quick second on this piece of getting the certifications. First, before we get started, describe what your role is as Director of Developer Advocacy, because that's always changing and evolving. What's the state of it now because with COVID people are working at home, they have more time to contact Switch, and get some certifications and yet they can code more. What's your role? >> Absolutely. So it's interesting. It definitely is changing a lot. A lot of our, historically a lot of focus for my team has been on those outward events. So going to the DevNet Creates, the Cisco Lives and helping the community connect and to help share technical information with them, doing hands on workshops and really getting people into how do you really start solving these problems? So that's had to pivot quite a bit. Obviously Cisco Live US, we pivoted very quickly to a virtual event when conditions changed. And we're able to actually connect as we found out with a much larger audience. So, you know, as opposed to in person where you're bound by the parameters of, you know, how big the convention center is, we were actually able to reach a worldwide audience with our DevNet Day that was kind of attached onto Cisco Live. And we got great feedback from the audience that now we were actually able to get that same enablement out to so many more people that otherwise might not have been able to make it, but to your broader question of, you know, what my team does. So that's one piece of it is getting that information out to the community. So as part of that, there's a lot of other things we do as well. We are always helping out build new sandboxes, new learning labs, things like that, that they can come and get whenever they're looking for it out on the DevNet site. And then my team also looks after communities, such as the Cisco Learning Network where there's a huge community that has historically been there to support people working on their Cisco certifications. We've seen a huge shift now in that group, that all of the people that have been there for years are now looking at the DevNet certifications and helping other people that are trying to get onboard with programmability. They're taking a lot of those same community enablement skills and propping up the community with helping you answer questions, helping provide content. They've moved now into the DevNet space as well, and are helping people with that set of certifications. So it's great seeing the community come along and really see that. >> I got to ask you on the trends around automation, what skills and what developer patterns are you seeing with automation? Is there anything in particular, obviously network automation has been around for a long time. Cisco has been leader in that, but as you move up the stack as modern applications are building, do you see any patterns or trends around what is accelerating automation? What are people learning? >> Yeah, absolutely. So you mentioned observability was big before COVID and we actually really saw that amplified during COVID. So a lot of people have come to us looking for insights. How can I get that better observability now that we need it while we're virtual. So that's actually been a huge uptick and we've seen a lot of people that weren't necessarily out looking for things before that are now figuring out' how can I do this at scale? And I think one good example that Susie was talking about the VPN example. And we actually had a number of SEs in the Cisco community that had customers dealing with that very thing where they very quickly had to ramp up. And one in particular actually wrote a bunch of automation to go out and measure all of the different parameters that IT departments might care about, about their firewalls, things that you didn't normally look at in the old days. You would size your firewalls based on, you know, assuming a certain number of people working from home. And when that number went to 100%, things like licenses started coming into play, where they needed to make sure they have the right capacity in their platforms that they weren't necessarily designed for. So one of the SEs actually wrote a bunch of code to go out, use some open source tooling to monitor and alert on these things and then published it, so the whole community could go out and get a copy of it, try it out in their own environment. And we saw a lot of interest around that in trying to figure out, okay, now I can take that and I can adapt it to what I need to see for my observability. >> That's great. Mandy, I want to get your thoughts on this too, because as automation continues to scale, it's going to be a focus and people are at home and you guys had a lot of content online for you recorded every session in the DevNet Zone. Learning's going on, sometimes linearly and non linearly. You got the certifications, which is great. That's key, great success there. People are interested, but what other learnings are you seeing? What are people doing? What's the top top trends? >> Yeah. So what we're seeing is like you said, people are at home, they've got time. They want to advance their skillset. And just like any kind of learning, people want choice they want to be able to choose what matches their time that's available and their learning style. So we're seeing some people who want to dive into full online study groups with mentors leading them through a study plan. And we have two new expert-led study groups like that. We're also seeing whole teams at different companies who want to do an immersive learning experience together with projects and office hours and things like that. And we have a new offer that we've been putting together for people who want those kinds of team experiences called Automation Bootcamp. And then we're also seeing individuals who want to be able to, you know, dive into a topic, do a hands-on lab, get some skills, go to the rest of the day of do their work and then come back the next day. And so we have really modular self-driven hands-on learning through the DevNet Fundamentals course, which is available through DevNet. And then there's also people who are saying, "I just want to use the technology. "I like to experiment and then go, you know, "read the instructions, read the manual, "do the deeper learning." And so they're spending a lot of time in our DevNet sandbox, trying out different technologies, Cisco technologies with open source technologies, getting hands-on and building things. And three areas where we're seeing a lot of interest in specific technologies. One is around SD-WAN. There's a huge interest in people skilling up there because of all the reasons that we've been talking about. Security is a focus area where people are dealing with new scale, new kinds of threats, having to deal with them in new ways. and then automating their data center using infrastructure as code type principles. So those are three areas where we're seeing a lot of interest and you'll be hearing some more about that at DevNet Create. >> Awesome. Eric and Mandy, if you guys can wrap up this Accelerating Automation with DevNet package and virtual event here and also tee up DevNet Create because DevNet Create has been a very kind of grassroots, organically building momentum over the years. And again, it's super important cause it's now the app world coming together with networking, you know, end to end programmability and with everything as a service that you guys are doing, everything with APIs, I only can imagine the enablement that's going to create. >> Mandy: Yeah >> Can you share the summary real quick on Accelerating Automation with DevNet and tee up DevNet Create. Mandy, we'll start with you. >> Yes, I'll go first and then Eric can close this out. So just like we've been talking about with you at every DevNet event over the past years, you know, DevNet's bringing APIs across our whole portfolio, and up and down the stack and Accelerating Automation with DevNet , Susie mentioned the people aspect of that. The people skilling up and how that transforms teams, And I think that it's all connected in how businesses are being pushed on their transformation because of current events. That's also a great opportunity for people to advance their careers and take advantage of some of that quickly changing landscape. And so what I think about Accelerating Automation with DevNet, it's about the DevNet community. It's about people getting those new skills and all the creativity and problem solving that will be unleashed by that community with those new skills. >> Eric, take us home here, Accelerating Automation with DevNet and DevNet Create, a lot of developer action going on in Cloud Native right now, your thoughts. >> Absolutely. I think it's exciting. I mentioned the transition to virtual for DevNet Day this year, for Cisco Live and we're seeing, we're able to leverage it even further with Create this year. So, whereas it used to be, you know, confined by the walls that we were within for the event. Now we're actually able to do things like we're adding the Start Now track for people that want to be there. They want to be a developer, a network automation developer for instance, we've now got a track just for them where they can get started and start learning some of the skills they'll need, even if some of the other technical sessions were a little bit deeper than what they were ready for. So I love that we're able to bring that together with the experienced community that we usually do from across the industry bringing us all kinds of innovative talks, talking about ways that they're leveraging technology, leveraging the cloud to do new and interesting things to solve their business challenges. So I'm really excited to bring that whole mix together, as well as getting some of our business units together too and talk straight from their engineering departments. What are they doing? What are they seeing? What are they thinking about when they're building new APIs into their platforms? What problems are they hoping that customers will be able to solve with them? So I think together seeing all of that and then bringing the community together from all of our usual channels. So like I said, Cisco learning network, we've got a ton of community coming together, sharing their ideas and helping each other grow those skills. I see nothing but acceleration ahead of us for automation. >> Awesome. Thanks so much. >> I would >> Go ahead, Mandy. >> Can I add one more thing? >> Add one more thing. >> Yeah, I was just going to say the other really exciting thing about Create this year with the virtual nature of it is that it's happening in three regions and you know, we're so excited to see the people joining from all the different regions and content and speakers and the regions stepping up to have things personalized to their area, to their community. And so that's a whole new experience for DevNet Create that's going to be fantastic this year. >> Yeah, that's it. I was going to close out and just put the final bow on that by saying that you guys have always been successful with great content focused on the people in the community. I think now during, with this virtual DevNet, virtual DevNet create virtual theCUBE virtual, I think we're learning new things. People are working in teams and groups and sharing content, we're going to learn new things. We're going to try new things and ultimately people will rise up and will be resilient. And I think when you have this kind of opportunity, it's really fun. And we'll ride the wave with you guys. >> So thank you so much (Susie laughs) for taking the time to come on theCUBE and talk about your awesome Accelerating Automation and DevNet Create Looking forward to it, thank you. >> Thank you so much, >> All right, thanks a lot. >> Happy to be here. >> Okay, I'm John Furrier with theCUBE virtual here in Palo Alto studios doing the remote content and men, we stay virtual until we're face to face. Thank you so much for watching and we'll see you at DevNet Create. Thanks for watching. (upbeat outro) >> Controller: Okay John, Here we go, John. Here we go. John, we're coming to you in five, four, three, two. >> Hello, and welcome to theCUBE. I'm John Furrier, your host. We've got a great conversation and a virtual event, Accelerating Automation with DevNet, Cisco DevNet. And of course we got the Cisco brain trust here. Cube alumni, Susie Wee, Senior Vice President GM and also CTO at Cisco DevNet and Ecosystem Success CX, all that great stuff. Mandy Whaley, who's the Director, Senior Director of DevNet Certifications, and Eric Thiel, Director of Developer Advocacy. Susie, Mandy, Eric, great to see you. Thanks for coming on. >> Great to see you, John. So we're not in person. >> It's great to be here >> We don't, can't be at the DevNet zone. We can't be on site doing DevNet Create, all the great stuff we've been doing over the past few years. We're virtual, theCUBE virtual. Thanks for coming on. Susie, I got to ask you because you know, we've been talking years ago when you started this mission and just the success you had has been awesome. But DevNet Create has brought on a whole nother connective tissue to the DevNet community. This ties into the theme of Accelerating Automation with DevNet, because you said to me, I think four years ago, everything should be a service or XaaS as it's called. And automation plays (Susie laughs) a critical role. Could you please share your vision because this is really important and still only five to 10% of the enterprises have containerized things. So there's a huge growth curve coming with developing and programmability. What's your vision? >> Yeah, absolutely. I mean, what we know is that as more and more businesses are coming online as ,well I mean, they're all online, but as they're growing into the cloud, as they're growing in new areas, as we're dealing with security, as everyone's dealing with the pandemic, there's so many things going on, but what happens is there's an infrastructure that all of this is built on and that infrastructure has networking. It has security. It has all of your compute and everything that's in there. And what matters is how can you take a business application and tie it to that infrastructure? How can you take, you know, customer data? How can you take business applications? How can you connect up the world securely and then be able to, you know, really satisfy everything that businesses need. And in order to do that, you know, the whole new tool that we've always talked about is that the network is programmable. The infrastructure is programmable and you don't need just apps riding on top, but now they get to use all of that power of the infrastructure to perform even better. And in order to get there, what you need to do is automate everything. You can't configure networks manually. You can't be manually figuring out policies, but you want to use that agile infrastructure in which you can really use automation. You can rise to higher level business processes and tie all of that up and down the stack by leveraging automation. >> You know, I remember a few years ago when DevNet Create first started, I interviewed Todd Nightingale and we were talking about Meraki, you know, not to get in the weeds, but you know, switches and hubs and wireless. But if you look at what we were talking about then, this is kind of what's going on now. And we were just recently, I think our last physical event was Cisco Europe in Barcelona before all the COVID hit. And you had this massive cloud surge and scale happening going on right when the pandemic hit. And even now more than ever, the cloud scale, the modern apps, the momentum hasn't stopped because there's more pressure now to continue addressing more innovation at scale because the pressure to do that because the businesses need >> Absolutely. >> to stay alive. I just want to get your thoughts on what's going on in your world, because you were there in person now we're six months in scale is huge. >> We are. Yeah, absolutely. And what happened is, as all of our customers, as businesses around the world, as we ourselves all dealt with, how do we run a business from home? You know, how do we keep people safe? How do we keep people at home and how do we work? And then it turns out, you know, business keeps rolling, but we've had to automate even more because you have to go home and then figure out how from home, can I make sure that my IT infrastructure is automated? How from home can I make sure that every employee is out there and working safely and securely, you know, things like call center workers, which had to go into physical locations and be in kind of, you know, just, you know, blocked off rooms to really be secure with their company's information. They had to work from home. So we had to extend business applications to people's homes in countries like, you know, well around the world, but also in India where it was actually not, you know, not, they wouldn't let, they didn't have rules to let people work from home in these areas. So then what we had to do was automate everything and make sure that we could administer, you know, all of our customers could administer these systems from home. So that put extra stress on automation. It put extra stress on our customer's digital transformation and it just forced them to, you know, automate, digitally transform quicker. And they had to, because you couldn't just go into a server room and tweak your servers, you had to figure out how to automate all of that. And we're still all in that environment today. >> You know one of the hottest trends before the pandemic was observability, Kubernetes microservices. So those things, again, all DevOps and you know, you guys got some acquisitions, you bought ThousandEyes, you got a new one. You just bought recently PortShift to raise the game in security, Kuber and all these microservices. So observability is super hot, but then people go work at home as you mentioned. How do you observe, what are you observing? The network is under a huge pressure. I mean, it's crashing on people's Zooms and Web Ex's and education, huge amount of network pressure. How are people adapting to this in the app side? How are you guys looking at the, what's being programmed? What are some of the things that you're seeing with use cases around this programmability challenge and observability challenges? It's a huge deal. >> Yeah, absolutely. And you know, going back to Todd Nightingale, right? You know, back when we talked to Todd before he had Meraki and he had designed this simplicity, this ease of use, this cloud managed, you know, doing everything from one central place. And now he has Cisco's entire enterprise and cloud business. So he is now applying that at that bigger scale for Cisco and for our customers and he is building in the observability and the dashboards and the automation and the APIs into all of it. But when we take a look at what our customers needed is again, they had to build it all in. They had to build in. And what happened was how your network was doing, how secure your infrastructure was, how well you could enable people to work from home and how well you could reach customers. All of that used to be an IT conversation. It became a CEO and a board level conversation. So all of a sudden CEOs were actually, you know, calling on the heads of IT and the CIO and saying, you know, how's our VPN connectivity? Is everybody working from home. How many people are you know, connected and able to work and what's their productivity? So all of a sudden, all these things that were really infrastructure IT stuff became a board level conversation. And, you know once again, at first everybody was panicked and just figuring out how to get people working. But now what we've seen in all of our customers is that they are now building in automation and digital transformation and these architectures, and that gives them a chance to build in that observability, you know, looking for those events, the dashboards, you know, so it really has been fantastic to see what our customers are doing and what our partners are doing to really rise to that next level. >> Susie, I know you got to go, but real quick, describe what Accelerating Automation with DevNet means. >> (laughs) Well, you know, we've been working together on DevNet in the vision of the infrastructure programmability and everything for quite some time. And the thing that's really happened is yes, you need to automate, but yes, it takes people to do that and you need the right skill sets and the programmability. So a networker can't be a networker. A networker has to be a network automation developer. And so it is about people and it is about bringing infrastructure expertise together with software expertise and letting people run things. Our DevNet community has risen to this challenge. People have jumped in, they've gotten their certifications. We have thousands of people getting certified. You know, we have, you know, Cisco getting certified. We have individuals, we have partners, you know, they're just really rising to the occasion. So accelerating automation, while it is about going digital, it's also about people rising to the level of, you know, being able to put infrastructure and software expertise together to enable this next chapter of business applications, of you know, cloud directed businesses and cloud growth. So it actually is about people just as much as it is about automation and technology. >> And we got DevNet Create right around the corner virtual, unfortunately won't be in person, but will be virtual. Susie, thank you for your time. We're going to dig into those people challenges with Mandy and Eric. Thank you for coming on. I know got to go, but stay with us. We're going to dig in with Mandy and Eric. Thanks. >> Thank you so much. Have fun. >> Thank you. >> Thanks, John. >> Okay, Mandy, you heard Susie, it's about people. And one of the things that's close to your heart you've been driving is, as senior director of DevNet Certifications is getting people leveled up. I mean the demand for skills, cybersecurity, network programmability, automation, network design, solution architect, cloud multicloud design. These are new skills that are needed. Can you give us the update on what you're doing to help people get into the acceleration of automation game? >> Oh yes, absolutely. You know, what we've been seeing is a lot of those business drivers that Susie was mentioning. Those are what's accelerating a lot of the technology changes and that's creating new job roles or new needs on existing job roles where they need new skills. We are seeing customers, partners, people in our community really starting to look at, you know, things like DevSecOps engineer, network automation engineer, network automation developer which Susie mentioned, and looking at how these fit into their organization, the problems that they solve in their organization. And then how do people build the skills to be able to take on these new job roles or add that job role to their current scope and broaden out and take on new challenges. And this is why we created the DevNet certification. Several years ago, our DevNet community, who's been some of those engineers who have been coming into that software and infrastructure side and meeting. They ask us to help create a more defined pathway to create resources, training, all the things they would need to take all those steps to go after those new jobs. >> Eric, I want to go to you for a quick second on this piece of getting the certifications. First, before we get started, describe what your role is as Director of Developer Advocacy, because that's always changing and evolving. What's the state of it now because with COVID people are working at home, they have more time to contact Switch, and get some certifications and yet they can code more. What's your role >> Absolutely. So it's interesting. It definitely is changing a lot. A lot of our, historically a lot of focus for my team has been on those outward events. So going to the DevNet Creates, the Cisco Lives and helping the community connect and to help share technical information with them, doing hands-on workshops and really getting people into how do you really start solving these problems? So that's had to pivot quite a bit. Obviously Cisco Live US, we pivoted very quickly to a virtual event when conditions changed and we were able to actually connect as we found out with a much larger audience. So, you know, as opposed to in-person where you're bound by the parameters of you know, how big the convention center is. We were actually able to reach a worldwide audience with our DevNet Day that was kind of attached onto Cisco Live. And we got great feedback from the audience that now we were actually able to get that same enablement out to so many more people that otherwise might not have been able to make it, but to your broader question of, you know, what my team does. So that's one piece of it is getting that information out to the community. So as part of that, there's a lot of other things we do as well. We were always helping out build new sandboxes new learning labs, things like that, that they can come and get whenever they're looking for it out on the DevNet site. And then my team also looks after communities such as the Cisco Learning Network where there's a huge community that has historically been there to support people working on their Cisco certifications. And we've seen a huge shift now in that group that all of the people that have been there for years are now looking at the DevNet certifications and helping other people that are trying to get on board with programmability, they're taking a lot of those same community enablement skills and propping up the community with, you know, helping answer questions, helping provide content. They've moved now into the DevNet space as well, and are helping people with that set of certifications. So it's great seeing the community come along and really see that. >> Yeah, I mean, it's awesome, and first of all, you guys done a great job. I'm always impressed when we were at physical events in the DevNet Zone, just the learning, the outreach. Again, very open, collaborative, inclusive, and also, you know, you had one-on-one classes and talks to full blown advanced, (sneezes)Had to sneeze there >> Yeah, and that's the point. >> (laughs)That was coming out, got to cut that out. I love prerecords. >> Absolutely. >> That's never happened to me to live by the way. I've never sneezed live on a thousand--. (Eric laughs) >> You're allergic to me. >> We'll pick up. >> It happens. >> So Eric, so I got to ask you on the trends around automation, what skills and what developer patterns are you seeing with automation? Is there anything in particular? Obviously network automation has been around for a long time. Cisco has been a leader in that, but as you move up the stack, as modern applications are building, do you see any patterns or trends around what is accelerating automation? What are people learning? >> Yeah, absolutely. So you mentioned observability was big before COVID and we actually really saw that amplified during COVID. So a lot of people have come to us looking for insights. How can I get that better observability now that we need it while we're virtual. So that's actually been a huge uptick. And we've seen a lot of people that weren't necessarily out looking for things before that are now figuring out how can I do this at scale? And I think one good example that Susie was talking about the VPN example. And we actually had a number of SEs in the Cisco community that had customers dealing with that very thing where they very quickly had to ramp up. And one in particular actually wrote a bunch of automation to go out and measure all of the different parameters that IT departments might care about, about their firewalls, things that you didn't normally look at in the old days, you would size your firewalls based on, you know, assuming a certain number of people working from home. And when that number went to 100%, things like licensing started coming into play, where they needed to make sure they had the right capacity in their platforms that they weren't necessarily designed for. So one of the SEs actually wrote a bunch of code to go out, used some open source tooling to monitor and alert on these things and then published it, so the whole community could go out and get a copy of it, try it out in their own environment. And we saw a lot of interest around that in trying to figure out, okay, now I can take that and I can adapt it to what I need to see for my observability. >> That's huge and you know, you brought up this sharing concept. I mean, one of the things that's interesting is you've got more sharing going on. >> Controller: John, let's pause right here. Let's pause right here. I'm going to try and bring Eric and Mandy and everybody out. And then just start right from here to bring Eric and Mandy back in and close up. Stand by Eric just hold tight. >> All right, hold on >> Controller: just for one moment. Hold tight, we got Mandy back >> Controller: Standby. Standby. Standby. Standby, standby, standby. Hold hold hold.

>> Hi, my name is Andy Clemenko. I'm a Senior Solutions Engineer at StackRox. Thanks for joining us today for my talk on labels, labels, labels. Obviously, you can reach me at all the socials. Before we get started, I like to point you to my GitHub repo, you can go to andyc.info/dc20, and it'll take you to my GitHub page where I've got all of this documentation, I've got the Keynote file there. YAMLs, I've got Dockerfiles, Compose files, all that good stuff. If you want to follow along, great, if not go back and review later, kind of fun. So let me tell you a little bit about myself. I am a former DOD contractor. This is my seventh DockerCon. I've spoken, I had the pleasure to speak at a few of them, one even in Europe. I was even a Docker employee for quite a number of years, providing solutions to the federal government and customers around containers and all things Docker. So I've been doing this a little while. One of the things that I always found interesting was the lack of understanding around labels. So why labels, right? Well, as a former DOD contractor, I had built out a large registry. And the question I constantly got was, where did this image come from? How did you get it? What's in it? Where did it come from? How did it get here? And one of the things we did to kind of alleviate some of those questions was we established a baseline set of labels. Labels really are designed to provide as much metadata around the image as possible. I ask everyone in attendance, when was the last time you pulled an image and had 100% confidence, you knew what was inside it, where it was built, how it was built, when it was built, you probably didn't, right? The last thing we obviously want is a container fire, like our image on the screen. And one kind of interesting way we can kind of prevent that is through the use of labels. We can use labels to address security, address some of the simplicity on how to run these images. So think of it, kind of like self documenting, Think of it also as an audit trail, image provenance, things like that. These are some interesting concepts that we can definitely mandate as we move forward. What is a label, right? Specifically what is the Schema? It's just a key-value. All right? It's any key and pretty much any value. What if we could dump in all kinds of information? What if we could encode things and store it in there? And I've got a fun little demo to show you about that. Let's start off with some of the simple keys, right? Author, date, description, version. Some of the basic information around the image. That would be pretty useful, right? What about specific labels for CI? What about a, where's the version control? Where's the source, right? Whether it's Git, whether it's GitLab, whether it's GitHub, whether it's Gitosis, right? Even SPN, who cares? Where are the source files that built, where's the Docker file that built this image? What's the commit number? That might be interesting in terms of tracking the resulting image to a person or to a commit, hopefully then to a person. How is it built? What if you wanted to play with it and do a git clone of the repo and then build the Docker file on your own? Having a label specifically dedicated on how to build this image might be interesting for development work. Where it was built, and obviously what build number, right? These kind of all, not only talk about continuous integration, CI but also start to talk about security. Specifically what server built it. The version control number, the version number, the commit number, again, how it was built. What's the specific build number? What was that job number in, say, Jenkins or GitLab? What if we could take it a step further? What if we could actually apply policy enforcement in the build pipeline, looking specifically for some of these specific labels? I've got a good example of, in my demo of a policy enforcement. So let's look at some sample labels. Now originally, this idea came out of label-schema.org. And then it was a modified to opencontainers, org.opencontainers.image. There is a link in my GitHub page that links to the full reference. But these are some of the labels that I like to use, just as kind of like a standardization. So obviously, Author's, an email address, so now the image is attributable to a person, that's always kind of good for security and reliability. Where's the source? Where's the version control that has the source, the Docker file and all the assets? How it was built, build number, build server the commit, we talked about, when it was created, a simple description. A fun one I like adding in is the healthZendpoint. Now obviously, the health check directive should be in the Docker file. But if you've got other systems that want to ping your applications, why not declare it and make it queryable? Image version, obviously, that's simple declarative And then a title. And then I've got the two fun ones. Remember, I talked about what if we could encode some fun things? Hypothetically, what if we could encode the Compose file of how to build the stack in the first image itself? And conversely the Kubernetes? Well, actually, you can and I have a demo to show you how to kind of take advantage of that. So how do we create labels? And really creating labels as a function of build time okay? You can't really add labels to an image after the fact. The way you do add labels is either through the Docker file, which I'm a big fan of, because it's declarative. It's in version control. It's kind of irrefutable, especially if you're tracking that commit number in a label. You can extend it from being a static kind of declaration to more a dynamic with build arguments. And I can show you, I'll show you in a little while how you can use a build argument at build time to pass in that variable. And then obviously, if you did it by hand, you could do a docker build--label key equals value. I'm not a big fan of the third one, I love the first one and obviously the second one. Being dynamic we can take advantage of some of the variables coming out of version control. Or I should say, some of the variables coming out of our CI system. And that way, it self documents effectively at build time, which is kind of cool. How do we view labels? Well, there's two major ways to view labels. The first one is obviously a docker pull and docker inspect. You can pull the image locally, you can inspect it, you can obviously, it's going to output as JSON. So you going to use something like JQ to crack it open and look at the individual labels. Another one which I found recently was Skopeo from Red Hat. This allows you to actually query the registry server. So you don't even have to pull the image initially. This can be really useful if you're on a really small development workstation, and you're trying to talk to a Kubernetes cluster and wanting to deploy apps kind of in a very simple manner. Okay? And this was that use case, right? Using Kubernetes, the Kubernetes demo. One of the interesting things about this is that you can base64 encode almost anything, push it in as text into a label and then base64 decode it, and then use it. So in this case, in my demo, I'll show you how we can actually use a kubectl apply piped from the base64 decode from the label itself from skopeo talking to the registry. And what's interesting about this kind of technique is you don't need to store Helm charts. You don't need to learn another language for your declarative automation, right? You don't need all this extra levels of abstraction inherently, if you use it as a label with a kubectl apply, It's just built in. It's kind of like the kiss approach to a certain extent. It does require some encoding when you actually build the image, but to me, it doesn't seem that hard. Okay, let's take a look at a demo. And what I'm going to do for my demo, before we actually get started is here's my repo. Here's a, let me actually go to the actual full repo. So here's the repo, right? And I've got my Jenkins pipeline 'cause I'm using Jenkins for this demo. And in my demo flask, I've got the Docker file. I've got my compose and my Kubernetes YAML. So let's take a look at the Docker file, right? So it's a simple Alpine image. The org statements are the build time arguments that are passed in. Label, so again, I'm using the org.opencontainers.image.blank, for most of them. There's a typo there. Let's see if you can find it, I'll show you it later. My source, build date, build number, commit. Build number and get commit are derived from the Jenkins itself, which is nice. I can just take advantage of existing URLs. I don't have to create anything crazy. And again, I've got my actual Docker build command. Now this is just a label on how to build it. And then here's my simple Python, APK upgrade, remove the package manager, kind of some security stuff, health check getting Python through, okay? Let's take a look at the Jenkins pipeline real quick. So here is my Jenkins pipeline and I have four major stages, four stages, I have built. And here in build, what I do is I actually do the Git clone. And then I do my docker build. From there, I actually tell the Jenkins StackRox plugin. So that's what I'm using for my security scanning. So go ahead and scan, basically, I'm staging it to scan the image. I'm pushing it to Hub, okay? Where I can see the, basically I'm pushing the image up to Hub so such that my StackRox security scanner can go ahead and scan the image. I'm kicking off the scan itself. And then if everything's successful, I'm pushing it to prod. Now what I'm doing is I'm just using the same image with two tags, pre-prod and prod. This is not exactly ideal, in your environment, you probably want to use separate registries and non-prod and a production registry, but for demonstration purposes, I think this is okay. So let's go over to my Jenkins and I've got a deliberate failure. And I'll show you why there's a reason for that. And let's go down. Let's look at my, so I have a StackRox report. Let's look at my report. And it says image required, required image label alert, right? Request that the maintainer, add the required label to the image, so we're missing a label, okay? One of the things we can do is let's flip over, and let's look at Skopeo. Right? I'm going to do this just the easy way. So instead of looking at org.zdocker, opencontainers.image.authors. Okay, see here it says build signature? That was the typo, we didn't actually pass in. So if we go back to our repo, we didn't pass in the the build time argument, we just passed in the word. So let's fix that real quick. That's the Docker file. Let's go ahead and put our dollar sign in their. First day with the fingers you going to love it. And let's go ahead and commit that. Okay? So now that that's committed, we can go back to Jenkins, and we can actually do another build. And there's number 12. And as you can see, I've been playing with this for a little bit today. And while that's running, come on, we can go ahead and look at the Console output. Okay, so there's our image. And again, look at all the build arguments that we're passing into the build statement. So we're passing in the date and the date gets derived on the command line. With the build arguments, there's the base64 encoded of the Compose file. Here's the base64 encoding of the Kubernetes YAML. We do the build. And then let's go down to the bottom layer exists and successful. So here's where we can see no system policy violations profound marking stack regimes security plugin, build step as successful, okay? So we're actually able to do policy enforcement that that image exists, that that label sorry, exists in the image. And again, we can look at the security report and there's no policy violations and no vulnerabilities. So that's pretty good for security, right? We can now enforce and mandate use of certain labels within our images. And let's flip back over to Skopeo, and let's go ahead and look at it. So we're looking at the prod version again. And there's it is in my email address. And that validated that that was valid for that policy. So that's kind of cool. Now, let's take it a step further. What if, let's go ahead and take a look at all of the image, all the labels for a second, let me remove the dash org, make it pretty. Okay? So we have all of our image labels. Again, author's build, commit number, look at the commit number. It was built today build number 12. We saw that right? Delete, build 12. So that's kind of cool dynamic labels. Name, healthz, right? But what we're looking for is we're going to look at the org.zdockerketers label. So let's go look at the label real quick. Okay, well that doesn't really help us because it's encoded but let's base64 dash D, let's decode it. And I need to put the dash r in there 'cause it doesn't like, there we go. So there's my Kubernetes YAML. So why can't we simply kubectl apply dash f? Let's just apply it from standard end. So now we've actually used that label. From the image that we've queried with skopeo, from a remote registry to deploy locally to our Kubernetes cluster. So let's go ahead and look everything's up and running, perfect. So what does that look like, right? So luckily, I'm using traefik for Ingress 'cause I love it. And I've got an object in my Kubernetes YAML called flask.doctor.life. That's my Ingress object for traefik. I can go to flask.docker.life. And I can hit refresh. Obviously, I'm not a very good web designer 'cause the background image in the text. We can go ahead and refresh it a couple times we've got Redis storing a hit counter. We can see that our server name is roundrobing. Okay? That's kind of cool. So let's kind of recap a little bit about my demo environment. So my demo environment, I'm using DigitalOcean, Ubuntu 19.10 Vms. I'm using K3s instead of full Kubernetes either full Rancher, full Open Shift or Docker Enterprise. I think K3s has some really interesting advantages on the development side and it's kind of intended for IoT but it works really well and it deploys super easy. I'm using traefik for Ingress. I love traefik. I may or may not be a traefik ambassador. I'm using Jenkins for CI. And I'm using StackRox for image scanning and policy enforcement. One of the things to think about though, especially in terms of labels is none of this demo stack is required. You can be in any cloud, you can be in CentOs, you can be in any Kubernetes. You can even be in swarm, if you wanted to, or Docker compose. Any Ingress, any CI system, Jenkins, circle, GitLab, it doesn't matter. And pretty much any scanning. One of the things that I think is kind of nice about at least StackRox is that we do a lot more than just image scanning, right? With the policy enforcement things like that. I guess that's kind of a shameless plug. But again, any of this stack is completely replaceable, with any comparative product in that category. So I'd like to, again, point you guys to the andyc.infodc20, that's take you right to the GitHub repo. You can reach out to me at any of the socials @clemenko or andy@stackrox.com. And thank you for attending. I hope you learned something fun about labels. And hopefully you guys can standardize labels in your organization and really kind of take your images and the image provenance to a new level. Thanks for watching. (upbeat music)

>> Announcer: Live from Barcelona Spain, it's theCube. Covering Cisco Live 2018, brought to you by Cisco, Veeam, and the theCUBE's ecosystem partners. (electronic music) >> Okay, welcome back everyone. This is theCUBE's live coverage at Cisco Live 2018 in Europe. I'm John Furrier, cohost of theCUBE with my partner in crime this week, Stu Miniman, analyst at Wikibon.com. Also, cohost at all the events we go to, most of the events I should say. Our next guest is Ashutosh Malegaonkar, who's the Principal Engineer at Cisco DevNet, involved in a lot of the great projects in Sandbox we're going to talk about. Welcome to theCUBE. >> Thank you. Thank you for having me, John. >> Thanks for coming on. >> One of the exciting stories here is the DevNet momentum continues. Congratulations to your team. >> Ashutosh: Thank you. But you're involved in a couple cool parts of the projects that we notice was getting a lot of traction, co-create a sandbox. >> Ashutosh: Yes. >> First, take a minute to talk about what that project is and why is it so popular. >> Yeah, so as you know DevNet is becoming the key core for Cisco and one of the things that we did in DevNet is like, it's a strategic initiative where we said that we are going to call it co-creations. And what that means is we are co-creating with Cisco's strategic partners, that's one. The second is that we are taking our customers, like our top 10 customers, our top 100 customers, our partners, and our developers. So we are looking at each of these three categories and saying, how can we actually help and take that to the next level with DevNet. >> So you're sharing a lot of resource. Is is the same project? Do people bring their own project to the table? How does it work? >> Yeah, so it's both. So for example, first let's talk about strategic initiatives where ... a strategic partner sorry. And in there we have Apple and Google as our strategic partners. With Apple, what we have done is we have actually created a Fast Lane Validation program and what that does is, with Fast Lane as a product, what we are doing is any app developer who wants to use application quality of service, we actually help them validate that application in DevNet. And one of the things that we noticed is app developers really don't understand quality of service, QOS, and as soon as we say quality of service they freak out. And so we have to actually handhold them, let them understand what it means and then we actually help them take their application on the path. >> I mean there's a lot of things in networks that are like that. Deep packet inspection, people freak out and QOS, but QOS is a very important feature. >> Ashutosh: It is. >> Big time. >> It is and that's one thing that we are basically saying how can network be the platform where you can use performance as a building block? And if you heard Susie and her keynote, that's what she was stressing on, right? We want to have that as a building block for developers. >> Yeah, really interesting points. One of the things we've been digging in the last few days is kind of the changing partner ecosystem. There's some partners that have been with Cisco for decades, networking, infrastructure, but Apple, not a traditional Cisco partner. The other one, you mentioned Google. >> Ashutosh: I did, yeah. >> So I believe Google's here doing some presentations. John and I have been digging in to all the C and SEF projects so what's Google doing here. >> Yeah, so with Google, what Cisco has done is we are coming up with our hybrid or multi-cloud strategy and in the hybrid cloud strategy what we are doing is there things where, if I'm an app developer, on-prem app developer and I want to access services which are in the cloud. Now what the partnership does is we have our security services all the way from on-prem to the cloud deployed in the Google Cloud system and as an app developer I can do my services on-prem but access some services which are in the cloud. So that's one application. Second is that if I'm an app developer working only in the cloud but I want to access some of the services which are on-prem, than how do I do it? And that's what this partnership is also helping out. >> Great. How's the reaction been of the Cisco Live audience here? How many people are lining up to come listen to Google talk about Istio? >> Yeah, so Istio is one part, but Kubernetes, like if you look at our sandbox, like it's becoming one our most popular sandbox in DevNet and Kubernetes is part. And with the Google partnership we are also working with Google on Istio. It's an open source project and what we have done is we have created a sandbox for Istio and that is also it's kind of an industry first, where developers are able to go through a learning lab to actually understand what it means. >> Yeah, absolutely. John and I were at the KubeCon show. We interviewed Lou from the Cisco team, heavily involved in the open source. But yeah, one of those things, how do we simplify it, how do we help people get the on-ramp? Sandbox is a great way for people to get started. >> Ashutosh: That's correct, that's correct. >> One of the things that we're excited about and this something that we're going to be doing, digging into all year is the impact of Kubernetes. And the sandboxing points to the trend of how people are partnering. I think you guys struck a really interesting form in this co-creation model because if you look at what service meshes are doing in markets is that the more that you can make it easier for developers and at the same time enabling the engineering side of it, getting down and dirty. We're talking about QOS, we're talking about plumbing stuff. There's still a lot of automation being done under the hood. This is the network opportunity, this is where we're seeing automation around provisioning and configuration management and all that good stuff. That needs to get done but it has to be addressable for true programmability. We're not there yet, but we're almost there. >> Ashutosh: We're getting there, yes. >> What's your reaction to that, a 19-year veteran at Cisco? Cisco has an inherent advantage having the network, so looking up, that's been enabling, but now you have people who want to look down and program into you. Kind of new dynamic. >> It is, it is. >> How are you guys looking at this? >> So the way I look at it, as you said, I've seen Cisco grow. I mean, I've grown up in the company and one of things, Cisco being the expert in networking, we have experts now which are getting to doing everything, in a sense. Like the edge is where a lot of stuff is happening and when you deploy edge services you also need stuff that needs to be done in the cloud. So for example, one of the examples I like to do is let's take machine learning as a good example, where I want to download some models, machine learning models onto the edge but the traffic is actually all at the edge, so I'm taking all the inputs from the edge, taking at the edge, calculating things, and then the models are being built in the cloud because I can't build those at the edge. So that's the thing that is happening now and what we see here is that Cisco is in the midst of both edge as well as cloud. >> And IoT was going to be very instrumental. If you talk to the pure networking nerds and geeks out there, they're going to say, "Edge? "We've been doing edge of the network for years." But now the edge is extending, right? To IoT so it's not a new concept for Cisco at all, is it? >> Its not. It's not new at all. Because as I said, something very similar to what we are doing for the Apple Fast Lane, as I told you before, like now the app developer has the ability to give QOS right at the app level. It's the same thing like with IoT. It's like all the devices are connected to Cisco. >> And this is what's going to be- it's fun to watch because you guys now have compute to throw at the edge, you have cloud that you can connect to the edge, but this going to change the nature of programming. Stateful and stateless applications become a really interesting dynamic. What's your reaction to that trend of as developers start to really start thinking about state? >> Sure, so one of the things that ... Again I go back to the edge thing where like if you have a tunnel and then there are cars passing by, you are actually looking at the cars as, let's say a stream of dots. Now that state you cannot be giving and storing it somewhere so you basically keep it at the edge, you figure out what's happening, compute, and take some actions there itself. >> That' where the action is. Ashutosh, thank you for coming on theCUBE and sharing your knowledge, appreciate it. Congratulations on the co-creation Fast Lane service you guys have, among other things. The collaboration model is the future. Cisco's really demonstrating that in the DevNet zone so props to the team. It's theCUBE, we always collaborate, sharing the best content here live in Barcelona with you. I'm John Furrier, Stu Miniman. More live coverage, day two of our two days wall to wall live coverage of Cisco Live 2018 in Europe. This is theCUBE. Be right back with more after this short break. (electronic music)

>> Narrator: Live, from Santa Clara in the heart of Silicon Valley, it's theCUBE. Covering Cloud Foundry Summit 2017. Brought to you by the Cloud Foundry Foundation and Pivotal. >> Hi this is Stu Miniman, joined with my cohost, John Troyer. Happy to welcome to the program a first-time guest, Chip Childers, who's the CTO of the Cloud Foundry Foundation. Chip, fresh off the keynote stage, >> Yep. >> how's everything going? >> It's going great. We're really happy with the turnout of the conference. We are really happy with the number of large enterprises that are here to share their story. The really active vendor ecosystem around the project. It's great. It's a wonderful event so far. >> Yeah, I was looking back, I think the last time I came to the Cloud Foundry Show, it was before the Foundation existed, We were in the Hilton in San Francisco, it was obviously a way smaller group. Tell us kind of the goals of the Foundation, doing the event, bringing the community in. >> Yeah, you can think about our goals as being of course, we're the stewards of the intellectual property, the actual software that the vendors distribute. We see our role in the ecosystem as being really two key things. One: we're focused on supporting the users, the customers, and the direct uses of the Open Source software. That's first and foremost. Second though, we want to make sure there is a really robust market ecosystem that is wrapped around this project, right. Both in terms of the distribution, the regional providers that offer Cloud Foundry based services, but also large system integrators that are helping those customers go through digital transformation. Re-platform applications, you know really figure out their way through this process. So, it's all about supporting the users and then supporting the market around it. >> Yeah, as we go to a lot of these events, you know, there are certain themes that emerge. There were two big ones that both of them showed up in what you did in the Keynote. Number one is Multicloud, number two is you got all of these various open sourced pieces, >> Chip: Yep. you know, what fits together, what interlocks together, you know which ones sit side by side. Why don't we start with kind of the open source piece first? Because you're heavily involved in a lot of those. Cloud Foundry, you know, what are the new pieces that are bolting on, or sitting on top, or digging into it, and what's going on there? >> You know, I think first I want to start with a basic philosophy of our upstream community. There are billions of dollars that rely on this platform today. And that continues to grow. Right, because we're showing up in Fortune 500, Global 2000, as well as lots of small start-ups, that are using Cloud Foundry to get code shipped faster. So our community that builds the UpStream software, spends a lot of time being very thoughtful about their technical decisions. So what we release and that what gets productized by the down streams is a complete system. From operating system all the way up to including the various programming languages and frameworks and everything in between. And because we release a complete platform, at a really high velocity, so many people rely on it's quality, we're very thoughtful about when is the right time to build our own, when should we adopt and embrace and continue to support another OpenSource project, so we spend a lot of time really thinking about that. And the areas today that I highlight around specific collaborations include the Open Service Broker API which we actually spun out of being just a Club Foundry implementation. And we embrace other communities, and found a way to share the governance of that. So we move forward as a big industry together. >> Stu: Yeah and speaking on that a little bit more. Very interesting to see. I saw Red Hat for instance speaking with Open Shift, Kubernetes is there. So, how should customers think about this? Are the path wars over? Now you can choose all the pieces that you want? Or, it's probably oversimplifying it. >> I think it's over simplifying it, it depends. You can go try to build your own platform if you want, through a number of serious components, or you can just use something like Cloud Foundry, that has solve for that. But the important thing is that we have specifically designed Cloud Foundry to allow for the backing services to come from anywhere. And so, it's both a differentiator for the various distributions of Cloud Foundry, but also an opportunity for Cloud providers, and even more importantly, it's an opportunity for the enterprise users that live in complex worlds, right? They're going to have multiple platforms, they're going be multiple levels of abstraction from Bms to containers, you know, to the path abstraction even event driven frameworks. We want that all to work really well together. Regardless of the choices you make, because that's what's most valuable to the customers. >> Okay, the other piece, networking you talked about. Why don't you share. >> Yeah, yeah so, besides the Service Broker API, we've added support for what's called Container to Container Networking. I don't necessarily need to dig into the details there, but let's just say that when you're building microservices that the application that the user is experiencing is actually a combination of a lot of different applications. That all talk to each other and rely on each other. So we want to make sure there's a policy-based framework for describing how the webs here is going to talk to the authentication service or is going to talk to the booking service, or the inventory service. They all need to have rules about how they communicate with each other. And we want to do that in the most efficient way possible. So we've adopted the Containing Networking interface as the standard plugin that is now at CNCF, the Cloud Native Computing Foundation. We think it's the right abstraction, we think it's great. It gives us access to all the fascinating work that is going on around software networking, overlay networking, industry standard API plugin to our policy-driven framework. >> Along the same theme, Kubo, a big new news project also kind of integration of some Cloud Foundry concepts with a broader ecosystem, in this case another CNCF project, Kubernetes. Could you speak a little bit to that? >> The Kubernetes community is doing a great job creating great container driven experience. You know that abstraction is all about the container. It's not about, you know, the code. So it's different than Cloud Foundry. There are workloads that make sense to run in one or the other. And we want to make sure that they run really well. Right, so the problem that we're solving with the Kuber project is what deploys Kubernetes? What supports Kubernetes if there is an infrastructure adage and a node goes offline? Right, because it does a great job of restarting containers, but if you have ten nodes in a cluster, and then now you're down to nine, that's a problem. So what Bosh does, is it takes care of solving the node outage level problem. You can also do rolling upgrades that are seamless, no downtime for the Kubernetes cluster. It brings a level of operational maturity to the Kubernetes users that they may not have had otherwise. >> Chip, can you bring us inside a little bit the creation of Kubo, is that something that the market and customers drove towards you? I talked to a couple other Cloud Foundry ecosystem members that were doing some other ways of integrating in Kubernetes. So what lead to this way of deploying it with Bosh? >> Yeah, absolutely so, it came out of a direct collaboration between Pivotal and Google. And it was driven based on Pivotal customer demand. It also, if you speak with people from Google that are involved in the project, they also see it as a need, for the Kubernetes ecosystem. So it's driven based on real-world large financial services companies that wanted to have the multiple abstractions available, they wanted to do it with a common operational platform that is proven mature that they've already adopted. And then as that collaboration board, the fruit of the project, and it was announced by Pivotal and Google several months back, they realized that they needed to move it to the vendor neutral locations so that we can continue to expand the community that can work on it, that can build up the story. >> The other topic I raised at the beginning of the interview, was the Multicloud. So in a panel, Microsoft, Google, MTC for Amazon was there. All of the Cloud guys are going to tell you we have the best platform and can do the best things for you. >> Of course they do. >> How do you balance the "We want to live in a multicultural Cloud world" and be able to go there versus "Oh I'm going to take standard plus and get in a little bit deeper to make sure that we're stickier with the customers there." What role does Cloud Foundry play? What have you seen in the marketplace for that? >> Well the public lab providers are, if you look at the services that they offer, you can roughly categorize them with two things. One, are the infrastructure building blocks. Two, are the higher level services, like their database capabilities, their analytics capabilities, log aggregation, you know, and they all have a portfolio that varies, some have specific things that are very similar. So when we talk about MultiCloud we talk about Cloud Foundry as a way to make use of those common capabilities, now they're going to differentiate based on speeds and feeds, availability, whatever they choose to, but you can then as a user have choice. And then secondarily, that Open Service Broker initiative is what's really about saying "great, there's also all these really valuable additional capabilities, that, as a user, I may choose to integrate with a Google machine learning-service, or I may choose to integrate with a wonderful Microsoft capability, or an Amazon capability." And we just want to make that easy for a developer to make that choice. >> Chip, Cloud Founder was very early in terms of a concept of a platform of services, let's not call it platform as a service right now. But you know, this platform that going to make developers lives easier, multi-target, MultiCloud we call it now, on from your laptop to anywhere. And it's been a really interesting discussion over the last couple years as this parallel container thread can come up with Kubernetes and Mesosphere and all the orchestration tools, and the focus has been on orchestration tools. And I've always thought Cloud Foundry was kind of way ahead of the game in saying "wait a minute, there's a set of services that you're going to have for full life-cycles, day two operation, at scale that you all are going to have to pull together from components." As we're doing this interview here, and this year at Cloud Foundry Summit are there anything that you think people don't kind of realize that over and over again people who are using Cloud Foundry go, "Wow I'm really glad "I had logging or identity management," or what are some of the frameworks that people sometimes don't realize is in there that actually is a huge time-savor. >> Yeah, there are a lot of operational capabilities in the Cloud Foundry platform. When you include both our Bosh layer, as well as the elastic runtime which is in the developer centers experience-- >> John: Anything that people don't often realize is in there? >> Well, I think that the right way to think of it is, it's all the things you need in one application, right? So we've been doing this for years as developers. In the applications operators team, we've been doing it. We've just been doing it via bunch of tickets, we've been doing it via bunch of scripts. What Cloud Foundry does is it takes all of those capabilities you need to really trust a platform to operate something on your behalf, and give you the right view into it, right? The appropriate telemetry, log aggregation, and know that there's going to be help monitoring there. It makes it really easy. Right, so we were talking earlier about the haiku, that Onsi Fakhouri from Pivotal had authored, it's appropriate. It's a promise that a platform makes. And platforms designed to let a user trust that the declarative nature of asking a platform to do X, Y, or Z, will be delivered. >> Chip, we've been hearing Pivotal talks a lot about Spring, when Cloud Foundry's involved. Is it so much so that the Foundation needs to be behind that, or support that? How does that interact and work? >> Well, we're super supportive of all the languages in the framework communities that are out there. You know, even if you pick a particular vendor, Pivotal in this case has a very strong investment in the Spring, Spring Cloud, Spring Boot, they're doing really amazing things. But that's also, it's our software, you know, they steward that community, so all the other vendors actually get the advantage of that. Let's take Dot Net and Microsoft. Microsoft open sourced Dot Net. So now you can run Dot Net applications on Linux. They're embrace of the container details and the APIs and their operating system is making it so that now it can also run on Windows. So the whole Microsoft technology stack, languages and frameworks, they matter quite a bit to the enterprise as well. So we see ourselves as supportive of all of these communities, right? Even ones like the Ruby community. When there's an enterprise developer that chooses to use something like Ruby, with the Ruby on Rails framework, if they use Cloud Foundry, they're getting the latest and greatest version of that language, framework, they know that it's secure, they know that it's going to be patched for them. So it's actually a great experience for that developer, that's working with the language. So, we like to support all of them, we're big fans of any that work really well with the platform and maybe integrate deeper. But it's a polyglot platform. >> We want to give you the final word. People take away from Cloud Foundry Summit 2017, what would you want them to take away? >> Yeah the simple takeaway that I can give you is that this is an absolutely enterprise grade open source ecosystem. And you don't hear that often, right? Because normally we talk about products, being enterprise great. >> Did somebody say in the keynote enterprise great mean that there's a huge salesforce that's going to try sell you stuff? (Chip laughs) Well that's coming from the buying side of the market for years. And you know, it was a bit of a joke. What is "enterprise great?" Well, it means that there's a piece of paper that says, this product will cost x dollars and the salesperson is offering it to you. So of course it's going to be enterprise great. But really, we see it as four key things, right? It's about security, it's about being well-integrated, it's about being able to scale to the needs of even the largest enterprises, and it's also about that great developer experience. So, Cloud Foundry is an ecosystem and all of our downstream distributions get the advantage of this really robust and mature technical community that is producing this software. >> Chip, really appreciate you sharing all the updates with us, and appreciate the foundation's support to bring theCUBE here. We'll be back with lots more coverage here from The Cloud Foundry Summit 2017, you're watching theCUBE. (techno music)