 Welcome back to theCUBE's coverage of DockerCon 2021. Virtual, I'm John Furrier, host of theCUBE, got a great CUBE segment here at Donnie Burkholz. VP of products at Docker, industry, veteran, seen all the ways of innovation now. Had a product at Docker, Donnie, great to see you. It's so great to see you again too, John. Hey, great program this year at DockerCon, almost pushing the envelope again. Just the world's changed significantly over the past few years, and this past year has been pretty crazy. Last year we were virtual, but at the beginning of the pandemic, the watershed moment, DockerCon 2020, you know, with that virtual event, and then share action-packed keynote track, four tracks, run, share, build, accelerate. You got a CUBE track, you got live hits, 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. CUBECon's very operational, you know, operators. DockerCon's very development focused. So this is a key developer event, really in the CNCF, cloud native world. What's going on in the pros? Give us the update. Yeah, and I think you made a fantastic point there, John, which is the developer focus. I joined Docker 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 for 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 a 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 a thing, we can ship it, we'll kind of shove it in your face and try and sell it to you. So I'm really excited about what we're doing at Docker by delivering things that our developers really care about based on problems that they have told us are really valuable to solve, problems that when we win, we win 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 if you've seen the keynote already, you'll see more and more of that. We announced four really big things and a lot of smaller things as well. Things like the Docker Verified Publisher Program, which brings more trusted content. The Docker Dev environments that help teams collaborate more effectively. Docker Desktop on Apple Silicon, bringing environments to the latest and greatest Dev machines that everybody is trying to get a hold of, especially now that CPUs are harder to come by, as well as 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 CI provider gets hacked, then they get hacked too. We're trying to help them defend against those kinds of cases. It's funny you made me think of 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 Docker, use 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 in real time out in the audience out there saying, okay, you got trust, supply chain, hardware, software, containers, there's no perimeter in clouds. So you have to have 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 supply chain actually hits home here. Talk about that, what all of this means. Yeah, I think Docker 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. 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 we think about where Docker fits in for developers, we've got Docker official images, which are probably adopted. The default for anything you're going to do in a container, you go and get a Docker official image and start doing it. But then what, right? You pull in a bunch of those, you start building applications, you start pulling other libraries, you build your own code on top on your dev environment where you're probably running Docker desktop to do so. And so we've got content coming from a trusted source. We've got Docker running on the developer laptop. And then we've got everything else, like where else does it go from there? And so there's a ton of both problem and opportunity to help bring all that complex kind of spaghetti pipeline mess together and help provide people with a path that they can have confidence in while they're doing so. It's interesting because it's different for developers than it is for options 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 needs to be trusted. What's the impact to the environment? What's the, how does developer experience get easier and simpler when that's happening? Now we see that as you get more and more content, 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. And so we've got Docker official images. Today we announced the Docker Verified Publisher Program. All of these are things that we're doing to try and make it easier for developers to find the good stuff, to use it and to not worry about it and just move on with their lives. What's your vision and what's Docker's 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 to production and production container orchestration, we watched the generation of Kubernetes arise and most of the vendors in the space were doing some kind of a top-down infrastructure deal, selling to the VP of ops or something along those lines. And so the development of those applications really was left by the wayside because that's not a problem that the VP of ops cares about. But it's a very interesting problem as we think about Docker 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 of 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 of evolution look like? As Justin Cormack and I were talking about developer productivity, the simplification containers as APIs, what is the priority? How do you look at that? Because that's the securities front and center, got a variety of security partners here in the ecosystem. Where's the priorities on the roadmap? 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. 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 got to ask you on the team formation, is the general consensus also in a lot of my interviews here at DockerCon and outside in the industry is that the monolithic organization building monolithic applications certainly has been disrupted. Certainly the engineering teams now look like they're going to be end to end workloads full visibility end to end with an SRE 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 siloed organization. Certainly it's been been discussed for a while, but this seems to be the standard now. What's your take on this? And is that what you mean by teams? Or could you share your view on how people are organizing teams? Because certainly GitHub and a lot of other leaders are saying, yep, we see the same way. These teams have 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, your old world dream 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 is completely not that it's that team is it's got developers on it. If there are dedicated testers or software engineers and tested there on it, if they need to have a DevOps person or an SRE, they're 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. They used to be that devs 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, they're on call for it. This is how we work internally, right? Our development teams and our product development teams I should say, because they're cross-functional really take ownership for their applications. And 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 the same thing as a matter of fact when I was at an enterprise before I joined Docker 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. I remember I interviewed you on theCUBE. It was awesome, great conversation. Go back and look at that tape. That's not exactly not tape, it's on disk but great, great conversation. 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 a 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 SRE engineering role is key. So with that, I've always thought Docker and containers as a perfect integration tool, right? Capability, I mean, why not? I mean, that's one of the benefits of containers is you allow you can containerize things. So if you play out what you just said about the teams integration is huge. Talk about how you see that evolving as a product person. Yeah, I think as you say, the integration is huge. 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 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 Docker 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. So when we think about those focuses like Docker is all about that application inwards 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 app and 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 mean security built in but there's a lot of migration with containers. You containers come in and out of clusters all the time. They're being orchestrated. They're being used with state and stateless data. What does trusted content mean? 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 a 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're incorporating into their app all the way to production or to a point of handoff if there is a point of handoff. 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 in prod. What does containers as an API mean? Is that just Docker reference, classic approach? Or is there a new definition to containers as APIs or container API? 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 low code, no code development, how could you imagine incorporating containers or a service composed of a group of containers into one of those kinds of contexts? To do so, you have to have a clean API that you can define and publish 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 got to ask you, Donny, put you on the spot because you've been on many, many sides of the table, analysts down at Docker, you've been at an enterprise doing some hardcore DevOps. If I'm a customer out there, I'd say I'm a classic Main Street enterprise. Hey, Donny, I'm putting my teams, we're kicking ass, we've been kicking the tires, been in the cloud, pandemic's given us a little lift. We know what to double down on. We feel good about where we're going, but I got a couple of 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 multicloud is yet, but hybrid means edge and ultimately distributed computing. What do I do? Docker Playbook, what do you say to me? How do you keep me calm and motivated? Yeah, I think the reality is, like you say, every company is going to be running in multiple different environments. It's probably not the same application in multiple environments, it's different apps and they've each gotten to a place. Maybe accidentally as different business units or different functions started ticking different clouds of their choice and getting them there. But in the end of it, 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. I used to work in the travel industry and you might have somebody trying to book a flight and that's 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, like how do you solve for those latency problems that we know are correlated to user experience and in a e-commerce kind of context correlated with revenue because people balance if they can't get a good response and it's complicated. The fact is it's just, it's a hard problem to solve. 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 a container here is like a container there, 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 kind of the early 2010s when private cloud was really starting to pick up steam. And we said, oh, let's make compatible storage layers. And that was true to a point. You could provide API compatibility, but you had to have a lot of storage 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 of those provide what, what does the API 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, you want some peacetime kind of philosophy. So I got to ask you, as you look at the landscape again, you've got a unique perspective of running product over a Docker, which puts you with the front lines and looking at the whole marketplace as a whole cloud native, but you also been an analyst. I got to ask you, what does success look like? Cause as the world changes, it's not always obvious until you see it. And then you go, that's 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, as 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 could do, you just think about what are those basic principles that let you be agile, not as a development team. Agile is a company, right? Getting from those ideas and that customer feedback all the way through the loop to build that thing, test it with your customers before you ship it, get it out there, maybe 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, it's blue, green, all those things, right? How do you de-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? Like 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 DockerCon 2021 this year, look at the calendar, obviously 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 Docker, but you got a new track called Accelerate. There is an acceleration coming out of the pandemic more than ever. 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'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. It's because somebody else built something that you can then reuse and build on top of, whether that's application components, whether that's SaaS or APIs, developer services, whether that's pre-integrated pipelines, so that you've already got plugins and tools that work. Every one of those things is 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 APIs, if there aren't pre-integrated offerings, it's not going to be an accelerator, it's going to be exactly the opposite. It's going to be, I want to fit this thing in, let me bring in five or six different consulting teams to start trying to piece all this stuff together, big slowdown. So the pre-integrated solutions, the open APIs, those are the kinds of things that really are going to accelerate people. 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 or 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 a benefit. But if you don't rein it in a little bit, how do you balance that? What's your advice to folks who this is a common problem? I mean, it could get away from you at some one hand, but if you slow it down too much, it's a gridlock and you miss fire. What's your thoughts on this? Yeah, that balance of scale and speed. And it definitely is a balance there. I think there's always a danger of over-architecting for your current state of reality. And one of the things that I've learned over the years is you've 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, 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 got to build for where you're at, build for where you're going soon. You're not going to know 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. You know, some of the recent trends around things like project to product, tie in 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 that agile approach of, there's a product team, they're 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. And 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, series of these teams, 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, you know, two pizza team, because that's an Amazonian thing, but it kind of applies here, right? So you got to have these teams kind of focused end-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, while 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 MBAs and that always, you know, go into business school, in fact, some of the best engineers shouldn't go to business school, in my opinion, but you know, they have to learn the vernacular of CapEx, OpEx, understand quality, you know, get, bring craft into the software. More and more developers are on the front lines closer and closer to the customer as they go direct. This is a huge change from just five, 10 years ago. What's your thoughts on this? And what do you tell people when they say, hey, Donny, how should I posture to the customer? What can I do to get better? What do you say to that? Yeah, it's a great question. 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 Docker is we bring our developers along on customer interviews. And so our product managers are constantly out there, you know, kind of beating the virtual street, talking to developers, talking to customers. 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 they're building for. It may not even be about that specific thing that they're building on that one day, 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? You know, do they have an MBA? No, but where do you start? You got to 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. We'll just like give them a set of requirements and they'll deliver stuff. But bringing 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 feedback. It's clearly the trend. I mean, one of 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 end-to-end approach to a whole other level. Donnie, great to have you on. Great to see you. Final question, 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. I think both 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. Awesome. DockerCon 2021 virtual, Donnie Burkholz. VP of products and Docker. Good friend of theCUBE and the industry as well. Donnie, thanks for that great insight and sharing some gems you dropped there. Thanks. All right, thank you. All right, DockerCon coverage. I'm John Furrier, host of theCUBE, theCUBE track here at Docker 2021 virtual. Thanks for watching.