>>Welcome back to the cubes coverage of dr khan 2021 virtual. I'm john for a host of the cube. Got a great cube segment here at Donnie Bergholz, VP of products at Docker Industry veterans, seeing all the ways of innovation now uh had a product that dr dani great to see you. >>It's great to see you again to john >>hey, great program this year, Dr khan almost pushing the envelope again. Just the world's changed significantly over the past few years in this past year has been pretty crazy last year were virtual at the beginning of the pandemic, the watershed moment. Dr khan 2020 you know, with virtual event and then share action packed keynote track, uh four tracks run share build accelerate, you got a cube track, you've got live hits. Uh, community rooms global, huge growth in the developer community around Docker Kubernetes is now well understood by everyone and the general consensus is everyone's in production with it moving like a fast train cloud natives at the center of the action coupons, very operational operators. Dr khan's very development focus. So this is a key developer event really in the CNC F cloud native world. What's going on the process? Give us the update? >>Yeah. And I think you made a fantastic point there, john which is the developer focus. Uh, I joined dr back in october of last year and one of the first things that I did was make sure that we were going out there listening to our customers, having a lot of fresh conversations with them and using those as the core product strategy as we were talking to customers. What we learned fell into three big buckets around building sharing and running modern applications. So we've used those to create our product strategy which is based on solving problems that our customers and developers using Docker care about rather than lot of product strategies that I've come across as an analyst and as a leader on the enterprise side, which are very much feature factory driven of like here's the thing we can ship it, what kind of shove it in your face and try and sell it to you. So I'm really excited about what we're doing a doctor by delivering things that are developers really care about based on problems that they have told us are really valuable to solve problems that when we win, we went together and so we're focused on helping developers really accelerate their application delivery. So what are we doing? There's so much stuff and you know, if you've seen the keynote already, you'll see more and more of that. We announced for really big things and a lot of smaller things as well, um things like uh doctor verified publisher program which brings more trusted content. Um the doctor deV environments that help teams collaborate more effectively, um dr desktop on apple silicon bringing environments to the latest and greatest of machines that everybody is trying to get ahold of. Especially now that cps are harder to come by. Uh uh as well as uh some of those little things like scoped personal access tokens, which makes it easier for people to use a Ci pipeline without having to give it full right privileges and be concerned that if they get hacked, if the sea acrobatic it's hacked, then they get hacked to we're trying to help them defend against those kinds of cases. >>It's funny you made me think of the eye with the apple silicon comment, the supply chain threats that you've seen in hardware. And even here I'm hearing the word kicked around just in the CTO of doctor used the word supply chain, software supply chain. So again, you bring up this idea of supply chain, you mentioned trust. I can almost see the dots connecting, you know, in real time out in the audience out there saying, okay, you've got trust supply chain hardware, software, containers, there's no perimeter and clouds. You have to have a kind of unit level security. This is kind of a big deal. Can you just unpack this trend? Because this is a security kind of anywhere kind of not going to use a buzzword, but like supply chain actually hits home here. Like talk about that. What? All wise all this means? >>Yeah, I think Doctor is in a really interesting position in terms of how development teams and enterprises are adopting it, because it's been around for long enough that enterprises have come to trust Docker and it's really gotten in there in a way that a lot of brand new technologies have not. And yet we're still pushing the boundaries of innovation at the same time. So when when we think about where dr fits in for developers, we've got dr official images, which are probably adopted the default for anything you're going to do in a container. You go and get a doctor official image and start doing it. But then what Right? You pulling a bunch of those, you start building applications, you start pulling other libraries, you build your own code on top, um, on your DEV environment where you're probably running doctor desktop to do so. And so we've got content coming from a trusted source, we've got dr running on the developer laptop and then we've got everything else like where else does it go from there? Uh, and so there's a ton of um, both problem and opportunity to help bring all that complex kind of spaghetti pipeline mess together and help provide people with the path of they can have confidence in while they're doing so. It's interesting because it's different for developers than it is for option. Security teams very, very different in terms of what they care about. >>So talk about the automation impact because I can see two things happening. One is the trusted environment, more containers everywhere. And then you have more developers coming on board. Right? So actually more people writing code, not just bots, machines and humans. So you have more people flooding in writing code, more containers everywhere that need to be trusted? What's the impact to the environment? What's the but how do you, how does develop experience get easier and simpler when that's happening? >>We see that as you get more and more content, The tail, the long tail continues to extend, right, more and more community generated third party content. People publishing their own applications on Docker hub and all across the Internet. And that makes the importance of being able to discover things that you can trust that you can incorporate without worrying about what might be there all the more important. So we've got dr official images today, we announced the doctor verified publisher program. All these are things that we're doing to try and make it easier for developers to find the good stuff to use it and not worry about it and just move on with their lives. >>What's your vision and what's your, what stalkers take on the collaboration aspect of coding? I think it's one of the key themes here. Where does that fit in? What's the story with collaboration? >>Yeah, we see this as an area that really has been left behind around the adoption of containers, the adoption of kubernetes, the focus has been so much on that pipeline and that path and production and production container orchestration where we watched the generation of kubernetes arise and most of the vendors in the space, we're doing some kind of top down infrastructure deal right selling to the VP of Ops or something along those lines. Um and so the development of those applications really was left by the wayside because that's not a problem that the VP of us cares about, but it's a very interesting problem as we think about dr being focused on developers now to help those teams collaborate because no application is built in a closet. Every single application that is built is built in partnership with other developers, with product managers, with designers, all these people who need to somehow work together to review not only the source code, but the application as a whole. >>What does the product? Um, Evolution looked like as Justin Cormack and I were talking about, you know, developer productivity, the simplification containers as a P. I. S. What is the, what is the priority? How, how do you look at that? Because the securities front and center and a variety of security partners here in the ecosystem. Where's the priorities on the road map? You can, if someone asked you, hey Donnie, what's the bottom line? What's the product strategy? >>Yeah, our priority is the team. First and foremost, it is not optimizing for the single developer, it is optimizing for that team working together effectively. We feel that that is a very underserved audience of that developer team as a unit. Um, if you look at everybody in the container space, like I said, they're all kind of focused on operations, production, cloud environments, not on that team. And so we see that as a great opportunity to solve really important problems that nobody else is doing a great job of solving today. >>I gotta ask you on the team formation is the general consensus. Also in a lot of my interviews here at dr khan and outside in the industry, is that the, the monolithic organization building monolithic applications certainly has been disrupted. Certainly the engineering teams now look like they're going to be into end workloads, full visibility and to end with an s sorry, on the team, everyone kind of built in these teams. We kind of platform engineering flexing in between. So you don't have that kind of like silent organization certainly has been discussed for well, but this seems to be the standard. Now, what's your take on this and is that what you mean by teams that could you share your view on how people are organizing teams? Because certainly get hub and a lot of other leaders are saying, yeah, we see the same way these teams have, you know, threaded leaders and or fully baked team members inside these teams. >>Yeah, we definitely see that team as a cross functional team. It's not, you know, your your old world, we might have been like, you've got the development team here, you've got the QA team here, you've got the operations team there. It's completely not that it's that team is it's got developers on it. If there are dedicated testers or software engineers and test their on it, if they need to have a devops person or an SRE there on it as well, it's all part of the same team and that team is building on top of the platforms that are exposed by other teams. And that's the big shift that I think has been in the works for probably a decade at this point has been that kind of rotation of responsibilities that you used to be, that DEV's owned the DEV environment and DEV test and ops owned Prod and everything about PROd and now it's much more that there are platforms that span every environment and there's a platform team responsible for each one of those components that delivers it in a self service way. And then there are teams that build on top of that that own their application all the way from development through to production, they support it there on call for it. This is how we work internally, our development teams in our product development teams, I should say, because they're cross functional, really take ownership for their applications and it's it's a super powerful imperative. It gives people the ability to iterate much more quickly by taking away a lot of those gatekeepers. And it's it's the same thing as a matter of fact, when I was at an enterprise before I joined dr it's the same thing we did. A big part of our strategy was creating these self service platforms so that product teams could move quickly. >>Remember I interviewed during the QB was awesome. Great concept. Go back to look at that tape. That's not exactly not tape, it's on disk, but Great. Great concept. Let me ask you one more question on that because one of the things that's clear that's coming out even in the university areas Engineering DeVOPS has now brought in much more of a focus of the SRE that used to be an ops role but now becomes becoming developer. I mean it's DEVOPS, as you said, it's been going on for a while over a decade now it's much more clear that this s. R. Re engineering role is key. So with that I've always thought Doctor and containers is a perfect integration tool capability. I mean why not? I mean that's one of the benefits of containers as you allow, you can contain arise things. So if you play out what you just said about the team's integration is huge. Talk about how you see that evolving as a product person. >>Yeah. I think as you say, the integration is huge. Um You know, one way that I look at it is that the application itself or the service itself is defined by either a container or a set of containers. Um And the product development team cares about what's inside of that set of containers up and to that container layer or that group of containers layer. Whether that's the doctor file with its containers. Docker compose those kinds of things and then there might be a platform team responsible for running a great kubernetes environment, whether they're using a cloud platform or in house and they care about everything outside of the containers, up to the containers as that interface. Uh So when we think about those focuses, like Docker is all about that application in words. Um And a lot of the more production oriented containers vendors are container outwards. So it's very different when we think about the kinds of problems we want to solve. It's about making that application definition really easy and portable and enabling a clean handoff to SRE teams who may be responsible for running that Apple product. >>You brought up trusted content, trusted containers, modern applications earlier. What does trusted containers mean to you? I mean that's I mean obviously means security built in but there's a lot of migration there with containers, containers coming in and out of clusters all the time. They're being orchestrated. They're being used with state and state stateless data. What does trusted content mean? >>No. Really, for us, the focus is an interesting one because when we think about building, sharing and running applications for developers, our run means we want to give developers are great interface into the production environment. We don't want to provide the production environment. And so some of those problems are ones we deeply care about where the developers are making sure that they've got a trusted, secure, verifiable path to get the content that they are incorporating into their app all the way to production or to a point of hand off. If there is a point of hand off, once it gets to production, it becomes the problem of different products and different vendors to make it really easy for those same enterprises to effectively secure that application and project. >>What does containers is as an A P. I mean that's just docker reference classic approach or is there a new definition to containers as a piece? Our container ap >>Yeah, I think the question becomes really interesting when you start thinking about what's inside of each one of those containers and how you might be able to use those as building blocks. Even thinking about trends that are on the rise, like Loco Noko development, how could you imagine incorporating containers or a service composed of a group of containers um, into one of those kinds of contexts to do so you have to have a clean ap that you can define and published in support of how a different component would interface with every one of those containers. What are the ports? What are the protocols? What are the formats? Every one of those things is important to creating an API >>So I gotta ask you don? T put you on the spot because you've been on many, many sides of the table, analyst Docker, you've been at an enterprise doing some hardcore devops. If I'm a customer out there and say I'm a classic main street enterprise. Hey Donnie, I'm putting my teams, we're kicking ass. We've been kicking the tires, been in the cloud pandemics, giving us a little lift, we know it to double down on, we feel good about where we're going. Um, but I got a couple clouds out there. I'm all in on one. I got another one going, but I'm going hybrid all the way. I don't even know what multi cloud is yet, but hybrid means edge and ultimately distributed computing. What do I do? What's the doctor Playbook, What do you, what do you say to me? How do you keep me calm and motivated? Yeah, >>I think, you know, the reality is like you say every company is going to be running in multiple different environments. Um It's probably not the same application in multiple environments and different apps and they've gotten to a place maybe accidentally as different business units are different functions started picking different clouds of their choice and getting them there. But in the end of it, like the company as a whole has to figure out how do I support that and how do I make it all work together effectively and deal with all the different, not just levels of expertise in these different environments, but the different levels of performance and latency to expect as you have applications that may need to run across all those, um you know, I used to work in the travel industry and you might have somebody trying to book a flight and that's but you know, bouncing across a cloud to a data center, to a different cloud, to a service provider and on back and you can imagine very quickly, how do you solve for those latency problems that we know are correlated to user experience and in an e commerce kind of context correlated with revenue because people balance if they can't get a good response, it's complicated. The fact is it's just it's a hard problem to solve. Um containers can definitely help solve part of that by providing a consistent platform that lets you take your applications from place to place. That lets you build a consistent set of expertise so that, you know, a container here is like a container, there is like a container over there um And work with those in a fairly consistent way. But there's always going to be differences. I think it's very dangerous to assume that because you have a container in multiple places, it's going to provide the same levels of guarantees. And we had a lot of these conversations back in the early 2010s when private cloud was really starting to pick up steam and we said Oh let's make compatible storage layers. Uh And it was true to a point you could provide api compatibility but you had to run as hard as you could to keep up with the changes and you couldn't provide the same level of resiliency, You couldn't provide the same level of data protection, you couldn't provide the same level of performance and global footprint and all those provide what what does the A. P. I mean to a developer using it. It's all of those things regardless of whether they're in an api spec somewhere. >>That's a great call out looking at the how things are moving so fast and you just got to keep up. It's almost like you want some peace, peace time kind of philosophy. So I gotta ask you as you look at the landscape again, you've got a unique perspective running product over a docker which puts you at the front lines and looking at the whole marketplace as as a whole cloud native. But you also been an analyst. I got to ask you what does success look like because as the world changes that it's not always obvious until you see it. And then you know that success and then some people are trying different approaches. How do you tell the winners from the losers or the better approaches versus the ones that struggle? Is there a pattern that you're seeing emerge from the pandemic as a team is a tech? What's the, what's the pattern of success that you see? Development teams and organizations deploying that's working and what's a sign of bad things? >>Yeah, I think, you know, one of the biggest patterns is the ability to iterate quickly and learn fast. You know, if there's nothing else that you can do, you just think about what are those basic principles that let you be Agile? Not as a development team. Agile is a company getting from those ideas and that customer feedback all the way through the loop. To build that thing, tested with your customers before you ship it, get it out there. Maybe you do some kind of a modern deployment practice to decrease your risk as you're doing so right. It's Canary, it's rolling, releases its blue green, all those things Right? How do you d risk, how do you experiment while you're doing so and how do you stay agile so that you're able to provide customer value as fast as possible? Almost every failure pattern that you see is one that happens because you're not listening to your customers effectively and often enough and you're not iterating quickly enough so you're building in a direction that is not what they wanted or needed, >>you know, looking at Dr khan 2021 this year, look at the calendar, the cube tracks in there, which I'm excited to do a bunch of coverage on. It's always fun. But you got the classic build share run, which is the ethos of Doctor, but you get a new track called accelerate, there is an acceleration coming out of the pandemic more than ever. Um it's been pretty cool. I mean you're seeing a lot more action in all areas but talk about the acceleration with containers and what you what you're seeing on the landscape side of the industry and how that's impacting customers. What specifically is this acceleration really all about? >>Yeah, when I think about what acceleration means to me, it's about how do you avoid building things, avoid finding things that you don't need to spend your time on? How can you pick things up? Incorporate those into your workflows, incorporate those into your applications that you don't have to build it yourself right, you can accelerate every time you want to accelerate. Its because somebody else built something that you can then reuse and build on top of whether its application components, whether that's SAs or apps, developer services, whether that's pre integrated pipelines. So you've already got plug ins and tools that work every one of those things as an accelerator, A lot of them are delivered by all kinds of different vendors all over the map. And so if they don't integrate well together, if there aren't open A. P. S, if there aren't pre integrated offerings, it's not gonna be an accelerator is gonna be exactly the opposite. It's going to be I want to get this thing in, let me bring in five or six different consulting teams to start trying to piece all this stuff together. Big, big slow down. So the pretty integrated solutions, the open A. P. S. Those are the kinds of things that really are going to accelerate people. >>I can't I can't agree with you more on this whole slowdown thing. And one of the hardest things to do is insert new team members are new kind of rules and process into kind of already accelerated momentum, which is hard. This is a hard new kind of a cloud native dynamic, which is scale and speed are critical, right? So it's one of those things that's actually benefit. But if you don't rein it in a little bit, how do you balance that? What's your advice to folks? This is, this is a common problem. I mean, it could get away from you. It's on one hand, but if you slow down too much, it's a gridlock and you, you misfire. What's your thoughts on this? >>Yeah, that, that balance of scale and speed. Um, and it definitely is a balance there. You know, I think there's always a danger of over architect ng for your current state of reality. Um, and you know, one of the things that I've learned over the years is, you've got to, you got to scale your process and scale your architecture to where you're at and where you're going to be soon, if you start Designing for five years, 10 years down the road, um it's going to slow you down in the short term and you might never get to where you thought you were going to be in five or 10 years. You've got to build for where you're at, built for where you're going soon, you're not gonna go for the future. And this is, it ties into these ideas like evolutionary architecture, like how do you build in a way that makes change easy because, you know, things are always going to change. Um, you know, some of the recent trends around things like project product playing so well to this, right? It's not like a project team comes together and builds the solution and then walks away and the solution works untouched for years or decades. Instead, it's it's that agile approach of is a product team there long lived. They own what they're building and they support it and they continue to enhance it, going forward to improve their ability to meet their customers needs over time. >>Yeah, and I think that's a super important point. The magical product team that just scales infinitely by itself while you're sleeping is different. Again, the team formation is an indicator of that. So, I think this whole agility going to the next level really is all about, you know, a series of these teams. Micro micro teams. Microservices, I mean, again, monolithic applications yielded monolithic organizations. >>Microservices >>brings in kind of this open source ethos, this new hate to use the term to Pizza team because it's an Amazonian thing, but it kind of applies here, Right? So you got to have these teams. I had to focus and to end and take ownership of that, whether it's product, platform or project at the end of the day, you're still serving customers. Final question for you on. Well, I got you here. I know end user experience you brought this up earlier. This is a huge important piece. I think last year, you and I talked about this briefly in our interview as developers come to the front lines of the business, some of them all don't have M B A. S and that always, you know, going to business school and some of the best engineers shouldn't go to business school in my opinion, But but you know, they have to learn the vernacular of complex topics, understand quality, get bring craft into the software more and more developers on the front lines closer and closer to the customer as they go direct. This is a huge change from just 5, 10 years ago. What's your thoughts on this? And what do you tell people when when they say hey donnie what how should I ah posture to the customer? What can I do to get better? What do you say to that? >>Yeah it's a great question. Um and it's one that I think a lot of companies are struggling to solve. How do we bring developers closer to the customers? And what does that mean? One of the things that we do regularly at Dr is we bring our developers along on customer interviews. So our product managers are constantly out there, you know kind of beating the virtual street, talking to developers talking to customers. Um and regularly they'll bring developers on the same team along. This is super valuable in helping our developers really build an understanding of the customers are building for, right. It may not even be about that specific thing that they're building on that one day. Um but it's about understanding the customer's needs and really making that something that is internalized in the way they think about how do they solve problems? How do they design solutions? How do they do? So in a way that is much more likely to resonate with the customers. Um Do they have an NBA? No, but where do you start? You gotta start somewhere? You start by bringing people into the conversation, so we don't expect them to lead an interview. We expect them to come along, learn and ask questions. And what happens so often is that people with, you know, the business in other companies might say yeah, developers, they're just these tech people will just like give him a set of requirements and they'll deliver stuff. Um but bring them along for the ride and letting them interact with the customers that are using their product is an amazing and exciting experience for developers. We hear consistently just super excited, treat back. >>It's clearly the trend. I mean one of the best, the best performing teams have the business and developers working together. It's really interesting phenomenon. I think it's going to change the makeup of taking that and to end approach to a whole nother level dani. Great to have you on. Great to see you final question. Um take a minute to put a plug in for the product team over there. What are you working on? What are you most excited about? Give a quick plug? >>You know, I am super excited about what we're doing in both trusted content and around team collaboration. Um I think both of those are just going to be amazing. Amazing opportunities to improve how developers are working on their microservices. It's so fragmented, it's so complicated that helping make that easier is going to be really important and valuable an area for development teams to focus on. >>Uh, Dr khan 2021 Virtual, Donnie Bergholz, VP of products and Dakar, good friend of the CUBA and the industry as well. Dani, thanks for that. Great insight and sharing some gems you drop there. Thanks. >>All right. Thank you. All >>right. Dr khan coverage I'm john for your host of the cube, The Cube track here at Dakar 2021 virtual. Thanks for watching. Mhm.

(lively music) >> Hello, and welcome to this special CUBE conversation. I'm John Furrier, founder of SiliconANGLE Media, co-host of theCUBE. We are here in our Palo Alto Studio to have a conversation around cloud computing, multi-cloud, hybrid cloud, the changes going on in the IT industry and for businesses across the globe as impacted by cloud computing, data, AI. All that's coming together, and a lot of people are trying to figure out how to architect their solution to scale globally but also take care of their businesses, not just cutting costs for information technologies, but delivering services that scale and benefit the businesses and ultimately their customers, the end users. I'm here with a very special guest, Donnie Berkholz, who's the VP of IT services delivery at CWT, Carlson Wagonlit Travel. Also the program chair of the Open Source summit, part of the Linux Foundation, formerly an analyst, a great friend of theCUBE. Donnie, great to see you. Thanks for joining us today. >> Well, thanks for having me on the show. I really appreciate it. >> So we've been having a lot of conversations around, obviously, cloud. We've been there, watching it, from day one. I know you have been covering it as an analyst. Part of that cloud ought to go back to 2007, '08 time frame roughly speaking, you know, even before that with Amazon. Just the massive growth certainly got everyone's attention. IBM once called Amazon irrelevant. Now going full cloud with buying Red Hat for billions and billions of dollars at a 63% premium. Open Source has grown significantly, and now cloud absolutely is the architectural linchpin for companies trying to change how they do business, gather more efficiencies, all built on the ethos of DevOps. That is now kind of going mainstream. So I want to get your thoughts and talk about this across a variety of touchpoints. One is what people are doing in your delivering services, IT services for CWT, and also trying to get positioned for the future. And then Open Source. You're on the Open Source program chair. Open Source driving all these benefits, now with IBM buying Red Hat, you've seen the commercialization of Open Source at a whole nother level which is causing a lot of conversation. So tell us what you're doing and what CWT is about and your role at the company. >> Absolutely, thank you. So CWT, we're in the middle of this journey we call CWT 3.0, which is really one about how do we take the old school green screens that you've seen when you've got travel agents or airline agents booking travel and bring people into the picture and blend together people with technology. So I joined about a year and a half ago to really help push things forward from the perspective of DevOps, because what we came to realize here was we can't deliver quickly and iterate quickly without the underlying platforms that give us the kind of agility that we need without the connections across a lot of our different product groups that led us, again, to iterate on the right things from the perspective of our customers. So I joined a year and a half ago. We've made a lot of strides since then in modernizing many of our technology platforms. The way I think about it here, it's a large enterprise. We've got hundreds of different applications. We've got many, many different product teams, and everything is on a spectrum. We've got some teams that are on the bleeding edge. Not even the leading edge, but I'd say the bleeding edge, trying out the very latest things that come out, experimenting with brand new Open Source tools, with brand new cloud offerings to see, can we incorporate that as quickly as possible so we can innovate faster than our competitors? Whether those are the traditional competitors or some of the new software companies coming into things from that angle. And then on the other end of the spectrum, we've got teams who are taking a much more conservative approach, and saying, "Let's wait and see what sticks "before we pick it up." And the fortunate thing, I think, about a company at the scale we are, is that we can have some of those groups really innovating and pushing the needle, and then other groups who can wait and see which parts stick before we start adopting those at scale. >> And so you've got to manage the production kind of stability versus kind of kicking the tires for the new functionality. So I've got to ask you first. Set up the architecture there. Are you guys on premise with cloud hybrid? Are you in the cloud-native? Do you have multiple clouds? Could you just give a sense of how you're deploying specifically with cloud? >> Yeah, absolutely. I think just like anything else, it's a spectrum of all we see here. There's a lot of different products. Some of them have been built cloud-native. They're using those serverless functions as service technologies from scratch. Brought in some leaders from Amazon to lead some of that drive here. They brought in a lot of good thinking, a lot of good culture, a lot of new perspective to the technologies we're adopting as a company that's not traditionally been a software company. But that is more and more so every day. So we've got some of that going on as completely cloud-native. We've got some going on that's more, I would say, hybrid cloud, where we're spanning between a public cloud environment back to our data centers, and then we've got some that are different applications across multiple different public clouds, because we're not in any one place right now. We're putting things in the best place to do the job. So that's very much the approach that we take, and it's one that, you know, back when I was in my analyst's world, as one of my colleagues called it, the best execution venue. What's the best place? What's the right place to do the right kind of task? We incorporate what are the best technologies we can adopt to help us differentiate more quickly, and where does the data live? What's the data gravity look like? Because we can't be shipping data back and forth. We can't have tons of transactions going back and forth all the time between different public clouds or between a public cloud and one of our data centers. So how do we best account for that when we're architecting what our applications should look like, whether they're brand new ones or whether they're ones we're in the middle of modernizing. >> Great, thanks for sharing, that's great, so yeah, I totally see that same thing. People put, you know, where the best cloud for the app, and if you're Microsoft Shop, you use Azure. If you want to kick the tires on Amazon, there's good roles for that, so we're seeing a lot of those multiple clouds. But while I've got you on the line here, I know you've been an analyst. I want you to just help me define something real quick because there's always kind of confusion between hybrid cloud and multi-cloud. Certainly the multi-cloud, we're getting a lot of hype on that. We're seeing with Kubernetes, with stateful applications versus stateless. You're seeing some conversations there. Certainly on Open Source, that's top of the agenda. Donnie, explain for folks watching the difference between hybrid cloud and multi-cloud, because there's some nuances there, and some people have different definitions. How do you guys look at that? Cause you have multiple clouds, but some aren't necessarily running a workload across clouds yet because of latency issues, so define what hybrid means to you guys and what multi-cloud means to you. >> All right, yeah, I think for us, hybrid cloud would be something where it's about integrating an on-prem workload off a more traditional workload with something in a public cloud environment. It's really, hybrid cloud to me is not two different public clouds working together or even the same application in two different public clouds. That's something a little bit different, and that's where you start to get, I think, into a lot of the questions of what is multi-cloud? We've seen that go through a lot of different transitions over the past decade or so. We've seen a lot of different, you know, vendors, going out there thinking they could sell multi-cloud management that, you know, panned out at different levels of success. I think for at least a decade, we've been talking about ideas like can we do cloud bursting? Has that ever really worked in practice? And I think it's almost as rare as a unicorn. You know, on-prem for the cost efficiencies and then we burst the cloud for the workload. Well, you know, to this day, I've never seen anything that gives you 100% functionality and 100% performance comparability between an on-prem workload and public cloud workload. There always seems to be some kind of difference, and this is a conversation that, I think, Randy Bias has actually been a great proponent of it's not just about the API compatibility. It's not just, you know, can I run Azure in their data centers or in mine? It's about what is the performance difference look like? What does the availability difference look like? Can I support that software in my data center as well as the engineers at Microsoft or at Amazon or at Google or wherever else they're supporting it today? Can I keep it up and running as well? Can I keep it performing as well? Can I find problems as quickly? And that's where it comes to the question of how do we focus on our differentiators and let the experts focus on theirs. >> That's a great point about Randy Bias. Love that great API debate. I was looking at some of that footage we had years ago. But this brings up a good point that I want to get your reaction to, because, you know, a lot of vendors going out there, saying, "Oh, our cloud's this. "We've got all this stuff going on," and there's a lot of hype and a lot of posturing and positioning. The great thing about cloud is that you really can't fake it until you make it. It's got to be working, right? So when you get into the kind of buying into the cloud. You say, "Okay, great, we're going to do some cloud," and maybe you get some cloud architects together. They say, "Okay, here's what it means to us. "In each environment, we'll have to, you know, "understand what that means and then go do it." The reality kind of kicks in, and this is what I'd like to get your reaction to. What is the realities when you say, "Okay, "I want to go to cloud," either for pushing the envelope and/or moving solid workloads that are in production into the cloud. What is the impact on the network, network security, and application performance? Because at the end of the day, those are going to be impacted. Those three areas come up a lot in conversations when all of the glam and all the bloom is off the rose, those are the things that are impacted. What's your thoughts on how practitioners should prepare for those three areas? The network impact, network security impact, and application performance? >> Yeah, I think preparation is exactly the right word there of how do we get the people we have up to speed? And how do we get more and more out of that kind of project mindset and into much more of the product mindset and whether that product is customer-facing or whether that product is some kind of infrastructure or platform product? That's the kind of thinking we're trying to have going into it of how do we get our people, who, you know, may run a Ci Cd pipeline, may run an on-prem container platform, may even be responsible for virtualization, may be responsible for on-prem networks or firewalls or security. How do we get them up to speed and turn them into real software engineers? That's a multi-year journey. That's not something that happens overnight. You can't bring in a team of consultants to fix that problem for you and say, "Oh, well, we came in and implemented it, "and now it's yours, and we walk out the door." It's no longer that, you know, build and operate mindset that you could take a little bit more with on-prem. Because everything is defined as code. And if you don't know how to deal with code, you're going to be in a real rough spot the next time you have to make a change to that stuff that that team of consultants came in and implemented for you. So I think it's turned into a much more long-term approach, which is very, very healthy for technology and for technology companies as a whole of how do we think about this long-term and in a sustainable way, think about scaling up our people. What do those training paths look like? What do those career paths look like? So we can decide, you know, how many people do we want certified? What kind of certifications should they have or equivalent skill sets? I remember hearing not too long ago that I think it was Capital One had over 10,000 people who were AWS certified, which is an enormously large number to think about, but that's the kind of transitions that we've been making as we become more and more cloud-native and cloud by default, is getting the right people. The people we have today trained up in these new kinds of skill sets instead of assuming that's something we can have some team fly in from magic land and implement and then fly away again afterwards. >> That's great, Don, thanks for sharing that insight. I also want to get your thoughts on the Open Source summit, but before we get there, I've got to ask you a question around some of the trends we've been seeing. Early on at DevOps we saw this together of the folks doing the hard work in the early pioneering days, where you saw the developers really getting closer to the front lines. They were becoming part of the business conversation. In the old world of IT, "Okay, here's our strategy. "Consolidate this, load some virtual machines," you know, "Get all this stuff up and running." The business decisions would then trickle down to the tech folks, then with the DevOps revolution, that's now cloud computing and all things, you know, IoT and everything else happening where the developers and the engineering side of it and the applications are on the front lines. They're in more of the business conversations, so I have to ask you. When you're at CWT, what are some of the business drivers and conversations that you guys are having with executive management around choices? Are they business drivers? Do you see an order of preference around agility? The transformation value for either customers or employees, compliance and security, are the top ones that people talk about generally. Of those business drivers, which ones do you guys see the most that are part of iterating through the architecture and ultimately the environment that you deploy? >> Yeah, I think as part of what I mentioned earlier, that we're on this journey we call CWT 3.0, and what's really new about that is bringing in speed and agility into the conversation of if we have something that we imagine as a five year transformation, how do we get to market quickly with new products so that we can start really executing and seeing the outcomes of it? So we've always had the expectations around availability, around security, around all these other factors. Those aren't going away. Instead, we're adding a new one, so we've got new conversations and a new balance to reach at an executive level of we now need a degree of speed that was not the expectation, let's say, a decade ago. It may not even have been the expectation in our industry five years ago, but is today. And so we're now incorporating speed into that balance of maybe we'll decide to very intentionally say, "We're not going to go over quite as many nine's today "so that we can be iterating more quickly on our software." Or, "We're going to invest more "in better release management approaches and tools," right? Like Canary releases, like, you know, Green-Blue releases, all these sorts of new techniques, feature flags, that sort of thing so that we can better deal with speed and better account for the risk and spread it to the smallest surface area possible. >> And you were probably doing those things also to understand the impact and look at kind of what's that's coming in that you're instrumenting in infrastructure because you don't want to have to put it out there and pray and hope that it works. Right, I mean? The old way. >> The product teams that are building it are really great and really quick at understanding about what the user experience looks like. And whether that's their Real User monitoring tools or through, you know, other tools and tricks that we may incorporate to understand what our users are doing on our tools in real time, that's the important part of this, is to shorten the iteration cycle and to understand what things look like in production. You've got to expose that back to the software engineers, to the business analysts, to the product managers who are building it or deciding what should be built in the first place. >> All right, so now that you're on the buyer's side, you've actually got people knocking on your door. "Hey, Donnie, buy my cloud. "Do this, you know, I've got all these solutions. "I've got all these tools. "I've got a toolshed full of," you know, the fool with the tool, as they say. You don't want to be that person, right? So ultimately you've got to pick an environment that's going to scale. When you look at the cloud, how do you evaluate the different clouds? You mentioned gravity or data gravity earlier. All kinds of new criteria is up there now in terms of cloud selection. You mentioned best cloud for the job. I get that. Is there certain things that you look for? Is there a list? Is there criteria on cloud selection that goes through your desk? >> Yeah, I think something that's been really healthy for me coming into the enterprise side from the analyst perspective is you get a couple of new criteria that start to rise up real quickly. You start thinking about things like what's that vendor relationship going to look like? How is the sales force? Are they willing to work with you? Are they willing to adapt to your needs? And then you can adapt back with them so you can build a really strong, healthy relationship with some of your strategic vendors, and to me, a public cloud vendor is absolutely a strategic vendor. That's one where you have to really care a lot and invest in that relationship and make sure things go well when you're sailing together, going in the same direction. And so to me, that's a little bit of a newer factor because it was easy to sit back and come in as the strategic advisor role and say, "Oh, you should go with this cloud. "You should go with that cloud "because of reasons X, Y, or Z," but that doesn't really account for a lot of things that happen behind the scenes, right? What's your sourcing and human department doing? How do they like to work with around contract, right? Will you negotiate a good MSA? All these sorts of things where you don't think about that when you're only thinking about technology and business value. You also have to think about the other, just the day to day, what does it look like? What's the blocking and tackling working with some of those strategic vendors? So you've got that to incorporate in addition to the other criteria around do they have great managed services? You know, self-service managed services that will work for your needs? For example, what do they have around data bases? What do they have around stream processing? What do they have around serverless platforms, right? Whatever it might be that suits the kinds of needs you have. Like for example, you might think about what does our business look like, and it's a graph, right? It's travelers, it's airports, it's planes, it's hotels. It's a bunch of different graphs all intersecting, and so we might imagine looking for a cloud provider that's really well-suited to processing those sorts of workloads. >> In the old days, the networking guys used to run the keys to the kingdom. Hey, you know, I'm going to rack and stack servers. I'm going to do all this stuff, but I've got to go talk to the networking guys, make sure all the routes are provisional and all that's locked down, mainly because that was a perimeter environment then. With cloud now, what's the impact of the networking? What's the role of the network? As we see DevOps notion of infrastructure as code, you've got to compute networking stores as three main pillars of all environments. Compute, check. Stores getting better. Networking, can you imagine Randy Bias? This was a big pet peeve for him. What's the role that cloud does? What's the role of the network with your cloud strategy? >> Yeah, I think something that I've seen following DevOps for the past decade or so has been that, you know, it really started as the ops doing development moved more into the developers and the ops working together and in many cases sharing roles in different ways, then incorporated, you know, QA, and incorporated product, to some extent. Most recently it's really been focused on security and how do we have that whole DevSecOps, SecDevOps thing going on. Something that's been trailing behind a little bit was network, absolutely. I had some very close friends about 10 years ago, maybe, who were getting into that, and they were the only people they knew and they only people they'd ever even heard of thinking beyond the level of using some kind of an expect script to automate your network interaction. But now I think networking as code is really starting to pick up. I mean, you look at what people are doing in public cloud environments. You look at what Open Source projects like Ansible are doing or on the new focus on network functionality. They're not alone in that. Many others are investing in that same kind of area. It's finally really starting to get up. Like for example, we have an internal DevOps Day that we run twice a year, and at the most recent one, guess who one of our speakers was? It was a network engineer talking about the kinds of automation they'd been starting to build against our network environments, not just in public cloud, but also on-premise. And so we're really investing in bringing them into our broader DevOps community, even though Net may not be in the name today. I don't think the name can ever extend to include all possible roles. But it is absolutely a big transition that more and more companies, I think, are going to see rolling along, and one that we've seen happening in public cloud externally for many, many years now. It's been inevitable that the network's going to get engaged in that automation piece. And the network teams are going to be more and more thinking about how do we focus our time in automation and on defining policy, and how do we enable the product teams to work in a self-service way, right? We set up the governance, but governance now means they can move at speed. It doesn't mean wait seven to 30 days for us to verify all of the port openings, match our requirements, and so on and so forth. That's defined up front. >> Yeah, and that's awesome, and I think that's the last leg of the stool in my opinion, and I think you nailed it. Making it operationally automation enabled, and then actually automating it. So, okay, before we get to the Open Source, one final question for you. You know, as you look at plan for the technologies around containers and microservices, what sounds a lot like networking constructs, provisioning, services. The role of stateless applications become a big part of that. As you look at those technologies, what are some of the things you're looking for and evaluating containers and microservices? And what role will that play in your environment and your job? >> I think something that we spend a lot of time focusing on is what is the day two experience going to look like? What is it going to be like? Not just to roll it out initially, but to, you know, operate on an ongoing basis, to make upgrades, to monitor it, to understand what's happening when things are going wrong, to understand, you know, the security stance we're at, right? How well are we locked down? Is everything up-to-date? How do we know that and verify it on a continuous basis instead of the, you know, older school approach of hey, we kind of do a ECI survey or an audit, you know, once a year, and that's the day we're in compliance, and then after that, we're not. Which I was just reading some stories the other day about companies saying, "Hey, there's a large percentage "of the time that you're out of compliance, "but you make sure to fix it just in time "for your quarterly surveys or scans or what have you." And so that's what we spend a lot of our time focusing on is not just the ease of installation, but the ease of ongoing operability and getting really good visibility into the security, into the health, of the underlying platforms that we're running. And in some cases, that may push us to, let's say, a cloud managed service. In some cases, we may say, "Well, that doesn't quite suit our needs." We might have some unique requirements, although I spend a lot of my time personally saying, "In most cases, we are not a snowflake, right?" We should be a snowflake where we differentiate as a company. We should not be a snowflake at the level of our monitoring tools. There's nothing unique we should really be doing in that area. So how can we make sure that we use, whether it's trusted vendors, trusted cloud providers, or trusted Open Source projects with a large and healthy community behind them to run that stuff instead of build it ourselves, 'cause that's not our forte. >> I love that. That's a great conversation I'd love to have with you another time around competitive advantage around IT which is coming back in vogue again. It hasn't been that way in awhile because of all the consolidation and outsourcing. You're seeing people really, really ramp up and say, "Wait a minute, we outsourced our core competency and IT," and now with cloud, there's a competitive advantage, so how do you balance the intellectual property that you need to build for the business and then also use the scale and agility with Open Source? So I want to move to that Open Source conversation. I think this is a good transition. Developers at the end of the day still have to build the apps and services they're going to run on these environments to add value. So Open Source has become, I won't say a professional circuit for developers. It really is become the place for developers because that's where now corporations and projects have been successful, and it's going to a whole nother level. Talk about how Open Source is changing, and specifically around it becoming a common vehicle for one, employees of companies to participate in as part of their job, and two, how it's going to a whole nother level with all this code that's flying around. You can't, you know, go dig without finding out that, you know, new TensorFlow library's been donated for Google, big code bases are being rolled in there, and still the same old success formula for Open Source is continuing to work. You're on the program chair for Open Source summit, which is part of the Linux foundation, which has been very, very successful in this modern era. How has that changed? What's going on in Open Source? And how does that help people who are trying to stand up architecture and build businesses? >> I think Open Source has gone through a lot of transitions over the past decade or so. All right, so it started, and in many ways it was driven by the end users. And now it's come back full circle so that it's again driven more and more by the end users in a way that there was a middle term there where Open Source was really heavily dominated by vendors, and it's started to come back around, and you see a lot of the web companies in particular, right? You're sort of Googles and Amazons and LinkedIns and Facebooks and Twitters, they're open sourcing tools on an almost daily basis, it feels like. I just saw another announcement yesterday, maybe the day before, about a whole set of kernel tools that I think it was Facebook had open sourced. And so you're seeing that pace just going so quickly, and you think back to the days of, for example, the Apache web server, right? Where did that come about from? It didn't come from a software vendor. It came from a coalition of end users all working together to develop the software that they needed because they felt like there's a big gap there and there's an opportunity to cooperate. So it's been really pleasing for me to see that kind of come back around full circle of now, you can hardly turn around and see a company that doesn't have some sort of Open Source program office or something along those lines where they start to develop a much more healthy approach to it. All right, the early 2000's, it was really heavy on that fear and uncertainty and doubt around Open Source. In particular by some vendors, but also a lot of uncertainty because it wasn't that common, or maybe it wasn't that visible inside of these Fortune 500 global 2000 companies. It may have been common, right? What we used to say back when I worked at RedMonk was you turned around, and you asked the database admins, you know, "Are you running MySQL? "Or are you running Postgres?" You asked the infrastructure engineers, "Are you running Linux here?" and you'll get a yes, nine times out of ten, but the CIO was the last to know. Well now, it's started to flip back around because the CIO's are seeing the business value and adopting Open Source and having a really healthy approach to it, and they're trying to kind of normalize the approach to it as a consequence to that, saying, "Look, it's awesome "that we're adopting Open Source. "We have to use this "so that we can get a competitive advantage "because every thousand lines of code we can adopt "is a thousand lines of code we don't have to write, "and we can focus on our own products instead." And then starting to balance that new model of it used to be, you know, is it buy versus built? And then Sass came around, and it's buy versus build versus rent. And now there's Open Source, and it's buy versus build versus rent versus adopt. So every one of these just shifts conversation a little bit of how do you make the right choice at the right time at the right level of the stack? >> Yeah, that's a great observation, and it's awesome insight. It feels like dumping a little bit, a lot of dumping going on in Open Source, and you worry that the flood of vendor-contributed code is the new tactic, but if you look at all the major inflection points from the web, you know, through bitcoin, which is now 10 years old this year, it all started out as organic community projects or conversations on a message board. So there's still a revolution, and I think you're right. Their script is flipping around. I love that comment about the CIO's were last to know about Open Source. I think now that might be flipping around to the CIO's will be last to know about some proprietary advantage that might come out. So it's interesting to see the trend where you're starting to see smart people look at using Open Source but really identifying how they can use their engineering and their intellectual capital to build something proprietary within Open Source for IT advantage. Are you seeing that same trend? Is that on the radar at all? Is that just more of a fantasy on my part? >> I think it's always on the radar, and I think especially with Open Source projects that might be just a little bit below the surface of where a company's line of business is, that's where it will happen the most often. And so, you know, if you were building an analytics product, and you decided to build it on top of, you know, maybe there's the ELK Stack or the Elastic Stack, or maybe there's Graylog. There's a bunch of tools in that space, right? Maybe, you know, Solar, that sort of thing. And you're building an analytics tool or some kind of graph tool or whatever it might be, yeah, you might be inclined to say, "Well, the functionality's not quite there. "Maybe we need to build a new plugin. "Maybe we need to enhance a little bit." And I think this is the same conversation that a lot of the Linux kernel embedded group went through some number of years ago, which is, it's long term a higher burden to maintain a lot of those forks in-house and keep updating them forever than it is to bring some of that functionality back upstream. That's a good, healthy dialogue that hopefully will be happening more and more inside a lot of these companies that are taking Open Source and enhancing it for their own purposes, is taking the right level of those enhancements, deciding what that right level is, and contributing those back upstream and building a really healthy upstream participation regardless of whether you're a software vendor or an adopter of that software that uses it as a really critical part of their product stack. >> Awesome, Donnie, thanks for spending the time chatting with me today. Great to see you, great to connect over our remote here in our studio in Palo Alto. A final question for you. Are you having fun, these days? And what are you most excited about because, again, you've seen. You've been on multiple sides of the table. You've seen what the vendors have. You actually had the realities of doing your job to build value for Carlson Wagonlit Travel, CWT. What are you excited about right now? What's hot for you? What's jazzing you these days? >> Yeah, I think what's hot for me is, you know, to me there's nothing or very little that's revolutionary in technology. A lot of it is evolutionary, right? So you can't say nothing's new. There's always something a little bit different. And so the serverless is another example of something that it's a little bit different. It's a little bit new. It's similar to some previous takes, but you got new angles, specifically around the financials and around, you know, how do you pay? How is it priced? How do you get really almost closer to the metal, right? Get the things you need to happen closer to the way you're paying for them or the way they're running. That's remains a really exciting area for me. I've been going to Serverlessconf for probably since the first or second one now. I haven't been to the most recent one, but you know, there's so much value left in there to be tapped that I'm not yet really on to say, "What's next? What's next?" I've helped myself move out of that analyst world of getting excited about what's next, and for me it's now, "What's ready now?" Where can I leverage some value today or tomorrow or next week? And not think about what's coming down the pipe. So for me, that's, "Well, what went GA?" Right? What can I pick up? What can I scale inside our company so that we can drive the kinds of change we're looking for? So, you know, you asked me what am I the most excited about right now, and it's being here a year and a half and seeing the culture change that I've been driving since day one start to come back. Seeing teams that have never built automation in their lives independently go and learn it and build some automation and save themselves 80 hours a month. That's one example that just came out of our group a couple months back. That's what's valuable for me. That's what I love to see happen. >> Automation's addicting. It's almost an addictive flywheel. We automate something. Oh, that's awesome. I can move on to something else, something better. That was grunt work. Why do I want to do that again? Donnie, thanks so much, and again, thanks for the insight. I appreciate you taking the time and sharing with theCUBE here in our studio. Donnie Berkholz is the VP of IT source of CWT, a great guest. I'm John Furrier here inside theCUBE studio in Palo Alto. Thanks for watching. (lively music)