Shifting Complexities in DevOps - Jim Shilts - NADOG/Shipa

In this episode of ShipTalk, we are joined by Jim Shilts who is the founder and organizer of North American DevOps Group or NADOG and is a developer advocate at the cloud-native firm Shipa. 

Jim has been working on solving engineering efficiency problems for over 20 years working at firms such as Build Forge and Electric Cloud, pre-dating the inception of Hudson/Jenkins. As Jim walks through his experience and how complexity and bottlenecks have shifted around in the decades gone by and whats in store for the future. 

Transcript

Ravi Lachhman  00:06
Hey, everybody! Welcome back to another episode of ShipTalk. I'm really excited to be here with Jim Shilts, who's a developer advocate and the founder of NADOG. So Jim's a developer advocate at a cloud native firm called Shipa— but Jim, for the folks who don't know you, why don't you tell us a little bit about yourself? 

Jim Shilts  00:25
Yeah, thanks for having me on your podcast here today. I'm Jim Shilts, as you said, I've been in this space for quite a while; I think it was 2003 when I got into this space. It was before the phrase DevOps even existed— about six years before it did. And about six years ago, I started a group called North American DevOps group, also known as NADOG. That group is really all about getting together [and] learning from each other. We started here locally in Southern California, and it quickly grew into other cities. It used to be the SoCal DevOps Group, and then we had to change the name to NADOG; then we started doing events in Europe a couple of years ago, so rather than change the name again, we're just known as EuroDOG there and NADOG here. 

Now with COVID, you know, we're doing all these things online— but still, the spirit is the same. It's about getting together, talking about our industry, learning from each other and doing it in a fun and casual environment. So you can actually make some real connections in this space.

Ravi Lachhman  01:25
That's awesome. I had the benefit of chatting to Jim before the podcast, [and] he was a treasure trove of knowledge. Jim has been doing DevOps legitimately longer than the term has been out there. And there's a little bit of connective tissue with Jim and I. Jim, in early days, was at a firm called Build Forge. I was at Rational when they acquired Build Forge; actually part of what my team was doing. was working on the installer for Build Forge when we were IBM-ifying the product. 

But let's take it back to really early days, before DevOps was a movement. Where are we headed? Let's talk about your time, in the early 2000s— what was the big traction going on then? 

Jim Shilts  02:14
Yeah, I think it's really funny to that we didn't know each other; we must have been on at least a few conference calls together in the earlier days. And IBM-ifying— I think we called it Blue Washing back then. But yeah, I joined Build Forge in 2003. I didn't know anything about the space at all— I had to learn what a deployment was, I had to learn what a build was. And at that time, it was all very much a waterfall approach to development. I mean, builds were an event, right? It was maybe once a week if you were really, really moving fast, and you'd have a weekly build that could take a couple hours could take a couple of days. 

There were some tools to kind of help with things— there was Cruise Control, and AntHill Pro— but mostly it was a manual build process. And people had build engineers— [and] that role doesn't exist anymore, right? Those people have evolved into sys admins and DevOps engineers and other things. But there was a team of build engineers for larger projects, and gosh in those early days, I saw somebody with a 23-page Word Document— that was their build process, and they had to manually key in all of the command lines or execute the scripts. If you fat fingered something or messed up somewhere, then you had to start the build process over. Like I said, builds could take all weekend sometimes, so it was pretty painful. 

So Build Forge came along— it was really a Jenkins-like type of product, right before Jenkins or Hudson even existed. I think the Hudson project may have started around the same time, but nobody was using it yet; it wasn't what it is today. And so really the beauty of that was [that] is it allowed people to take their existing process, to take that 23 page Word Document, and just put that over into an automated system. They could literally take those commands, put them into steps within Build Forge and those scripts, execute these scripts, and then take that human element out of the process. And then there were added benefits to that— speed became a benefit. Then people started going,” Oh, how can I make this even faster?” And then people started saying, “Oh, how can I move this over to deploy? How can I automate the build process, so I don’t even have to press the go button?”— which is where CI started to come into play.  

Even then, we didn't call it CI; it was just an integration with whatever SCM tool you're using. And with Rational—we had a plug-in that allows you to tell it, hey, just keep watching this repository, and if you see something new or something change, then execute a build. But then that started moving the bottleneck even further to the right. So we found a huge bottleneck in build, and then we just pushed it over to test—then we just pushed it over to production, and just kept pushing it that way.

And so then you started to see the evolution of other things— to manage infrastructure as code, how do I get more infrastructure to my people. So it's really, really interesting to watch this whole thing evolve, to watch that bottleneck just continue to shift and move around as we really fine tune or speed something up, make it more automated— somebody else is going to feel the pain somewhere. So that product, like you said, was acquired by IBM. The guys who started that company, Joe Senner and Tim Wall— [I want to] give a huge shout out to them. They introduced me into the space— like I said, I had no idea what it was. Joe was the CTO, [and] spent a lot of time with me, just educating me on what this is,— understanding and visualizing that wall between development and your operations teams and your infrastructure teams. [It was] just trying to understand the value of that and breaking that wall down— which is really what all DevOps is about. We were talking about a DevOps process, and we didn't even know that we were talking about it at that point.

Ravi Lachhman  06:19
Yeah, that's perfect. That's really early days, right? I’m really excited to take a jog down memory lane. I remember coming right out of school, [and] it's like teaching someone to hate— I didn't really realize that there was a wall there until later in my career, because our software engineering team was insulated. All of my software engineering tasks that I had to do— the end of it was “did it work on my local machine?”. And then we had these people who are now missing on milk cartons, the build and release engineers— they would massage it and take it forward. But we were paired one-to-one. 

I think that at the time, when I was working at Rational, there was probably two or three of us on the team. And there [were] two other people who were taking it after we had it locally built on our machine. Who knows what they did with it, until QA came back and complained and opened up a ticketing request. [Chuckles] So that was it. Then slowly as time was progressing and as I became more senior— now I started having to worry about when would the changes be available— that was several years after that; I started seeing the walls. 

I'm jealous of your 23 page document— I remember for that one, I switched gears out of Rational into IBM Federal Consulting; I wanted to do some cleared work for some odd reason. And at the agency I worked with, it was a 153-page change document to get something into production. Which I'm pretty sure is the same way [they do it] today.

Jim Shilts  07:52
Yeah, you see that as the evolution for a lot of solutions, right? And that's really why all of these DevOps-related and cloud native-related products exist— they find something that people are doing manually, find something that is creating a bottleneck somewhere in the list, and then build something that will help knock that bottleneck out of the way. 

[In] my career, I have gone through a lot of these companies as this thing has evolved. [It was] Build Forge, and then IBM—which was an experience in it of itself. They were such a huge company and for me, it was very difficult to navigate. Because coming from a very small company like Build Forge— we were nine people when they started, and then 40 people by the time we got acquired which is only 18 months. It was a huge roller coaster. 

Trying to navigate that, navigate what these enterprise agreements were and all the multiple brands involved— we did a lot more interacting internally than we really did with the customers at IBM. But then I was Electric Cloud for a couple of years as well, which they were a little more focused on. At the time, they had kind of a shiny, newer Build Forge product. But at the same time, we saw Jenkins and Hudson hitting the scene, so that whole build automation and CI was very quickly getting won over in open-source world. And so, Electric Cloud was trying to shift their focus a little more over on the deployment side. 

But then when I got to CA Technologies a few years after that, they were focused on that side— on the release automation side. They also had a really cool product for service virtualization. I think it used to be called LISA. We were creating all these builds, but then you'd get over to test or if the developers needed to do unit tests— they didn't have the infrastructure to test it. So that was what was slowing them down— and service virtualization allowed them to spin up these virtual environments and really virtual applications to test against very quickly. [This] helped knock that barrier down. 

It’s really cool and interesting to see where these things pop up. Nobody was thinking about anything like service virtualization back in the early days, but there became a requirement for it. The company who— I can’t remember what the company who created LISA [is called]— but they saw a need and spun up that product, and then CA buys them. [This] is the other thing that happens— all these smaller companies build these great products, and then they become IBM and Microsoft and CA, which is now Broadcom.

Ravi Lachhman  10:34
They'll get you one of these days— they're coming. [Chuckles] And you say it so eloquently. It’s like the old computer science adage: you're just moving complexity like an abacus, [from] left to right. And so in anybody's career journey— and your journey has seen it— builds got efficient, right? We're able to build very efficiently, we have all these artifacts… but where do they go? The funnel is stuck at the top, We have hundreds of potential builds, but we're now limited by the infrastructure.

So there's a couple things that ended up happening, which the DevOps world (or the Continuous Integration or Continuous Delivery world—[whatever] you want to call it—kind of evolved to, is that there's this concept of if you need to make a change, it needs to be repeatable. But people take that to the extreme. I’ve always been taught, as part of my engineering [and] me being grilled through the years, if you have to make a change, [you need] to recreate everything from scratch. And so that’s what ends up happening, like having available or waiting infrastructure— it's rare these days. You’re like, oh, it changed— rebuild it, rebuild it, rebuild it, rebuild it, rebuild it, rebuild it, as much as you can. And this is where I think the bottlenecks you're mentioning came up. Like, hey, we're able to make a build that the developer can take care of, then this is where the operation folks need to come in. They know the infrastructure, they have the skill set— and this is what leads us to DevOps, right? There's definitely a merging of the two skills.  

Maybe we could talk about the early days of NADOG. What drove you to start it, and how was it the early days? 

Jim Shilts  12:19
I was actually working at CA and working on projects with their release automation tool, which used to be called Nolio, I believe— I think that was another acquisition by CA— and mostly with the LISA or service virtualization product. CA has a habit— or they did, I don't know if they still do it as Broadcom—but they would acquire a company and then they would change the name, and the name of the company would be the definition of what the product is. So rather than being called Nolio, which was the brand, they say, “No, no, it does release automation. So that's what it's called; it's called Release Automation.” 

But anyway, I digress. I was working at CA, and I was really looking for a better way to kind of tap into my local peer group. I'd been in the space for a while, and there were a lot of people that were close to me geographically that I just didn't know. I thought I was really missing a huge opportunity just to know these people, to share war stories, to learn from each other. So I kept talking about spinning up a local community group— and I need to give another shout out to Alison Tierney, who was my boss at the time. She kept asking me every other week, “Did you do it yet? Did you start something?” I was like, “Oh no, still thinking about it.” And she goes, “No, open up your laptop, put a date on the calendar. That's going to be the first one.” I said, “Okay.” 

So I did it and took credit, and she was right. Once I had the date on the calendar, I was like “Okay, I'm really working toward it. I've got to make this work.” So again, the idea was, let's just get together in a fun and casual environment, and let's meet some of our local peers. We didn't have any agenda, [and] we didn't have a speaker; we just got together for lunch. 

There were eight people who came to that first event. It was at a Mexican restaurant in Irvine, California, and it was awesome. Everyone that was there— we were all talking and sharing stories. Someone brought up, hey, I'm working on XYZ, and then there were other people in there who had already solved that problem. I was like, “Wow, this is really cool. This really works.” So we did another one; I just put another date on the calendar as soon as I got back from that one in San Diego, and we had 20 people there. And then I put another date in the calendar in Los Angeles, and we had 25 or 30 people there— and it just kept snowballing. 

After a year, we had like 1000 people in Southern California that were regularly coming to these events. We were doing lunches, but then we started shifting over to happy hours. People said, hey, if we're going to get free stuff—because at the time CA was sponsoring these things [and] paying for the lunches and happy hours. And I asked people early on as well, and said, “Hey, do we want to make this a membership thing where you pay into this, and then we use that money to pay for lunches and stuff? Or do we want to bring sponsors in and let them pay for everything?” 

They said unanimously, “We’ll let the sponsors pay for it.” So as we started bringing sponsors into these events, we really had to make sure that we kept this an agnostic group. We didn't want this to turn into a commercial for whoever was sponsoring. The rules are that we give to sponsors who come in [understanding that] this is a thought leadership group. This is all about the practical, the “how do we do this, how do we do that.” So if you [the sponsor] come to these things, you're not there to sell your products— you're there to interact with these people as well and just be a member of the group. 

So they [the sponsors] totally get that— a lot of them get that. I think that community approach to getting introduced to new products is just so much more effective than putting your commercial out there constantly. If you can get out there and connect with the community, it’s not only better for them but it's better for you because you're understanding what their day-to-day pain points are— what they're doing and what they're working on. It helps you to go back and rejigger what you're doing on your side of the fence too. 

So we were doing that for four or five years. We started in 2015. Then in 2020, it became my full time job just running NADOG— because at that point, we had 13,000 members and 35 cities, we were doing quarterly events in all of these cities. Every month, we would have 10 to 12 events that were running, and we had plans to expand that even more. So I decided at the beginning of the year, this is going to be my full time gig. 

Then COVID came. We went “oh, shoot.” So since then, we've moved everything online [and are] trying to keep that same spirit in mind. When we do our online events, we have a featured speaker who will come on and talk. It'll be mostly people from the group— we had somebody from the Air Force talk a couple of weeks ago, [and] we had somebody MIT talk last week. Really, really great speakers coming [too]. We've had Kohsuke Kawaguchi who is actually the creator of Jenkins, come on a couple of times and talk to the group. So we had some really cool names come on and share with us. We'll do that for 30 minutes, and then turn it into a group discussion. We really want them to be interactive, because that's the real value— it’s when we hear from the other members chime in about their experiences as well. 

Then we use the last 30 minutes of our event to just do some virtual networking. Whoever wants to stick around, we're going to create some smaller breakout rooms— because if you got 50 people in a Zoom Meeting, that's extremely chaotic. It's way more chaotic than having 50 people in a brewery or a restaurant together. So what we do is create breakouts within Zoom, and we'll put five people in a room [and] give everyone a chance to kind of go around the horn to introduce themselves— this is who I am, what I do, what I'm working on. Really, really good. It's about the best way we could find to have that continued personal connection while we're still quarantined. 

It works really well, and I think it works to the spirit of what we're trying to do in NADOG. So now we do a weekly event like that, where you get to get on, hear some great thought leadership, chime in, be part of the discussion, and then get a chance to meet some of your peers as well. 

Ravi Lachhman  18:32
Yeah, that's a great background. As always, DevOps is more than just a tool or a checkbox. It's definitely a movement, it's people. 

Jim Shilts  18:45
I was just going to say, that's actually our biggest challenge— and not just ours in NADOG, but I think it's all of our biggest challenge— that we’ve got to get on the same page about what DevOps is, and  what the definition of it is. Because now there are people who have DevOps in their title. Okay, what is a DevOps engineer really— it's not DevOps. DevOps Engineer, when you boil it down, most of the time ends up being an automation engineer— I'm the person trying to stitch these things together and automate from development to production. That's usually what a DevOps engineer is. 

But DevOps, like you said, is a movement. It's a way of thinking about how we develop. It's about taking responsibility for what you do, but also understanding it— understanding what you do, how it affects the next person down the line, and the next person beyond that. [It’s also about] what value you're bringing by what you're doing, from the developer all the way to the business owners, even the CEO of the company. We all need to be tied in. I've talked to people coming to events [about it], [to] somebody who's in QA or somebody who's in development, and they say, “Oh, yeah, I know I'm not DevOps. That wouldn't be in my wheelhouse.” 

But it’s like, “No, you are. You're part of it.”So when we talk DevOps, we're talking about it in the traditional definition of what it is— it's about breaking down barriers, about collaborating, about all being on the same page and marching to the same beat of the drum.

Ravi Lachhman  20:12
Yeah, perfect. I used to tell people a joke that I'm going to start an appliance company, DevOps Appliance. It's blue when you have DevOps, and turns red— no DevOps. And then it'll flip back to blue when DevOps comes back on.

Jim Shilts  20:27
[Laughs]. We had when we were in the early days of Build Forge [a] tool that was really cool. It was very, very much like Jenkins. If you looked at Jenkins and Build Forge side by side, it's very similar. If you know how to use one, you can use the other. Build Forge was highly extensible— anything that you can hit with a command line or run with a script, you can automate with Build Forge. So we had a company that we worked with, [and] they put these lights that could change from red to green. They put them on top of everybody's cube, and if you broke the build, your light turned red. 

So that culture, too, is very much not DevOps, right? The shaming culture, the stress of that. So I thought that was funny, but it just reminded me because you brought up the different colored lights in your appliance.

Ravi Lachhman  21:24
I would constantly be on red. This whole taking a page out of the SRE book, blameless culture. I've certainly been blamed; I deserve the blame sometimes, but sometimes didn't deserve the blame. [Chuckles].

Jim Shilts  21:40
It's funny, though, because [previously] you didn't want to be the guy who broke the build, right? But now the culture has shifted so much— you look at companies like Netflix, the Simian Army, and the Chaos Monkey and stuff. They encourage breaks early on: “let's see as many breaks as we can, all the way to the left. The more we see there, the more we can fix, the more we see in production, the more we're screwed— the more we've got to go back, the more we're losing money.” I know people who have started in development jobs in places like Google, where they're deploying code into production on day one. You're going to be deploying day one, so they're not afraid of breaking. I think it’s a very long journey for a lot of people to get to that point where they're that confident. 

There are some industries where that's just not going to happen: financial, as an example. They're not going to say, “Oh, yeah, go ahead and break the bank.” But I think having a system where you see breaks or failures as opportunities, as long as you can have some kind of control over them and have them in a space where you can make earlier corrections, rather than seeing those things failing in production [can be beneficial]. And Canary deployments is a great method— being able to put it out in just small segment of your community, before you start to roll it out to everyone else. So we're seeing a lot more solutions come around that offer that kind of feature.

Ravi Lachhman  23:13
Yeah, makes perfect sense. [It’s] a very pragmatic answer too; it's never one size fits all. Sometimes you can take more risks and break things early, and often, sometimes you can’t. One of my favorite projects I've ever worked on was for a very big bank, and they were modernizing. I as part of the cloud migration team / engineering team, [and] they were migrating the check cashing-up to the cloud. Just in terms of monetary value, they cashed over a trillion dollars of checks in the year I was there. So we can't screw up— the economy would stop pretty much right. [Chuckles] That's a lot of money. It's a T, like you said, a thousand billion.

I'm going to cheat a little bit, because it’s not every day that I have a founder of a very successful DevOps group here. I’ll also give a little bit of a cheat to tell people how I learned about stuff, to short circuit some things. Keeping up with trends is hard; it's a challenge for anybody in technology. It's part of our job, but as a cheat, if you want to see where trends are headed— this is the current-and-trend part of the conversation— I always like to look at agendas of conferences to see where the organizers’ heads were at when they pick certain topics. 

And so, just refreshing on the last time you had, let's say multiple speaker at NADOG—what were some popular topics, as an organizer? What was prudent?  There's a little bit of a professorship there, like “is this important to the audience, is this not important”. But as an organizer, what were some important topics you wanted to cover?

Jim Shilts  24:49
Yeah, that's a good question. And we generally don't have multiple speakers or certainly now online. We stick it to one and keep it very focused. These are 90-minute events, 60 minutes if you're just there for the talk in the group discussion. But if I look at the trend of the topics— and let me qualify with this, as well: we generally don't pick the topics. Our speakers do. But I still think it's telling, the things that people are wanting to talk about. 

We've seen it go from in the early days, it was all just about automation and release automation. And then people were very interested in data for a while as well— how do I protect my data? A lot of things happened in the industry: some big disasters, I won't name any names of companies, but some bad things happened with data— and so people wanted to know how to protect it. Then GDPR Regulations were coming along a few years ago, so we had a lot of talk around that stuff. There were a lot of security-related topics.

But probably about two years ago, [the conversation] really started to shift toward cloud native topics. So anything Kubernetes-related people wanted to know more about, anything microservices and cloud native because a lot of companies just knew that's where things are going, that's where we're going to evolve. Like you said, as we start to create, as we start to speed up this process of delivering new changes, that's going to back up at some point. You're going to go so fast that now we’ve created another bottleneck that wasn't there before— we created one. And so that's really what the promise of cloud native is— you can deploy things in a much more efficient way. You can spin up containers and run things in micro services that are a lot more efficient, which make a lot more sense and reduce a lot more the blast radius than a monolithic or traditional application does. 

And that's when I joined Shipa too, last year. That's really what they're focused on— taking that bottleneck now that exists on the developer and platform engineering side, [and] giving developers an easier way to actually deploy to Kubernetes without having to worry about the infrastructure. But [it’s] still [so that they’ll] benefit from all the great things that Kubernetes brings. And they give the platform teams a way to manage the policies and to manage the frameworks and to deliver that framework to their development communities. So we're seeing a lot of discussion around the cloud native space in the Kubernetes space. 

And I think too, it seems like it's starting to come full circle. We talked about a little bit already, that definition of DevOps— people are trying to get back to the grassroots of that, saying, “Okay, we've been so focused on automation, which if you look at like the CALMS or CALMR, whichever acronym you use— which is a way of defining what DevOps. It's culture and automation, lean measurement, and sharing or replace the sharing with recovery if you're on the scaled agile docket. But automation is one piece of that. If that's all you're doing is automating things, you could be automating junk, right? And you don't know, so you’ve got to have the culture piece. You've got to have that the lean infrastructure piece. You’ve got to have the measurement and observability piece as well, and you’ve got to be able to recover. 

So I think I see the trend coming back to that as well. We're very excited about this, this new space of moving things to cloud native, and I think everyone knows, “Hey, we're going to get there.” Most organizations have bought into that; all their new projects are going cloud native first if they can, and then they're looking at ways to bring their older apps into the microservices world. At the same time, since we're moving into this new space, I think people are going back and saying, “Hey, we should bring the DevOps culture into this with us. And let's go back to what that really means and what that is.”

Ravi Lachhman  29:17
I'm glad that's coming back. I echo the same sentiment, [as you said] very eloquently; I’m cheating to get answers here. It's really good. Mirroring my experience, there was a big focus on the culture, and the culture talks were kind of there… but it was a big push. And “hey, these are new technologies that are bridging the gap”, right? As a software engineer, I needed to learn more operational tasks with Kubernetes. And for the platform admins or system, engineers who work in Kubernetes, they need to learn some software engineering principles too. So we're having to meet in the middle. And that's why it was a natural place at the DevOps meetings and organizations to bring us together. 

Just coming to the back quarter of the podcast, [I have] two questions. Can you tell me a little bit more about Shipa? So I've been hearing some press about it, but for the listeners who don't know much about Shipa— what does Shipa do, and how do they do it?

Jim Shilts  30:18
Yeah, and thanks for that. Like I said, I joined Shipa in October of last year as a developer advocate. [It was] my first time in that space. I'm working as a developer advocate and a community organizer within Shipa. Before I get into what they do—their go-to-market strategy is very much in tune with my ideals and with what NADOG was started for in the first place. It’s “let's get out there and talk to the community, let's be part of the community, let's let this be a community-driven product and solution, and not a marketing or sales-driven solution.” But as we talked about before, we're seeing now an evolution in this cloud native and Kubernetes space that is very, very similar to what we saw in the monolithic or traditional development space nearly 20 years ago. 

Gosh, it's making me feel really old saying that [laughs], but it's almost 20 years ago. [As an aside] The way that I can remember where I was at any given time, or where I was working is by thinking about the ages of my kids. I have six kids, and so my 16 year old—actually he'll be 17 next month— my 17 year old was born right when I started at Build Forge, so it was nearly 20 years ago now.

So if you look at this Kubernetes space now, things are very, very complex. It's not only a lot more things to deal with, but it's a whole new way of looking at an application. An application in Kubernetes does not look like an application in a VM— it's very, very different. Things are very complex, and dev is really getting bogged down with the infrastructure side of things. They're having to handle Helm Charts and YAML files and Kubernetes objects. Like you said, they're having to learn more of the infrastructure side, and at the same time, the platform teams are having to learn more of the development side. And they're kind of butting heads— neither one really wants to do to do the other person's job. 

One of the reasons I joined [Shipa] is [that] they're really focused on trying to take those burdens of Kubernetes out of the hands of the developers, but still give them all the benefits of Kubernetes. So do really need to know where your app is being deployed, if you're a developer? Do you really need to know what the process of it is? It's like getting in your car; you want to press the gas pedal and go— do you need to know how the engine works? It might be nice to know how some of the things work in case it breaks down and you can get in there and fix [it]. But most of the time, you just want to get from point A to point B, and back again. As a developer, that's what you want to do. So that's what Shipa is focused on— providing that A to B for the developers.

But then on the platform side of things, [we also focus on] giving the platform teams a way to not only abstract Kubernetes away from the developers, but also give them controls around all of the advanced policy management— things like RBAC controls, and security scans, all of the things that are important to them. [We] create what we call frameworks for a developer or a development team, put it into a cluster, put it into multiple clusters, and all over the place. If you want. you can have them in different clouds, you can have them on prem, have a very much a hybrid environment— whatever aligns with your current strategy of your company— but then offer that out to the development team. 

So it's a really exciting time to be involved in the cloud native space, because even though it's been around for a little while, I think we're just at the very beginning of seeing it explode into being a very, very powerful and widespread thing that we see in production. A lot of people have their toes in the water in cloud native and in Kubernetes, but I think a lot of people are getting ready to jump in and cannonball into the water. And so there needs to be something there to help them get to that point.

Ravi Lachhman  34:32
Perfect, really helps clear up what Shipa does and continued success in the project and product. 

Last two questions for you, Jim. So let's say that I'm new to the DevOps community— what can I do to get involved with something like NADOG or any other community? It’s such an important thing. I always have this conversation with one of my cousins. He's your staunch systems engineer; he has the RHEL books and certification on his bookshelf. But, you know, he's a little bit scared to come to a DevOps Days even when I'm the organizer. Like, come on, I'll buy your ticket. Come to one of the events.” What would be maybe the first foot forward someone can take in participating in a community?

Jim Shilts  35:18
Number one, I truly believe it's highly important that you do get involved somewhere, whether it's with NADOG or somebody else. There's lots of options out there. We don't see ourselves as competitive with any of them. I mean, we're a community, right? So we want to partner with other people. In fact, we've partnered with people like DevOps Live out of Dallas. We partner with the group at All Day DevOps, Mark Miller and Derrick Weeks. We partnered with DevOps World, the CloudBees event that they run as well. We see ourselves as part of the overall community. And so I encourage anyone, whether it's with NADOG or anywhere else, [to] get involved. There are options out there. 

And NADOG [may not be] for everybody, right— leading up to COVID, all of our events were on-site. We'd rent out a brewery, we'd rent out a private room at a restaurant, somebody would host us in their office space if they had a good space to have a bunch of people. They’d either be at happy hour and we'd have beer and wine and soft drinks and food, or we do a lunchtime event. And that's not for everybody, right? For the last couple of years, we've been planning our move to an online format to offer that to people so they could still participate in the community without having to leave their house [and] without having to actually interact with real people. I think that a lot of people in this space are naturally shy, so we do try to bring that out from people as much as we can. 

But for NADOG, really, the only requirement to get involved is if you're going to attend one of the events, whether it's live or online, we ask that you're you are an IT practitioner or you're an IT leader. If you're not— if you’re a salesperson, marketing person, recruiter—you can participate as a sponsor, that you show your support of the community, and you're welcome to come in and be part of it as well. But even when they attend, we want them to attend as attendees, not as salespeople. So we're really, again, focused on making this not a sales type of a thing. We want this to be a community where we learn from each other. 

But to get involved, I mean, you really just have to go to nadog.com. It's free to sign up. You just put in your information just so we can contact you about when new events are. Or if you prefer, you can just follow [our] an event page, and you can just sign up for events that way and join there. Same thing when we're doing things live, it'll be the same way— we've got an event page, and then you can join the mailing list so we can inform you. 

But if it's not NADOG, you know, I suggest going to meetup.com. Lots of different options there googling for other events. And one of the biggest steps for people, but one of the most valuable, is [to] volunteer to speak somewhere. All these events are looking for speakers, and if you work for an enterprise company and you're part of the DevOps movement— volunteer to speak. Come up with a topic and speak. It's not only going to be good for you to really help you better understand that topic, but you're going to be sharing with a much broader audience. And that's really what that the culture of DevOps is about— it’s about all of us sharing and learning from each other. 

Ravi Lachhman  38:45
No, perfect. Like, hey, just take that first step forward. And if you're shy, just listen. That’s it!

Last question for you. I always end every podcast with this question. It’s a very intrinsic question; there's no right or wrong answer. So let's say that current Jim is walking down the street and you run into Jim who just graduated university. What would you tell your past self? It can be anything— “Don't go to jail? Don't do that. Do that.” What could it be?

Jim Shilts  39:25
What would I tell him? Well, there’s actually a good lead in from your last question, because this is what I tell other people who are just getting started in this space. It’s to get involved now, because I waited a long time before I started NADOG. And not just starting NADOG, but I wasn't involved— I wouldn't go do things after hours. There was no way; five o'clock. But part of it was [that] I have a big family and we had a lot of things going on. So we worked hard at work, and then I worked hard at home and then we slept hard when it was time to go to bed. So it was a little more difficult. 

But as that started to clear up a little bit, when I finally was able to jump in and start really participating in the community and getting involved, I immediately felt the value from that. So I would say [for] anybody just starting their career and coming out of college, get involved today. And I think that this generation coming out of college today probably is a little bit better at it than we were because we didn't have the social media that we do today, snd it wasn't as easy to connect and to get involved as it is today. 

But get on LinkedIn, start building your network, start getting out and meeting people—especially your local community— because not only [are you] going to learn from people [that are] going to benefit you in your career, but you're going to be looking for another job someday. And what do they say: [for] 80% of people, the job they have is the job they got because their friend referred them. And we've had a lot of instances of that, where people at NADOG events made connections and got new careers through being part of the community. We're very proud of that piece of it as well. 

But yeah, I wish I would have gotten involved a lot sooner and [had] just been active in in the in the community.

Ravi Lachhman  41:17
Excellent advice. Very sage advice for anybody? Like, if you're not out there, how do you how do you grow? But with that, Jim, thank you so much for being on the ShipTalk podcast. Really glad to have you.

 
Jim Shilts  41:31
Great to finally meet you after bumping into you for so many years.