Laura Frank of CloudBees on When the Stars, Coffee, DockerCon and Code Align!

Andre Pino: In today’s episode, I’m joined by Laura Frank – director of engineering at CloudBees. Welcome, Laura.

Laura Frank: Hey, Andre. Great to be here.

Andre: So Laura, tell us a little bit about your role at CloudBees, and then formerly at Codeship, where Codeship was recently acquired by CloudBees. Also a little bit about your background in IT so people can get a better understanding of who you are, and what your background is.

Laura: Sure, let’s talk about Codeship first. That’s recent memory and then also our transition to becoming part of the CloudBees family. So I started at Codeship in 2015 in the fall. So I’ve been there for – almost three years now. I started out as a senior software engineer so previous to joining Codeship, now CloudBees, I had worked as a senior software engineer at a couple of different companies focusing mostly on developer tools.

So when I learned about Codeship – at DockerCon, oddly enough, it was a pretty natural fit. I was normally writing Ruby. Had gotten into Golang, once it became a bit more popular, and been really involved in the Docker project. So that was sort of exactly the role that Codeship had open. And it just happened that the company was very interesting to me. It has European founders who are German-speaking and I speak German. So it just kind of everything fit together in a really nice way. And -

Andre: The stars aligned for you, huh?

Laura: Yeah, they did. It was totally serendipitous as well. So Codeship sponsored DockerCon in 2015, the US one, and I had just met, I think - Jess Frazelle and I had just had coffee before her talk and I had gone with her into her conference room where she was giving her talk and just grabbed a seat in the front row, so I could cheer loud and clap very loudly and I just happened to sit next to two people from Codeship and started talking because the Wi-Fi and then got a business card and that’s sort of how the relationship started. So very, very serendipitous. Very accidental. So very fortunate that that happened. I can imagine that if I had chosen a different coffee drink that might have taken five seconds longer I might not have gotten that exact seat. So I’m really thankful for how everything worked out.

What brought me to DockerCon that year in 2015 was that I was working at CenturyLink Labs on a research and development team with I think about 11 other engineers. I think as time goes by my memory fades a bit but we were working on some open source tools for Docker developers or the developers who are using Docker. Because at that point in 2015, Docker was really just a container on time. Had some other things around it. Like Docker Compose, previously Fig, and Kitematic, for example, which was a UI. But you know, a year before when we had gotten started there really weren’t many tools in the Docker space. We had the great fortune to work on open source tools for the Docker community. So that was a really great experience. I have been involved in Docker for since about late 2013. So really right there at the beginning. I’ve been there the whole time. I’m still here. And I really enjoy it.

Andre: In fact, you’re a Docker Captain, correct?

Laura: Yeah, I am a Docker Captain. And the Captain’s program is similar to the Microsoft MVP or other kind of champion programs that are pretty popular at larger – maybe larger enterprise corporations. I think it’s not so popular for open source projects, although I guess Docker is now joining the ranks of being a bit larger corporation. The Captain’s program started, and still is, very much focused on community leadership. So before the Captain’s program was founded, there were sort of smaller bands of community leaders. There was a group for people who like to blog a lot. And a group of people who spoke a lot. And a group of people who organized the community meetups. And it was in 2015 at the EU DockerCon that the Captain’s program officially launched, where we sort of consolidated all of those community leaders and gave them a designation and a pretty cool hat and a nice sweatshirt. So I’ve been happily rocking my Captain title since then. It’s a really cool program to not only get exposure to the community and to have a greater reach when I do something or write something, or you know, I can help more people because my reach is a bit greater – but also to have the peer relationships with the other Captains. They’re very exceptionally smart. Very humble. Very focused on helping others. And it’s a great group to be a part of.

Andre: That’s awesome and prior to that, how involved were you in other open source projects?

Laura: Yeah, admittedly Docker was sort of my first period of my life where I spent more than half of my professional time working on open source. I had previously – previous to joining CenturyLink - had worked at HP Cloud back when there was an HP Cloud public cloud offering. Now it’s been renamed to, I think, HP Helion and I actually haven’t looked at what HP is up to. Now there is HP Enterprise and a bunch of other changes. But we were working on OpenStack. So of course that’s open source and it was definitely a different experience working on open source for a company like HP. There’s definitely some red tape and some – excuse me, hoops to jump through when contributing to open source. It was a bit of a different experience. But that’s how I got – I kind of got initiated into the world of enterprise open source contribution. Then when I ended up joining CenturyLink and was working on the research and development team in the labs division it was a much different ball game. No red tape and just a much more free flow of information and – I think we were able to have a bit bigger reach because there was not so much friction.

Andre: Yeah, I think you’re right. And I think that’s the experience probably a lot of folks have with open source, especially in larger organizations. So your primary role today at CloudBees is what?

Laura: My primary role is director of engineering. So that means a lot of things. What I normally do, on a daily basis, changes greatly depending on the week, the month, the time of year, whether it’s conference season or not. So I’m responsible for the Codeship product. Not, of course, single-handedly responsible, but one of the people who is responsible for it. And specifically the engineering team that works on the build infrastructure. So, building a CI/CD product is really fun, but also really complex - there’s a lot of moving parts and if you think about implementing some feature into a CI/CD – SaaS product, let’s say you’re enabling a new feature for builds that of course needs to touch the UI, so we have a great team of engineers who work in JavaScript and do a lot of design. We have Rails is there as well, so we have a great Rails team. And then all the way kind of on the bottom of the stack, we have this huge Elastic build structure that handles all of the builds that are being run on Codeship. So that’s where I spend most of my time. I have the pleasure of working with very smart, very wonderful engineers on the infrastructure team. So it’s always something new. Aside from the engineering responsibilities, I’m also frequently putting on my speaker hat and my community leader hat. Speaking at conferences, preparing for conferences, so for example, was just at KubeCon in Copenhagen. I have DockerCon coming up. Was also just at GOTO Chicago. I’m giving a workshop mostly focusing on Docker and containerization. And I have a couple of events coming up in the second half of this year that are a little bit secret so I won’t say anything. But I’m looking forward to announcing them.

Andre: So your primary role at Codeship, and now CloudBees, is in making tools for other developers. So I guess my question is, how much of your own direct experience and that of your team’s building software gets fed into the features and functions of the platform?

Laura: That’s a really interesting question and I would say a lot. I think it’s as our product grows and as our user base grows, I think it becomes – we become a little bit less self-serving. I think people who work in DevOps, specifically building DevOps tools I should say, have the great fortune of being able to scratch your own itch a lot of the time. One thing that’s been very important to Codeship over the years, since day one really, is that we dog food the stuff that we build. So we deploy Codeship with Codeship. And when I tell people that I think half of the people have a pretty like, oh yeah, okay, that’s cool. I expected that. And the other half are like oh my god, are you crazy? Because it seems so risky you know, what if we do something wrong. What if we break Codeship. And then we can’t deploy the change. Or not fix Codeship because Codeship is broken. We definitely have that emergency lever in place just in case that happens. It I think it’s only happened one time to my knowledge in the last five years. But certainly since we use our own tool, if there is something that makes our team work more slowly or something that’s standing in our way, we have the power to fix it pretty easily. So if there is a feature that we’re missing, or we need to upgrade to a different version of some dependency, we can do that pretty easily. What’s been an interesting challenge is that we had to sort of mature as an organization and I know CloudBees also went through this maybe a little bit different experience because Jenkins is at the heart and that has a lot of momentum and community behind it, but we had to go through the kind of evolution of focusing on ourselves and our problems to really thinking about, oh, we have customers who do nothing like what we do at Codeship. We have customers who are using languages that we don’t use. They’re deploying to cloud providers that we don’t use. And we really have to think about, okay, how can we have the most impact with what we’re building? Am I building something because I want to do it, for the sake of engineering? Or are we building something because we think it’s actually gonna help more than just our own team and really be a benefit to our product as a whole.

Andre: Right – and so that’s when reaching out to those customers and learning more about their requirements comes into play?

Laura: Yeah, that’s definitely a big part of how we make decisions about what to build so there is always the – that – those two questions, am I building the right thing? Am I building the thing right? And that question, am I building the right thing, we get a lot of feedback from customers either on Twitter, at conferences, direct conversations with our product team about specifically what they’re using Codeship for. And it’s always interesting to hear the wildly different use cases. And then from those, that feedback we can start to see some patterns emerge, or what I think is the most interesting part and what I enjoy most about the more strategic parts of my job is listening to many customers complain about the same things and suggest the same solution, or rather, I guess that they say oh, I want this – I want this feature. My life would be so much better with this feature. And then having to work backwards and say okay, why are they asking for that feature, what is the actual problem that they’re having? And can’t we solve that problem by doing this instead? And that would be much easier. And then giving them that solution and it just seems like, you know, it’s like the angels are singing and there’s rainbows and butterflies all over the place, they just get so happy to feel that they’ve been listened to and that their problem was solved and then to see that friction go away is very rewarding. And I think that’s what I most enjoy about working on developer tools. Because it’s much easier to measure the impact that you’re having because you can see it, with someone you’re sort of speaking the same language with.

Andre: Yeah, and I also think that in an open source world, by nature of open source there is a lot of transparency in terms of what the requirements are and what the road map is. How does that work in the Codeship environment? How transparent are you about requirements and road map?

Laura: Yeah, that’s a good question. We try to be as transparent as possible, especially internally with what we’re working on, what our strategy is, just to make sure the whole company is aligned. When it comes to conversations that we have with customers outside of Codeship, we try to give as much information as far ahead in advance as we possibly can. I think it’s really rewarding to be able to say, yeah, that feature you requested, it’s on our roadmap for Q2 of next year. We also have to have those difficult conversations where a customer says, hey this thing is a blocker. And we have to say, like sorry – we’re not gonna build this thing and say no to something and be okay with that customer maybe finding a different tool that works better for their use case. I find it’s better to say no, we’re not gonna do it. At least the customer has an answer, versus saying oh yeah, we’ll think about it. I think it’s nice to be direct and transparent and that’s been a part of Codeship’s culture since day one. It’s one of our - transparency is one of our core values and we really do like to practice it in all ways of the word, not just internally but also with customers.

Andre: And I would expect that customers would appreciate that openness as well?

Laura: Yeah, I think they definitely do. No one likes to be strung along. Maybe it’s unfortunate to hear that the feature that you’ve requested is not gonna happen, but I’d rather know that versus just be left wondering. The other thing that I really enjoy is we have usually very involved beta periods before we release a feature to GA. So often what happens is that we’ll have a handful of customers request the same feature or share the same pain that they’re having and we build the solution. And then we’re able to directly contact them and say, hey, guess what? This is coming two weeks from now. Do you want to be part of the beta? And usually they’re really excited and then very engaged and give us a lot of great feedback. So we have awesome customers. I guess a CI/CD tool is something that you use every single day. So if you have an opportunity to give feedback and say, hey, it would be better if this happened, people are really invested in it, because it’s something that really changes the way that their day goes. It changes how they work.

Andre: So let’s go back and talk about Docker for a bit. So you know, we’ve seen containers and microservices become an increasingly important part of continuous delivery platforms. What’s your perspective on this? Where do you see it going?

Laura: I think containerization is the default virtualization strategy going forward. I think it’s taking a while for it to be adopted. But if you think about when virtual machines were the new big thing, it took a while for them to be adopted, but now you don’t even think about it. It’s a commodity. And I think containers are heading definitely in that same direction. And we’re already starting to see some signs of it. Like the first sign is when tools pop up to manage something that you used to manage by hand. So for example, Kubernetes and orchestration tools are here now to manage containers. So now you don’t actually touch the container, you touch one layer above it. And I think slowly the tools start building on top of one another and then you know, containerization is not even something that you think about. It’s just a given that it’s there. And I think that’s going to be the reality. Maybe not this year. Maybe not even next year. But in three to five years, I think a majority of projects will be using container technology in some way or another.

Andre: So for the average software developer who is building the next great app or feature for the company they work for. What do they really need to understand about containers, Docker and Kubernetes?

Laura: I think I really like learning things the hard way. And I think that what I see – I see a lot of developers get tripped up on the details. Which I guess is – if that’s a bad thing, I sort of – I question my attitude about learning things the hard way, because I think when you do get down into those details and get really tripped up on what ports you’re exposing, I think you learn the whole system. I think for someone who is starting out, it’s not necessary that you can build everything from scratch all by yourself. There are so many tools there to help you get started. There’s lots of templates. And I think that’s the most interesting, compelling thing about, for example, a tool like Docker Compose and how it’s changed the way that developers can build their applications and then how new people can become on-boarded to that project is that all you need now is a Git repository or whatever source control repository and a Docker Compose file. And then using that you can just with a couple basic commands have a containerized environment spun up on your local machine and you can be productive really quickly without having to learn the ins and outs and the specific plumbing stuff of the container world. I think that’s a great place to start. And then once that becomes natural and you’re hungry for a bit more, then I think it’s good to start digging low, digging a bit deeper and really understanding containers and how they work and how to write Docker files and how to use them more efficiently. But then also going up one level to the Kubernetes, or the container orchestration level, and think about okay, how can I run this in production? So starting at that entry point of hmm, I’m gonna use Docker for development. I’m gonna use a tool like Docker Compose to help me be more productive and isolate dependencies. And then when that feels comfortable going a little bit deeper, a little bit higher up I think is a great strategy to get acquainted and sort of fully immersed in the container world.

Andre: So Kubernetes is a very interesting topic. It seems to be the hot technology right now. You know, where is the maturity of Kubernetes today, from your perspective, and how do you see the adoption within enterprises?

Laura: That’s an interesting question. I think Kubernetes is definitely the hot new tool. It’s the new product that’s, in sort of, that innovation space. And I think especially engineers and developers tend to be sucked towards whatever is like the new thing in the innovation space. And I think that’s great. I think that helps us push our field forward and push our tooling forward and helps us achieve new things. I think what my opinion on Kubernetes and orchestrations or Docker – Docker also has orchestration tool and containers in general, it was best said at DockerCon in 2017 and I can’t remember who said it, but the quote was “It’s a really exciting time for boring technology.” And I think for a long time Docker, containerization, Kubernetes was thought of as this, like really disruptive thing and it’s gonna change everything. And because it’s being used – so, widespread usage and is adoption is growing very rapidly, sort of turned it into being like, actually we don’t want disruption. If you’re a hospital or a bank or an automotive company, you don’t want disruption. You want stability and boringness. And I think Kubernetes and other orchestration tools that have this sort of highly available, self-healing declarative manner of operating are just that. You’re actually adding more boring stuff or adding more predictability and more stability to your system by using these tools. So I think they are definitely mature and becoming quickly enterprise-ready. I think enterprise-ready encapsulates a lot of different things, not just Kubernetes. But like also there is a multitude of other things on the periphery just like container tools that makes something enterprise-ready. I think we’ve seen pretty strong signals from Azure and Microsoft and AWS and of course, Google and now Docker, with Docker Enterprise Edition 2.0, having Kubernetes baked into it, as well that the enterprise is ready for Kubernetes. They’re asking for it. the tools are there. So it’s just a matter of you know, having that digital transformation from within or having the champion within the enterprise or teams within the enterprise to adopt these tools.

Andre: Yes, I mean, if you just look at the vendors who are supporting the Cloud Native Computing Foundation, it’s very clear that the Kubernetes technologies are going to be incorporated into their products and tool sets. So I think you’re right. I think it very much supports your thesis that these are boring technologies. Because once it gets incorporated into higher-level tools then it just becomes a foundational technology that’s just being incorporated into what developers use.

Laura: Yeah, I think one interesting perspective is that there was a time in the world where electricity was a really disruptive technology and that you were very aware, and really had to manage if you had electricity in your house or not. And now, it’s just something that’s yeah, I pay for a VM on AWS. I don’t think about the fact that oh, there is electricity in there. It’s not even something that I give a millisecond of thought to. And I think eventually, I mean, maybe not that big of a difference, but I think containerization and a lot of these technologies that are becoming commodities will also have that invisibility to the end user.

Andre: Yeah, I totally agree. The industrialization of containers is probably the era we’re coming into right now. Andre: So Laura, as we conclude is there anything else that you’d like to tell our audience about what you see happening and coming down the line in the future?

Laura: Yeah, there’s one point that you brought up that I wanted to touch on which was companies supporting the cloud native computing foundations, so CNCF. I think there is a tendency to equate Kubernetes is cloud native, and that’s very true but it can also be true that teams are doing something that’s cloud native that might not be using Kubernetes. And that Kubernetes is just part of the story. And I often get a lot of questions about you know, people who are maybe a bit new to the container infrastructure or are sort of, like, maybe a bit overwhelmed by how fast it’s moving. And don’t understand that these container tools are really additive and they’re not exclusive. So, one example is often I get asked about like, okay, well do you choose Kubernetes or Docker? And my answer to that is both, I need both. Docker has a lot of really great tools for the developer, for example, Docker Compose. Docker has an orchestration system. And they have productivity tools like Docker for Mac, Docker for Windows that have both their orchestration solution and Kubernetes. So it’s not really a question of “either/or”. And as competitors, as much as I see them as two parts of a system that’s continuing to evolve and I bet in six months or nine months there’s gonna be some third thing where people will ask, oh, well is it Kubernetes or Docker or this thing. We kind of need it all to exist. We need virtual machines and containers together. We need Docker and Kubernetes together. And I think when these tools, when you pick the thing that makes the most sense for your project, that’s when you can see the most benefit and start moving toward that goal of cloud native.

Andre: I think that makes a lot of sense. Laura, thanks so much for your time today. It was a really interesting conversation.

Laura: Cool, thanks so much, Andre.