Erik: Cory, thanks for joining us on the podcast today.

Cory: Yeah, thanks so much for having me.

Erik: This will be an interesting one. I cover a lot of different topics in the podcast. Some of them, I'm very comfortable with. Some of them, a little bit outside my comfort zone. I guess this is a little bit outside, so I'm looking forward to getting educated here. But Cory, maybe a good place to start here would be for you to walk us through your quite interesting background, and share where you first started getting into the topic of DevOps and the topic of improving productivity for developers.

Cory: Yeah, so, I've been in the space for a while. My background was originally in healthcare information systems. I was a HIPAA security analyst. Prior to that, I actually wasn't interested in software at all. I've done a little bit of software development for fun, just like modern games in the '90s. I wrote some software to do my first job. I automated my own job away, and I got a promotion into the software department. And I changed careers. I was originally a physics major. So, I got into healthcare, healthcare IT. I was a HIPAA security analyst for a while. Then I just started falling in love with writing software. And so, in 2005-2006, I moved from Florida to Southern California to join a startup. I had no idea which one. I was just going to do it.

My first job out here was working for a company. They were in a data center. Their lease was expiring, and they knew the move. This was around the same time that Amazon had first launched EC2. And so, my boss came into the office one day and was like, "You've worked in data centers, and you write software?" Because it was like people that worked on the operations team, and they were people who were on the software team. But I was the one person that sat in between. He's like, "Do you want to help us figure out how to migrate from the data center to these cloud computers to the Amazon selling?" I was like, "None of that makes any sense to me, what you just said. Amazon is selling cloud computers?" And so, I start working in the cloud. I worked in some IaSQLs about 11 years ago, and then the rest is just history. I've been pigeonholed into the DevOps role for the past 16 years or so.

Erik: Okay. So, you got in actually fairly early, at least in the migration to cloud. Then over the past 16 years, I guess, DevOps has evolved quite a bit. It feels like, in some ways, it's completely evolved. I was just chatting with a friend the other day. He was saying, there are some areas where they're just 98% more efficient than they were, because there's things you can just automate. Then there are some areas where it feels like it hasn't really changed that much. So, if you look at the DevOps landscape, where are we at a point where we say, okay, we're extremely efficient today and maybe there's incremental improvement to make, but we're already on a good path? Then what are the areas where you still see a lot of room for improvement in DevOps?

Cory: I think, honestly, I'm not a fan of DevOps nowadays. I do it, but I think that we have a warped perception of what it is. It started out as a culture where it was like we can tear down these silos between ops and engineering. I think that it made sense for a very brief period of time. When I was working in early cloud 2006, 2010, 2011, there wasn't a ton of cloud services. It made sense. We had software. We want to introduce change. We needed to get things into the cloud. It made sense for people to own stuff.

Now, with just the proliferation of what the cloud is, none of the clouds aim to be simple. They aim to be capable. They have to be able to sell something to everyone. In doing that, a couple of things have happened. One, the cloud has gotten much more difficult to manage and deploy things there. At the same time, our software has gotten more complicated. We have customers that demand things work as well as Facebook software at day one, where they're gone. We have a global audience, when 10 years ago, you might struggle to get a few 1,000 people on your website. Now you can go massive scale pretty quickly. And so, I think those two things come together to make the world that doesn't really fit DevOps anymore.

The average software engineer doesn't have any cloud operations experience. 8% of software engineers have deep cloud operations experience. So, that means it's like when we're doing DevOps, what are we really doing? If we're getting a company or if we're getting software developers out of boot camps, constantly, they haven't worked in production environments. Operations is production experience. What are they doing? They're learning on the job, which is great. That's how you learn to do operations. But you can't really have good production systems where people are learning how to run the thing. And so, I think that this idea of "everyone does DevOps nowadays" doesn't work. And you're seeing it not work. That's where you're starting to see DevOps things. You're not seeing DevOps culture. We all do a little bit of DevOps, but you're starting to see teams where there's a DevOps role. That is an anti-thesis of what DevOps was, originally. So, it's the industry showing that this isn't working.

What that team is, that team is an operations team. That's really what it is. So, let's call it what it is. We do want to tear down these silos. But the way that we're trying to do it or saying everybody can go and manage cloud infrastructure, that's not the way to do it. I struggle with that terminology. But at the same time, I do DevOps. I'm a software engineer. I have deep operational expertise. I write software to automate operations. But that's me using software to do something I'm an expert in.

I'm not sure if that answers your question. But I feel like we're not quite there anymore. I think that DevOps idea was a moment in the past, and we need to evolve past that. We have way too many software developers coming to the industry to try to continue to do that. If you look at the functionality of the average platform as a service and the functionality of the cloud, they are massively separate and there's nothing in between. Passes are easy and opinionated. The cloud is complex and unopinionated. We need to make systems — it's land somewhere in between so that companies can grow, they don't get cornered into passes. But also, engineers can deploy software effectively and securely without having to go become an operations engineer.

Erik: That's an interesting perspective. I really hadn't thought about it in that way. But it makes sense that there was a brief period of time when the cloud was simple enough that you could bridge those two divides with a person that had multiple skill sets, and they would play that role. And now we're at a point where just because of the addition of performance and functionality, the cloud has gotten more complicated. At the same time, you really have the proliferation of applications, right?

I'm in the IoT space, so I have so many clients who are — they're industrial companies. They're chemical companies. They're biopharma companies. They're not data science companies. And now they're building software that's really essential to their business and their products. It's driven by people that understand the customer. They understand the market. They're innovators, but they're not IT people. So, then they have this challenge of how do we put this together into a package that scales, given the type of organization that we are and the resources that we have? So, I think that's the challenge, at least, that we see here. Still, you need to address this. But maybe the traditional DevOps role doesn't fit well into those organizations and is maybe not sufficient to solve the challenge there.

Cory: Yeah, it's funny. I saw this meme, a meme tweet. I don't know — this humorous thing on the internet recently. It was like, "Time to build future: one hour. Time to figure out IAM: three days." Really, IAM, in and of itself, just configuring permissions of how your applications and people access the cloud is complicated — to the fact that we now have IAM engineers. That is insane. That is wild. But that's where the world is. This stuff is complicated.

When you look around at, again, the experience base, where 8% of engineers have this deep-cloud operations experience — that's from the Stack Overflow survey. That's not from some weird Gartner Survey. That's Stack Overflow, the heart of software industry. It says that it's 8% to 10% of people have that skill set. So, when you think about that, where are the people at? They work in Google. They work in AWS. They work at Apple. They work with the biggest companies in the world. When you look around to the rest of us trying to deploy things into the cloud, a lot of us are just guessing. And you're competing, salary-wise, from of the biggest companies on the planet.

If you have the budget for five engineers and you need to start deploying stuff to the cloud, how do you do that? Do you go hire an ops person? That's not a great use of your money. It's not a great use of that person's time. Do you take one of your engineers that may not have that experience and say, "Go figure it out"? Okay, well, now your feature velocity is down, if somebody is trying to figure this stuff out. Also, is it configured well? Is it secure? Is it cost-efficient? I don't know. You'll figure it out eventually. But in the meantime, your customer's data is in there. My mom's data, our family's data is in there. We've got to protect this information that we're storing. I don't think that the way that we approach DevOps today does that, where we're saying, like, "Hey, everybody can do it. It's so simple." I think, honestly, it discounts the deep expertise that operations folk actually have by saying anybody can do it.

Erik: Yeah, I know. It's an interesting point. Again, bringing it back a little bit to the IoT topic, there's legislation going through Congress right now that's basically pushing liability from the device operator to the OEM. I mean, the status quo up to now has basically been: somebody builds a baby monitor or whatever. They put it on the market, and it's really up to the owner of the device to protect their data. Now they're pushing that liability back and saying, "Okay. If you're putting a smart device out there, you have to make sure that it adheres to certain security standards." You can just imagine all these companies that are basically looking at their tech stack, and they're saying, "Okay. How are we going to do this?" And now we already have a mature tech stack. Maybe it's one thing if you're building from scratch. It's 10x more complicated if you already have a tech stack in place, and you're trying to start building that security into it.

Cory: Yeah, and it's funny. There's this new phrase that I feel like — they're not new phrases. It has been around a few years. But I feel like it's a phrase that is just starting to be thrown around all willy-nilly. Shift left. We shift operations left. We're shifting security left. When you look at ML, ML ops, we're shifting their operations left. We're shifting a lot of stuff left, except for expertise. To come in and say, "Okay, DevSecOps, you're writing software. Your job is also to secure the software, and your job is also to operate the software." It's okay. Where's your time for developing features?

We have this thing on the other side of all the engineering work we do, that weighs against that security and operations. That's the product manager. If you're the product manager at your average — let's say e-commerce company — they don't see your software or your load balancer serving a ton of traffic quickly. They don't see your database being secure. They see that the button bought more thing. And so, their goals are not aligned with the goals of a secure and functional system. Their goals are aligned with conversions. And so, that's another thing I see. It's hard with shifting all this accountability left as the rest of the org doesn't really see that for most organizations. Or you might be working at Google and say, "Well, Google does." It's like, yeah, well, Google does. But the 1,000 T-shirt companies out there, medical device companies don't necessarily see that. And if the product managers aren't seeing that work, then what is the engineer doing? They only see the work that they can see service in the product. So, that's another reason. I just think that it's not really serving our industry and all industries well, as everything starts to become a software company.

Erik: Okay. Well, interesting. Tell me then, where does Massdriver fit into this? What's the value proposition of Massdriver? Who is the value proposition for in this relatively complicated chain?

Cory: So, we have two value props depending on the growth stage of the organization. What we're trying to do is land in between pass and the cloud. What we're trying to do is make essentially a pass that is customizable and can grow with your business. On the surface, if you come to Massdriver, and you're a small team that doesn't have any operations experience, what you see is pretty much a point-and-click way of building cloud infrastructure. There's a lot of people that are building this point-and-click building cloud infrastructure stuff. But the way we do it is a bit different.

When you see something in Massdriver, it's very use case-oriented. We're not saying, "Grab the 35 components of a network and connect them together to make a network." We're thinking about the things you connect from the perspective of a software engineer. I need a network. I need a database. Routing tables, subnets — that stuff doesn't matter. I want it to be secure. I want it to be compliant. We're talking about requirements and policies. The engineers want not necessarily cloud infrastructure details. So, it makes a lot easier to start provisioning secure and compliant things connecting to your applications, getting them running.

Now, where the real magic is, as your business grows — as an operations engineer, I've walked into so many companies that run a pass, they've gotten to the point that they need to move to the cloud. That's an expensive migration. The way Massdriver works is, those packages that you're connecting together are actually really just packages. Under the hood, Massdriver is a giant package manager for cloud infrastructure and applications. So, when your operations team comes in, four years from now, instead of them having to migrate from something, it's already running in your cloud account. So, we deploy everything into your AWS, as your GCP, on-prem Kubernetes. Now I can take the tools that I'm familiar with — Pulumi, Helm, Terraform. I can customize those packages into my engineers. Nothing changes. The diagrams that you draw that look just like the stuff you see on the whiteboard is how they provisioned infrastructure. But I have full control over it as an operations person, when the time comes, to be able to need to fine tune infrastructure, add new functionality to the platform.

Erik: How low-code is this? Because I guess, still, developers are using this so they do have a base level of technical competence here. But then, I'm also imagining some of my clients, where it's basically a product manager, and they have an IT team back in Germany. But I'm here in China. And so, they often trying to figure things out on how do I migrate to a cloud in China with the the option of figuring it out themselves, or sending it back to the IT pipeline and waiting three months until somebody answers the ticket.

Cory: Yeah, so, it's fairly low-code. You can go from no code to as much code as you want. Again, if you go on the Massdriver, you see like one of the boxes, one of the items you'd see on a whiteboard when you're connecting together. There's an actual source code repository behind that. You can just go for that repository and start modifying the way that — let's say, Postgres work for Timescale or EventBridge works behind the scenes. So, you can get as deep into the code as you want, or you can just look at it from like a use case perspective. I want Postgres. I want it highly available. I want backups for seven days. You're looking at it very much from the attributes of what you need from the cloud.

Now, when you're deploying your applications, it gets to the coding parts as it gets closer to your code. When you get to your application, connecting to that database, then you might see code for the first time. But that's in your source repository. So, you're saying, where do you want to mount that environment variable? It's extremely low-code. Our customers generally don't see TerraForm or YAML or any of that stuff that they don't want to.

On the other side, if you're a deep operations team. Sorry, if your operations team have deep expertise, you can fine tune the thing. You can literally add functionality to it. You can extend the runtimes, the application that the platform supports. Customers can add their own clouds to it. If you want to run OVH or Scaleway, you could just add that to your silo. Now Massdriver supports that cloud as well. So, it's got a pretty wide range, depending on where your expertise level and comfort level is.

Erik: Got you. Okay. Then who would you be working with, typically? I understand it's tech companies. What's the right size or maturity level? Are there specific industries where you've seen more traction in the market?

Cory: Yeah, so, pretty early-stage startup. We're about to start our next round. This will be our first series. So, pretty early stage still. We're mostly focusing on startups and people that are about our age as well. So, pre-Series A. That's what's been the easiest for us to sell to and migrate onto the platform. Now, with that being said, it's really funny because companies get big quickly nowadays. We've got some startups where it's like, okay, there's three or four people there. Then we start looking at their traffic profiles, and it's 8 million requests an hour. It's like, okay. It's a small team, but they're already serving a ton of traffic. We have another company; it's moving up the platform. They're trying to figure out how to migrate 20 terabytes of data onto Massdriver from this old environment they managed themselves. So, they're pretty small teams with pretty big scale already.

Then on the other side, we've got a few enterprises. We have one of the big three consulting firms. It's using it for a small project. Honestly, it's a pretty wide range of industries that are using it. But the companies that we see the most are healthcare. Again, because we do a lot of the compliance, scanning out of the box. So, SOC 2, PCI, HIPAA — we do on all this infrastructure by default. So, it can get you really close to compliance. At the infrastructure level, you kind of have to focus on your apps.

Then the other place that we're really seeing a ton of interest is machine learning and AI. I mean, we're at the fourth Gold Rush of Silicon Valley with ML and AI. We're selling shovels. I mean, we want to do some of our own ML and AI stuff. But today it's like, when you look at a lot of teams and you go into companies receive this transactional product that makes the money and then there's the ML team, more often than not, the ML teams don't have a ton of operational support. And they're figuring out this stuff themselves. And so, we have companies coming to us today that they want to run this ML product. They've been doing model training, but they don't know how to do the operations stuff. They got something running locally on their machine. Then you figure out how to get it into the cloud. Then we even have a pass that is a pretty early-stage pass that is for the ML space that's building their pass on top of Massdriver. So, we're actually seeing this full promise that we were hoping to be able to deliver. You can even run systems as complicated as passes on top of the platform.

Erik: This is a little bit of a deviation. But I'm really interested in hearing your thoughts on this topic of GPT or generative AI. Because it feels like it's really democratized access to machine learning in a way that really wasn't — I mean, two years ago, you needed some data scientists and a fair bit of investment to get something off the ground. And now you need an idea and a reasonably competent developer, and you can start building an application. But then, like you said, those applications can start to scale, and you're starting to deal with maybe high volumes of data, high user bases, et cetera. But how do you see that kind of democratization of access to AI evolving right now?

Cory: Yeah, it's really interesting. I think it's super exciting. I've definitely played around with ChatGPT and Jasper and a few other ones, especially in the areas that I'm weak in. I'm a tech CEO, but this is my first time CEO. I don't have a ton of marketing experience. So, I've been leaning on Jasper and ChatGPT to rewrite some of my copy. What's funny is, it's like — I'm like, oh, that sounds pretty good. Then I read it, and I'm like, that doesn't really sound really good. It was nice and wordy, but it's not a really great marketing hook. So, I think there's a lot of novelty to it.

I was thinking about this a few, maybe like a month or so back when people were freaking out about — before ChatGPT, there was the image one. Artists were like, "Oh, they're going to take art from us. There's not going to be art anymore." It's a thing it can't draw hands. It can draw all sorts of weird stuff, but it can't make a human hand. Then the same panic started happening. I feel like when ChatGPT came out, it was like, "Oh, what are writers going to do? There's not going to be writers anymore." It's like, okay, yeah, if you're the writer that's writing the seven paragraphs before a recipe about somebody's grandma on a recipe site, yeah, that person is out of a job. But when you talk about authors and people that make movies, I feel like a lot of the human experience, especially in writing, is exposure and experience.

What's interesting is — take a good writer. They've had this exposure to writing. They've read some books. They've had some exposure to education, and they've had the experience of their life. Those two things craft their existence that lets them write well. When you look at ChatGPT, it has zero experience and 100% exposure. And so, you get down as these watered-down ideas of what humans do. I mean, it's like ChatGPT is a brain in a skin suit. It's not quite human. It doesn't feel really human. And so, what I worry about a bit when it comes to — in software. We've already seen the weird stuff with co-pilot, autopilot, whatever it's called. It does some weird comments sometimes. It's trained off of the stuff we put out there. And so, it's trained off of open source. When you start looking at infrastructures, what is it trained off of?

I admit. A lot of what we do is commodity as operations engineers. But the stuff that you see out in the public isn't great. Let's say that you train it on the AWS docs. They're hard to follow. I felt like I'm reading a white paper most of the time that I'm configuring something, reading it over and over and over again. There's all sorts of these rules everywhere. It's like, if you selected this, you can't do this. You got to set IOPS for this, and yada, yada, yada. It's very hard to follow. I don't know that AI is going to get that.

What's worse is, when you start looking at a lot of the IaC that we do — let's say, that we're writing TerraForm to automate some of our infrastructure. TerraForm is an abstraction on top of the cloud's APIs. Then there's this open-source registry where you can share these modules. This is a lot of the stuff under the hood of how Massdriver works. We have these modules as well. But when you go to the TerraForm registry, what they are is a bunch of organizations — say, 1,000 companies — all sharing the same module, all of them putting their opinions on it. And so, you get to the point that there's literally no expertise in whatsoever.

You go look at, let's say, the TerraForm module for making a network. It is a reimplementation of the underlying TerraForm code, which is a reimplementation of the API that it's calling. When you look at something, like a VPC on the TerraForm registry, there's 180 inputs. When you look at the API for AWS, there's 20 inputs to what a network is. And so, we have massively overcomplicated it by having everyone's bespoke opinion of how their organization works on something that is a commodity. That is what ChatGPT is going to be trained off of. It's going to learn the watered-down experience of all operations, how all companies are trying to do it, which is just the most vague configuration there is. There's 180 inputs for VPC. How do you even design a good VPC that way? And so, without expertise actually being baked into the things it's being trained on, it's just going to learn what the APIs look like. It's not going to learn how to configure them well. It's not going to learn what SOC 2 is or isn't. It's just going to learn that, oh, I can hit this API with some numbers and letters, and it'll respond 200 okay.

So, I'm not worried. I feel like every decade, we're worried about something that's going to take the software away from software engineers, and something is going to replace us. I don't think we're there yet. Will it happen by 2400? Maybe. But a decade ago, we were worried about Dreamweaver. A decade before that, they were worried about Fortran or something like that. We're always worried about something coming along and making it so easy that everybody else can do it. I don't think ChatGPT is going to be the thing to take away the jobs of operations engineers.

Erik: Yeah, that's an interesting perspective. I was listening to a podcast the other day where somebody was describing DALL-E, in what it's good at and what it's not good at it. What it's good at is, if you go to an art gallery and you see the text that they used to describe a picture, they might say this is a Renaissance painting from this time period, and they'll describe it in a certain way. But they don't say, "The woman is to the left of the man. The sun is on the top right of the picture." And so, what humans do is they go and say, "I want you to do a picture with two people. The woman is on the left of the man. The sun is on the top left." And DALL-E is like, "I have no idea what to do with this, because I've never seen a picture with alt text that describes it in that way." But if you go and say, "Hey, I want a Renaissance picture of da, da, da," it'll kind of figure it out because it's seen a bunch of examples with — so, there are certain things that it's good at.

We're working on a little side project right now, where we're basically using the API to summarize a bunch of regulations. Just look through the regulation, find keywords, and summarize it in a reasonable way. That works because it's doing a very narrow part of a process that's very tightly defined with text that we're giving it. We're basically just feeding it 20,000 documents and say, "This is the text you're going to work with." That's kind of where I feel like it fits in right now. So, probably, with software engineering, it'll be the same thing. There will be some specific jobs that will do very well. But then, the whole flow of the operations has a lot of complexity. There's a certain art to it. We'll see if it ever gets there. But it seems like we still have ways to go at this point.

Cory: Yeah, and it'll be interesting too, especially if we're seeing the code. It's one thing if it's writing code and doing the stuff for us. Can an AI model just be my CMS, or is it going to generate code that I have to then run? If it's generating code that I have to now run, all code that we write is mostly read by humans. It's like we write some code, but then our teammate is reading it. Then the question is like, okay, it can write code that compiles. Can it write code that's efficient? Then can it write code that is human-readable? So, what we don't want is, okay, I wrote the code in 20 seconds. But it's 24 hours to debug a production bug where there was an outage, because we couldn't comprehend what it output.

And so, that's the real worry. It's like, what is good code? I feel like there's jokes left and right on Twitter that we're not even good at writing code. Everybody always has impostor syndrome and says, like, "Oh, I'm not great at it. We're all just guessing anyway." Okay. So, we're going to train that thing off an industry of millions of people just guessing. That's great.

Erik: Right. Well, okay. So, a little deviation. But let's come back to the product now. So, if we look at Massdriver, the way you described it on your website is three different — I don't know if we'd call these modules or capabilities. But it's design, connect, observe. Can you just walk me through? What are the three big jobs to be done here?

Cory: Yes, we're actually in the process of making some changes. So, by the time this comes out, it might be shifted a bit. The original idea — this was mind blowing to us. Again, this was built by an operations team. So, it's like all three of the co-founders have worked in the operations space for a number of years. When we started working on this, our idea was that people don't necessarily enjoy doing the cloud operations. But it's like a lot of the people that I've worked with, where I was an operations person there on the dev team, they didn't like doing DevOps, or they didn't want to do the DevOps stuff. My bias was always, oh, people aren't excited by it. People don't want to do it. It's a little complicated.

What we started to see is, there's just not a ton of people that have experience with it. There's this local bias of like, oh, I know operations engineers. Everybody knows how to work in the cloud. But when you get out into the greater audience of software engineers — people coming out of boot camps, people coming out of colleges — nobody teaches production there. Nobody teaches how to run our software. They teach you how to write the software. Writing alone is difficult to teach. And so, when we build this, originally, it was like, okay, it was very high-level. It's like, hey, you can connect all these things. What we started to see is, our customers were coming in and they were like, "We start with the network." It's like, "Okay. I don't remember how CIDR ranges work. I don't remember how subnet work."

We actually started out as a product that was very easy to prototype stuff, if you knew what you're doing. And so, we've started to move away from that a bit. What's going to be out, probably by the time this goes live, is we're shifting the perspective to focus from your application side, and then you can tell us what you need. My application needs an event bus. It needs Postgres. Then we can generate the infrastructure for you. So, we still very much have that design phase or designing from the point of view of the application now rather than the network up. Today, you go and you add a network. You add a cluster. You connect it. You add a database, and put it on your network. You add an app, and you connect it to your cluster in your database. And it's running. Literally, our sales guy can get Kubernetes, Postgres, and Redis up with an application running on a load balancer in 10 minutes. Seven of those minutes are Postgres deploying. So, that is the design phase.

Connect is just literally connecting. Connecting is actually our intellectual property. Again, when you see the canvas, there's boxes which are the actual pieces of infrastructure. Then there's the lines in between it. The boxes are just IaC. That's actual real code written by somebody who's an expert in that. They publish it into our package manager. When you drag it on, it provisions it. You can write your own packages as well. Where the magic happens is the lines. When you connect the boxes together, each box has — we have a cloud type system that describes the cloud and use cases and how things function in the cloud. When you drag one of these boxes — whether you write it yourself or whether it's ones written by Massdriver — if you say what the type is, it comes out of it.

You might have Postgres. That is a type. That's something you're looking for. It's a very use case-oriented type in Massdriver. But if you're on AWS, it might be RDS with 15 replicas and some router roles and some IAM. If you're on GCP, it might be CloudSQL with three instances. What's inside the box doesn't matter. You use a software developer, so long as you're getting highly available Postgres. We have this type system. Then the lines are a direct digraph. So, we know what you deployed, whether we wrote that package or not. And we know the dependency direction. We use that to do things like automate IAM. You get principle of least privilege of Massdriver with no effort. We can see that your application is using S3. We can see that you've set you're writing to S3. We'll generate an IAM role for your application. We'll generate just enough policy for you to be able to write to that bucket. If you say that you read and write to the bucket, we'll generate enough policy for you to read and write to the bucket. Similarly, if you draw a line from an application to a Kubernetes cluster, it configures your continuous delivery.

Again, behind these boxes is all the code in the world. If you want it, it's like you get continuous delivery out of the box by drawing a line. If you say, "It doesn't work the way I want. I want to do some more interesting AB stuff," then you can fork the bundle and modify how the AV rules work and the rollout rules work for your continuous delivery. When you draw a line from a database to an application, it injects the database credentials directly into the runtime, the environment variables, your application. That's where you actually hit code for the first time when you're using Massdriver. You're saying, I'll route those connections into your applications environment.

But the cool thing is, if you really just want Postgres, you drag Postgres on. You connect your app to it, deploy it, and you're getting something that's been SOC 2 scanned, HIPAA scanned, PCI scanned. If it's on a cloud, it's done in the cloud's security scanning on it. IAM is automated with principle of least privilege. Security, like credentials, the only place they exist are in your applications runtime. You don't have to set up HashiCorp Vault. You don't have to set up Secrets Manager. You don't have to put something in last passwords directly injected into the runtime of your app. That's the real magic. That's the connecting part.

Then the observe is, it's not quite a platform if you can't tell what's going on in it. And so, we have automated monitors and alerting by defaults. We have an alerting system similar to PagerDuty. If something breaks, you get an alert in your email. You click the link. Instead of going to Datadog, we're going to look in a bunch of logs trying to figure out what the hell's going on. We take you back to the diagram, highlight the piece of infrastructure that's experiencing the issue. Then your alerts are right there. We just rolled out automated metrics as well. So, now your metrics for all of your cloud stuff streams back in real time. Your diagram is now your dashboard where you configure infrastructure, and it's where you're able to get alerts. So, you can see the full health of your system and address any issues right from the platform.

Erik: Got you. Then, on your website, you also go into a little bit of detail probably more on the connect side. So, you have this — maybe this will change by the time you have the next update out anyways — four supported platforms. That's AWS, GCP, Azure, and Kubernetes. Seven supported data stores: Postgres, MongoDB, et cetera. And then these 58 production-ready best practice bundles. I guess the platform is pretty intuitive. The data stores, likewise. The production-ready best practice bundles, what does that entail?

Cory: Everything in Massdriver is a bundle. If you deploy your application in the Massdriver, it becomes a bundle. What we do is we take — anything that gets deployed, we package the IaC around it or the infrastructures code around it. Even if you're running a Docker container in Kubernetes, there's still some cloud IaC to it. Your application needs a role, at least, and it may need some other resources as well, like service accounts, et cetera. Everything in Massdriver is a bundle. All the boxes that you see on the canvas that you're connecting together are bundles. And so, databases are bundles. You can add new database support. Actually, I think we have 7 databases that are in Mass Driver by default. I think there's probably 13 variants total. There's like RDS. There's serverless Postgres, MySQL, et cetera.

The rest of the bundles are things like queues, API gateways, lambdas, networks, machine learning workspaces. So, it's pretty much all of the high-level concepts you think about in the cloud. Again, we're very use case-oriented. We have a network. We don't have subnets and router table modules. We have a module that describes the entire idea of a network in as few parameters as possible.

Erik: Okay. I'm curious, your thought process for how to grow this. I guess there's a couple things that I've seen, platforms — maybe platforms that are maybe more application-oriented than yours. But in some cases, they identify customers who are a bit more tech-savvy and are basically building out what you're calling a bundle. So, they might build out a new bundle that you don't have in place, and they'll customize it for a particular situation. Then in some cases, companies are bringing that in and repackaging their customer's work as product. In some cases, they're also allowing their customers to monetize that and say, "I've created a new extension almost of the platform."

I'm not sure if that makes sense here. I'm reflecting more on industry vertical where they might be building something for quality checks on the platform and then saying, "I want to add that as a new module on the platform." Then I guess the other approach is you wait for customers to come out and send a request and say, "Hey, can you help us with this?" And you grow organically in that way. What's the path? Because I guess, you have 58 today. I'm sure this is going up week by week. So, what's the model there?

Cory: Yes, we have a couple as far as growth for adding more functionality. We have effectively two work streams. We have the platform which has all of the functionality and the UI and the CLI. That's an important note. We have our CLI as well. We're API-first. We're not one of these cycles that you can do everything. It's actually a GraphQL API behind the scenes. Anything you see in the UI, you can actually do more in the GraphQL API. We ship graph first. But you can also do GitOps. There are some teams that don't GitOps. You can do GitOps in Massdriver. You happen to get this sweet diagram as a part of your GitOps model.

As far as how we add more bundles, that second workstream is bundle development. We build them in a couple of ways. When we first made Massdriver, there were no bundles. We came to our first customer like lists, platforms. You write some TerraForm or Helm. You publish it in the platform. It's like TerraForm cloud, except you can visualize the thing. It does all these security practices for you. Our customers were like, "We don't know how to build cloud infrastructure, so we're not going to write TerraForm." We're like, "What do you mean you don't know how to write?"

One of our first customers, he was like, "I don't know what the f*** a CIDR range is. He's the CTO of a very large company." It was just like, okay, people really don't necessarily have this expertise to even start using the platform. So, we started building these bundles so people had a starting point. What's funny is, we actually had a bunch of these bundles built because we use Massdriver to run Massdriver. We essentially just took all of our private bundles that we were running our software with, and we publish them first. What was nice is like, we went through all this security scanning, all this compliance scanning, all this effort to make them best practice following reference architectures, because we're all paranoid ops people that are working on the platform. All of a sudden, we had all this functionality. Customers were like, "Oh, this is great. I can run a Kubernetes cluster in five minutes, and my Postgres. I can just attach my apps to it, and it's running." It's like, oh, people want the bundle functionality. So, we started leaning into that.

We actually spend one day a week. Every Friday, everyone on the team starts working on bundles. So, it's Bundle Dev Friday. We do smuggle that ish Friday. We actually are big fans of the idea of four-day work week. So, we're down to four and a half days right now. So, half-day Fridays, we work on bundles. There's two goals in that. One is just to get more functionality of the platform. I would love it — actually, I do love it when somebody comes to the platform, and they can build exactly what they need, and they don't have to think about ops. That's great. That's great. That is exactly what we want to deliver to that person. They get to focus on their software. They get to focus on shipping customer value. When they're ready for an operations team, their operations team is going to be super excited that they've got compliance security, TerraForm, and it's running in their cloud instead of being trapped in the past.

The other thing that we do with building bundles is make sure that the experience is good. It's like we can go to the UI and connect things all day long and see, oh, the UI works great. It's really nice to be able to draw stuff. But I know, at some point in time, there's going to be operations people working on these bundles for their engineering teams. I want to make sure that that developer experience for operations is as great as the user experience for their developers in the UI. The other thing we're doing with the bundle development is just constantly trying to make it easier to build stuff. We've got some tools now that can take TerraForm modules from the TerraForm registry, automatically generate a Massdriver bundle from it, and publish it into the platform. So, if you have existing TerraForm and you want to run it in Massdriver, you can run this tool and it'll package it up.

Now, why do we do that? Because the Massdriver bundle is your IaC tool. Plus, it is rich validation in UI. So, you can actually even control the user interface of Massdriver. You can make enums. You can add rules to make sure people are entering valid values, et cetera. That's the two ways that we grow those. Now we also have enterprise customers that come on. And sometimes we're like, okay, as a part of coming on, we need this functionality. You don't have a bundle for it today. So, we'll prioritize building something like that. That's where a lot of our actual Azure stuff came from. We had a customer come along and like, "We run on Azure." And so, we're like, "Okay. Well, we'll build a bunch of Azure modules." They were like, "It's going to take you forever." We did it in a week. So, it goes to show how easy it is to extend the platform.

Erik: Since you brought up this bundle Friday and your four-and-a-half-day workweek, I'm curious about this. I mean, when I look at the About Us page on your website, you really get the feeling that the people here enjoy working there, and that you have a culture around that. We're trying to figure this out at our company as well. I'm also of the feeling that consulting has a reputation as being a terrible work-life balance. Get young people, and work them until they bleed. Then they move on to something where they can actually have a decent life. In IT, I guess, traditionally, you also had this kind of 996 lifestyle. I think, for a lot of people, that doesn't work anymore. But you still have a high-pressure environment, high performance environment. So, how do you manage that as a tech company managing work-life balance with your team?

Cory: I mean, there's definitely points in time where people work more than four and a half days. I think that is something that you can lean into when you have a really good work-life balance. When people are stoked about coming to work, if they have to work a late night, it's not as exhausting anymore. But one of the ways that we work around making sure something like that doesn't happen is, A, we're very vocal about getting the fuck off line. Like one of the guys on my team — if he hears this, I think he's going to know exactly who I'm talking about — I see him on at 7 PM. Sometimes I'm like, "Why are you online? Go hang out with your family. Get off of the site. Go do something." And so, we encourage people to leave at the end of their day — one.

Two, I think the way that we approach work is very different as well. We follow Basecamp's Shape Up. We don't do things like, "Hey, how many points is this ticket? Is it five, or is it seven? Is it medium? Is it large? You have a deadline." Instead, what we do is, we have an idea of what we want to put into the product. Me and my co-founder come up with how much days’ worth of effort it's worth. What we say is like, "Hey, this is worth three days of your time. Spend three days working on it. At the end of three days, if it looks good, we'll put it in prod. If not, we'll try to determine how much more time we think it's going to take, and if it's worth that much more effort." The incentives, they're a bit more aligned. Instead of saying like, "Hey, it's seven points. You have to have it done by Friday," none of that even makes sense. But if I tell you, "Hey, this is worth three days of effort. Let's see if we get it in," it shifts the way we do our work. I don't know. We ship fast.

It's really funny. As a CEO and as somebody who's building a product, I occasionally feel like we're moving so slow. I feel like it's glacial sometimes. But it's funny. It's like, a year ago, a year and two months ago, you couldn't delete infrastructure maps driver. There was no sidebars. There were no public bundles. You had to write your own. And in less than a year, we built an alerting system. We built an automated metrics ingestion system. We've built an IaC agnostic provisioning engine. We've built the platform itself. We've built our package manager, which is IaC agnostic. So, when you see the amount of stuff that we built in a year, it's mind blowing that we've shipped this much stuff. Because we've got like six businesses worth of software in our one product.

And so, I think it's just giving people that time to actually have that freedom. When they show up on Monday morning, they're stoked because they had two and a half days off. It's not like they were working till 6 PM on a Saturday, and they haven't seen their families. I really think that just being excited about the work you do rather than doing some work is what makes the big difference there.

Erik: Yeah, I agree. You can get a tremendous amount done if you're motivated and working with people you enjoy working with. And you can waste a tremendous amount of time if you're exhausted, and your mind is not quite working. You feel like you just got to fill up the hours, or you have to participate in every meeting, because that's how you get FaceTime. Yeah, it makes make sense.

Last thing I wanted to touch on here, Cory. Maybe there's a couple other things you wanted to share. But the last thing I had on the agenda here was your pricing. I always think it's interesting to understand the logic behind a company's pricing model. Yours seems pretty direct. It looks like it's a percentage of monthly cloud spend and somewhere between like 10%, 20%, something like this. Maybe first, you can describe what it actually is. But then I'm interested in your thought process of how you selected that pricing model.

Cory: Right now, our pricing is 30% of your managed cloud spend — so, stuff that Massdriver is managing after your first $500 a month. The goal is, I want the platform to be accessible and free to anybody that doesn't have a large cloud spend. If your cloud spend is less than $500 month, Massdriver is always free. The thing that really sucks about what we're doing is, I can never truly give you a free hosting experience. Heroku can do that. Well, actually, Heroku can't. They're taking away from you. But some people can actually give you the compute for free. We can't because we run in your cloud account. There is a base cost to running a Massdriver because you don't have to pay AWS or GCP or Azure.

I want people to be able to learn about the cloud, and it's hard to do that. It's hard to go run something on AWS if I have never done it before. What I don't want to do is say, you have to pay for AWS, and you have to pay for some Massdriver. So, we have that cap on there. It's like, if it's less than $500, you'd never get a bill for Massdriver. After that, it's $0.30 or 30% per dollar. If your bill is $501 a month to your cloud account, your Massdriver bill is $0.30. And so, the goal there is that scales pretty well. If you get up to, let's say, $10,000 a month of cloud spend, it's a $3,000 Massdriver bill.

How does that play out? It's like, okay, it's cheaper than an operations person. You're still at that point where, if you look at $3,000 a month, that's $36,000 a year. If you go hire an ops person in the US, you're talking $150, $180 just salary, before benefits, before all the business stuff. Then to be able to get full utilization as somebody with that deep expertise, and even find that person that has — they know Mongo. They know RDS. They know your language. They know everything about your stack. It's going to be very hard to find. And so, if we can help you get to the point where you're able to ship software without bringing in this expensive person that has deep expertise, that you're not ready for yet, that's a benefit.

Really, what we see is, most people, they'll hit that — we have a slider go up to 10,000. That's usually around the time where people ask us for fixed pricing. So, we're pretty cool about getting people — fixed pricing looks better for us. If I go to my VCs and I say that I've got ARR instead of monthly billings, it looks great. We want to get people in the fixed pricing. So, if there's concern about the 30%, we're pretty quick to find a percent that works and lock people in. That works for most of our customers. Everybody else is sitting in that usage base consumption range.

Erik: Got you. Yeah, it makes sense. Good. Cory, anything else that we haven't touched on yet that's important for folks to understand?

Cory: Yeah, about the platform, I think we want to do a lot of it. Honestly, I'm really just interested in more people getting deep expertise with the cloud. I wrote an article recently. If you search for Elephant in the cloud, it's on the Microsoft blog. I was invited to write a thought piece on the future of the cloud. It's just about this existential dread I have. We are building, or not building. We're making a lot of software engineers. We're plenty. The growth rate of software engineering role is five times any other job in the United States. We're making five times more software engineers than we're making doctors. We're making more software engineers, less lawyers. Some people might say it's a good thing or a bad thing. I don't know. Jury is out on that one.

We're making a lot more software engineers, and we're not making as many doctors and all these experts anymore. And so, the problem with this is, now you start to look like five years from now, it's like a good portion of our industry has only five years of experience, less two years of experience. We're just constantly making more and more engineers. We have a lot of people without this production experience, a lot of people without deep experience. And so, it worries me where this ends up. What is it? 67 years ago, there was one software engineer. And now there's more software engineers than there is the population of Australia. That's nuts. There's way more software engineers than almost any other job on the planet.

When you think like the years 2050, we do have AI. Maybe it's helping doctors do surgery. Great. The person that wrote that software went to school for 12 weeks and came out of a boot camp. But that doctor went to school for eight years and did a residency. And so, it's really funny to think about professionalism and software development. We're an industry of hobbyists, and we very much have grown. We very much approach our jobs this way. But we're getting to the point where every single industry on the planet is a software company. I think that we need to start approaching software with a bit more professionalism.

I would love to see, if in 2050, there's actual medical software engineering career path, that is great. Let people get some of that expertise. I think we need the same thing for operations. Somebody has to operate these systems, and we're not doing enough training and education in that. And so, I would love to talk about it. If anybody wants to hit me up on Twitter and talk about how we get more people operational expertise, but we don't have enough — and everybody has to run their software someplace. So, that's something that worries me. So, hit me up if you want to talk about it. Because I would love to find a solution.

Erik: Yeah, awesome. Well, folks, that is massdriver.cloud. Cory, thanks for your time today. I really appreciate it.

Cory: Yeah, thanks so much.