Automating in Pre-Container Times with Michael DeHaan

• Speaking Tech: https://michaeldehaan.substack.com/
• michaeldehaan.net: https://michaeldehaan.net
• Twitter: https://twitter.com/laserllama

Transcript

Announcer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.

Corey: This episode is sponsored by our friends at Revelo. Revelo is the Spanish word of the day, and its spelled R-E-V-E-L-O. It means “I reveal.” Now, have you tried to hire an engineer lately? I assure you it is significantly harder than it sounds. One of the things that Revelo has recognized is something I’ve been talking about for a while, specifically that while talent is evenly distributed, opportunity is absolutely not. They’re exposing a new talent pool to, basically, those of us without a presence in Latin America via their platform. It’s the largest tech talent marketplace in Latin America with over a million engineers in their network, which includes—but isn’t limited to—talent in Mexico, Costa Rica, Brazil, and Argentina. Now, not only do they wind up spreading all of their talent on English ability, as well as you know, their engineering skills, but they go significantly beyond that. Some of the folks on their platform are hands down the most talented engineers that I’ve ever spoken to. Let’s also not forget that Latin America has high time zone overlap with what we have here in the United States, so you can hire full-time remote engineers who share most of the workday as your team. It’s an end-to-end talent service, so you can find and hire engineers in Central and South America without having to worry about, frankly, the colossal pain of cross-border payroll and benefits and compliance because Revelo handles all of it. If you’re hiring engineers, check out revelo.io/screaming to get 20% off your first three months. That’s R-E-V-E-L-O dot I-O slash screaming.

Corey: This episode is sponsored in part by LaunchDarkly. Take a look at what it takes to get your code into production. I’m going to just guess that it’s awful because it’s always awful. No one loves their deployment process. What if launching new features didn’t require you to do a full-on code and possibly infrastructure deploy? What if you could test on a small subset of users and then roll it back immediately if results aren’t what you expect? LaunchDarkly does exactly this. To learn more, visit launchdarkly.com and tell them Corey sent you, and watch for the wince.

Corey: Once upon a time, Docker came out and change an entire industry forever. But believe it or not, for many of you, this predates your involvement in the space. There was a time where we had to manage computer systems ourselves with our hands—kind of—like in the prehistoric days, chiseling bits onto disk and whatnot. It was an area crying out for automation, as we started using more and more computers to run various websites. “Oh, that’s a big website. It needs three servers now.” Et cetera.

The times have changed rather significantly. One of the formative voices in that era was Michael DeHaan, who’s joining me today, originally one of the—or if not the creator of Cobbler, and later—for which you became better known—Ansible. First, thanks for joining me.

Michael: Thank you for having me. You’re also making me feel very, very old there. So, uh, yes.

Corey: I hear you. I keep telling people, I’m in my mid-30s, and my wife gets incensed because I’m turning 40 in July. But still. I go for the idea of yeah, the middle is expanding all the time, but it’s always disturbing talking to people who are in our sector, who are younger than some of the code that we’re using, which is just bizarre to me. We’re all standing on the backs of giants. Like it or not, one of them’s you.

Michael: Oh, well, thank you. Thank you very much. Yeah, I was, like, talking to some undergrads, I was doing a little bit of stuff helping out my alma mater for a little bit, and teaching somebody the REST lecture. I was like, “In another year, REST is going to be older than everybody in the room.” And then I was just kind of… scared.

Corey: Yeah. It’s been a wild ride for basically everyone who’s been around long enough if you don’t fall off the teeter-totter and wind up breaking a limb somewhere. So, back in the bad old days, before cloud, when everything was no longer things back then were constrained by how much room you had on your credit card like they are today with cloud, but instead by things like how much space you had in the data center, what kind of purchase order you could ram through your various accounting departments. And one of the big problems you have is, great. So, finally—never on time—Dell has shipped out a whole bunch of servers—or HP or Supermicro or whoever—and the remote hands—which is always distinct from smart hands, which says something very insulting, but they seem to be good about it—would put them into racks for you.

And great, so you’d walk in and see all of these brand new servers with nothing on them. How do we go ahead and configure these things? And by hand was how most of us started, and that means, oh, great, we’re going to screw things up and not do them all quite the same, and it’s just a treasure and a joy. Cobbler was something that you came up with that revolutionized how provisioning of bare-metal systems worked. Tell me about it.

Michael: Yeah, um, so it’s basically just glue. So, the story of how I came up with that is I was working for the Emerging Technologies Group at Red Hat, and I just joined. And they were like, “We have to have a solution to install Xen and KVM virtual machines.” So obviously, everybody’s familiar with, like, EC2 and things now, but this was about people running non-VMware virtualization themselves. So, that was part of the problem, but in order to make that interesting, we really needed to have some automation around bare-metal installs.

And that’s PXE boot. So, it’s TFTP and DHCP protocol and all that kind of boring stuff. And there was glue that existed, but it was usually humans would have to click on buttons to—like Red Hat had system-config-netboot, but what really happened was sysadmins all wrote their own automation at, like, every single company. And the idea that I had, and it was sort of cemented by the fact that, like, my boss, a really good guy left for another company and I didn’t have a boss for, like, a couple years, was like, I’m just going to make IRC my boss, and let’s get all these admins together and build a tool we can share, right?

So, that was a really good experience, and it’s just basically gluing all that stuff together to fully automate an install over a network so that when a system comes on, you can either pick it out from a menu; or maybe you’ve already got the MAC address and you can just say, “When you see this MAC address, go install this operating system.” And there’s a kickstart file, or a preseed in the case of Debian, that says, “When you’re booting up through the installer, basically, here’s just the answers and go do these things.” And that install processes a lot slower than what we’re used to, but for a bare-metal machine, that’s a pretty good way to do it.

Corey: Yeah, it got to a point where you could walk through and just turn on all the servers in a rack and go out to lunch, come back, they would all be configured and ready to go. And it sounds relatively basic the way we’re talking about it now, but there were some gnarly cases. Like, “When I’ve rebooted the database server, why did it wipe itself and reprovision?” And it’s, “Oh, dear.” And you have to make sure that things are—that there’s a safety built into these things.

And you also don’t want to have to wind up plugging in a keyboard and monitor to all of these individual machines one-by-one to hit yes and acknowledge the thing. And it was a colossal pain in the ass. That’s one of the things that cloud has freed us from.

Michael: Yeah, definitely. And one of the nice things about the whole cloud environment is like, if you want to experiment with those ideas, like, I want to set up some DHCP or DNS, I don’t have to have this massive lab and all the electricity and costs. But like, if I want to play with a load balancer, I can just get one. That kind of gives the experience of playing with all these data center technologies to everybody, which is pretty cool.

Corey: On some level, you can almost view the history of all these things as speeding things up. With a well-tuned Cobbler install, it still took multiple minutes, in some cases, tens of minutes to go from machine you’re powering on to getting it provisioned and ready to go. Virtual machines dropped that down to minutes. And cloud, of course, accelerated that a bit. But then you wind up with things like Docker and it gets down to less than a second. It’s the meantime to dopamine.

But in between the world of containers and bare-metal, there was another project—again, the one you’re best known for—Ansible. Tell me about that because I have opinions on this whole space.

Michael: [laugh]. Yeah. So, how Ansible got started—well, I guess configuration management is pretty old, so the people writing their own scripts, CFEngine came out, Puppet was a much better CFEngine. I was working at a company and I kind of wanted another open-source project because I enjoyed the Cobbler experience. So, I started Ansible on the side, kind of based on some frustrations around Puppet but also the desire to unify Capistrano kind of logic, which was like, “How do I push out my apps onto these servers that are already running,” with Puppet-style logic was like, “Is this computer’s firewall configured directly? And is the time set correctly?”

And you can obviously use that to install apps, but there’s some places where that blurred together where a lot of people are using two different tools. And there’s some prior art that I worked on called Funk, which I wrote with Seth Vidal and Adrian Likins at Red Hat, which was, like, 50% of the Ansible idea, and we just never built the config management layer on top. So, the idea was make something really, really simple that just uses SSH, which was controversial at the time because people thought it, like, wouldn’t scale, because I was having trouble with setting up Puppet security because, like, it had DNS or timing issues or whatever.

Corey: Yeah. Let’s dive in a bit to what config management is first because it turns out that not everyone was living in the trenches in quite the same way that we were. I was a traveling trainer for Puppet for a summer once, and the best descriptor I found to explain it to people who are not in this space was, “All right, let’s say that you go and you buy a new computer. What do you do? Well, you’re going to install the applications you’d like to use, you’re going to set up your own user account, you’re going to set your password correctly, you’re going to set up preferences, copy some files over so you have the stuff you care about. Great. Now, imagine you need to do that to a thousand computers and they all need to be the same. How do you do that?” Well, that is the world of configuration management.

And there was sort of a bifurcation there, where there was the idea of, first, we’re going to have configuration management that just describes what the system should look like, and that’s going to run on a schedule or whatnot, and then you’re going to have the other side of it, which is the idea of remote execution, of I want to run an arbitrary command on this server, or this set of servers, or all the servers, depending upon what it is. And depending on where you started on the side of that world, you wound up wanting things from the other side of that space. With Puppet, for example, is very oriented configuration management and the question became, well, can you use this for remote execution with arbitrary commands? And they wound up doing some work with Mcollective, which was a very complicated and expensive way to say, “No, not really.” There was a need for things that needed to hang out in that space.

The two that really stuck out from that era were Ansible, which had its wild runaway success, and the one that I was smacking around for a bit, SaltStack, which never saw anywhere approaching that level of popularity.

Michael: Yeah, sure. I mean, I think that you hit it pretty much exactly right. And it’s hard to say what makes certain things take off, but I think, like, the just SSH approach was interesting because, well for one, everybody’s running it. But there was this belief that this would not scale. And I tried to optimize the heck out of that because I liked performance, but it turns out that wasn’t really a business problem because if you can imagine you just wrote this little bit of automation, and you’re going to run it against your entire infrastructure and you’ve got 30,000 machines, do you want that to—if you were to, like, run an update command on 30,000 machines at once, you’re going to DDoS something. Definitely, right?

Corey: Yeah. Suddenly you have 30,000 machines all talk to the same things at the same times. And you want to do them in batches or smear it across.

Michael: Right, so because that was there, like, you just add batch support in Ansible and things are fine, right? People want to target little small groups of things. So, like, that whole story wasn’t true, and I think it was just a matter of testing this belief that everybody thought that we needed to have this whole network of things. And honestly, Salt’s idea of using a message bus is great, but we took a little bit different approach with YAML because we have YAML variables in it, but they had something that compiled down to YAML. And I think those are some differences in the dialect and some things other people preferred, but—

Corey: And they use Jinja, at one point to wind up making it effectively Turing complete; you could wind up having this ridicu—like, loop flow control and loops and the rest. And it was an interesting exposure to things, but yikes, at some l—at the same time.

Michael: If you use all the language features in anything you can make something complicated, and too complicated. And I was like, I wanted automation to look like grocery lists. And when I started out, I said, “Hey, if anybody is doing this all day, for a day job, I will have failed.” And it clearly shows you that I have because there are people that are doing that all day. And the goal was, let me concentrate on dev and ops and my other things and keep this really, really simple.

And some people just, like, get really, really into that automation technology, which is—in my opinion—why some of the earlier stuff was really popular because sysadmin were bored, so they see something new and it’s kind of like a Java developer finding Perl for the first time. They’re like, “I’m going to use all these things.” And they have all their little widgets, and it gets, like, really complicated.

Corey: The thing that I always found interesting and terrifying at the same time about Ansible was the fact that you did ride on top of SSH, which is great because every company already had a way of controlling access by SSH to IT systems; everyone uses it, so it has an awful lot of eyes on the security protocol on the rest. The thing that I found terrifying in the early days was that more or less every ops person would wind up checking this out onto their laptop or whatnot, so whenever they wanted to run something, they would just run it from their laptop over a VPN or whatnot from wherever they happen to be, and you wind up with a dueling banjos type of circumstance where people were often not doing it from a centralized place. And in time, best practices emerged where, okay, that is going to be the command and control server where that runs at, and you log into it. And then you start guarding that with CI/CD flows and the rest. And like anything else, it wound up building some operational approaches to it.

Michael: Yeah. Like, I kind of think that created a problem that allowed us to sell a product, right, which was good. If you knew what you were doing, you could use Jenkins completely and you’d be fine, right, if you had some level of discipline and access control, and you wanted to wire that up. And if you think about cloud, this whole, like, shadow IT idea of, “I just want to do this thing, therefore I’m going to get an Amazon account,” it’s kind of the same thing. It’s like, “I want to use this config management, but it’s not approved. Who can stop me?” Right?

And that kind of probably got us in the door in few accounts that way. But yeah, it did definitely create the problem where multiple people could be running things at the same time. So yeah, I mean, that’s true.

Corey: And the idea of, “Hey, maybe I should be controlling these things in Git,” or some other form of version control was sort of one of those evolutionary ideas that, oh, we could treat this like code. And the early days of DevOps, that was a controversial thing. These days, you say you’re not doing it and people look at you very strangely. And things were going reasonably well in that direction for a while. Then this whole Docker thing showed up, where, well, what if instead of having these long-lived servers where you have to install updates and run patches and maintain a whole user list on them, instead you had this immutable infrastructure that every time there was a change, you would just go ahead and deploy a brand new set of servers?

And you could do this in the olden days with virtual machines and whatnot; it just took a long time to push things out, so do I really want to roll the entire fleet for a two-line config change? Probably not, so we’re going to batch it up, or maybe do this hybrid model. With Docker, it takes less than a second to wind up provisioning the—switching over to the new container series and you’re done; you can keep going with that. That really solved a lot of these problems.

But there were companies that, like, the entire configuration management space, who suddenly found themselves in a really weird position. Some of them tried to fight the tide forever and say, “Oh, this is terrible because it means we don’t have a business model anymore.” But you can only fight the future for so long. And I think today, we’d be hard-pressed to say that Docker hasn’t won, on some level.

Michael: I mean, I think it has, like, the technology has won. But I guess the interesting thing is, config management now seems to be trying to pivot towards networking where I think the tool hasn’t ever been designed for networking, so it’s kind of a round peg, square hole. But it’s all people have that unless they’re buying something. Or, like, deploying the undercloud because, like, people are still running essentially clouds on top of clouds to get their Kubernetes deployments going and those are monstrous. Or maybe to deploy a data layer; like, I know Kafka has gotten off of ZooKeeper, but the Kafka-ZooKeeper thing—and I don’t remember ZooKeeper [unintelligible 00:14:37] require [unintelligible 00:14:38] or not, but managing those sort of long, persistent implications, it still has a little bit of a place where it exists.

But I mean, I think the whole immutable systems idea is theoretically completely great. I never was really happy with the whole Docker development workflow, and I think it does create a problem where people don’t know what they’re deploying and you kind of encourage that to where they could be deploying different versions of libraries, or—and that’s kind of just a problem of the whole microservices thing in general where, “Did somebody change this?” And then I was working very briefly at one company where we essentially built a whole dashboard to detect service versions and what version of the base image everybody was on, and all these other things, and it can get out of hand, too. So, it’s kind of like trading some problems for other problems, I think to me. But in general, containerization is good. I just wished the management glue around it was easy, right?

Corey: I wound up giving a talk at a conference a while back, 2015 or so, called, “Heresy in the Church of Docker,” and it was a throwaway five-minute lightning talk, and someone approached me afterwards with, “Hey, can you give the full version of that at ContainerCon?” “There’s a full version? Yes. Yes, I can.” And it talked about a number of problems with the management layer and the rest.

Now, Kubernetes absolutely solves virtually every problem that I identified with it, but when you look at the other side of it, getting Kubernetes rolled out is effectively you get to cosplay being a cloud provider yourself. It is incredibly complicated, and of course, we’re right back to managing it all with YAML.

Michael: Right. And I think that’s an interesting point, too, is I don’t know who’s exactly responsible for, like, the YAML explosion. And I like it as a data format; it’s really good for humans. Cobbler originally used it more of an internal storage, which I think was a mistake because, like, even—I was trying to avoid setting up a database at the time, so—because I knew if I had to require setting up a database in 2007 or 2008, I’d get way less users, so it used flat files.

A lot of the YAML dialects people are developing now are very, very nested and they requires, like, loading a webpage, for the Docks, like, all the time and reading what’s valid here, what’s valid there. I think people learn the wrong lesson from Ansible’s YAML usage, right? It was supposed to be, like, YAML’s good for things that are grocery lists. And there’s a lot of places where I didn’t do a good job. But when you see methods taking 15 parameters and you have to constantly have the reference up, maybe that’s a sign that you should do something else.

Corey: At least you saved us, on some level, from having to do this all in XML. But still, there are wrong ways and more wrong ways to do it. I don’t think anyone could ever agree on the right way to approach these things.

Michael: Yeah. I mean, and YAML, at the time was a good answer because I knew I didn’t want to write and maintain a parser as, like, a guy that was running a project. We had a lot of awesome contributors, but if I had to also maintain a DSL, not only does that mean that I have to write the code for this thing—which I, you know, observed slowing down some other projects—but also that I’d have to explain it to people. Looking kind of like Bash was not a bad thing. Not having to know and learn something, so you can kind of feel really effective in about 15 minutes or something like that.

Corey: One of the things that I find really interesting about you personally is that you were starting off in a bare-metal world; Ansible was sort of wherever you wanted to run it. Great, as long as there are systems that can receive these things, we’re great. And now the world has changed, and for better or worse, configuration management slash remote execution is not the problem it once was and it is not a best practice way of solving a lot of those problems either. But you aren’t spending your time basically remembering the glory years. You’re actively moving forward doing some fairly interesting stuff. How would you describe what you’re into these days?

Michael: I tried to create a few projects to, like, kind of build other systems management things for the same audience for a while. I was building a build server and a new—trying to do some next-gen config stuff. And I saw people weren’t interested. But I like having conversations with people, right, and I think one of the lessons from Ansible was how to explain highly technical things to technical audiences and cut out a lot of the marketing goo and all that; how to get people excited about an idea and make a community be really authentic. So, I’ve been writing about that for really, it’s—rebooted blog is only a couple of weeks old. But also kind of trying to do some—helping out companies with some, like, basic marketing kind of stuff, right?

There’s just this pattern that everybody has where every website starts with this little basic slogan and two buttons and then there’s a bunch of adjectives, but it doesn’t say anything. So, how can you have really good documentation, and how can you explain an idea? Because, like, really, the reason you’re in it is not just to sell stuff, but it’s to help people and to see them get excited about your ideas. And there’s just, like, we’re not doing a good job in this, like, world where there’s thousands upon thousands of applications, all competing at once to, like—how do you rise above that?

Corey: And that’s always the hard part is at some point, this does become your identity and you become known for a thing. And when you start branching out from that thing, you bring the expertise from that area that you were in, but you start applying it to new things. I feel like so many companies get focused—and people get focused—on assuming that their audience is just like them, where they’re coming in with the exact same biases, the exact same experiences. And given that basically no one was as deep in the weeds as you were when it came to configuration management, that meant that you were spending time in that side of the world, not in other pursuits which aligned in some ways more directly with people developing other things. So, I suspect this might be one of the weird things we have in common when we show up and see something new.

And a company is really excited. It’s like, it’s basically a few people talking [unintelligible 00:20:12] that both founders are technical. And they’re super excited about something they can’t quite articulate. And it’s this, “Slow down. Tell me exactly what it is your product does.” And that’s a hard thing to do because my default response was always the if I don’t understand that is clearly the way in which I am deficient somehow. But marketing is really about clear communication and there’s not that much of it in our space, at least not for early-stage companies.

Michael: Yeah, I don’t know why that is. I mean, I think there’s this belief in that there’s, like, this buyer audience where there’s some vice president that’s going to buy your stuff if you drop the right buzzwords. And 15 years ago, like, you had to say ‘synergy,’ and now you say ‘time to value’ or ‘total cost of ownership’ or something. And I don’t think that’s true. I mean, I think people use products that they like and that they need to be shown them to try them out.

So like, why can’t your webpage have a diagram and a screenshot instead of this, like, picture of a couple of people drinking coffee around a computer, right? It’s basic stuff. But I agree with you, I kind of feel dumb when I’m looking at all these tech products that I should be excited about, and, like, the way that we get there, as we ask questions. And the way that I’ve actually figured out what some of these things do is usually having to ask questions from someone who uses them that I randomly find on my diminishing circle of friends, right? And that’s kind of busted.

So, Ansible definitely had a lot of privilege in the way that it was launched in the sense that I launched it off Cobbler list and Cobbler list started off of [ET Management Tools 00:21:34] which was a company list. But people can do things like meetup groups really easily, they can give talks, they can get their blogs reblogged, and, you know, hope for some Hacker News or Reddit juice or whatever. But in order to get that to happen, you have to be able to talk to engineers that really want to know what you’re doing, and they should be excited about it. So, learn to talk to them.

Corey: You have to speak their language but without going so deep in the weeds that the only people that understand it are the folks who are never going to use your product because they want to build it themselves. It’s a delicate balance to strike.

Michael: And it’s a difficult thing to do, too, when you know about it. So, when I was, like, developing all the Ansible docs, I’ve told people many times—and I hope it’s true—that I, like, spent, like, 40% of my time just on the website and the docs, and whenever I heard somebody complain, I tried to fix it. But the idea was like, you can lose somebody really fast, but you kind of have to forget what you know about the product. So, the worst person to sometimes look at that as the person that built it. So, you have to forget what you know, and try to see, like, what questions they’re asking, what do they need to find out? How do they want to learn something?

And for me, I want to see a lot of pictures. A lot of people write a bunch of giant walls of text, or worse for me is when there’s just these little pithy expressions and I don’t know what they mean, right? And everybody’s, like, kind of doing that these days.

Corey: This episode is sponsored in part by our friends at ChaosSearch. You could run Elasticsearch or Elastic Cloud—or OpenSearch as they’re calling it now—or a self-hosted ELK stack. But why? ChaosSearch gives you the same API you’ve come to know and tolerate, along with unlimited data retention and no data movement. Just throw your data into S3 and proceed from there as you would expect. This is great for IT operations folks, for app performance monitoring, cybersecurity. If you’re using Elasticsearch, consider not running Elasticsearch. They’re also available now in the AWS marketplace if you’d prefer not to go direct and have half of whatever you pay them count towards your EDB commitment. Discover what companies like Equifax, Armor Security, and Blackboard already have. To learn more, visit chaossearch.io and tell them I sent you just so you can see them facepalm, yet again.48]

Corey: One thing that I’ve really found myself enjoying recently has been your substack-based newsletter, Speaking Techis what you call it. And I didn’t quite know what to expect when I signed up for it, but it’s been a few weeks now, and you are more or less hitting across the board on a bunch of different things, ranging from engineering design patterns, to a teardown of random company’s entire website from a marketing and messaging perspective—which I just adore personally; like that is very aligned with how I see the world—

Michael: There’s more of that coming.

Corey: Yeah, [unintelligible 00:23:17] a bunch of other stuff. Let’s talk about, for example, the idea of those teardowns. I always found that I have to be somewhat careful in how I talk about it when I’m doing a tweet thread or something like that because you are talking about people’s work, let’s be clear here, and I tend to be a lot kinder to small, early-stage companies than I am to, you know, $1.6 trillion companies who really should have solved for this by now, on some level. But so much of it misses the mark of great, here’s the way that I think about these things. Here’s the way that I don’t understand what the hell you’re telling me.

An easy example of this for me, at least I’m curious to get your thoughts on it, I tend to almost always just skim what they’re saying, great. Let’s look at the pricing page because I find that speaks to people in a way that very often companies forget that they’re speaking to customers.

Michael: Yeah, for sure. I always tried to find the product page lately, and then, like, the product page now is, like, a regurgitation of the homepage. But it’s what you said earlier. I think I try to stay nice to everybody, but it’s good to show people how to understand things by counterexample, to some extent, right? Like, oh, I’ve got some stuff coming out—I don’t know when this is actually going to get published—but next week, where I was like just taking random snippets of home pages, and like, “What’s everybody doing with the header these days?”

And there’s just, like, ridiculous amounts of copying going on. But it’s not just for, like, people’s companies because everybody listening here isn’t going to have a company. If you have a project and you wanted to get it noticed, right, I think, like, in the early days, the projects that I paid attention to and got excited about were often the ones that spend time on their website and their messaging and their experience. So, everybody kind of understands you have to write a good readme now but some of, like, the early Ruby crowd, for instance, did awesome, awesome web pages. They know how to pick out fonts, and I still don’t know how to pick out fonts. But—

Corey: I ask someone good at those things. That’s how I pick ‘em.

Michael: Yeah, yeah. That’s not my job; get somebody that’s good at that. But all that matters, right? So, if you do invest a little bit in not promoting yourself, not promoting your company, but trying to help people and communicate to them, you can build that audience around your thing and it makes it a lot more interesting.

Corey: There’s so many great tools out there that I find on GitHub that other people have to either point me to or I find it when I’m looking at it from a code-first perspective, just trying to find a particular example of the library being used, where they do such a terrible job of describing the problem that they solve, and it doesn’t take much; it takes a paragraph or two at most. Or the idea that, “Oh, yeah, here’s a way to do this thing. Just go ahead and get your credential file somewhere else.” Great. Could you maybe link to an example of how to do that?

It’s the basic stuff; assume that someone who isn’t you might possibly want to use this. And I’m not even slightly suggesting that you wind up talking your way through how to do all of that. Just link to somewhere that has a good write-up of it and call it good. Just don’t get in the way of people’s first-time user experiences.

Michael: Yeah, for sure. And—

Corey: For some reason, that’s a radical thought.

Michael: Yeah, I think one of the things the industry has—well, not the industry; it’s not their problem to solve, but, like, we don’t really have a way for people to find what’s cool and interesting anymore. So, various people have their own little lists on GitHub or whatever, but there’s just so many people posting on the one or two forums people read and it goes by in a day. So, it’s really, really hard to get attention. Even your own circle of followers isn’t really logging into Twitter or anything, or LinkedIn. Or there’s all the congratulations for your five years of Acme Corp kind of posts, and it’s really, really hard to get attention.

And I feel for everybody, so like, if somebody like GitHub or Microsoft is listening, and you wanted to build, like, a dashboard of here’s the cool 15 projects for the week, kind of thing where everybody would see it, and start spotlight some of these really cool new things, that would be awesome, right?

Corey: Whenever you see those roundups, that was things like Kubernetes and Docker. And great, I don’t think those projects need the help in the same way.

Michael: No, no, they don’t. It’s like maybe somebody’s cool data thing, or a cool visualization, or the other thing that’s—it’s completely random, but I used to write fun graphics programs for fun or games and libraries. And I don’t see that anymore, right? Maybe if you find it, you can look for it, but the things that get people excited about programming. Maybe they have no commercial value at all, but the way that people discover stuff is getting so consolidated is about Docker and Kubernetes. And everyone’s talking about these three things, and if you’re not Google or you’re not Facebook, it’s really—or Amazon, obviously—it’s hard to get attention.

Corey: Open-source on some level has changed from a community perspective. And part of it is because once upon a time, you could start with the very low-level stuff and build something, get it up and working. And that’s where things like [Cobbler 00:27:44] and Ansible came out of. Now it’s, “Click the button and use the thing everyone else is using. And if you’re not doing that, what are you doing over there?”

So, the idea of getting started tinkering with computers are built on top of so many frameworks and other things. And that’s always been the case, but now it’s much more apparent in some ways. “Okay, I’m going to go ahead and build out my first HTML file and serve it out using something in Node.” “Great, what is those NPM stuff that’s scrolling past?” It’s like, “The devil. That is the devil’s own language you are seeing scroll past. And you don’t need to worry about that; just pretend it’s not there.”

But back when I was learning all this stuff, we’re paying attention to things scrolling past, like, you know, compilation messages and the Linux boot story as it wound up scrolling past. Terrible story; the protagonist was unreliable, but all right. And you start learning how these things work when you start scratching at the things that you’re just sort of hand-waving and glossing over. These days, it feels like every time I use a modern project, that’s everything.

Michael: I mean, it is. And like what, React has, like, 2000 dependencies, right? So, how do you ever feel like you understand it? Or when recruiters are asking for ten years at Amazon. And then—or we find a library that it can only explain itself by being like this other library and requiring these other five.

And you read one of those, and it becomes, like, this… tree of knowledge that you have no way of possibly understanding. So, we’ve just built these stacks upon stacks upon stacks of things. And I tend to think I kind of believe in minimalism. And like, wouldn’t it be cool if we just burned this all and start—you know, we burn the forest and let something new regrow. But we tend to not do that. We just—now running a cloud on top of a cloud, and our JavaScript is thousands of miles high.

Corey: I really wish that there were better paths for getting started. Like, I used to think that the right way to wind up learning how all this stuff work is to do what I did: Start off as, you know, the grumpy sysadmin type, and then—or help desk—and then work your way up and the rest. Those jobs aren’t there anymore, and it doesn’t leave people in a productive environment. “Oh, you want to build a computer game. Great. For an iPhone? Terrific.” Where do you go to get started on that? It’s a hard thing to do.

And people don’t care at that scale, nor should they necessarily, on how to run your own servers. Back in the day when you wanted to have a blog on the internet, you were either reduced to using LiveJournal or MySpace, or you were running your own web server and had to learn how to make sure that it didn’t become an attack platform. There was a learning curve that was fairly steep. Now, there are so many different paths to go down, you don’t really need to know how any of these things even work.

Michael: Yeah, I think, like, one of the—I don’t know whether DevOps means anything as a topic or not, but one of the original pieces around that movement was systems administrators learning to code things and really starting to enjoy it, whether that was Python or Ruby, and so on. And now it feels like we’re gluing all the things together, but that’s happening in App Dev as well, right? The number of people that can build a really, really good library from the ground up, like, something that has C bindings, that’s a really, really small crowd. And most of it, what we’re doing is gluing together other people’s libraries and compensating for the flaws and bugs in them, and duct tape and error handling or whatever. And it feels like programming has changed a lot because of this—and it’s good if you want to get an idea up quickly, no doubt. But it’s a different experience.

Corey: The problem I always ran into was the similar problems I had with doing Debian packaging. It was always the, oh, great, there’s going to be four or five different guides on how to do it—same story with RPM—and they’re all going to be assuming different things, and you can crossover between them without realizing it. And then you just do something monstrous that kind of works until an actual Debian developer shoves you aside like you were a hazard to everyone around you. Let me do it for you. And there we go.

It’s basically, get people to do work for you by being really bad at it. And I don’t love that pattern, but I’m still reminded of that because there are so many different ways to achieve any outcome that, okay, I want to run a ridiculous Hotdog or Not Hotdog style website out there. Great. I can upload things. Well, Docker or serverless? What provider do I want to put it on? And oh, by the way, a lot of those decisions very early on are one-way doors that you don’t realize you’re crossing through, as well as not knowing what the nuances of all of those things are. And that’s dangerous.

Michael: I think people are also learning the vendor as well, right? Some people get really engrossed in whether it’s Amazon, or Google, or HashiCorp, or somebody’s API, and you spend so much of your brain cells just learning how these people’s systems work versus, like, general programming practices or whatever.

Corey: I make it a point to build something on other cloud providers that aren’t Amazon every now and then, just because I don’t want to wind up effectively embracing a monoculture.

Michael: Yeah, for sure. I mean, I think that’s kind of the trend I see with people looking just at the Kubernetes stuff, or whatever, it’s that I don’t think it necessarily existed in web dev; there seems to be a lot of—still a lot of creativity and different frameworks there, but people are kind of… what’s popular? What gets me my next job, and that kind of thing. Whereas before it was… I wasn’t necessarily a sysadmin; I kind of stumbled into building admin tools. I kind of made hammers not houses or whatever, but basically, everybody was kind of building their own tools and deciding what they wanted. Now, like, people that are wanting to make money or deciding what people want for them. And it’s kind of not always the simplest, easiest thing.

Corey: So, many open-source projects now are—for example, one that I was dealing with recently was the AWS CLI. Great, like, I’m thrilled to throw in issues and challenges here, but I’m not going to spend significant time writing code against it because, one, it’s basically impossible to get these things accepted when all the maintainers work at Amazon, and two, is it really an open-source project in the way that you and I think about community and the rest, but it’s basically sole purpose is to funnel money to Amazon faster. Like, that isn’t really a community ethos I feel comfortable getting behind to be perfectly honest. They’re a big company; they can afford to pay people to build these things out, full time.

Michael: Yeah. And GitHub, I mean, we all mostly, I think, appreciate the fact that we can host the Git repo and it’s performant and everything, and we don’t have blazing unicorns quite as often or whatever they used to have, but it kind of changed the whole open-source culture because we used to talk about things on mailing lists, like, what should this be, and there was like an upfront conversation, or it might happen on IRC. And now people are used to just saying, “I’ve got a problem. Fix it for me.” Or they’re throwing code over the wall and it might not be the code or feature that you wanted because they’re not really part of your thing.

So before, people would get really engrossed with, like, just a couple of projects, and if they were working on them as kind of like a collective of people working against different organizations, we’d talk about things, and they kind of know what was going on. And now it’s very easy to get a patch that you don’t want and you’re, like, “Oh, can you change all of these things?” And then somebody’s, like, now they’re offended because now they have to do all this extra work, whereas that conversation didn’t happen. And GitHub could absolutely remodel themselves to encourage those kinds of conversations and communities, but part of the death of open-source and the fact that now it’s, “Give me free code,” is because of that kind of absence of the—because we’re looking at that is, like, the front of a community versus, like, a conversation.

Corey: I really want to appreciate your taking so much time out of your day to basically reminisce about some of these things. But on a forward-looking basis, if people want to learn more about how you see things, where’s the best place to find you?

Michael: Yeah. So, if you’re interested in my blog, it’s pretty random, but it’s michaeldehaan.substack.com. I run a small emerging

consultancy thing off of michaeldehaan.net. And that’s basically it. My Twitter is laserllama if you want to follow that. Yeah, thank you very much for having me. Great conversation. Definitely making all this technology feel old and busted, but maybe there’s still some merit in going back—

Corey: Old and busted because it wasn’t built this year? Great—

Michael: Yes.

Corey: —yes, its legacy, which is a condescending engineering term for ‘it makes money.’ Yeah, there’s an entire universe of stuff out there. There are companies that are still toying with virtualization: “Is this something we get on board with?” There’s nothing inherently wrong with that. I find that judging what a bunch of startups are doing or ‘company started today’ is a poor frame of reference to look at what you should do with your 200-year-old insurance company.

Michael: Yeah, like, [unintelligible 00:35:53] software engineering is just ridiculously new. Like, if you compare it to, like, bridge-building, or even electrical engineering, right? The industry doesn’t know what it’s doing and it’s kind of stumbling around trying to escape local maxima and things like that.

Corey: I will, of course, put links to where to find you into the [show notes 00:36:09]. Thanks again for being so generous with your time. It’s appreciated.

Michael: Yeah, thank you very much.

Corey: Michael DeHaan, founder of Cobbler, Ansible, and oh, so much more than that. I’m Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you’ve enjoyed this podcast, please leave a five-star review on your podcast platform of choice—and/or smash the like and subscribe buttons on the YouTubes—whereas if you’ve hated this podcast, please leave a five-star review on your podcast platform of choice, smash the buttons as mentioned, and leave a loud, angry comment explaining what you hated about it that I will then summarily reject because it wasn’t properly formatted YAML.

Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.

Announcer: This has been a HumblePod production. Stay humble.