>>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.