Transforming DevOps: Redefining Agility, Reliability, and Security – Adam Jacob, System Initiative

This is Techstrong tv. Hey everyone. Welcome back to techstrong tv.

I am, I'm really honored and pleased to have I I, this is the first time on the show in years. Adam, Jacob, and Adam. Well you guys all, well, a lot of you know Adam, but if you don't, he's gonna tell you about Adam.

But Adam is also now the founder and c e o of a new company called System Initiative. And, um, Adam, welcome to Text Strong tv. It's great to see you.

Thanks, Alan. It's good to see you too. Absolutely.

So, Adam, I, I hope I didn't embarrass you, but for those people who maybe don't know Adam, Jacob? Yeah. I'm Adam Jacob.

A little bank. Yeah. In a previous, yes.

You're in a previous life. I, uh, I started a company called Chef, um, originally called Ops Code. Um, and, you know, most of my career, I still feel like a systems administrator kind of in my heart.

I, I know that like job title is now long, long passed into the, into the midst of history. But, um, but yeah, mostly I've made my career building building tools for, for what is now like DevOps people. Um, and you know, I was, so, I, I, I wrote Chef originally, I was CTO mostly had a bunch of different job titles, but I was mostly the CTO of Chef for most of his life.

And then, um, and then wound up, uh, did that for like 15 years and then, uh, took a few, took a little time off, and then started System Initiative. What now? A little like four years ago.

So, Absolutely. Um, so Adam, you know, it's funny, my previous interview I did this morning was with Chris se, the CTO of, uh, cloud Native Computing Foundation. And we were talking about Kubernetes of all things Makes sense as one does.

When you talked, he had PCF F guy. Yeah, Right. But he was mentioning, he had a recent talk with one of the, probably the fourth largest credit card, uh, brand out there after MasterCard, visa and Amex, you can guess.

And, and they were talking about how they're just moving to the cloud and they're now looking at maybe starting to use some cloud native technologies like Kubernetes and stuff. And, and he said, you know what? We live in a bubble where of course everyone does DevOps.

Of course everyone does containers and, and cloud Native and Kube and and so forth. But we, we tend to forget that a lot of the, a lot of the world hasn't quite, they're just starting their journey. Yeah.

And there's, you know what, Adam, there's a lot of people out there who are still called system administrators. I think it's Yeah, yeah, yeah. They're still there, right?

They're still there, yeah. Yeah. And Some of them are called system administrators.

Some of 'em have new fancier titles, but they're still system. Yeah. Like we're, you're still a systems administrator, right?

If you're a DevOps engineer, you're a systems administrator. Absolutely. Man.

If you're a cloud infrastructure engineer, that's a systems administrator, right? You're a platform engineer. That's a systems administrator.

Let's be honest. Anyway, I lost that argument long ago. I'm gonna call you whatever you wanna be called, but You know, yeah, I I need to just don't call me late for dinner.

Yeah, exactly. All right. So let, let's talk about systems system initiative you started at four years ago.

Yeah. And like you said, you did take some time off in between that and, and, and Chef. Yeah.

Right. Yeah. Um, what was the motivation there?

What, what kind of drove you to do this? I mean, look, I feel like I, I, I, a lot of my journey at Chef, I spent a lot of time I in the field. So I would, you know, I would spend at least, at least a couple of weeks, sometimes months outta the year, uh, working with customers sort of directly.

So I would take these, I would like take small teams and run 'em, you know, uh, so I would take like small slices of a big enterprise and I'd be like, okay, I'm gonna teach you how to do all this stuff and we'll do it together. And then like, and, and then you'll see like how you can stitch all this work together and sort of do, do the DevOps, you know? Um, and I love those engagements.

Were so fun. And, uh, and you met so many, like fascinatingly smart people who had done so many clever things. And, uh, and I love doing it.

Um, but I wound up in a meeting toward the end of my time at Chef where, um, I was asked sort of, you know, go to the whiteboard and, and tell us how we're gonna accelerate that. Our enterprise, here's, here's the shape of our problem. We want to, you know, be able to ship whenever we want to, and, you know, make it happen safely and quickly to production securely, you know, tell, tell us how.

So I went to the whiteboard and I, and I, and I drew it. I was like, here's how like you're gonna do these things. And when I finished the, um, they're like, c their global CTO high fived me.

And normally when that happens in a meeting that you were trying to sell something, you feel pretty good about yourself, you know, you're like, yeah, mm-hmm. I'm awesome. Right?

Done. Yeah. And I, I, I felt none of that, you know, like, all I wanted to do was go home.

And, uh, and like I didn't, I didn't get like a, I didn't get any juice out of it. And, and the reason wasn't cuz I was wrong. It's not like I felt bad cuz I was like lying to this person.

Like, I knew it would work, but I knew that it wasn't actually gonna work for them because hidden inside of my description of what they should do were a million subtleties that if they didn't get them just so right. If they didn't do it just right, then the whole thing would fall apart. Because the way the tooling came together, not any individual tool, but the entire workflow was, was a mess.

Right? Like, and in order to really get the outcomes that you wanna see in the enterprise, that workflow has to fundamentally change. And the way the tools were put together and the way the stack was put together didn't actually support that change.

Right? You, it was easy to get the, the, the religious conversion to be like, oh, okay, I want all these things. I want DevOps, I want, I want all the aspirational good times.

But when it came to time to actually change how you worked, we didn't actually ask people to change how they worked all that much. We, we, we, we threw a little bit of lean at it. We, we, we swapped the tooling out.

We've replaced the actual tools you use maybe how many times in the last 15 years? Two generations, three generations, maybe more. Right?

And, um, but the outcomes are roughly identical to what they were in 2009. Um, and, and it's because I fundamentally had come to believe that it, it was, it was that the way we put the tools together was the problem. Um mm-hmm.

And so that's where system initiative came from, was this recognition that actually what we have is a user experience problem that we need. We need to fundamentally alter the way people work together so that they can collaborate in real time on these DevOps problems, which is always what we wanted them to do. And to do that, we had to build systems that had faster feedback loops.

We needed to change the way the interaction model worked. It needed to be more like, like collaborating in Figma or in Google Docs than mm-hmm. Than a poll request, right?

Yeah. Um, like, uh, and that's, that's how System Initiative was born. I love it.

com. Yeah. Right?

November of 2013 would be, will be 10 years. Um, and I, I was late to the party, I felt, right? Yeah.

I mean DevOps was well, well entrenched Yeah. Four years or so, right? Yeah.

At least. And, and um, but you know, we look back now over these 10 years and, and there are a lot, there were always naysayers, there were always people who said, oh, it's more marketing. It's Anything worth doing is got people who think it's b******t.

Absolutely. But when, when recently, let's say in the last two years, three years, we've heard things like, well, you know, DevOps is not as successful for most organizations. And I think you alluded to it, right?

You knew it wasn't gonna work for the company that you had just kind of diagrammed it out. Yeah. The Dora report, the last Dora report had 88% of DevOps adopters stuck deploying once a month.

At best. At best at best. Exactly.

So it wasn't as successful as advertised. Other people said, well, you know, it was too dev centric. Other people said it was too centric.

Too Centric. Yeah. The platform engineering, the platform engineering's replacing it.

It's had its day, it's kind of faded, it's passe, whatever. But yet maybe I'm the, you know, the glass is half full kind of guy. I, I just see so many DevOps principles and, you know, kind of precepts embedded into the way we do things now.

Yeah, yeah. In both dev and ops that I, yeah, I don't wanna say it upsets me, but I I violently disagree with those, these areas And these people. Oh, it, it upsets me.

It upsets me, but like it upsets it up. It upsets me because I remember what it was like before we did that work. And, and you know, look, I think when you, the question is what is it that we actually believe brings about these good outcomes?

And if we're not seeing the outcomes we wanna see in the world, is that because our aspirations were wrong? Is that because what we believed in was wrong or because what we hoped for was wrong? Were we wrong to hope for those things?

Were they impossible tasks that the evidence tells us? No, we know that it's possible for, for folks to get to that place. We know it's possible for, for people to work that way.

We've seen it, but it's rare, right? Um, and it's rarer than we want it to be. And I think the risk we run when we get stuck in these cycles of, look, I, I run venture backed startups and so like, you know, we are all looking to build categories and to think about how we can create space between us and, and whoever it is we're trying to compete against in the market.

I think the platform engineering movement as a piece of product marketing is kind of brilliant, right? And it's, and it has and it made a lot of noise. Cuz here we are talking about it on tech strong tv.

Sure. You know what I mean? Like, like we're we're talking about platform engineering cuz they put out a thing that was like, DevOps is dead and there's a f*****g tombstone and you know, like Yeah.

The whole thing, you know, the whole thing happened and here we are talking about it. And so like that marketing worked. I think the risk is, if you look at how, what the world was like when pred DevOps, it looked a lot like the description that they tend to make of how platform engineering is gonna work.

It said, look, devs don't want to have to think about infrastructure. So what we're gonna do is separate devs from operations people, and we're gonna say that the barrier between them is the deployment system and, and anything beneath the deployment system is opsis problem. Anything above the deployment system is devs problem, which cheers.

That's how it was. And you know, what we did to make that work? We built platforms that, that automatically deployed the code from our application developers onto all of our stuff.

That's what we did. And it was not better. It was worse because those developers were isolated from the impacts of their changes.

The operations people were isolated from what was happening in the application. Like we know it's worse. It, it was manifestly worse.

And, and to make it even weirder, we're still not talking in the platform engineering sense. We're rarely talking about changing the fundamental paradigm of the workflow. We're actually just saying, let's take the existing workflow we're doing and put another layer on top of it so you have even less visibility into what's actually happening.

You have even less capacity for control. You have like, I don't get it. I mean, I get it.

Well, no, to me, I get it. It's like, Let's party party like it's 1999, But it's, but we're 1999 ing it and Right. And we're at the risk of throwing away the part of DevOps that always matters 20 Years.

That's what we're, Yeah. And, and the part that, and, and look, if you never experienced how it used to be, I get it, it is an appealing idea to imagine that what we're doing is like living in a factory and, and the way this should work is that their thing is upstream of my thing. You know, the developer is upstream of my downstream DevOps problem, but mm-hmm.

It's not actually the correct model for what we do. What we do is much more like art. It's much more like professional sports, like building and shipping high quality production software all the time is much closer to a soccer game than a factory.

And, and, and people that's a great analogy. And, and people need we, but we don't have tools that allow us to play it that way. Right?

Only the best people in the world wind up with flows that work that way because they invest all this time and money and they make a bunch of really tiny decisions that sort of get them where they need to go. And so I think about what I think is necessary is less like a platform engineering revolution, although the idea that you need an interface that works semantically for your job, of course. Right?

So like, don't get me wrong, I'm not saying that you don't want a developer to be able to like deploy easily. Of course you do. Mm-hmm.

Right? Of course you do. Um, but I think in order to really change the outcomes to really alter the trajectory of what these out enterprises are doing, we need a second wave of DevOps innovation.

Like we just really fundamentally need, need people to try crazy new things. Like we need people to be like, Hey, what if it worked this way, not that way. And, or, you know, what if, what if, you know, like the queue folks I think are a great example of this.

Like I count them in this second wave because like, there's a really foundationally interesting question at the heart of Q, which is how do I, what if everything was just configuration and we built a language whose only job was to, to let you manage configuration at scale in like really dynamic and interesting ways that we've never seen before. That's an, that's an interesting, that's a super interesting angle. Yeah.

It's not a riff on something we've seen before. It is a new thing. Is it gonna work?

I have no idea. Um, is it better? No.

But if you dunno, if it doesn't work, you'll, you'll fail and learn And we'll, but we'll something and we'll learn something new, Try something else. And and I think right now we're sort of stuck as a movement in the recognition that we know what happens if we pick up the DevOps handbook and we like roll through it roughly the way we've been rolling through it the last 15 years, which is 88% of us roughly per the tour report. We'll be stuck with mediocre outcomes and it's not good enough and we gotta fix it.

Um, and I don't think we fix it by throwing away our shared aspirations for how we should work or what brings about good outcomes. We have a lot of evidence that good outcomes come from collaboration, that it does come from pushing people closer together. It does come from from that, that ability for a developer if they need it to understand the details of what the infrastructure is and for an infrastructure person to understand the details of the application when they, when and how they need it.

I, I think that's obvious that that can't die. And, and if we let it shame on us, You know, a lot of this, Adam listening to you and it kind of, as always you talk and I I I, it just opens my mind up to, to concepts and things that I, I haven't really thought about in this way. But a lot of this goes to education and how we learn and how we do things.

So, you know, a lot of education today is kind of monkey see, monkey do, right? And so when we look at, okay, how did do DevOps write? We tend to wanna blueprint and, and we want a formula that says, okay, we do step one, we do step two, we do step three, do step four equals step five.

Step five plus step six equals step seven. And if we just follow that rote formula, we'll have DevOps nirvana. Mm-hmm.

But it doesn't, real life doesn't work like that, right? Because we are playing soccer, we're not building a model car or a model airplane here. We could learn from those steps, but the innovation and the improvisation Yeah.

Is kind of what makes it special and what make what advances the ball, Right? Yeah. Yeah.

I think the trick is that, um, that that there's this idea ofs Hari, right? Which is basically the, the an idea of like how, how you move through learning toward mastery. Mm-hmm.

Right? So, you know, when you're at the early stages of anything, you know, how do you learn to play, how do you learn to play soccer, football if you're European? Like there's, there are fundamental skills that you must practice and, and that you shouldn't try to innovate on.

Like if you don't know how to dribble a soccer ball, you shouldn't try to innovate your way to soccer, to dribbling, you should like learn to dribble and you should like, like that's the, you should just figure it out. Um, and then eventually if you've mastered it, now you can start to get weird. You know, you wanna be innovative with your dribbling great.

What you gotta do first is just, but You need those underlying skills, Man, get me, get me those fundamentals solid. Right? And, and, and I think what we tend to do when we talk about, part of why I think this is a workflow and an experience problem is if the thing that number, if the number one thing that brings about better outcomes is people collaborating with each other more often, then what we need to get you doing by default on the first day is collaborating with people more often.

And instead what we do is go great day one, what are you gonna do? Well, let's set up, let's set up a Git repository. We'll put some infrastructures code in there, we'll package the application up.

We're gonna build a continuous delivery pipeline. We're doing, let's build some ci, then we'll do maybe some GI ops. We gotta deploy that thing to Kubernetes.

Like we run down the list of all the stuff you gotta do. All that stuff happens before we start talking to each other. Yeah.

Before we start really collaborating mm-hmm. We're gonna, we're gonna, when all this stuff happens, then maybe you can talk to each other and then where do we talk to each other? Well, code review.

Yeah. And like it's in the name, it's not code collaboration, it's review. Somebody did it and I looked at it after the fact.

Mm-hmm. And like, like in, in part of what I learned in those engagements that I used to do at Chef was that, that I could actually really fundamentally alter the trajectory of how teams worked by basically making them collaborate on the f I would just show up and be like, okay, I, all of the way you work is thrown out the window. Here's how you're gonna work for the next four weeks.

You're just gonna do it this way and you're gonna practice. And at the end you'll know how it works and, and then you'll know how to take it into your, into your environment and, and continue to do it or not because I'm gone anyway. So if you don't like it, like what'd you lose?

And it turns out you can really teach people in a couple of weeks like how to work this way. Um, cuz it's not that hard. Mm-hmm.

But it is hard if you don't know how to stitch it all together. It is hard if you don't know what the roadmap is or you don't know what the fundamental skills are, it is hard. Right.

If you don't have those building block skills, let's call 'em building block. That's what you need. Adam, I only got a little time left.

I want to bring this back to system initiative now. Mm-hmm. How do you help, how, how does system initiative help with this?

Yeah, so System Initiative helps with this by rethinking that user experience from the jump. So what we basically do is we let you rather than like do infrastructure as code where you write it all down and then sort of run it and get a plan and then hope that it works. Instead, we build a simulation.

So we build like a one-to-one model of the resources that exist in a w s and then we let you compose those models together and the, and then they intelligently configure each other. So you can say, Hey, I have a Docker image that needs to run on Core os which then needs to run on an e c two instance. You can visually link those models together.

And what's happening under the hood is it's a bunch of functions that are generating configuration for you. So it knows how to like translate from the model of a Docker image to the model of a core os configuration to the model of an e c two user data. Um, and then that simulation can give you immediate feedback on what you're doing because it doesn't actually have to go into the real world.

It's a simulator, right? It's, it, it actually can just say, Hey, this looks good or it looks bad. And then you can extend it by writing JavaScript code that describes your policy.

So if you wanna say, Hey, in our environment we can only use Docker images from our, our internal registry, for example. Um, you can just write a qualification rule that you can apply to all Docker images and it will tell you in real time if you try to use a Docker image that isn't in the right registry, um, uh, and all that happens in a multiplayer ui, so you can actually come join me. We can together do it in real time together.

Like you would watch with a designer working in Figma. Um, that's system initiative in a nutshell. And right now it's very early, so we're about to open source it.

Um, and you know, the, what we've got is, is we think the foundations of a really different workflow, um, and a really different way of working. And it's kind of ready for people who, who love this stuff, um, to come and have a play and to collaborate with us on figuring out like how, what, what are the right ways to evolve from the foundation we've laid to, to really changing how people do this kind of DevOps work. I love it.

com? com. com.

I n I t. Yeah. That's funny.

The first company I helped take public that was our ticker symbol in it. I n I t. It was inter reliant.

Nice. But we were in it. Yeah.

com and It was crazy times. It was crazy times. But that's why I'm here today anyway, Adam, always a joy to have you on here.

Thank you so much. Best of luck with System Initiative. com.

Go check it out. When, when do you think like the, the, uh, open source and stuff will be out? Yeah, I mean, I'm, I'm hoping, you know, I'd love it to be the shortest Right now it's in a closed beta so you can mm-hmm.

You can come sign up and we are letting people in. Um, uh, but, uh, but it's, but it's, you know, right now it's pretty ready for like a developer. Like, you gotta be wanting to like, check out the source code and compile it yourself.

Like it's a little rough. It's a little rough and tumble, but, um, it'll be, uh, it'll be ready, um, hopefully soon. So like the, as soon as I can get it done.

So like, if I can get it done next week, I'm shipping it. So like, Yeah. So you promised to come back though when it is and let us all know.

Oh, hell yeah. All right. That's what I needed.

Hey Adam, best of luck, man. Be in, be we'll be in touch for sure. And keep up.

Thanks. Keep it up. It's a pleasure.

All right, Adam Jacob system initiative here on Textron tv. We're gonna take a break. We'll be right back.