Finding Your Tribe - Tracy Ragan - DeployHub

In this episode of ShipTalk, we are joined by Tracy Ragan who is the CEO of DeployHub. Tracy is no stranger to open source communities spending time with the Eclipse Foundation and Continuous Delivery Foundation [part of the Linux Foundation].  A software and open source community is more than just a place to get free software, the community aspect is crucial. Especially during the COVID pandemic, the human element is key to furthering the software engineering craft.  Tracy talks about her career and community journey and why it is important to find your tribe.  At a bonus at the end, a joint perplexity around the rise of YAML.

Transcript

Ravi Lachhman  00:06
Hi everybody, welcome back to another episode of ShipTalk! I'm your host, Ravi Lachhman, and today I'm very excited to be talking to one of our buddies, Tracy Ragan. Tracy, thanks for coming on to the podcast today.

Tracy Ragan  00:17
Oh, thank you. It's my honor, it really is. 

Ravi Lachhman  00:20
So a little bit of background about Tracy, if you don't know her: Tracy is a CEO of a firm called DeployHub. Tracy, why don't you tell the listeners, if they don't know, a little bit about yourself?

Tracy Ragan  00:31
Sure, so I've been doing this thing we call DevOps literally my entire professional career. When I graduated from college, it was a mainframe experience for me. There were things like Endevor that did all of the hard work of compiling and linking code and shipping it into production. And Endevor, by the way, means Environment for Development and Operations; it’s the first DevOps tool ever on the market. When I started coding in C and C++ in the OS/2 environment and presentation manager, I quickly learned that what we now know is Continuous Delivery in the distributed platform did not exist like it did on the mainframe. It has taken me on an odyssey, from understanding make files to version control to Continuous Integration and now Continuous Delivery. So my background is pretty deep. 

In 1995, I started a company called OpenMake Software. And it specializes in generating build control files to automate— truly automate— the compile and link steps. And that has really thrown me into this area of configuration management, which is what I'm most passionate about.

Ravi Lachhman  01:48
Awesome, excellent background. [Since] you've been in industry, and we've been in industry for such a long time, a lot of things that are happening in the DevOps movement seem more revolutionary than evolutionary, but you brought up a really good point. 

Sometimes, I'm a little bit cynical about the revolution versus evolutionary argument that, as a software engineer myself, I would be like, “Oh yeah, every time we would commit, we would have a build, or have these particular steps of automation 10, 15, 20 years ago”. I think the opportunity for more people to be exposed to it is what’s happening now. What's been your experience? You literally lived through a wide swath of automation; how would you categorize that?

Tracy Ragan  02:32
So we'll just bring it to the present. You guys did a conference, and you named it Unscripted. I have been preaching Unscripted for quite some time now. Because the area that has always held back the distributed side of the house— and now we can think about it in terms of cloud native and everywhere that has gone— has been the habit that people have [of] grabbing the nearest scripting tool and solving the problem with a script. And even if we call a script from us a Continuous Delivery pipeline or a CI workflow, it's still not automated. It's still a script. 

A script is a script, no matter how you define it, you know? It's static; it's not declarative. And it has held us back for quite a long time. So that's how I've always seen it. Even from the make perspective. I hated make files. I was writing them, but I hated them. So I was like, why don't we just generate this crap? Why do we have to write a make file; can't this just be generated? And that's what we did with OpenMake software and Meister. 

Now ironically, when we get up to present day, we're hearing a lot about this… [like] SolarWinds and the huge breach at the government level. CD is smack in the middle of that conversation. And unfortunately, they're talking about it as if CD could potentially have been the problem. But what was the problem was the build— a file got put in a library and probably in a directory, and the build said when you link, just take everything in this library and suck it all in and create the binary. And that allowed it to create its own life. 

It was the script that was the problem; it wasn't the CD process. So here we go again, I'm still preaching Unscripted! So thank you for naming that Unscripted Conference. I wear my T-shirt all the time.

Ravi Lachhman  04:31
Awesome, very excellent points there. That SolarWinds hack was very complicated. I don't know if you've read the Microsoft AppSec report, but it was like probably one of the longest AppSec reports I've read. It's like 50 pages long, like exactly how the signed DLL got in there. But it’s a common practice— not trying to harp on this stuff for too long— if a file is there, it should be trusted. But there's lots to learn after the SolarWinds hack.

Tracy Ragan  05:01
Its core, though, to what we do [at] both DeployHub and Harness. It's core to this conversation for us, and so it concerns me because we can't just say it was the CD pipeline that caused the problem. We're at a point in time when we're talking about cloud native, we're talking about microservices, we're talking about digital transformation, we're talking about going faster; we have to do all of that a lot better. We have to achieve DevOps at scale. And we're not going to do it in this old fashioned way, where you have some sort of a make script, or an ant script or whatever it is that you're trying to assemble these pieces together. And thank goodness microservices don't even require that anymore. We can finally get away from that. But it just offers new challenges that we have to solve. 

Ravi Lachhman  05:51
Perfect. I didn't realize your background before you started DeployHub was actually automating those make files. It used to drive me nuts; I started out in the Java days, [and] I was like, why can't these ant or Maven files be generated by the IDE? But Tracy was fighting that problem long before.

Tracy Ragan  06:07
I was!

Ravi Lachhman  06:11
Why don't you tell us a little bit about DeployHub, maybe some of the genesis? I only know you from DeployHub, so maybe some of the genesis of how it started. And the dog— the viewers can't see your awesome dog. And that logo!

Tracy Ragan  06:23
Well, I'm a huge dog fan. I have four dogs, and they’re with me all the time. And I live in Santa Fe, New Mexico. So when I did the logo for DeployHub, I said I need to bring in my heart to this— and sunsets and dogs work together. So that's what that logo represents. It's a dog in a sunset. 

But DeployHub came about because of this amazing pivot that the industry in general is making from monolith to microservices. If we think about— and I'm seeing all of this from the perspective of builds and configuration management— it from the perspective of CI, just thinking about Continuous Integration… What is Continuous Integration? Continuous Integration is the process of checking in a file and immediately compiling it, so that you always have an available release candidate. You want a 10-minute build or less, and if the build breaks, somebody needs to fix it immediately. Because you always want a release candidate— you always want a healthy executable that you can roll out. 

The way we did that was through a compile process. And when you compile code, you do four really important steps. First of all, you create an application version. Secondly, you create a bill of material report that shows what went into it. Hopefully, you were being careful about it— and that’s what the OpenMake software team was worried about, is the SolarWinds example. It was getting something stuck in there that you shouldn't have had. And thirdly, you create a difference report that says the difference between one build and the next are these files. And this is everything that auditors use; it's what production teams use to say if they're going to accept a change. And then also, if you're really good at it, you created an impact report that said, if I change this, I might impact these other teams. 

When you look at microservices, we throw away all of that because a microservice is like a Python script. For example, you might run a scan; you might look to see if there's Python libraries you need to add to your container. But for the most part, it's pretty small. It's maybe 300 lines of code, not 3000 lines of code. So we lose everything that I just talked about. We lose the application version, we lose the difference report, we lose the BOM report. And we don't have a good blast radius for the microservices that we do release. 

DeployHub was everything about tracking that. It's a microservice management platform that tracks every single microservice and its relationship outside of clusters. So it's not waiting for you to deploy and look at a registry or API gateway to see how the transactions are being executed and monitoring. We're doing all that above the order of a cluster. I like to call it automated configuration management. And we connect into the CD pipeline at the point in time that you register a new container. That's a new release candidate, right? In the past, it was a file and it created a build. Now we say, hey, you've got a new release candidate when there's a new container registered— and that's when we go to work. 

The core of DeployHub is Ortelius. Ortelius has been added to the Continuous Delivery Foundation as an incubating project, which we're super excited about; the community is super psyched about it. Our goal is to provide a way for anyone who's deploying a microservice to do so in an independently deployable manner, and [to] address this monolithic habit that we have and help move us away from scripted environments.

Ravi Lachhman  10:18
Awesome. And for the viewers (Tracy and I have a video on, but we only hear the audio [on] the podcast), Tracy actually has a CD Continuous Delivery Foundation sweater on. [Directing attention back to Tracy] And as you mentioned, Ortelius is an incubating project in the Continuous Delivery Foundation. But how I actually met Tracy was through the Continuous Delivery Foundation. It was actually one of the first foundations I ever joined that was dedicated to pure open source. So to kind of get to the theme of this podcast, the importance of giving back— Tracy, you were there since the inception of the CDF. Can you tell us a little bit about what drew you to it and the importance of having the CDF out there?

Tracy Ragan  11:04
So I was a founding member of the Eclipse Foundation. I was the only woman sitting on that board for quite some time; I think I was there for maybe four years. And I left finally. I was like, I've got to focus on my business; this is something I can't continue doing, I've served my time. And it was early on when literally Chip McGorry had seven or eight people in a room, and he was looking for a female to be added to it. And I was the token female, bless his heart. [chuckles] I'm so glad he reached out. 

So I left and I didn't really keep track of the Continuous Delivery Foundation. I was at a DevOps World about two years back, and somebody by the name of Tracy Miranda sent me an email. She said, “I'm Tracy Number Two.” I'm thinking, that’s weird, her name is Tracy; I don't know why she called herself Tracy Number Two. And she said, “Would you like to have lunch? I'd like to talk to you about a new open source foundation.” I said, absolutely. 

In that meeting, I discovered that Tracy Miranda took my place on the Eclipse Foundation. So she was the new token woman, and I never knew that a Tracy replaced a Tracy, which I think is hilarious. It was a total even swap. So fast forward, I don't know, 10 years— probably longer than that— and she reaches out and says, “Hey, this is what we're thinking about doing. We believe that Jenkins needs to be part of a larger order. We believe that this is the time for a broader discussion around Continuous Delivery, and we're thinking about starting the CD Foundation. Would you be able to step up and help?

And of course, I said yes. How could I turn Tracy Number Two down? There's no way I would have ever said no to her. We’ve become great friends, and she's been an amazing to work with. And she's now the executive director of the CD Foundation, and I'm thrilled. So I've been having a lot of fun. These are my peeps, and there's nothing that thrills me more [than to] serve my peeps.

Ravi Lachhman  13:12
I didn't realize you were there [at] the Eclipse Foundation. The Eclipse Foundation has a special place in my heart, one of the only pieces of open source I ever contributed to. When I started my career, I worked at IBM, so I was working for Rational Software. We were contributing back to something called TPTP. It’s a funny name— test platform, tooling platform. And yeah, that made it very easy. One of the few open source contributions, legitimately. 

Tracy Ragan  13:37
I learned a lot; I learned a lot about open source governance sitting on that board for the time that I did. I learned how difficult it is to do the lift of an open source community. And at that point in time, we didn't really know open source was going to be as big as it is now. Everybody had the idea that companies like Red Hat would do really well with an open source core

Ravi Lachhman  14:01
Gotcha. So you've been around the open source community for a long time as a software engineer yourself. For some folks who might be a little bit on the edge, like, “what’s the point of open source? Is this some free software?” It's more than that. It's about building a community. 

Maybe you can touch on this— the importance of, hey, this is [the] rationale behind how we give back to the communities, how we educate people, maybe in some sort of open source realm? 

Tracy Ragan  14:31
Well, first of all, I have to say that I'm that I'm a serial volunteer. I really am. I have a problem, I guess. [chuckles] I really like volunteering. And I've volunteered for a lot of different things, including in my local community; we have a historic ballpark that I spent a good three years helping to renovate, and I put a lot of heart and time into it. But to be honest, I don't like to be out of service. I like to be in service. And when you're working in a open source community, you're creating a really amazing group of people that you are going to call your friends over time. 

And I can't explain it… it feels like a tribe. It's your tribe. It's your people that you share common interest with. You learn about their families; when they don't show up for meetings, you get worried about them. During COVID, I'm telling you right now, I feel like this open source community has saved me in many ways. Because I'm used to being out and about; I fly to San Francisco a couple times a week, or a couple times a month, I go to shows, I meet people like yourself— and I haven't been able to do that. So it's not about just the product; it's about the community. 

Open source is really about the community. And when you get a bunch of people together who can either rebuild the ballpark or build a really awesome microservice management tool, it's the same thing. It's about being in service with other people that are like you. You have similar ideas, similar thoughts… You both love the same problem. Whether it be loving the ballpark or loving the fact that we have to figure out how to manage microservices, it's about the community. I can't emphasize that more. It has nothing to do, really, with the software. It really has to do with the community.

Ravi Lachhman  16:36
Yeah, excellent point. When I joined the CDF, there was a lot of very like-minded people, which sounds like, oh, I didn't know there were so many people who were focused or had these types of ebbs and flows you're going through when sharing your story. And the good thing I really like about the CDF [is] it's very inclusive, so anybody can join. We constantly have more people; if you monitor the Slack channel, there's always people joining and jumping around different special interest groups. A 

Another I would say intrinsic of problem as software engineers have— [though] Tracy certainly has an excellent brand— [is related to] one of the challenges I've had early as a software engineer. [It] was [that] my work never really followed me around. So what I did at IBM and then at Red Hat never really crossed the chasm, and stuff I worked on [was] behind the firewall and some government agency— because you don't want to see it or you'll be in trouble. [Chuckles] 

Part of this is building a portfolio as a software engineer. So artists have portfolios; we're hiring a graphic designer, so we can see all their portfolios. But software engineers on the other hand, it's hard to have a portfolio. I see open source as a way of having a portfolio like, hey, look what I've created to the public. Not sure if you've seen any of that, or have any thought around how can your accomplishments follow you around? 

Tracy Ragan  17:48
That's a good question, and I have to say that there are many software engineers who prefer not to talk to other people. [Laughs] You know, they don't necessarily think about themselves and their brand. Some of the most brilliant people that I've met— you look at their resume, and it's incredible. And it's like, why are you not out front and center? But it takes a certain personality to be out front and center. 

Contributing to an open source community, though, provides those brilliant people a real platform to be recognized because they can sit down listen to some problem sets and get excited about contributing code. Where[as] another person may just be working on outreach, and blogs— that person who's working on outreach and blogs probably started their brand, but the person who's sitting there with their headphones on and coding the hard stuff— it's harder for them to get recognized. 

And in most open source communities— and we're working on this now for Ortelius— [ensure] there's a recognition program, whether it be badges that you get to add on to LinkedIn about how many pull requests you've achieved or how long you've been with a project. It certainly is a way to get some recognition for those folks who aren't interested in being out front and center. 

Ravi Lachhman  19:08
Yeah, that's perfect. I like that the comment you made about this being a platform for folks. Sometimes I forget because I used to be told a lot that I was too talkative to be in the software lab or be in the actual team. Like, “you just talk all day. You enjoy the stand-up and talk the whole time.” Different strokes for different folks— it's always good to remember the spectrum, right? There's some people that [who are] quiet or reserved or might not be as sociable, but they stand by their work.

So it's not every day that I get to talk to the CEO, and so [I’m going to] use this time for CEO-related topics now. We’ve been really fortunate in the podcast, talking to several DevOps leaders in different firms. To pivot a little bit around hiring— it's something that's pretty critical. It's hard to have good hiring, and I'm going through the hiring process now expanding my team. So what if you're hiring a new engineer or a new person? What are some traits that you typically look for?

Tracy Ragan  20:18
It's hard for me to put my finger on it exactly. I can tell you that some of the best people I have hired have had very little experience in the area that I'm hiring them for. I look for somebody who can display to me initiative. Because OpenMake Software and DeployHub— we're small companies, and initiative is important. Somebody who is willing to come up and even during an interview say, “Hey, I've got this great idea.” Or, “I've looked at what you're doing on your website, and these are some suggestions I have for you.” I never consider that an insult. 

And when I'm looking to hire, if somebody has done that kind of research and is willing to express those ideas with me, I'm going to fall in love. Because it's that kind of person that succeeds in a small company. The kind of people that don't succeed are the ones that might show up right at eight o'clock and leave right at five o'clock, and they have their list of things that I give them to do. They're the hard ones to work with. I look for people who can display some level of initiative, and that's the best way I can describe it.

Ravi Lachhman  21:45
That makes perfect sense. I think it's something that either you have an intrinsic drive, or you don't. And it all depends about passion, right. [It’s] going back to initiative, someone's really passionate about the job. Your thoughts are pretty much in line with most of the DevOps leaders I talked to you. It’s, you know, they even hire the person not the skill, because you can teach skill but you can't teach the intrinsic drive. As cliche as that sounds, it’s extremely true because someone who wants to learn is definitely going to be there to learn, versus someone who's like, well, this is how you do it and I already have my set ways. 

Tracy Ragan  22:19
Here's a perfect example. We hired somebody out of Boston University who was in the film department. He had done some coding, but [it] turns out he was really good at telling stories. And there's no better GUI designer than a storyteller. So we could teach them basic JavaScript, but we couldn't teach him how to tell a story; he had to bring that to the table. If you're willing to really broaden your vision on what people can do, it's surprising the talent you can find.

Ravi Lachhman  22:57
Yeah, absolutely. That’s an excellent example. Some of the best software engineers that I know [were] philosophy majors in university, just because they were passionate about a certain thing or liked learning a certain way. But they also have skills that can translate over like, “Hey, this is what the user was thinking.” Or in a lot of philosophy or literature, it's like getting [into] someone's head, like, “What were they thinking when they did that?” And well, the computer is soulless, it knows what you tell it. So that's a very perfect example. 

So Tracy, how do you go about learning new skills? [Addressing audience] Tracy is on the forefront of a lot of technology. If someone wants to be more like Tracy, how do you go about learning and keeping up with industry trends?

Tracy Ragan  23:46
You have to love the problem. If you love the problem, learning is easy. Now, that being said, I do have to say I schedule a lot of time on my calendar, and I try to leave my Sundays for doing reading and studying just to stay on top of this industry. This is a wave that I've been riding for quite some time, so I've gotten in the habit of learning. I don't always drive down deep into a particular area; I oftentimes will try to understand the basic concepts and understand how they fit in. And then if I feel like I really need to understand the lower levels— like I felt like I really needed to understand Kubernetes at a much deeper level. I had to go beyond Phippy Goes to the Zoo, but man is that a really good place to start. [It’s] keeping frosty over the years, reading and learning new things, and then you find out everything is the same. And eventually you start mapping things and go, okay, I understand; okay, service mesh, request routing, I get that.  

So that's one way that I do it, but I do have to say that you have to love the problem. If you love the problem, the learning is fun.

Ravi Lachhman  25:04
Yeah, I’ve never heard it explained like that before. It’s [a] very ornate, very eloquent way of saying what's the intrinsic drive to keep learning. Another point I really liked that you brought up was the age-old computer science adage: everything is cyclical. Just like an abacus, you're just moving complexity left to right. 

Tracy Ragan  25:22
[Chuckles] Exactly. Exactly.

Ravi Lachhman  25:25
I started to notice that too. I'm like, oh yeah, I’ve seen this problem before, but we just have a different syntax or different way of solving it and shift the complexity somewhere else. The complexity’s still there, though.

Tracy Ragan  25:38
The one thing I was never good at is languages. I took four years of Spanish in high school, and then two years in college, and I still can't speak it. I struggled with computer languages, too. I wouldn't say I was the best programmer. But the ones that I had to learn, I really dug into.

But some people are so good at learning— what do they call them, somebody can pick up a language pretty quickly…. There's some developers who use that same pattern matching that we just talked about to learn new languages. That's a skill I never could achieve.

Ravi Lachhman  26:13
I have the same problem. I took several years of Spanish; I can't speak a lick of it. Tracy and I are very similar. [Both laughing] It almost cost me graduating university on time, because I had, buried in the bowels of Georgia Tech, some language or a programming class dedicated to languages [that I had to take]. I took AP Spanish, like four years of Spanish in high school— like, I guess no, that was not the case. I [was] like, I will take natural language processing then. [Laughs]

Tracy Ragan  26:48
That problem for me translated into computer languages too. I mean, I picked up Cobalt pretty quickly; I think that was in college. And then I went to C and C++ okay. But then over time, I didn't want to learn Java. I really didn't. And man, I hate YAML. I really hate YAML. [Laughs]

Ravi Lachhman  27:06
I hate YAML. It might be understated much I dislike it. I start using YAML a few years ago; 2018, I was taking the CKA exam. I knew I had to install a linter because YAML, for those who don't know, is space-separated— so how many spaces you have, and the next line actually matters.  

Tracy Ragan  27:32
Very much.

Ravi Lachhman  27:34
It makes it more human-readable. But as a human myself, I just can't see spaces. I'm not good at saying “that's four spaces. That's five spaces. One, two, three, four. One, two, three, four, five. So I have a linter that just puts periods where there's spaces. JSON is machine readable; I’d rather just do that. 

Tracy Ragan  27:53
Well, that's where my learning stops. I've decided [for] languages, I think YAML can be the last one I ever learned. 

Ravi Lachhman  27:59
There's this website that's like, YAML-linter.com. I'm pretty sure they have thousands of secret configurations to run. Like if I couldn't figure out where my YAML was wrong, I would run it through this website. I knew better than to take the secrets out. But it's like, oh, you’re missing a space here. Ugh!

Tracy Ragan  28:16
Well, you know, there used to be an editor called Brief. I literally used to keep it on a floppy, and I kept it in my purse because anywhere I went, I needed to use Brief because that's what I was used to using. It edited columns. 

Now, I'm sure there's an editor out there that uses columns— somebody tell me if there is— because that would make YAML a lot easier. Then you could go through and you could swipe a column and see if they're all the same. But I don't have an editor that handles columns, and so YAML becomes really difficult. But that has nothing to do with this conversation. It’s one of my pet peeves!

Ravi Lachhman  28:50
I feel so like relieved someone else hates YAML. [Laughs] I can talk for an hour about “why do they do it like this, tabs are better! Data structure, come on!” So last question. [And] thank you so much for your time today. I always like to ask this one intrinsic question, and I don't give anybody any sort of advance warning. But it's an intrinsic question— let's say that you ran into like a young Tracy, with current Tracy. Like, you just graduated University and you ran into your past self on the street— what would be one or two pieces of advice that you would give yourself?

Tracy Ragan  29:27
Find your voice. That's hard for women to do. I have made so many mistakes— in terms of running a software company, in terms of my career— because I didn't find my voice until so late in life. I don't know how anybody can learn that. Some women pick it up— and I believe, truly believe, some of the millennials I have met have found their voice so much earlier than I ever did.

And I'm really proud that women today— young women today— are finding their voice because it is critical. It's critical for everything we do in life. So find your voice. I would have told myself that. I would have said do it quickly.

Ravi Lachhman  30:11
That's very excellent advice. I think it's a struggle for a lot of people, but it’s very prudent advice. Tracy thank you so much for being on the ShipTalk Unscripted podcast. I'm sure the listeners will love this episode. And Tracy, thanks so much for being on. 

Tracy Ragan  30:28
Ravi, thank you. Thank you so much for inviting me. And did you ever get to go to Rio de Janeiro?

Ravi Lachhman  30:34
Did not. So little backstory for where we ended off. QCon— one of the dream conventions I always wanted to speak to—Tracy tee'd it up that I could take her spot at QCon South America, QCon Brazil. And then this pandemic happened. It was right at the time they were like lining up the speakers.

Tracy Ragan  30:55
Well if that happens again, I'll be sure to pass it off to you,

Ravi Lachhman  31:00
Thank you so much Tracy! Cheers, everybody.