App Development Challenges in 2024 with Docker’s Solomon Hykes

This is Textron tv. Hey guys, thanks for the throw. We're here with Solomon.

Hes who's founder for Dagger, and of course famous for his work on Docker to begin with. And we're talking about the challenges that developers are facing in 2024. Solomon, welcome the show.

Thank you. Thanks for having me. I feel like in some ways we have perhaps made one step forward and two steps back some days depending on whether I am optimistic or feeling pessimistic.

Yeah. But I feel like Docker made life simpler on one level, but at the other hand, there's now thousands of these containers running around and people are having a hard time figuring out how to manage the whole thing. A lot of, uh, folks are wondering whether microservices is the right approach, or do we need monoliths and microservices?

And of course, we all do ci and very few of us do cd. So we're trying to figure out how to actually maybe automate the delivery of all these software components. And I wish we made more progress there, but what's your assessment of where we're Yeah, I mean, uh, there are definitely steps backward in involved somewhere.

Um, yeah, it feels like, to me, it feels like we started a process of industrializing the delivery of applications, you know, and we, we will, it's well underway, but it's not finished. And I think right now we're just experiencing that transition from, um, you know, and smaller teams writing smaller applications and, um, more leeway for doing things manually, you know, in a non-standardized way. And now we're all sort of, um, transitioning to way larger software projects that have to ship faster.

They're just a lot more complexity involved. And, uh, I mean, certainly containers contributed to that, you know, like unlocking, making it possible to build bigger things and ship them faster. So we sort of, the, the problem I think was always going to be there.

We just had to get to it first, you know, so I, I think we're just in phase two of this, of this, uh, transition. How does, do we get there? And I'm asking the question because so much of what we do, uh, for DevOps is on the CI side, and it's particularly, you know, generally the developers are managing that part of the process, and then there's the ops side that focuses more on cd.

And I think we tried to tightly couple these things under a single platform, but maybe you, are we gonna be better off loosely coupling them, or, you know, how should we approach this? Yeah, yeah. I think part of the problem is fragmentation, you know, there's just so much choice.

And, um, and the big question is, what, what do I standardize on as an enterprise? You know, as a software organization, what do I rely on not changing? And what do I just assume will change over time in my stack?

Right? And I think in the past as an industry, we've made some wrong bets there. We made a bet on something called PAs, if you remember, where we said, let's just pick the best version of everything and then let, that'll be our big box, and that'll be the whole platform, and then we'll standardize on the whole thing.

And we just sort of let every vendor fight and then when we'll win, and that'll be the winning platform. And that just didn't really happen. Right?

Um, no matter what big paths, big platform you, you bet on, um, almost immediately you start seeing a little custom pieces, uh, appear around it, you know, so everyone just has glue and then more glue, everything's just glued together. Uh, so that, that's, I think that's the crucial problem. What do you standardize on and what do you not, you know, what's a constant, what's a variable?

Um, and if you get that right, then everything else becomes easier. The issue with PAs, as far as I could tell, it was an opinionated platform, but everybody had a different opinion about what the platform should be. So how do we have our cake and eat into, Yeah.

Yeah. I think that's, I, I think of it in terms of, um, uh, I think manufacturing is a good analogy. You know, this is our industrial revolution.

Uh, we're going from little workshops to these, um, more streamlined factories. And ironically, I think the software world is behind the physical world in that sense. You know, um, physical manufacturing is much more, um, is, is much more, um, mature, uh, and, and streamlined than software manufacturing, right?

This is new to us, and because it's virtual, it's okay, we can wing it. You know, we're used to things not being as rigorous, but I think now the scale and criticality of all the software has reached a point where we can't really get away with it. You know?

So, so, okay, what, where's the factory? You know, that's the platform, really. Um, and so I think PAs, you know, like you said, this opinionated platform, that was the equivalent of buying an off the shelf factory.

Someone else designed the perfect factory, and everybody should just buy that factory and use it to manufacture whatever they're building. But, you know, that's not how manufacturing works. Um, you know, Tesla isn't building their cars, they're not manufacturing it with an off the shelf factory.

Designing your, your, your factory is, goes hand in hand with designing your product. So everyone's going to need a custom platform to, to some extent, you know, the question is what building blocks do you assemble it from? You know, it's gotta be cost effective to do it.

And right now everyone is stuck in a, in a, you know, in a awkward middle where they have to choose between, you know, paths the off the shelf factory that will not scale. It will not adapt to your needs. And starting from the ground up and having dozens of engineers just building this custom platform from the ground up, which is in this new world of, um, capital, no longer being free, just not no longer an option, you know, it's, it's too wasteful.

Mm-Hmm. So there's gotta be a middle ground where you build your own factory, but you do it out of modular components, you know, something that you can, uh, snap together. Maybe 80% of it is just common best practices.

You just drop that in and the remaining 20% is yours. You know, you can customize as you go. So that's, I think that's the big challenge of this whole space of, um, you know, application delivery and, and DevOps, We hear the phrase platform engineering all the time.

Mm-Hmm. What's your say? Is that the middle ground?

We're trying to get to The pro when the problem persists long enough, then, um, it outlives any given, uh, buzzword. So I think I don't see a fundamental difference, uh, between, you know, DevOps, SRE, um, platform engineering. I think it's just the, the same, generally the same people trying to solve the same problem and trying again.

And then over time you have, you know, new vendors, um, new people in, in the enterprise trying to put a fresh label in what they're doing. But it's still, yeah, it's, it's, it is definitely relevant. It's the, it's what everyone's trying to do.

I dunno about, um, that there's a specific, uh, you know, Gartner classification with platform engineering, it, you know, and, um, IDP internal developer platforms. And, um, I don't really care about individual market categories, you know, but yeah, building a platform, um, to make your software organization more productive is, is, uh, the problem we're talking about. So Where do you guys fit in that spectrum of buzzwords that we're throwing around out there?

Well, we're focused on the middle, we're focused on the pipelines. You know, I think of this whole industry as, you know, the, the process of shipping apps, really, there's really two big parts to it. There's development, you know, humans write code and increasingly they're getting help from, you know, software to generate the code and all of that.

So you've got the IDE, you've got the collaboration. Um, and then downstream from that, all the way downstream, you've got production, you know, infrastructure to run your compute, run your, your, your databases and, uh, connected at all with high performance networking. And, um, in the middle you've got the pipelines to go from A to B, right?

And my assessment is those two, um, you know, development and production on either side have matured enormously. There's, there's just never been, uh, more choice and, and more high quality tools and services. I mean, cloud infrastructure is just, you know, it can scale to billions of users and you can run your application in a dozen different ways.

Um, and same on the development side, right? Languages, frameworks, et cetera. Um, the problem is in the middle you have a lot of artisanal scripts, a lot of really terrible and old pipeline, so they're just barely holding it together.

And as the, as the choice actually increases, you've got this bottleneck in the middle. It's hard. It's getting harder and harder to keep up because it's really layers and layers of, um, yeah, shell scripts and old yaml and Jenkins files and just this, this unmaintainable mess.

And so sooner or later it breaks, where dagger comes in is we take that mess in the middle, all these artisanal scripts, and we give you a proper platform to turn that into software. So you we're basically, we've reached the point where to ship your application, you need a dedicated application, you need to write code to ship the code, you need to program your factory as software, and we give you the building blocks to do that. Where is that line between art and science in terms of how we build code?

Because people talk about factories, and yet a lot of developers I know are kind of waiting for that inspirational moment to start down and write code, and, you know, they're not really sitting at the end of an assembly line somewhere building a car. So how do we build a factory for something that is a little more craft than pure science? Yeah.

Well, first of all, when I think factory, I think of something entirely automated, right? You've got humans maintaining it and then got humans in the lab upstream designing the software as they should. Um, but there's no as manual assembly line here, right?

That's the problem, um, that we're in today. It's sort of more like a, a workshop today. You gotta assemble a thing by hand.

Um, in order to ship it, you want something fully automated. So I think that the, the problem is in most organizations, you've got a lot of developers, and then you have a very small number of engineers that are responsible for taking their work and shipping it for, for operating that factory, right? And so the dream is to have it fully automated.

The problem is that you're too busy putting out fires and fixing the script and writing just one more script, um, to actually take a step back and design a proper automated factory that will take, you know, the, the next 50, uh, changes that developers ship and run it through a reliable, um, pipeline. You know, so everyone's caught in that, in that, um, in that process. Uh, and so those engineers that are the bottleneck that are severely burned out, a lot of times, um, that's dagger's customer.

We come in and give them a tool to sort of, um, break free of that cycle, you know? Um, and we give, we do that by giving them a way to write code very quickly, very easily, and gradually, not in a big bang re-platform way, just gradually replace one artisanal script at a time with something more robust, right? So gradually they replace the glue with a Lego, you know, something that's more maintainable.

Uh, and that just gives, gives them a sense of control and, um, gradually they can take a, and all of a sudden pipelines, um, you know, have less issues. The, the features developers have been, have been asking for get shipped more quickly and slowly, but surely you just remove that bottleneck. The key is to be pragmatic about it and not, uh, try to do it all at once.

You have to embrace an incremental approach to it. Speaking of embracing incrementally, we have all these different kinds of artifacts out there, including containers, and now we have things coming down the pike like wasm, and we have legacy Java virtual machines, and we also have, um, you know, there's monoliths and microservices. Are we overly obsessed with the architectural issues of the day and, and, and the, and, and our preferences versus they the right thing for the right job at the right time.

I think it happens, but overall, you know, some teams would do that, others are too conservative, others are, you know, find the right balance. So there's a little bit of everything. It, it is just a fast moving industry, you know, that's the fundamental problem of software.

You gotta balance the, the insane pace of change, uh, and the need to, you know, support, uh, support critical systems for a business that can't, you can't change everything every week, right? So that's, I think that's the fundamental challenge of, uh, software teams. So we, um, yeah, our, our, we think of our job as supporting that and not encouraging, um, bad behavior.

You know, ideally a good tool, um, helps you embrace the, the right best practices. Yeah. So based on your experience, what's your best advice to folks out there in terms of achieving that goal and, and rethinking software engineering, but not maybe tearing our hair out as it goes, but, um, how do we stay sane?

Well, I, I would say, um, I would say the most important thing is to, to follow your gut feeling as a, as an, as an operator and as an engineer, you know, especially teams that are in charge of large systems, you know, they, they've, they've dealt with all sorts of issues in the past, you know, um, and a lot of times, um, they have a gut feeling on whether a platform strategy is gonna work or not. The question is, um, is anyone listening, uh, in management? And so, um, you know, it's, it's, I think it's primarily an issue of communication between engineering and management at the end of the day.

Um, it's, it's, uh, it's always a messy process. There's no silver bullet. So if someone's selling you a silver bullet and you think, oh, that seems like it's too good to be true, it's gonna magically sold everything overnight, then that's probably true.

You know? Um, I don't know if I have any useful advice beyond that, you know, uh, I think it does get better. You know, there's a risk of getting jaded and thinking nothing new will ever help.

It's, it only gets worse. You know, sometimes it, if you've had one too many outages and you're out there fixing, fixing that script that just blew up again, it can feel like there's no hope. But I, I do think it does get incrementally better.

You just gotta accept that, uh, you know, it's, um, yeah, one incremental improvement at a time, really. All right. Speaking of silver bullets, will AI save us from ourselves?

What do you think? Yeah, I think that's a good example. I, I, I, I think AI is, is, I think of it as, it's like a new chip coming out with incredible new capabilities.

Uh, it's a component, you know, uh, and it, it op it makes new applications possible, some of which we're seeing, they're obvious, some of which are not obvious. We'll, we'll discover them over the next few years. Uh, so that's exciting and it's real.

It's also, um, it, you know, it's, it's, it's still a component that goes into broader software stack. So AI applications are still applications, um, and DevOps teams are still gonna have to ship them in pipelines and keep them up. You know, they just, now you just have to learn a whole, whole bunch of new, uh, lingo and, uh, new tools and new vendors and new capabilities and, you know, life goes on.

It's, so, it's both an exciting, um, open-ended change and also in, in some other ways, business as usual. You know, that's just, that's what we signed up for in the software industry. Rapid change.

There you go, folks. You heard it here. AI is cool.

And as awesome as it may be, there's really no substitute for common sense. And so, you know, use your gut, use your instincts and follow along as best you can. Solomon, thanks for being on the show.

Thank you. All right. And back to you guys in the studio.