Dominic Holt is CEO of harpoon, a drag-and-drop Kubernetes tool for deploying any software in seconds.

Victoria talks to Dominic about commoditizing DevOps as a capability, coming up with the idea for drag and drop just thinking through how he could do these things in a visual and intuitive way, and using Kubernetes as a base for Harpoon.

Harpoon
Follow Harpoon on Facebook, or LinkedIn.
Follow Dominic Holt on LinkedIn or Twitter.
Follow thoughtbot on Twitter or LinkedIn.

Become a Sponsor of Giant Robots!

Transcript:

VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Dominic Holt, CEO of harpoon, a drag-and-drop Kubernetes tool for deploying any software in seconds. Dominic, thank you for joining me.

DOMINIC: Yeah, of course. Thanks for having me, Victoria.

VICTORIA: Yes, I'm really excited to talk all about what Kubernetes is. And I have Joe Ferris, the CTO of thoughtbot, here with me as well to help me in that process.

JOE: Hello.

VICTORIA: Excellent. Okay, so, Dominic, why don't you just tell me how it all got started? What led you to start harpoon?

DOMINIC: I got into the DevOps space fairly early. It was, I don't know, probably 2012 timeframe, which sounds like not that long ago. But, I mean, DevOps is also still a baby. So I have a software background. And I was starting to figure out how to do the continuous; I guess, automated way of standing up cloud infrastructure for Lockheed Martin at the time because people didn't know how to do that. There weren't a lot of tools available, and nobody knew what DevOps was. And if you said it to somebody, they would have slapped you.

VICTORIA: Aggressive. [laughs]

DOMINIC: [laughs] Maybe not, maybe not. Maybe they'd be nicer about it. But anyway, nobody knew what DevOps was because it wasn't coined yet. And I started realizing that this was not some system administration voodoo. It was just common sense from a software development standpoint. And I ended up leaving Lockheed shortly thereafter and going and working for a small business here in San Diego. And I said, I have no idea what any of this stuff is, but we're going to do it because, in a few years, everybody's going to be doing it because it's common sense. So we did.

We grew quite a large practice in consulting and DevOps, among other things. And predominantly, I was working with the U.S. Navy at the time, and they needed a standardized way to deploy software to aircraft carriers and destroyers, the ships out there in the ocean. And so, I came up with a design for them that used Kubernetes. And we built a pipeline, a CI/CD pipeline, to automatically deploy software from the cloud to Navy ships out in the ocean on top of Kubernetes. And everything worked great. And it was there, and we tested it.

But at the end of the day, handing over the maintenance, what we call day two ops, proved to be troubling. And it never quite made it onto the ships in the way that we wanted. So after that, I did a bunch of consulting with other groups in the Navy, and the Air Force, and Space Force, and all kinds of different groups across the government. And I also started consulting in commercial, fortune 500, startups, everything.

And I just saw that this problem was really pervasive, handling the day two operations. You get everything up and running, but then maintaining it after that was just complicated for people because all of the DevOps implementations are snowflakes. So if you go from Company A to Company B, they look nothing alike. And they may have a lot to do with somebody named Jim or Frank or Bob and how they thought was the best way to do it.

And so, running a DevOps consultancy myself, I just knew how hard it was to find the talent, and how expensive they were, and how hard it was to keep them because everyone else was trying to hire my talent all the time. And I just thought to myself, all of this is completely untenable. Somebody is going to commoditize DevOps as a capability. And what would that look like?

VICTORIA: Right. I'm familiar with the demand for people who know how to build the infrastructure and systems for deploying and running software. [laughs] And I like how you first talked about DevOps, just it being common sense. And I remember feeling that way when I went to my first DevOps DC meetup. I was like, oh, this is how you're supposed to build teams and organizations in a way to run things efficiently and apply those principles from building software to managing your infrastructure.

DOMINIC: Yeah. Well, I had lived the life of an enterprise software developer for quite a while before then. And I had gone through that whole process they talk about in all of DevOps bibles about why it is we're doing this, where the software development team would have their nice, fancy dev laptops. And the operations team with the pagers or whatever would be the ones managing the servers. And the software developers were never really sure exactly how it was going to work in production, but were like; I'm just going to throw it over the fence and see what the ops people do.

And inevitably, the ops people would call us very angrily, and they would say, "Your software doesn't work." And then, of course, we would say that the ops people are all crazy because it works just fine here on my laptop, and they just don't know what they're doing. And, I mean, we would just fight back and forth about this for six months until somebody figured out that we were running the wrong version of some dependency in the software on the ops side, and that's why it didn't work. So that process is just crazy, and nobody in their right mind would want to go through it if they could avoid it.

VICTORIA: Right. I'm sure Joe has had some stories from his time at thoughtbot.

JOE: Yeah, certainly. I was interested by what you said about working with...I think it was Frank, and Ted, and Bob. I've definitely worked with all those people in their own snowflakes. And one of the things that drew me to Kubernetes is that it was an attempt to standardize at least some of the approaches or at least provide anchor points for things like how you might implement networking, and routing, and so on.

I'm interested to hear, you know, for a drag-and-drop solution, even though Kubernetes was meant to standardize a lot of things, there are a lot of different Kubernetes distributions. And I think there are still a lot of Kubernetes snowflakes. I'm curious how you manage to tackle that problem with a drag-and-drop solution to hit the different Kubernetes distributions out there.

DOMINIC: Yeah, I mean, I think you nailed it, Joe. Standing up Kubernetes is a little bit complicated still these days. It's been made a lot easier by a lot of different companies, and products, and open-source software, and things like that. And so I see a lot of people getting up basic Kubernetes clusters these days. But then you look at companies like ARMO that are doing compliance scans and security scans on Kubernetes clusters, and they're making the claim that 100% of the Kubernetes clusters they scan are non-compliant [laughs] and have security issues.

And so that just goes to show you all of the things that one has to know to be successful just to stand up a cluster in the first place. And even when I...like for a client or something, over the years, if I was standing up a Kubernetes cluster and a lot of it was automated, you know, we used Terraform and Ansible, and all the other best practices under the hood. A lot of the response I got back when we handed over a cluster to a client was, "Okay, now what?"

There are still a lot of things you have to learn to maintain that cluster, keep it up to date, upgrade the underlying components of the cluster, deploy the software, configure the software, all those things. And can you learn these things? Absolutely. Like, they're not rocket science, but they're complicated. And it is a commitment that you have to make as an individual if you're going to become proficient in all of these things and managing your own cluster.

And so we were just...we had done this so many times at different companies I had worked with, for different clients, and seeing how all of the different pieces work together and where clients were having problems and what really hung people up. And so I just started thinking to myself, how would you make that easier? How would you make that more available to the pizza guy or an 18-year-old with no formal training that's on a ship in the ocean? And that's why I came up with the idea for drag and drop, just thinking through how can I do these things in a visual way that is going to be intuitive for people?

VICTORIA: Well, I have, obviously, a very thorough understanding of Kubernetes, [laughs] just kidding. But maybe explain a little bit more about to a founder why should they invest in this type of approach when they're building products?

DOMINIC: So I think that's a great question. What I find these days is DevOps is almost a requirement to do business these days in some sort of nimble way. So you have to...whether you're a large enterprise or you're a garage startup, you need to be able to change your software to market forces, to stuff that's happening in the news, to your customers don't like something. So you want to change it to something else quickly or pivot because if something happens, you can get your day in the sun, or you can capitalize on something that's happening.

And so the difficulty is I think a lot of people have an impression that DevOps scripts are sort of like a build once and forget type of thing, and it'll just work thereafter. But it's actually software, and I like to think of software as living organisms. You have to take care of them like they're people, almost because if you don't, they'll become brittle and unhealthy over time. If you have a child, you have to feed them probably multiple times a day, brush their teeth. You got to tuck them in at night. You have to be nice to them. You have to do all the things that you would do with a child.

But with software as well, if you just take the quick route, and quick fix things, and hack, and take shortcuts, eventually, you're going to have a very unhealthy child on your hands, and they're going to have behavior problems. At the end of the day, you have all these DevOps scripts, and they can be quite complex together. And you have to take care of them like they're your own child.

And the problem is you're also taking care of your software products like it's your child. And so now you're taking care of two children. And as somebody that has two children, I can tell you that things become much more complicated when two children are having behavioral problems than just one. And you're at the store, and it's very embarrassing.

So I guess the point is that harpoon is a capability that can basically take care of your second child for you, which is your DevOps deployments. And then you can just focus on the one child that you, I mean, this is turning into a terrible analogy at this point. [laughter] But you should love all of your children equally. But, in this case, you're looking to take care of your products and get it out there, and harpoon is something that can take care of your DevOps software for you.

VICTORIA: I agree. I think when your software or children are problematic, it's more than just embarrassing sometimes. It can create a lot of financial and legal liability as well. From your research, when you're building this product and, like, who's going to be interested in buying this thing, is that something that people are concerned about?

DOMINIC: Yeah, absolutely. I mean, the fact that we can stand up your cluster for you, stand up all of your cloud infrastructure for you, and then dynamically generate all of the configuration as code as well, and how to open those things securely up to the network and control everything such that you're not going to accidentally do something that's really bad, can definitely help out a lot of people.

The interest has been really overwhelming from so many different groups and organizations. We have people that are interested in the Department of Defense in both the U.S. and other countries. We have fortune 500 companies that see this as a pathway to accelerate digital transformation for legacy applications or even to use it as a sandbox, so people aren't bugging Frank, and Joe, and Bob, who run the Kubernetes clusters in production.

We have startups who see it just as a way to skip over the whole DevOps thing and work on getting a product-market fit so that they have a production environment that just works out of the box. So it's been really interesting seeing all the different use cases people are using harpoon for and how it's helped them in some way get to some and realize some goal that they have.

JOE: I'm curious if it's been a challenge as somebody managing the underlying infrastructure as sort of a plug-and-play thing. One experience I've had working more on the operations side of DevOps is that everything becomes your problem. Like, if the server misbehaves, if there's a database crash, whatever, certainly, that's your problem. But also, if the application is murdering your database, that becomes your problem. And it's really an application problem. But it surfaces visibly in the infrastructure when the CPU spikes and it stops responding to requests. And so, how do you navigate that agreement with your users? How do you balance what's your responsibility versus theirs to not kill the cluster?

DOMINIC: One thing that's great about Kubernetes and why it's a great base for our product is that Kubernetes is really good at keeping things running. Certainly, there are catastrophic things that can happen, like an entire region of EC2 and Amazon Web Services goes down. And that is, obviously, if you have your clusters only running in that particular region, you're going to have a bad day.

So there are things beyond our control. I mean, those things are also covered by the service-level agreement, the SLA with AWS, since you're using your own AWS account when you're utilizing harpoon. So it's like a hybrid SaaS where we deploy everything into your account, and you own it. And you can adjust those infrastructure things on your own as you'd like. So from that standpoint, you're kind of covered with your agreement with AWS as an example of a cloud service provider.

And certainly, Kubernetes also kind of knows what to do in some of those instances where you have a container that is murdering everything. In a lot of cases, it can be configured to, you know, just die or go into a CrashLoopBackOff or something if it's just taking up all your resources in the cluster versus destroying your entire cluster in a great fireworks display. So we put some of those protections into the platform as well.

But yeah, to your point, being an ops person is a difficult job because we're usually the ones [laughs] that get blamed for everything when something bad happens, even though sometimes it's the software team's fault or sometimes it's even just the infrastructure you're built on. Occasionally, AWS services and Google Cloud and Azure services do go down, and things happen.

We've had instances, even during harpoon development, where we're testing harpoon late at night on AWS, and sometimes AWS does wonky things at night that people don't realize. It's not completely perfect capability. And we're like, oh, why does it only happen at 11:58 on Tuesdays? Oh, because AWS updates their servers during that time, and it slows down everything.

It's still good to understand all the underlying components and how they work, and that could certainly help you regardless of if you use harpoon or not. But ultimately, we're just trying to make it easier for people. They can spend less time focusing on those things. We can help them with a lot of those problems that might occur, and they can focus on their software.

VICTORIA: Great. I think that's...it's interesting to me to always hear about all the different challenges in managing operations of software. So I like that you're working on this space. It's clearly a space that needs more innovation, you know, we're working on it here at thoughtbot as well. Has there been anything in your, like, any theory that you had going into your initial research that when you talked to customers surprised you and caused you to change your direction?

DOMINIC: Yeah. I mean, we run the gamut there. So we did a lot of early customer discovery to try to figure out who might be interested in this product. And so, our first thought was that startups would be the most interested in this product because they're building something new. They just want to get it out there. They want to build their MVP, and they just want to throw it on the internet and get it rolling and not have to worry about whether the software is up and down while they're doing a bunch of sales calls. Because really, during the MVP phase, if you're doing lean startup-style company development, then you really just want to be selling. You want to always be selling.

And so we thought it would just be a no-brainer for startups. And we talked to a lot of startups, and some startups for sure thought it was valuable. But a lot of them were like, "Yeah, that's cool, but we don't care about DevOps. [chuckles] We don't care about anything. Like, I'll run it on my laptop if I have to. The only thing I care about is finding product-market fit and getting that first sale." And so, at least as far as the very first customers that we were looking for, they weren't the best fit.

And then we went and talked to a bunch of mid-market companies because we just decided to go up to the next logical level. And so mid-market companies were very interested because a lot of them were starting to eyeball Kubernetes and maybe sort of migrate some of their capabilities over there. Maybe they had a little bit of ability to be a bit nimble, in that sense, versus some of the enterprise customers. And so they were very interested in it. But a lot of them were very risk averse, like, go find a bunch of enterprise customers that will buy it, and then we'll buy it. And so then we went to talk to the enterprise customers.

And that was sort of like an eye-opening time for us because the enterprise customers just got it. They were like, "Yeah, I'm trying to migrate legacy capabilities we built 10 or 15 years ago to the cloud. We're trying to containerize everything and refactor our existing software. I got to redesign the user interface that was built ten years ago." And if somebody's got a DevOps easy button, then sign me up. I would like to participate because I can't spell Kubernetes yet, but I definitely know what it is, and I want to use it.

So working with the enterprise customers was really great for us because it showed us what the appetite was in the market and who was going to immediately benefit from it. And then, ultimately, that rolls down to the mid-market companies. And maybe later-stage startups as well are starting to find a lot of value in the platform from, you know, have maybe started finding some product-market fit and care a little bit about whether people can access my software and it's maintainable and available. And so we can definitely help with that.

VICTORIA: That's super interesting, and it aligns with my experience as well, coming from consulting companies and the federal government who are working on digital services, and DevOps, and agile, and all of those transformational activities. And so it's been five years, it looks like since you started harpoon. What advice would you give to yourself if you could travel back in time when you were first starting the project?

DOMINIC: So I made lots of mistakes along the way. I'll inevitably make more. But when I first started building this thing, I wasn't even sure how it was going to work. Kubernetes can be a bit of a fickle beast, and it wasn't really built to have a drag-and-drop UI on top of it. And so there are lots of things that could go wrong, trust me, [laughs] I learned them. But building an initial prototype, like, the very base of can the capability work at all, came together pretty quickly. It was maybe three or four months of development during my nights and weekends. And building an enterprise scalable product took quite a bit longer.

But once I had an initial capability, I was very excited because, again, I didn't even know if this was possible, certainly not five or six years ago. So I didn't even really want to raise a round or make money. I do know how venture capital works. So it wasn't even my expectation that people would want to give me money because all I had was an MVP and no product-market fit. And I had just thrown it together in three or four months. But I was just excited about it.

I'm a software developer at heart, and technology excites me. And solving problems is kind of what gets me up in the morning. So I just called all the people I knew, a bunch of VCs, other people, and they're like, "Yeah, I would like to see that. Let's set up a time." And so I think maybe they interpreted that as, like, I want to do a pitch to you for money. [laughs] And I just proceeded to go to, like, this dog and pony show of showing a bunch of people this thing I built, and I thought they would just understand it and get what I was doing.

And I just proceeded to get my ass handed to me over and over and over again. Like, "This isn't that great of a product. How much money are you making?" Blah, blah, blah, blah. I'm like, "No, no, you don't get it. I just started. It's just a prototype at this stage. It's not even a finished product." And they're like, "Well, you're definitely going to fail. [laughter] You're wasting your time. What are you even doing here?"

And so that was...I like to think that I have thick skin, but that's hard to hear as an entrepreneur; just people don't get your vision. They don't understand what it is you're building and why it's going to be valuable to people. And it could be a long time before you get to a point where people can even understand what it is you're doing, and you just have to sort of stay the course and, I mean, I did. I went around on some rock somewhere and hung out in a tent on an island for a while. I just kept going.

And you just got to pour all your heart and soul, and effort into building a product if you want to make it exist out there in the world. And a lot of people are not going to get it, but as long as you believe in it and you keep pushing, then maybe someday they will get it. For the first year after we had a working enterprise-grade product, we kind of did a soft launch. And we had a small set of customers. We had 8 to 10 people that were sort of testing it out and using it, things like that.

We kind of went, you know, more gangbusters launch at the end of last year, and it was crazy. And then...what? I don't know, maybe 60 days since we did a more serious launch. And we have gone from our ten soft users to 2,000 users.

VICTORIA: Wow. Well, that's great growth. And it sounds exciting that you have your team in place now. You're able to set yourself up for growth.

Mid-Roll Ad:

Are your engineers spending too much time on DevOps and maintenance issues when you need them on new features?

We know maintaining your own servers can be costly and that it’s easy for spending creep to sneak in when your team isn’t looking.

By delegating server management, maintenance, and security to thoughtbot and our network of service partners, you can get 24x7 support from our team of experts, all for less than the cost of one in-house engineer.

Save time and money with our DevOps and Maintenance service. Find out more at: url tbot.io/devops

VICTORIA: So now that you're getting more established, you're getting more customers, you have a team supporting you on the project; what parts of the DevOps culture do you feel like are really important to making a team that will continue to grow?

DOMINIC: I've been an individual contributor for a long period of time. I was a first-level manager and managed people. At a very granular personal level, I've been a director, and a VP, and a CTO at a bunch of different places. And so all of those different roles and different companies that I've worked at have taught me a lot about people, and teams, and culture, and certainly about hiring.

I think hiring is the absolute most important thing you can do in a company, and definitively in a software company. Because there are just certain people that are going to mesh well with your culture, and the people that do and that are driven and passionate about what they do, they're just going to drive your company forward. And so I just spend a lot of my time when we need to grow as a company, which happens here and there, really focusing on who is going to be the best next person to bring on to the company.

And usually, I'm thinking about this far in advance because whenever we do need that person, I don't want to have to start thinking about it. I want to just know, like, it is Frank, it is Bob, it is Jamey, or Alex, or whoever else. Because it is...at a personal level, there has to be people who are very aligned with your visions, and your values, and your culture, and they care and are going to push the company forward.

And if you're just hiring people with a quick coding interview and a 30-minute culture fit session, you're going to make a lot of hiring mistakes. You're going to find people who are just looking for a nine-to-five or things like that, and, I mean, there's nothing wrong with that. But in a startup especially, you really need people who buy into the vision and who are going to push the thing forward.

And I'm looking for people who just care, like; they have an ownership mentality. Maybe in a different lifetime or a different part of their career, they'd be an entrepreneur at their own company. But you just give them stuff, and they're like, cool, this is mine. I'm going to take care of this. It's now my child. I will make sure that it grows up and it is healthy and goes to a good university. Those are the type of people that you want in your company, people that you would trust with your children. So those are the criteria for working at harpoon, I guess.

VICTORIA: Yeah, that's good. So what does success look like in the next six months or even beyond the next five years?

DOMINIC: I think it's still very early market for us. Certainly, we have an explosive growth of users using the platform, and that's really heartening to see. That's really awesome that people want to use the thing that you built. But again, there are so many companies out there and organizations that are still not even doing DevOps. They're just doing manual deployments, maintaining clusters manually, not using containers or Kubernetes. Not to say that you have to use these things and that they're a panacea, and they work in every sense because they don't.

But obviously, there's been a major shift in the industry towards containers and container orchestration like Kubernetes. Even some of the serverless platforms that people like to use are actually backed by Kubernetes, so you see a major shift in that direction. But there are still so many different companies and organizations that, again, are still locked into legacy ways of doing things and manually doing things.

There are companies that are trying to get their products off the ground, and they're looking for faster and easier, and cheaper ways to do that. And I think that's what's really exciting about harpoon is we can help these companies. We can help them be more successful. We can help them migrate to things that are more modern and agile. We can help them get their product off the ground faster or more reliably. And so that's kind of what excites me.

But you know what? We do a lot of demos, you know, sales demos and things like that. And, really, we don't have PowerPoints. We're just like, cool, this is the app, and this is how you use it. And it is so simplistic to use, even though Kubernetes is quite complicated, that the demo goes pretty quick. We're talking five, six minutes if there are not a lot of questions. And we always get exactly the same response, whether somebody is not super familiar with Kubernetes or they are familiar with Kubernetes, and they've set up their own cluster. It's almost always, "Wow," and then a pause, and then "But how do I know it works?" [laughs]

So there's going be a lot of work for us in educating people out there that there is an easier way to do DevOps now, that you can do drag and drop DevOps and dynamically generate all of your scripts and configuration, and open up networks, and deploy load balancers, and all the other things that you would need to do with Kubernetes, literally in a few minutes just dragging and dropping things. So there's going to be a lot of education that just goes into saying, "Hey, there's a new market, and this is what it is. And this is how it compares to the manual processes people are using out there. Here's how it compares to some of the other tools that are more incremental in nature."

And trust, you know, over time, people are going to have to use the platform and see that it works and talk to other people and be like, yeah, I deployed my software on harpoon, and nothing terrible happened. Demons didn't come out of the walls, and my software kept running, and no meteors crashed in my house. So it's just going to take some time for us to really grow and build the education around that market to show that it's possible and that it exists, and it can be an option for you.

VICTORIA: Right. I used to do a lot of intro to DevOps talks with Women Who Code and DevOps DC. And I would describe Kubernetes as a way to keep your kubes neat, and your kube is where your software lives. It's a little house that keeps the doors locked and things like that. Do you have another way to kind of explain what is Kubernetes? Like, how do you kind of even just get people started on what DevOps is?

DOMINIC: I like to usually use the cattle story. [laughs] So, in DevOps, they have these concepts of immutable infrastructure or immutable architecture. And so when you have virtual machines, which is what people have been running on for quite a while, certainly some people still run on bare metal servers, but pretty much everybody's got on board with virtualization at this point, and so most software these days is at least running on virtual machines. And so the difficulty with virtual machines is, I mean, there's nothing wrong with them, but they're kind of like pets. They exist for long periods of time. They have what we call state drift, and that's just the changing of the data or the state of the virtual machine over time.

And even if I were to kill off that virtual machine and start another one, it wouldn't be exactly the same one. It wouldn't be, you know, fluffy. It would be a clone of fluffy. And maybe it wouldn't have the same personality, and it wouldn't do exactly the same things. And sometimes that might be good; maybe fluffy was a terrible dog. But in other cases, you're like, oh crap, I needed that snowflake feature that Bob built three years ago. And Bob has been hit by a train, so people can't ask Bob anymore.

And so what then really happens at these organizations is when the virtual machines start acting up, they don't kill them. They take them to the vet. They take care of them. They pet them. They tell them they're a good boy. And you have entire enterprises that are super dependent on these virtual machines staying alive. And so that's no way to run your business. And so that's one of the reasons why people started switching over to containers because the best practices in containers is to build software that's immutable.

So if you destroy or kill one of your containers, you can start another one. And it should work exactly the same as before, and that's because when you build your containers, you can't change them unless you rebuild them. I mean, there are ways to do it, but people will wave their finger angrily at you if you try to do that because it's not a best practice.

So, at the end of the day, virtual machines are pets, and the containers are cattle. And when containers start acting up, you kill them. And you take them to the meat factory, and you go get another one. And so this provides a ton of value from a software development and an ops perspective because anytime you have a problem, you just kill your containers, start new ones, and you're off to the races again.

And it significantly reduces the troubleshooting time when you're having problems. Obviously, you probably want to log things and check into things; why did that happen? So that maybe you can go make a fix in your software. But at the end of the day, you want to keep your ops running. Containers are a great way to do that without having to be up at midnight figuring out why the virtual machine is acting up.

And so the difficulty with cattle is they like to graze and wander and break through fences and things like that. And mostly, when you have an enterprise software application or even just a startup with an MVP, you probably have multiple containers that you need to run and build this application. And so you need somebody to orchestrate. You need somebody to wrangle your containers.

And so Kubernetes, I like to say, is like cowboys. Like, they're the ones that wrangle your cattle and make sure they're all going in the right direction and doing the right things. And so it just makes natural sense. Like, if you have a bunch of cattle, you need somebody to take care of them, so that's what Kubernetes does.

JOE: Yeah, just to add to that, one of the things I really like about Kubernetes is that it's declarative versus prescriptive. So if you look at a lot of the older DevOps tools like Chef, things like that, you're effectively telling the machine what you want it to do to end up with a particular deployment. With containers, you'd say, start this number of containers on this node. Start this number of containers on this node. Add a virtual machine with these. Whereas with Kubernetes, you state the way you would like the world to be, and then Kubernetes' job is to make the world like that.

So from a developer's perspective, when they're deploying things, they don't actually usually want to think in terms of the steps involved between I push this code, and somebody can use it. What they want us to say is I want this code running in containers, and I would like it to have this configuration. I would like it to have these ports exposed. And I love that Kubernetes, to a pretty good extent, abstracts away all of those steps and just lets you say what you want.

DOMINIC: Yeah, that's a lot of the power in Kubernetes. You just say, "This is what I want, and then make it so." And Kubernetes goes out and figures out where it's going to schedule your container on what node or server if it dies. Kubernetes is like; I'm pretty sure you wanted one of those running, so I'm going to run it again. It just handles a lot of those things for you that previously you would need somebody with a pager to call to fix. And Kubernetes is automating a lot of that deployment and maintenance for you.

VICTORIA: Right. And it seems like there's the movement to really coalesce around Kubernetes. I wonder if either of you can speak to the healthiness of the ecosystem for Kubernetes, which is open source, and why you chose to build on it.

DOMINIC: So there was sort of a bit of a container orchestration war for a while. There was a bunch of different options. And I'm not saying that a lot of them weren't good options. Like, Docker built a capability called Swarm, and it's fairly simple to use and pretty powerful. But there was just a lot of backing from the open-source community behind Kubernetes when Google made it an open-source project. There were other things sort of like Kubernetes but not really like Mesos. And they all had like this huge bloodbath to see who was going to be the winner. And I just feel like Kubernetes kind of pulled ahead.

It was a really smart move from Google to make it open-source and get the open-source community's buy-in to use. And it just became a very powerful but complex tool for running your software in production. Google had been using some form of that called Google Borg for a number of years prior. And I'm guessing they're still quite a bit different. But that's how it kind of came about. Do you have anything to add, Joe?

JOE: I'd say that I judge the winner or the health of an ecosystem by the health of the off-the-shelf and open-source software that can run on that system. So Kubernetes is a thing that you use yourself. You build things to run on it. But also, you can pick and choose many things from the community that people have already built. And there is a huge open-source community for components that run on Kubernetes, everything from CI/CD to managing databases to doing interesting deployment styles like canary deployments. That's really healthy.

It just didn't happen with the other systems like Swarm or Nomad was another one. And most of the other companies that I saw doing container orchestration eventually just changed to doing their flavor of Kubernetes, like Rancher. I forget what their original platform was called. But their whole thing was based on that cattle metaphor. [chuckles] And they took a pretty similar approach to containers. And now, if you ask somebody what Rancher is, they'll tell you it's a managed Kubernetes platform.

DOMINIC: Yeah, I think it's called Longhorn, so they very much have the cattle theme in there. I mean, they're literally called Rancher, so there you go. But yeah, at the end of the day, something is going to come after Kubernetes as well. And I like to think that it's not so much a matter of what's going to be next? Is there going to be something beyond containers or container orchestrators like Kubernetes?

I just think there are going to be more and more layers of abstraction because, at the end of the day, look at the advent of things like ChatGPT and generative AI. People just want to get their jobs done more efficiently and faster. And in software, there's just a lot of time and money that goes into getting software running and keeping it running, and that's why Kubernetes makes sense. But then there's also a lot of time that goes into Kubernetes.

And so we think that harpoon is just sort of the natural next layer of abstraction that's going to live on as the next thing. So if 15 years ago I told you I was going to build a web application and I was going to go run it in the cloud, maybe you would have said, "You're crazy, Dom. Like, how could you trust this guy, Jeff, with all your software? What if he is going to steal it? And what if he can't run a data center? What then?"

And now, if I told you I was going to go build a data center because I want to build a web application, you would look at me like I was a pariah and that I was not fit to run a company and that I should just use the cloud. So I think it's the same process. We're going to go with containers and Kubernetes. And software deployment, in general, is going to be an abstraction layer that lives on top of all that because software developers and companies just want to push out good software to end users. And any sort of way to make that more efficient or more fun is going to be embraced eventually.

JOE: Yeah, I agree with that. I hear people ask, "What are you going to do when Kubernetes is obsolete?" pretty often. And I think it's achieved enough momentum that it won't be. I think it'll be what else is built on top of Kubernetes? Like, people talk about servers like they're obsolete, but they're not; there are still servers. People are just running virtual machines on them. And virtual machines are not obsolete. We'll just run containers on them. So once we get beyond the layer of worrying about containers, you'll still need a container platform. And based on the momentum it's achieved, I think that platform is going to be Kubernetes.

VICTORIA: Technology never dies. You just get more different types of technology. [laughs] Usually, that's my philosophy on that.

DOMINIC: Yeah, I mean, there's never been a better time to be a software developer, especially if you're an entrepreneur at the same time, because that's what happens over time. Like, what we're achieving with web applications today and what you can push out to the internet and kind of judge if there's a market for would have been unimaginable 20 years ago because, again, you would have had to build a data center. [laughs] And who has a bunch of tens of millions of dollars sitting around to do that?

So now you can just use existing software from other people and glue it together. And you can use the cloud and deploy your software and get it out to the masses and scale it. And it's an amazing time to be alive and to be building things for people.

VICTORIA: Right. And you mentioned a few things like artificial intelligence before, and there are a lot of people innovating in that space, which requires a lot of data, and networking, and security, and other types of things that you want to think about if you're trying to invent that kind of product. Which brings me to a question I have around, you know when you're adding that abstraction layer to these Kubernetes clusters, how does that factor into security compliance frameworks? And does that even come up with the customers who want to use your product?

DOMINIC: Yeah. I mean, definitely, people are concerned about security. When we do infrastructure as code for your virtual infrastructure that's running your Kubernetes cluster that we deploy for you, certainly, we're using best practices from a security standpoint. We do all the same things. If we're building out custom scripts for some clients somewhere, we'd want it to be secure. And we want to lock down different aspects of components that we're building and not just expose all the ports on maybe a load balancer and things like that.

So by default, we try to build in as much security as we can. It's pragmatic. I think ultimately we'll probably go down to the path of SOC 2 compliance, and then anything that goes on top of a harpoon cluster or that is deployed with harpoon will be SOC 2 compliant to a large degree. And so yeah, I mean, security is definitely a part of it. We're currently building in a lot of other security features, too, like role-based access control and zero trust, which we'll have pretty soon here.

So, yeah, if you want to build your software and get it deployed, you want it to be scalable, and you also want it to be secure. There are so many ilities that come into deploying software. But to your point, even on the artificial intelligence side, people are looking for easier ways to abstract away the complexity. Like, if I told you to go write me a blog post with either ChatGPT or go build your own generative AI model and use that, then you're probably going to be like, yeah, I'll just go to the OpenAI website. I'll be back in a minute.

And that's why also you see things like SageMaker from AWS. People want abstraction layers. They want easier ways to do things. And it's not just in DevOps; it's in artificial intelligence and machine learning. That's why drag-and-drop editors are becoming more popular in building web applications mobile applications. I think all of this software development stuff is going to be really accessible to a much larger community in the near future.

VICTORIA: Yeah, wonderful. That's great. And so, Dominic, any final takeaways for our listeners today?

DOMINIC: Definitely, if you have interest in how either harpoon or Kubernetes, in general, might be applicable to you and your company, we're a bunch of friendly people over here. Even if you're not quite sure how to get started or you need advice on stuff, definitely go hit us up on our website or hit up support at harpoon.io, and send us a message.

We're very open to helping people because, again, what we're really trying to do is make this more accessible to more people and make more people successful with this technology. So if we have to get on a bunch of phone calls or come sit next to you or do whatever else, we're here to be a resource to the community, and harpoon is for you to get started. So don't feel like you need a bunch of money to get started deploying with Kubernetes and using the platform.

VICTORIA: That's a great note to end on.

So you can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg.

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thank you for listening. See you next time.

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Special Guest: Dominic Holt.

Sponsored By:

thoughtbot: Are your engineers spending too much time on DevOps and maintenance issues when you need them on new features? We know maintaining your own servers can be costly and that it’s easy for spending creep to sneak in when your team isn’t looking. By delegating server management, maintenance, and security to thoughtbot and our network of service partners, you can get 24x7 support from our team of experts, all for less than the cost of one in-house engineer. Save time and money with our DevOps and Maintenance service. Find out more at: tbot.io/devops

Support Giant Robots Smashing Into Other Giant Robots

Episode 290: TMBA290: A Conversation about Bootstrapping and Drop Shipping with Andrew Youderian