(bright music) >> "Supermetafragilisticexpialadotious." What's in a name? In an homage to the inimitable Charles Fitzgerald, we've chosen this title for today's session because of all the buzz surrounding "supercloud," a term that we introduced last year to signify a major architectural trend and shift that's occurring in the technology industry. Since that time, we've published numerous videos and articles on the topic, and on August 9th, kicked off "Supercloud22," an open industry event designed to advance the supercloud conversation, gathering input from more than 30 experienced technologists and business leaders in "The Cube" and broader technology community. We're talking about individuals like Benoit Dageville, Kit Colbert, Ali Ghodsi, Mohit Aron, David McJannet, and dozens of other experts. And today, we're pleased to welcome David Linthicum, who's a Chief Strategy Officer of Cloud Services at Deloitte Consulting. David is a technology visionary, a technical CTO. He's an author and a frequently sought after keynote speaker at high profile conferences like "VMware Explore" next week. David Linthicum, welcome back to "The Cube." Good to see you again. >> Oh, it's great to be here. Thanks for the invitation. Thanks for having me. >> Yeah, you're very welcome. Okay, so this topic of supercloud, what you call metacloud, has created a lot of interest. VMware calls it cross-cloud services, Snowflake calls it their data cloud, there's a lot of different names, but recently, you published a piece in "InfoWorld" where you said the following. "I really don't care what we call it, "and I really don't care if I put "my own buzzword into the mix. "However, this does not change the fact "that metacloud is perhaps the most important "architectural evolution occurring right now, "and we need to get this right out of the gate. "If we do that, who cares what it's named?" So very cool. And you also mentioned in a recent article that you don't like to put out new terms out in the wild without defining them. So what is a metacloud, or what we call supercloud? What's your definition? >> Yeah, and again, I don't care what people call it. The reality is it's the ability to have a layer of cross-cloud services. It sits above existing public cloud providers. So the idea here is that instead of building different security systems, different governance systems, different operational systems in each specific cloud provider, using whatever native features they provide, we're trying to do that in a cross-cloud way. So in other words, we're pushing out data integration, security, all these other things that we have to take care of as part of deploying a particular cloud provider. And in a multicloud scenario, we're building those in and between the clouds. And so we've been tracking this for about five years. We understood that multicloud is not necessarily about the particular public cloud providers, it's about things that you build in and between the clouds. >> Got it, okay. So I want to come back to that, to the definition, but I want to tie us to the so-called multicloud. You guys did a survey recently. We've said that multicloud was mostly a symptom of multi-vendor, Shadow Cloud, M&A, and only recently has become a strategic imperative. Now, Deloitte published a survey recently entitled "Closing the Cloud Strategy, Technology, Innovation Gap," and I'd like to explore that a little bit. And so in that survey, you showed data. What I liked about it is you went beyond what we all know, right? The old, "Our research shows that on average, "X number of clouds are used at an individual company." I mean, you had that too, but you really went deeper. You identified why companies are using multiple clouds, and you developed different categories of practitioners across 500 survey respondents. But the reasons were very clear for "why multicloud," as this becomes more strategic. Service choice scale, negotiating leverage, improved business resiliency, minimizing lock-in, interoperability of data, et cetera. So my question to you, David, is what's the problem supercloud or metacloud solves, and what's different from multicloud? >> That's a great question. The reality is that if we're... Well, supercloud or metacloud, whatever, is really something that exists above a multicloud, but I kind of view them as the same thing. It's an architectural pattern. We can name it anything. But the reality is that if we're moving to these multicloud environments, we're doing so to leverage best of breed things. In other words, best of breed technology to provide the innovators within the company to take the business to the next level, and we determine that in the survey. And so if we're looking at what a multicloud provides, it's the ability to provide different choices of different services or piece parts that allows us to build anything that we need to do. And so what we found in the survey and what we found in just practice in dealing with our clients is that ultimately, the value of cloud computing is going to be the innovation aspects. In other words, the ability to take the company to the next level from being more innovative and more disruptive in the marketplace that they're in. And the only way to do that, instead of basically leveraging the services of a particular walled garden of a single public cloud provider, is to cast a wider net and get out and leverage all kinds of services to make these happen. So if you think about that, that's basically how multicloud has evolved. In other words, it wasn't planned. They didn't say, "We're going to go do a multicloud." It was different developers and innovators in the company that went off and leveraged these cloud services, sometimes with the consent of IT leadership, sometimes not. And now we have these multitudes of different services that we're leveraging. And so many of these enterprises are going from 1000 to, say, 3000 services under management. That creates a complexity problem. We have a problem of heterogeneity, different platforms, different tools, different services, different AI technology, database technology, things like that. So the metacloud, or the supercloud, or whatever you want to call it, is the ability to deal with that complexity on the complexity's terms. And so instead of building all these various things that we have to do individually in each of the cloud providers, we're trying to do so within a cross-cloud service layer. We're trying to create this layer of technology, which removes us from dealing with the complexity of the underlying multicloud services and makes it manageable. Because right now, I think we're getting to a point of complexity we just can't operate it at the budgetary limits that we are right now. We can't keep the number of skills around, the number of operators around, to keep these things going. We're going to have to get creative in terms of how we manage these things, how we manage a multicloud. And that's where the supercloud, metacloud, whatever they want to call it, comes that. >> Yeah, and as John Furrier likes to say, in IT, we tend to solve complexity with more complexity, and that's not what we're talking about here. We're talking about simplifying, and you talked about the abstraction layer, and then it sounds like I'm inferring more. There's value that's added on top of that. And then you also said the hyperscalers are in a walled garden. So I've been asked, why aren't the hyperscalers superclouds? And I've said, essentially, they want to put your data into their cloud and keep it there. Now, that doesn't mean they won't eventually get into that. We've seen examples a little bit, Outposts, Anthos, Azure Arc, but the hyperscalers really aren't building superclouds or metaclouds, at least today, are they? >> No, they're not. And I always have the predictions for every major cloud conference that this is the conference that the hyperscaler is going to figure out some sort of a multicloud across-cloud strategy. In other words, building services that are able to operate across clouds. That really has never happened. It has happened in dribs and drabs, and you just mentioned a few examples of that, but the ability to own the space, to understand that we're not going to be the center of the universe in how people are going to leverage it, is going to be multiple things, including legacy systems and other cloud providers, and even industry clouds that are emerging these days, and SaaS providers, and all these things. So we're going to assist you in dealing with complexity, and we're going to provide the core services of being there. That hasn't happened yet. And they may be worried about conflicting their market, and the messaging is a bit different, even actively pushing back on the concept of multicloud, but the reality is the market's going to take them there. So in other words, if enough of their customers are asking for this and asking that they take the lead in building these cross-cloud technologies, even if they're participating in the stack and not being the stack, it's too compelling of a market that it's not going to drag a lot of the existing public cloud providers there. >> Well, it's going to be interesting to see how that plays out, David, because I never say never when it comes to a company like AWS, and we've seen how fast they move. And at the same time, they don't want to be commoditized. There's the layer underneath all this infrastructure, and they got this ecosystem that's adding all this tremendous value. But I want to ask you, what are the essential elements of supercloud, coming back to the definition, if you will, and what's different about metacloud, as you call it, from plain old SaaS or PaaS? What are the key elements there? >> Well, the key elements would be holistic management of all of the IT infrastructure. So even though it's sitting above a multicloud, I view metacloud, supercloud as the ability to also manage your existing legacy systems, your existing security stack, your existing network operations, basically everything that exists under the purview of IT. If you think about it, we're moving our infrastructure into the clouds, and we're probably going to hit a saturation point of about 70%. And really, if the supercloud, metacloud, which is going to be expensive to build for most of the enterprises, it needs to support these things holistically. So it needs to have all the services, that is going to be shareable across the different providers, and also existing legacy systems, and also edge computing, and IoT, and all these very diverse systems that we're building there right now. So if complexity is a core challenge to operate these things at scale and the ability to secure these things at scale, we have to have commonality in terms of security architecture and technology, commonality in terms of our directory services, commonality in terms of network operations, commonality in term of cloud operations, commonality in terms of FinOps. All these things should exist in some holistic cross-cloud layer that sits above all this complexity. And you pointed out something very profound. In other words, that is going to mean that we're hiding a lot of the existing cloud providers in terms of their interfaces and dashboards and things like that that we're dealing with today, their APIs. But the reality is that if we're able to manage these things at scale, the public cloud providers are going to benefit greatly from that. They're going to sell more services because people are going to find they're able to leverage them easier. And so in other words, if we're removing the complexity wall, which many in the industry are calling it right now, then suddenly we're moving from, say, the 25 to 30% migrated in the cloud, which most enterprises are today, to 50, 60, 70%. And we're able to do this at scale, and we're doing it at scale because we're providing some architectural optimization through the supercloud, metacloud layer. >> Okay, thanks for that. David, I just want to tap your CTO brain for a minute. At "Supercloud22," we came up with these three deployment models. Kit Colbert put forth the idea that one model would be your control planes running in one cloud, let's say AWS, but it interacts with and can manage and deploy on other clouds, the Kubernetes Cluster Management System. The second one, Mohit Aron from Cohesity laid out, where you instantiate the stack on different clouds and different cloud regions, and then you create a layer, a common interface across those. And then Snowflake was the third deployment model where it's a single global instance, it's one instantiation, and basically building out their own cloud across these regions. Help us parse through that. Do those seem like reasonable deployment models to you? Do you have any thoughts on that? >> Yeah, I mean, that's a distributed computing trick we've been doing, which is, in essence, an agent of the supercloud that's carrying out some of the cloud native functions on that particular cloud, but is, in essence, a slave to the metacloud, or the supercloud, whatever, that's able to run across the various cloud providers. In other words, when it wants to access a service, it may not go directly to that service. It goes directly to the control plane, and that control plane is responsible... Very much like Kubernetes and Docker works, that control plane is responsible for reaching out and leveraging those native services. I think that that's thinking that's a step in the right direction. I think these things unto themselves, at least initially, are going to be a very complex array of technology. Even though we're trying to remove complexity, the supercloud unto itself, in terms of the ability to build this thing that's able to operate at scale across-cloud, is going to be a collection of many different technologies that are interfacing with the public cloud providers in different ways. And so we can start putting these meta architectures together, and I certainly have written and spoke about this for years, but initially, this is going to be something that may escape the detail or the holistic nature of these meta architectures that people are floating around right now. >> Yeah, so I want to stay on this, because anytime I get a CTO brain, I like to... I'm not an engineer, but I've been around a long time, so I know a lot of buzzwords and have absorbed a lot over the years, but so you take those, the second two models, the Mohit instantiate on each cloud and each cloud region versus the Snowflake approach. I asked Benoit Dageville, "Does that mean if I'm in "an AWS east region and I want to do a query on Azure West, "I can do that without moving data?" And he said, "Yes and no." And the answer was really, "No, we actually take a subset of that data," so there's the latency problem. From those deployment model standpoints, what are the trade-offs that you see in terms of instantiating the stack on each individual cloud versus that single instance? Is there a benefit of the single instance for governance and security and simplicity, but a trade-off on latency, or am I overthinking this? >> Yeah, you hit it on the nose. The reality is that the trade-off is going to be latency and performance. If we get wiggy with the distributed nature, like the distributed data example you just provided, we have to basically separate the queries and communicate with the databases on each instance, and then reassemble the result set that goes back to the people who are recording it. And so we can do caching systems and things like that. But the reality is, if it's distributed system, we're going to have latency and bandwidth issues that are going to be limiting us. And also security issues, because if we're removing lots of information over the open internet, or even private circuits, that those are going to be attack vectors that hackers can leverage. You have to keep that in mind. We're trying to reduce those attack vectors. So it would be, in many instances, and I think we have to think about this, that we're going to keep the data in the same physical region for just that. So in other words, it's going to provide the best performance and also the most simplistic access to dealing with security. And so we're not, in essence, thinking about where the data's going, how it's moving across things, things like that. So the challenge is going to be is when you're dealing with a supercloud or metacloud is, when do you make those decisions? And I think, in many instances, even though we're leveraging multiple databases across multiple regions and multiple public cloud providers, and that's the idea of it, we're still going to localize the data for performance reasons. I mean, I just wrote a blog in "InfoWorld" a couple of months ago and talked about, people who are trying to distribute data across different public cloud providers for different reasons, distribute an application development system, things like that, you can do it. With enough time and money, you can do anything. I think the challenge is going to be operating that thing, and also providing a viable business return based on the application. And so why it may look like a good science experiment, and it's cool unto itself as an architect, the reality is the more pragmatic approach is going to be a leavitt in a single region on a single cloud. >> Very interesting. The other reason I like to talk to companies like Deloitte and experienced people like you is 'cause I can get... You're agnostic, right? I mean, you're technology agnostic, vendor agnostic. So I want to come back with another question, which is, how do you deal with what I call the lowest common denominator problem? What I mean by that is if one cloud has, let's say, a superior service... Let's take an example of Nitro and Graviton. AWS seems to be ahead on that, but let's say some other cloud isn't quite quite there yet, and you're building a supercloud or a metacloud. How do you rationalize that? Does it have to be like a caravan in the army where you slow down so all the slowest trucks can keep up, or are the ways to adjudicate that that are advantageous to hide that deficiency? >> Yeah, and that's a great thing about leveraging a supercloud or a metacloud is we're putting that management in a single layer. So as far as a user or even a developer on those systems, they shouldn't worry about the performance that may come back, because we're dealing with the... You hit the nail on the head with that one. The slowest component is the one that dictates performance. And so we have to have some sort of a performance management layer. We're also making dynamic decisions to move data, to move processing, from one server to the other to try to minimize the amount of latency that's coming from a single component. So the great thing about that is we're putting that volatility into a single domain, and it's making architectural decisions in terms of where something will run and where it's getting its data from, things are stored, things like that, based on the performance feedback that's coming back from the various cloud services that are under management. And so if you're running across clouds, it becomes even more interesting, because ultimately, you're going to make some architectural choices on the fly in terms of where that stuff runs based on the active dynamic performance that that public cloud provider is providing. So in other words, we may find that it automatically shut down a database service, say MySQL, on one cloud instance, and moved it to a MySQL instance on another public cloud provider because there was some sort of a performance issue that it couldn't work around. And by the way, it does so dynamically. Away from you making that decision, it's making that decision on your behalf. Again, this is a matter of abstraction, removing complexity, and dealing with complexity through abstraction and automation, and this is... That would be an example of fixing something with automation, self-healing. >> When you meet with some of the public cloud providers and they talk about on-prem private cloud, the general narrative from the hyperscalers is, "Well, that's not a cloud." Should on-prem be inclusive of supercloud, metacloud? >> Absolutely, I mean, and they're selling private cloud instances with the edge cloud that they're selling. The reality is that we're going to have to keep a certain amount of our infrastructure, including private clouds, on premise. It's something that's shrinking as a market share, and it's going to be tougher and tougher to justify as the public cloud providers become better and better at what they do, but we certainly have edge clouds now, and hyperscalers have examples of that where they run a instance of their public cloud infrastructure on premise on physical hardware and software. And the reality is, too, we have data centers and we have systems that just won't go away for another 20 or 30 years. They're just too sticky. They're uneconomically viable to move into the cloud. That's the core thing. It's not that we can't do it. The fact of the matter is we shouldn't do it, because there's not going to be an economic... There's not going to be an economic incentive of making that happen. So if we're going to create this meta layer or this infrastructure which is going to run across clouds, and everybody agrees on, that's what the supercloud is, we have to include the on-premise systems, including private clouds, including legacy systems. And by the way, include the rising number of IoT systems that are out there, and edge-based systems out there. So we're managing it using the same infrastructure into cloud services. So they have metadata systems and they have specialized services, and service finance and retail and things like doing risk analytics. So it gets them further down that path, but not necessarily giving them a SaaS application where they're forced into all of the business processes. We're giving you piece parts. So we'll give you 1000 different parts that are related to the finance industry. You can assemble anything you need, but the thing is, it's not going to be like building it from scratch. We're going to give you risk analytics, we're giving you the financial analytics, all these things that you can leverage within your applications how you want to leverage them. We'll maintain them. So in other words, you don't have to maintain 'em just like a cloud service. And suddenly, we can build applications in a couple of weeks that used to take a couple of months, in some cases, a couple of years. So that seems to be a large take of it moving forward. So get it up in the supercloud. Those become just other services that are under managed... That are under management on the supercloud, the metacloud. So we're able to take those services, abstract them, assemble them, use them in different applications. And the ability to manage where those services are originated versus where they're consumed is going to be managed by the supercloud layer, which, you're dealing with the governance, the service governance, the security systems, the directory systems, identity access management, things like that. They're going to get you further along down the pike, and that comes back as real value. If I'm able to build something in two weeks that used to take me two months, and I'm able to give my creators in the organization the ability to move faster, that's a real advantage. And suddenly, we are going to be valued by our digital footprint, our ability to do things in a creative and innovative way. And so organizations are able to move that fast, leveraging cloud computing for what it should be leveraged, as a true force multiplier for the business. They're going to win the game. They're going to get the most value. They're going to be around in 20 years, the others won't. >> David Linthicum, always love talking. You have a dangerous combination of business and technology expertise. Let's tease. "VMware Explore" next week, you're giving a keynote, if they're going to be there. Which day are you? >> Tuesday. Tuesday, 11 o'clock. >> All right, that's a big day. Tuesday, 11 o'clock. And David, please do stop by "The Cube." We're in Moscone West. Love to get you on and continue this conversation. I got 100 more questions for you. Really appreciate your time. >> I always love talking to people at "The Cube." Thank you very much. >> All right, and thanks for watching our ongoing coverage of "Supercloud22" on "The Cube," your leader in enterprise tech and emerging tech coverage. (bright music)

>> Live from Seattle,Washington, it's theCUBE. Covering KubeCon andCloudNativeCon North America 2018 brought to you by Red Hat, the Cloud Native Computing Foundation, and it's ecosystem partners. >> Hey, welcome back everyone,live Cube coverage here at KubeCon, CloudNativeCon2018 in Seattle. I'm John Furrier with Stu Miniman hosting three days of coverage. Wall to wall, 8,000 people,double from last year, North America, expanding intoChina, Europe, everywhere. The CNCF is expanding, so is Kubernetes. The rise of Kubernetes has spawned the Cloud Native movement going mainstream that's ecosystem driven. We got a great guest here. Steven Bower, data andanalytics infrastructure lead at Bloomberg, featuredthem on siliconangle.com in one of our special reportsand user using Kubernetes and the variety of Cloud Native. Steven welcome to theCUBE. >> Thanks for having me. >> Thanks for coming on,award winning end user, given all the end users,everyone's kind of award winning. >> Yeah, yeah, yeah. >> Congratulations. Bloomberg's known, we've covered you guys, great development team. You guys have a lot ofengineers at Bloomberg as well as being a media company on cable, Bloomberg terminal, everything else. You've got a lot of datascience, you've got a lot of engineers, you're building stuff. What's the focus on Kubernetes? Where are you using it? How are you contributing? What's the dynamic? Why are you winning with Kubernetes? >> Sure, that's a good question. I think, well we're usingit all over the place in lots of different things. We have a huge engineeringteam that does all kinds of different things. So in the area that I manage,which is data and analytics infrastructure, we have been we basically managedatabases and search engines and all kinds of other tech like that. What we've ended uprealizing is that we built something that looks a lot like Kubernetes but doesn't work nearlyas well for all of those different systems, tomanage them at scale. You know, we're talkingthousands of instances of post cross and solar andall kinds of different things and having a singletool, or single platform which we can kind of levelup all of those things really makes a lot of sense in terms of not necessarily like cuttingcosts and things like that 'cause that's actuallynot as interesting to me as actually allowing theteams that manage those things to actually contribute to those projects, contribute to solar or postcross and stuff like that and free them from havingto spend a lot of time managing infrastructure. >> Tim Hopkins said, itwas just on theCUBE here before you came on,from Google, one of the co-leads on Kubernetesat gkegoogles@cloud. He said something interesting. I want to get your reaction to this. One of the benefits of Kubernetesis to give the confidence that deployments are going to be reliable and that confidence gets a flywheel and then people startshipping more as a matter of course of the business,not like oh my God we got to push a new code,oh my God, fingers crossed, press the button. The old model was fingers cross, go, QA, no, no, confidence, theconfidence and the iteration. Is that where you'reseeing the value, too? Does that relate to you? Does that make sense to you?Does that resonate with you? >> Yeah, it definitely does. A lot of the models thatwe're trying to move towards are really like declarative model of both how we develop software andthen how we deploy software and then how we manage it in production. Kubernetes offers that, thatecosystem across the board. That's been really, trying to think of a great way to put this. Being able to have that tooland being able to do that and the repeatability. In the world that I livein, everything we do we don't do one of it,we do, I think we run something like 2000 solar clusters. So all we're doing all daylong is just stamping out the same thing over and overagain and if I can build one system that doesthat very, really cleanly and simply and then I canuse that same system for running post tests orrunning something else that gives us the confidenceand we can test it, we can run it on our laptops. Our developers can developand do all that kind of stuff and it works the same everywherethey go and we can just rinse, lather, repeat kind of. >> So Steve, step back for a second. Your infrastructure, is thisall Bloomberg Data Center's? How does cloud fit into the discussion? >> Yeah, I mean, we dohave some infrastructure running in the cloud but primarily it's all on prem and data center. In my world it's all onmetal because we have all these data systemsthat need direct access to SSDs and MME andall this kind of stuff. >> Can you give us, withoutsharing state secrets, a little bit of the scaleof what you're doing? I love data's at the centerof what you're doing there. We can all understand howimportant data is to your business but talk aboutwhat the requirements are that why you have some special requirements that thetypical enterprise wouldn't. >> Sure, I think, youcan look at Bloomberg as a media company, wehave news, all that stuff. We obviously have the Bloomberg terminal and really what drives that terminal, it's all kinds of software but in the end it's data, right, andit's all kinds of data. What is that definition,big data and all these whatever stuff that everyonewas pitching five years ago. We have all of those problems. We have data that is movingat millions of ticks a second. We have enormous data sets. We have really complex data sets like people scanning courtfilings from tiny little courts all around thecountry and sending that data in and we have tonormalize that and put it in. So all these crazy differenttypes of information. They are both demanding interms of the complexities of parsing data and puttingthem and structuring them into those systems as wellas the scale so we have some pretty enormous andhigh performance systems that require us and kindof drive us to that need for metal and very focused on performance in all different aspects. >> Great, wonder, give us your engagement with this ecosystem here. One of the big questionscoming in is okay, Kubernetes, the thingwe here from the CNTF is well, it's getting kind of boring. I don't know that I agree with the term. I understand they'resaying it's becoming mature and therefore there's less drama around it which is good but this ecosystemis anything but boring. You ask a user like yourself, you've got complex requirements. There's more than 30different projects a year. What do you use out of here? What do you build yourself? What do you contribute to? How do you consideropen-source contributions? It's a big nut and wedon't have a ton of time but if you could scratch thesurface on some of those. >> I think the number onelesson that I've learned from this ecosystem isthat it's moving so rapidly that when we decide tobuild something on our own we have a talk tomorrow aboutour data science platform which we built about ayear-and-a-half, two-years ago. By the time we were ready to talk about it and everything like that,you have all the other different technologiesthat have moved forward. So it made us realize thatif we're going to start something internally,a new project, either A we should go look and seewhat's out there and contribute to that or we should juststart it in open source to begin with rather thanthat oh, let's build it and then we'll open source it. >> Chasing your tail kind of thing. >> Yeah, it's like we have tobecome part of the ecosystem in our entirety. >> That brings up a good question. I want to ask you this incontext of thinking about your peers that mightnot be as progressive as Bloomberg on the tech side. You guys certainly do a greatjob and it's well documented. Classic IT shop, racking andstacking servers and boxes and now we got the wholedigital transformation thing going on, same old, same old but now, 2019, real impact. The investments they'remaking on how to change their IT, their data isnow in front of them. They have to deal with them. This is right front andcenter 'cause companies are realizing they'regoing to go out of business if they don't actually make the adoption 'cause the data's super valuable. So how do you see the Kubernetesand the CNC of ecosystem changing the investment practices of a classic enterprise IT? You know, if your peerscalled you and said hey Steven, hey help me out,what's the secret playbook? Where do I go? I don't want to get, Igot to make some changes. What do they change? What's the impact of theinvestment with Kubernetes? What's the end game? What's the real impact? >> I think, it's a toughthing, right, 'cause Bloomberg is really notlike your typical IT shop. We are a software company at heart and so that makes us alittle bit different. When I talk to other people,I say that in the sense that not a lot of companiescan afford to decide to make a project open-- >> 'cause they outsource everything. >> Right, outsource it. Well, I mean-- >> They outsource everything. >> That's actually a huge change though. We're not sitting heretalking about hundreds of commercial products that are owned by a small handful of vendorsthat are multi-million dollar investments foreverything we're doing. We're talking about lotsof little tiny companies that have products thatare really, really valuable that are in the open sourceworld that we can get our hands on and startworking with before we even make a decision about talkingabout support or whatever. There's all kinds of technologies that, I walk into this room andthese are like friends all around 'cause we'veworked with all their software and we're like hey, theseguys have a company now. This was just a GitHubrepo a couple years ago and I think that that's abig change and embracing that, that's probablyreally hard for your typical kind of IT shop where theywant to have this clear line of I can call techsupport and get someone on the phone and that's like the main-- >> The classic old software model but it's changed. >> So Steve, one of thethings we're trying to get some insight on here isit's not just running Kubernetes in production,it's what am I doing with it. How does that change my business? I understand ML is a big pieceof what you're doing there. Give us some insight as to how does this transform your business? Does it transform your business? >> Specifically on the MLside and we'll talk about this actually that's kind of thefocus of our talk tomorrow so I don't want to stealtheir thunder too much but a lot of it was really about looking at okay, how did ML, deep ML people work? How did they want to work? If you ask an ML personwhat they really want they want an infinitely scalable cluster that it's just theirs and they want to an assay to manage all theinfrastructure for them and a data engineer to managecleaning up all the data and all these things and they wanted that all to themselves and not haveto share it with anyone else. So a lot of what we try tofigure out is how we can actually deliver that to themand it really has transformed. Once people realize that onour platform they had access to an enormous pool of GPUs,it went from oh, I want to work on my box and can you giveme GPUs on my one little box to wow, I can dohyper-parameter tuning across hundreds of GPUs overnight or during the day or whatever their needs are. It really unlocked people's capabilities and they're actuallylike, they went from being skeptical of a systemthat they had to share and things like that 'causeit actually just works and that's really the-- >> That's really thedopamine effect for them. They can see value withouthaving to go through the slogging of the configurationsand the normal stuff >> Yeah, exactly.>> that they had to do. >> Authentication. >> So we've been hearingthreads of the CICD pipeline is a big benefit,which you're kind of seeing as well but whatwe're also seeing people building below Kubernetes seeing storage and networking getting better. How do you see that holistically? Are you seeing is thenetwork more performant, that notion of programmabilitybecomes now part of it, automation, it's software. Everyone has to build software. In fact, I talked to theVP of Technology Innovation at Proctor and Gamble andhe's saying hey, we outsourced everything, I got to start hiring software so maybe not as big asBloomberg but the trend is let's get more software people on board but they still got networks,they still got storage, they still got the gear. What's the impact, the under-the-hood? >> Yeah, I think it'scomplex because you typically have these structures thatare built inside companies where you have a networkingteam and you have an infrastructure, ahardware team and whatever. One of the SREs on my team the other day, he was like, do you thinkwe can talk to the network team about puttingsoftware on their switches? That's a really interestingquestion to start asking and he actually had areally good use case. That makes a lot of sense, maybewe should think about that. And then dealing with, there'sobviously the technology aspect of that but there's also skillsets. Someone that's been workingwith a bunch of switches for a bunch of years isn'tnecessarily a programmer, used to a typical CICDprocess and things like that. >> On the flip side, I thinkthat's cool to recognize the networking guy butwe heard Tim Hopkins say there's a lot of policyknobs in Kubernetes that the networking guyscould potentially take advantage of so it mightwork the other way. Are the network guys looking at Kubernetes saying hey, or are theynot yet that sophisticated but they would love, they'd love policy. Network guys write policy. Wouldn't you want-- >> Yeah, yeah, oh absolutely. It's actually one of thebiggest draws of using Kubernetes in our ecosystem. We've made heavy use ofapplying network policy down to the workload level which means that from a securityperspective, if I know that I'm transmittingdata between two different places and I've only openedup assets for that one application, for thatone particular use case, rather than saying well,I know that I'm running the same workload on thesame box and I got to open it up for everyoneon that box but maybe someone might use thatthing but maybe they won't and like worrying about stuff like that, it's like no, I can runa workload and I know that these are the only two end points that it can talk to. >> Oh, that's a relief. That's like, hey, we're done. >> So for them this is their panacea. I know exactly whatworkloads are doing exactly what on the network andwhat they're capable of so that's been-- >> That's real progress. That's progress. >> Oh, it's huge progress, yeah. And we've been able todo things that we used to not be able to do for years. >> Talk about the-- >> I just had a quicklittle question there. You mentioned you've gotten SREs. When did you pick that up asa term that you called there and how do you see if you talk a little bit to the skill set and the jobs of peoplethat you have inside. >> Bloomberg's a big companyso the terminology of it and what actuallyindividual teams are doing is probably a little bitvaried across the organization. It's been something that'scome in over probably the last two to three years at Bloomberg. In my organization, it wasactually really interesting 'cause when I started off with, you know, you read the Google book and whatever. What I did is I wentto the guys on my team that were going to becomethe SREs for the organization and I had them write thismanifesto about how we should build and deploy and managesoftware and I didn't tell them necessarily up front thatthis is what was going to happen but when they finishedwriting that and agreed that this is how thingsshould work and they argued for a while, I said, okay,now go build all the tooling to make this easy forpeople to do, all right. And that's what we, and thenthey've just been building off their tooling. Turns out when you're workingwith a lot of the tools and the CNTF and then with Kubernetes, that's actually not that hard. There's lots of thingsthere that are just easy when you get to that place and so that's the kind of journey we'vebeen on to really try to build that infrastructure andthey've done a good job. The engineers downstream of them the speed that they're able to develop and the assurance that there was a CVE forKubernetes two weeks ago and we patched it theafternoon the CVE came out. Being able to do that in anysort of company of scale is I've worked a lot ofbanking and stuff like that in my past and it's unheard of to be able to deploy things in that speed. >> And that's really, Imean this is the goodness of clouds, the goodnessof having that kind of consistency operationally. It's funny you use SRE,that's a Google term. It's a great term andyou've got developers, you got operations kindof working together now. That's the magic. Well Steven, thank you so much for sharing this great insight on theCUBE. Certainly great valuefor the folks watching. Lot of traction, a lot ofpeople, end users contributing and consuming Kubernetes,building around it. Great trend, it's really fun to watch. A lot of composable servicesup and down the stack so congratulations. Steve Bower, Data andAnalytics Infrastructure Lead at Bloomberg. This is theCUBE bringingyou all the action, sharing the data here at KubeCon. This is theCUBE. We'll be right back withmore after this short break. (electronic music)