 Okay, welcome back to theCUBE coverage of DockerCon 2021. I'm John Furrier, host. We've got a great guest here, Dana Lawson, Vice President of Engineering and Technology, partnerships at GitHub. Dana, welcome to theCUBE. You're leading the engineering team over at GitHub, been around the block on the cloud enterprise area. Congratulations. Welcome to theCUBE. Well, thanks for having me, John. I am super excited, DockerCon 2021. Wow! I can't believe it's been that long, right? Got the keynote coverage. Automation is also the top trend here in the world. DevOps, DevSecOps, developer productivity, modern errors here. A lot of action and DockerCon, just more attendance every year. Containers setting up the cloud native, you know, the tsunami of new ways that people are programming, new way teams are formed, new way people are being super productive with the pandemic we've seen. Developers really lead the charge in the virtual work environment. So a lot of action. So first, tell us what's going on in the developer community right now. Give us your take. I mean, my take on it is the developer teams are just working closer than ever before. You know, we see this across all industries, whether you're going through your own digital transformation and trying to streamline your workflow. You know, we've had this concept of DevOps now for about a decade. And we all were hopeful. I was one of those early adopters that was like, yes, this will change the world as you can imagine. And like we're seeing it materialize. And I feel like in this historic year, it's on steroids. We see teams working across the aisle, doing things we've never experienced before with this concept of interconnected tools. And so we're seeing really the, I would say the practice of DevOps really going across every member of the team and not being just a practice that maybe one person on their team did. And you know, this trend has been ongoing for a while but with these new key technologies out there, it's really on fire in my opinion. Yeah. I mean, outside of just the whole cloud native awesomeness that's happening. You see Kubernetes enabling a lot in new things. The virtual work environment with the pandemic, developers just, they're like, this is the way we've been working a long time. Finally, it just got standardized for the rest of the world. They didn't really miss a beat. And combined again with the cloud scale and we saw the earnings from all the big companies, the developers have been super productive this year. Do you see that continuing and how was that going to change in your opinion as the pandemic kind of lifts a little bit and now the new normal gets back to real life? Certainly this benefits came out as what's your take on this engineering dynamic going on? I mean, you said it there, like this is a common kind of workflow that people had pre-pandemic, especially in the open source community where it's literally a bunch of random people around the world that don't obviously get to talk as quickly and as, you know, synchronously. And so async communications gone up and what we've seen there is teams really tuning in their automation, right? So whereas you may have had it in your backlog to say, you know what, I should probably go automate that workflow. Now that we have been forced even companies that haven't just haven't thought about in the past to say, okay, how do I get code from A to B seamlessly? They're spending time on those workflows. And I think that we're seeing that naturally, you know, in the keynote where I mentioned some of the research that we've done is we're seeing developers work more, but we're seeing them work more on open source projects and the things that they want to work on, not necessarily going and saying, I'm going to go and spend, you know, 20 hours at work. But really it's that continuation of like, hey, instead of automation being an afterthought, we're going to make it something that is at the forethought of what we're doing. And so what it's really done is just increased the time spent on writing great code and hopefully having a better uptime. I am a DevOps, SRE, SysAdmin, whatever you want to call it at heart forever will be. And so, you know, getting to have more time to spend on SLOs and really the, you know, like I call it the safety guards, the rails of your system so that you can just really go in there and allow everybody to contribute. And that's what I think we're seeing. And we're going to continue to see that as things just get easier, as stuff happens out of the virtual box. I mean, simpler, easier is always a good strategy. I was just reporting for our team on the KubeCon and CloudNativeCon, there's more CloudNativeCon going on than KubeCon because Kubernetes got kind of boring and enabled more CloudNative development. And then the other trend that we've been reporting on is end user contribution to open source. You're starting to see end users, not just the usual stuff, such like Lyft and whatnot. You're seeing like real enterprises like having teams contributing into open source in a big way. This is kind of a new interesting dynamic. What's your take on that? Is that a signal of simplicity? What does it mean? I'm going to tell you, I think that companies and big names didn't realize they were using open source and they have been all along. It's been around for a minute. Some of our most favorite, you know, libraries and frameworks have been open source from the beginning. You hear me talking about, you know, Java and Toncat. That's open source. And so it's really this understanding of the workflow. So I want to say that what we see now is there should be an investment because the world's team of open source developers are powering our technology. And why shouldn't we as companies embrace and actually give back and spend that quality time? Because us innovating together on open source, you know, privately and publicly just makes everything better for everybody. And so I think we're going to continue to see this trim. I'm excited about it. You know, GitHub has done some amazing work in this space by with GitHub sponsors because we want open source to continue to enable, you know, the innovation and having people participate. And now we're seeing it with businesses alike. And so I think we're going to see this practice continue on and really take a look not only of the technology they're using, but the open source practices, like how do these maintainers and these open source teams shift reliable quality code that is changing the world and how can we put those practices within our own development teams on what we're building for our customers. So you're just going to continue to see this. And I think also with that being said because the barrier of entry has lowered some by the advancements, right? We're seeing the rise of the citizen developer as well. So we're seeing, you know, people all within the company and some that are much more, you know, farther along with their transformations participate in a way they never have before whether it's like, you know, the design part and the design thinking of it to like, how do you curate and have a great experience for your customers? We're just seeing participation at all levels of development stack. And that also is the stuff outside of the actual code being written because it's so interconnected. And so I don't know, I'm excited. I'm excited to see what we're going to unlock by having people participate more so than ever and then having companies invest in that participation. I love your enthusiasm. I agree. I think it's a great time for open source because it has democratized. It is bringing in new people. The aperture of the persona is coming in is not just computer science and it's engineering. There's hybrid SRE roles developing. And then you got creative. There's a creativity aspect coming back. And I've been riffing on this for a few years. It's what I'm kind of seeing this development. Love to get your thoughts. Used to be like craftsmanship was involved in building software. And then agile came in, ship fast and iterate. And now craft is coming back. We're starting to see creativity in the developer experience through collaboration tools and kind of this democratization. What's your thoughts on this? I know you think about this as an engineering leader. Craft, agile, bringing them both together, speed and quality. Is craft coming back? Craft is definitely coming back. And I think it is because we've nailed them mundane stuff, right? Like, you know, we're all hyper focused on like, you want to be the best out there. You got to shift immediately, agile, agile, agile. But what we know is like, you can ship a bunch of stuff nobody wants very fast. You can ship a bunch of stuff that hasn't been curated to really, you know, solve the problem. Now you'll be fast, but will it be awesome? I think people demand more. And I really believe that because we've embraced some of these frameworks or closing tool sets that we get a focus on the craft. And that's what we're trying to do, right? Ultimately, we want every person that builds to be an innovator and not just an innovator for innovation sake, but because they're changing and affecting somebody's life, right? And so when we dig deep and focus in on the craft and we still have these expertise, we're just going to be applying that in a very intentional way versus, okay, hurry up, bill, bill, bill, hurry up, bill, bill, bill, bill, bill, bill, go. Because now it's connected. And so we're seeing the rise of that craft. And what I think is going to in turn happen is we're all going to have a better experience. We're all going to reap the benefits of having that expertise. There's this fear sometimes when we talk about automation and DevOps and interconnected tool systems that maybe you're taking somebody's job that they were doing before, the daily task. No way, all we're doing is saying like, cool, take the repeatable thing that you're doing over and over and over and let's focus on that craft. Let's, if you're a security person and you want to get down and deep and understand where vulnerabilities are going to come from and things that people haven't even thought of, cool. Let's take away some of the other things that we know can be caught and solved without you paying attention in some aspects. I think we just need to along the whole stack. So it's pretty exciting times. Yeah, I agree. And we call that undifferentiated heavy lifting. Just get it out of the way. Since you brought that up, let's take automation down that road of experience. What does it mean for the developer? Because this is really an opportunity, right? So the phrase I've heard is, if you do it more than a few times, just automate it away. So when's the right time to automate? Where does automation play into the developer experience? When does it make it more productive? Where's the innovation angle? Could you share your thoughts on when people look through the prism of automation, productivity versus innovation? What's the automation view there? I mean, it is a good little metric. It could be done at five times and it's the same thing over and over and over. Your question is now like, do you have to be doing that? I mean, you should, because you're doing it. So I think it's about finding and defining your own boundary for what you need, right? I mean, it's hard to get out there and say every workflow, like we can go and apply the stamp. We already tried that with agile frameworks. We're like, everybody, you're gonna do Scrum or you're gonna do a combat. You know what? It doesn't work. What we really need to do is have teams understand their workflows, right? Understand and do some diagnosis and saying like, we're in the system. And I think that's powerful metrics and insights of going like, where are we having a slowdown? Where are people spending their time? If people are spending their time doing break fix or they're spending their time continuously trying to jam something into a certain pipeline, you have to ask yourself, is this something that we should be spending that time on? What if we had that time freed up? And so I do think you can go and put some good boundaries in there, whatever yours may be. I'd love some of those rulesets, but really, you know, DevOps and automation starts with the process, right? We think about it. And when I develop software, I always think about it through that design thinking lens of how will this work when I get to it? And so if we're focusing on the design aspect and the user experience, then we start looking at the pieces in between from that code to having people use it and say, what do I need to do? And sometimes, you know, depending on your industry, you may have these other needs that not everybody has. So it's hard to say there's a one size fits all, but there is a good rule. Like, have you've done the same repeatable thing over every, every day, numerous days? Like you probably should just go spend the time to automate that. And I think it's the convincing point, right? Like if we go and a lot of us are our nerds and engineers at heart and I love freaking math. So it's that like, okay, if we spend two hours, you know, building maybe a GitHub action for a Docker, one time, instead of somebody having to repeat this process no matter what it is, like you're giving that time back. And that time is mental capacity, mental capacity that can be applied to something that's more important. And hopefully the more important thing is the user experience. So yeah, I mean, you know, we all have those little systems out there. I say use them, but take a step back. I think the bigger part, the harder part is like, you know, yes, you will have to slow down for a minute, which is scary to go and build something repeatable so that you can speed back up. You know? Yeah, that's awesome. Great, great insight. I love the energy. A lot of ask you while you're here because this is something that I've been thinking about. I've been hearing a lot of developers talking about understand the workflow. You mentioned that's a key thing. I love that. Getting in and understanding the customer experience, working backwards. But that brings up the whole, how do you form the teams? How do you think about team formation? Because at cloud scale with cloud native, you can use building blocks. You have automation. You can easily compose and then build intellectual property around things, use containers, make things easier. So as you start thinking about teams, is it better to have teams focus on, say workflows and then decouple teams? Is there a strategy for general purpose teams? Or how do you look at the team formation from the developer perspective to make the experience great, the high quality? Is there a state of the art in your opinion, given the composability and all the ease of use going on? I mean, what's the ideal way to think this through? What's your thoughts? Oh, like, you know, there's, I'm gonna say there's not one team to rule them all. There's not one team kind of foundation that's gonna be able to be applicable. It's all different, right? Like even within the same company, especially at scale, you may have these different compositions of your team. And I think it comes down to like, what problems are you trying to solve within your workflow? What are you trying to accomplish? I think when we step back and we think about, you know, our CICD pipelines and really code from idea into cloud, I believe in a unified system because I don't want developers worrying about it and doing one offs. I'm like, you don't need to know that. And that's like been an argument that's going on. You know, I'm a huge Kubernetes fan. And so it's been like, should the feature developers understand the innards of Kubernetes? I'm gonna say something controversial. I'm gonna say no. I'm gonna say they don't need to know. They need to know how to monitor, alert and how to have smart rollbacks and have a system that does it for them. That's why we have orchestration. That's why we have Docker containers. That's why we have, you know, world-class APM and monitoring systems in place because we've done that. We've done that hard work. So I would say no, they don't need to know that. So, but you still need these needs, right? And depending upon where you are in this transformation, right? Maybe you're still like, you know integrating some of these cloud-native principles and tool sets. And so you need some SMEs. I do really love the SRE embedded model not embedded like on your, you know like embedded like a chip set but embedded in the team because that person really should be a mentor and should be a force multiplier. You know, you don't want to fall on the trap and be like, oh, we have an SRE on the team. They're going to do all the DevOps stuff. No, no, no, no. They're going to go and help you think about your product through a customer lens, right? They're the experts going like, whoa, maybe we should have an SLA because this is a tier one feature. Let's go and make sure we build that automation so that we curate this feature with the highest level of availability but then teach the team how to do that. So now you have this practice as a part, right? Like you're honing your craft, you have this practice. Now, does that mean they need to go learn everything about like the monitoring suite and tools you use? No, but they should understand how to read the output of that. And so there's not one team size to rule them all unfortunately. I personally, I'll tell you what I'm a fan of is like, I think that you should have flexibility. Like once again, think about the points where you need to have the connective unified system, right? And then you have this opportunity for developers to have some agency and creative freedom because maybe you've been on a team that's been working on, I don't know, let's say your audit service. I think every software has some component of audit in some ability because you want to know what to use using what. Well, after they've done their tour of duty because most of the cool stuff they've already fixed and made a feature set let them go roll into something else because then you have that connective tissue on the inner points of your system that are always the same, right? We want really repeatability. We want them just to focus on writing the code. And I think because of these advancements we are unlocking opportunity for developers to think broader, right? Like maybe you've been on the platform team and you want to go dip your toes into writing features. Well, 90, okay, maybe not 90, but I'll say 80% of that everyday repeatable task like focus on that, get that shipped out but then you have the SME and you're really thinking holistically as a customer obsessed team of what you're building and why. So no one, no one way. Yeah, I love the idea of the platform person just having more flex out and because that brings a platform mindset to the other pieces but also feature acceleration versus product strategy thinking through the arc of why you're building in the first place, right? So, and then the embedded SRE great point there, a great call out there because everything's cloud scale now you got to have pen tests, built-in automation. Who's going to design that? So I think it's really interesting how you're putting that together and I think that's very relevant. Any new things that you see happening now with cloud native, you mentioned Kubernetes. I think the story that we've been telling is Kubernetes got boring and that's good, right? So meaning it's working and people like it, it's interoperability, orchestration, it feels like a unifying connective tissue between under the hood and above at the application layer. So it's nice. But the consequence to that is there's more cloud native going on. So that means more services are going to be connected and torn down. You mentioned observability and monitoring. That's important too. So as an engineering leader, that's not another department, right? That's going to be core to the developer and what's your thoughts on how to integrate observability. Now there's a zillion companies doing it now but is that going to, and we, what's your thoughts? I mean, there is a zillion. My thoughts are like, heck yeah, like observability isn't at the end of the stack, right? Observability is a part, just like quality is a part. Just like when we think about agile, it's, let me just throw it this way, right? Like when Docker came, right? We had, it basically have this maybe, this baby OS encompassed on servers so you could have multiple, multiple, multiple, multiple distributed, right? I think of like, let's say that like your team is that Docker container, man, you want everything in there, right? It is a part of the practice. You want your learning, you want your logging, you want it all wrapped up in this nice little bow and you want lots of them all working together harmoniously. The same thing can be said about our teams. We want them to be their own little micro operating system where they have all the resources available for them to go and do the thing that they are intending to do and not have to worry about that subset but it also gives them that control, right? And so it's building in that layer of abstraction that's needed but also understanding why it's important. So it's a little bit of both, right? We're not going to curate deep subject matter experts, you know, on, you know, the OSI model and every aspect, right? Like we're not going to turn a front end engineer necessarily into a network engineer but utilizing the tool sets, having a playbook where it is controlled, maintained in a part of your culture, all it's going to do is allow you to move faster and it's allowing you to see what's really running out there in the wild and I see these trends happening. I think we're continuing to see, you know the rise of cloud native technologies because applications now are really a set of APIs that go across the world and in and out. And so the way that we develop is slightly different. And so we need to think about well, how is it orchestrated and deployed? Well, if you have a repeatable pattern once again if we go back to that and think of our team and I promise nobody asked me to come up with this as like a little Docker, a little Docker container itself you know, you're going to write that image into what makes sense for you and have all the resources available and you're going to rinse and repeat that over and over and over again. And so, I mean, we're just seeing this continuation of, you know, monitoring DevOps, SRE it's not a problem, it's a culture, right? It's not one person's job or a role. It's a part of how you build great software. It's just a practice. Yeah, I mean, you mentioned a abstraction layer that used to be conventional wisdom that they were good, but there was trade-offs was performance trade-offs or some overhead that says not anymore. It's good that you can basically build an abstraction layer and say, hey, I don't want to deal with networking anymore it's going to make it programmable. That's cool. That's right. No problem. So you start to see these new innovation patterns, right? So what are you most excited about when you start to see these new kinds of things of being, you know, brought on that were limited years ago, like you start in the abstraction layers you see the role of the SRE you're seeing the democratization of new developers coming in that are bringing new perspectives. She's seeing all these new kinds of ways that's refactoring how people write code. But what are you seeing as the most exciting? For me, honestly, it's like the opportunity for anybody to really be a builder, maker and developer. Right? You don't have to have a traditional CS degree. If you do, that's awesome. Like come and teach us all some stuff. We probably should know that's foundational. I don't have a CS degree. You know, we're moving on from these opportunities where it's self taught to where you actually a hundred percent can go and learn and build and create. We're seeing the rise in these communities. I feel like these tool sets are really just lowering the barrier of entry for those people that don't have advantage to go to like a four year school and get a degree for people that are just like have a great idea. What excites me is that next developer, we talk about the hundred million developers sitting somewhere in the world, just going, I have a great idea and I'm gonna change the world. And I don't know how to get started, but they do. They have it at their hands now. If you can go on to a website, get a little bit dangerous with these tool sets, you can go and get your idea into the masses. And what we're gonna end up doing is like you said, democratizing tech, it's gonna bring in new ways to think. It's gonna change how we interact with systems. We get our blinders on sometimes, especially I live in Portland on the West Coast of the US. We know that the world is a vast, majorly huge, dynamic, awesome place. The things that work for me may not work for somebody on the other side of the world. The things that I do may not be relevant, but we're gonna find that human connection. We're gonna continue to say, well, wait a minute, how can we optimize for any human anywhere? How can we help take all these differences but doing them in a repeatable pattern? And so like for me, that's exciting is these tool sets that we've been working on for years are now gonna be put in people's hands that never thought they could. And that is exciting. And like to see the rise of just creativity is what really makes humans special because we build and make. And the fact that it's more inclusive now becoming more inclusive on all aspects of inclusive, whether it's individuals and coders and types of code. So integration is the new normal, right? Integrating in data, control planes, all that goodness coming in because of the ease of use of developer experience. Super awesome. Dana, you're awesome. Great to have you on theCUBE and sharing your energy and insight, great call-outs on many topics. A lot of gems being dropped there. Thanks for coming on theCUBE. Well, thanks for having me. It's been awesome and DockerCon's been great. I can't wait to see the rest of the show. DockerCon 2021 virtual real life coming back maybe in physical next year or hybrid for sure. This is theCUBE's coverage of DockerCon 2021. I'm John Furrier, your host. Thanks for watching.