Otto, Vagrant, Automation

Welcome back everyone, this is the Change Log and I'm your host Adam Stikoviak. This is episode 180 and on today's show, Jared and I are going by Mitchell Hashimoto, Megrant fame, Otto fame, Hashi court fame, and it's so great having a guest like Mitchell back on the show. This is Mitchell's third time on the show as a matter of fact. And what's most interesting about this is that Mitchell has built his company on top of his open source and it's so nice to have guests like Mitchell back on the show to share all their doing, to share all their learning and to just keep sharing what they're doing in open source.

So it was awesome having him back. We had four awesome sponsors for the show, co-chip, brain tree, backlays, and also a node. Our first sponsor is co-chip, a longtime supporter and huge fan of the Change Log, head to co-chip.com slash the Change Log to check out what they do in continuous delivery, continuous integration, check out their blog, we feature every single week in Change Log weekly, you can easily set up continuous integration for your application in just a few steps and to pull your code when your test pass using co-chip, get started today with their free plan, when you upgrade to a premium plan, use our special code, the Change Log podcast, that will get you 20% off any plan you choose for three months, head to co-chip.com slash the Change Log to get started and now on to the show. Welcome back everyone.

We're here with Mitchell Hashimoto, founder of HashiCorps and Mitchell Gapton, forgive me because I know sometimes people say Hashi and some people say Hashi so you can probably correct me or us on that but you're the creative auto and vagrant and packer and surf and console. You're an already author and a developer that's obsessed, as you say, with automation. So this is free for you. Welcome back to the show.

Thanks. Thanks again for having me. And we of course got Jared sent to online Jared's Hello. Hey everybody.

Happy to be here. We are third three-peat guest, which would be the triple three-peat, which is I think he should win something. I wish we had something more than t-shirts to get away. I did get a t-shirt from you.

Go for con, I think so. All right. Cool. Well, we can send you three more.

We'll send you three more. So yeah, this is three-peat for you Mitchell. If you didn't know, third time on the Change Log, first one was with win back in episode 72. That was February 9th, 2012.

So that was not very long after you founded HashiCorps or HashiCorps and episode 88 was your second one. So not far after that. It was 13. That was me and Andrew talking to you then.

And like I said, for reference to this show, we're doing today that everyone's listening to is episode 180. So big, you know, 72 episodes later. So lots changed since since the last time you've been on the show. But I guess for those who may not have gone back and listened to 72 or 88, what's a good way we can intro you to the change log?

I think if you're a developer, I think that the most well-known thing would be as the creator of Vagrant could be the most interesting and since then I've just been working on a lot more stuff, spent a few years basically focusing moving along from developers more towards operators and security and IT and like that side of things. And I think very relevant to what we'll talk about today, most recently have been swinging back full force to developers. So yeah, that's sort of it right now in a very abstract sense. And the intro I said, Hashi, Hashi, which one is it?

Well, if you're speaking Japanese, it's Hashi. But I mean, either way, it's really fine. It's phonetically fine to me. I always wonder if I'm like, because I know it extends from your last name.

You know, it's kind of rooted in your identity who you are. So I didn't want to like, you know, say your name correctly or say your name incorrectly. Also your company name correctly. So if there was a right way, let's let's establish that so we can not deviate.

Sure. I mean, it's the correct way it's Hashi core. I think maybe developers were used to or even influenced to say Hashi core because we're used to doing things or hashes. So yeah, that could be it.

And then I guess if they didn't know you or your last name, they might even think that your name is a play on a hash for some reason, maybe. Yeah, I haven't personally gone back and re listened to 72 or 88 in prep for this call just because I think he was lazy, but I can't imagine we did a great job of sharing some of your history. And just while preparing for this call, I still don't know this article from Business Insider. So I thought it'd be kind of interesting to start this show with a bit more depth on not so much just what you produce and what you and your team, your company produce, but a bit about who you are first.

I think this is an interesting article because the title of the article is a 25 year old coding genius was making half a million dollars a year in college. And he just raised 10 million for a startup. I mean, that's a bold title for one, but I read this article and I was just like, wow, man, what a rich history you have getting into computers, right? And you got your parents opposition into some things that happened when you were young.

I mean, the first text up you did was in when you were 12. So someone can go read that article and get the same thing. But I was just hoping you can share some, some thoughts and some history of who Mitchell is to the audience. Sure.

I want to start by making a few go back and read that article. I'll start by making a few corrections. The article report article portrays my parents sounding a lot meaner or disapproving than they were. So it's harsher than it should be.

Let's just put it that way. But sort of, yeah, I mean, I started, I picked up programming when I was 12 and I don't consider myself a genius by any means, but I, you know, I've been doing it a long time. So I have sort of that behind me. And one thing I noticed going back in my history is that I've always been passionate about automating things.

I mean, I got into programming because I like to automate things. When I was 12, I was automating video games. So not cheating them in the sense of pretending the human was playing versus, you know, circumventing certain things. So I was actually playing the game by using a computer code, I guess.

And that's how I sort of gotten into trouble as the article I think mentions. I was automating games and some game publishers, game makers didn't like that. So I got into some trouble there, stopped doing that. But I sort of moved on into legal things after that and, and created a small business that automated the setup of PHP forums.

I created a small business in college that automated getting you into classes you want. I, for fun, created, continued to create sort of like game bots, but just for myself, just for fun. And it sort of led to where I'm today, where if you look at all the, all the stuff I built, it's around better automation around developers, operators, data centers, that sort of stuff, and you sort of alluded to it. But yeah, I mean, I sort of wasn't sure if computer programming was going to be the thing I did professionally, it was really just something I love to do.

I sort of viewed it with concern of whether it was a real career or not compared to like a doctor or a lawyer or the more traditional quote unquote real careers. But I got really lucky, my freshman year in college, I got a pretty for a freshman, I got a really good job as a developer at a consultancy. And I think that really proved not only to people around me, but to myself, that this could be a pretty good career. You know, as a naive 18 year old, I had no idea, you know, how, how good of a job being a programmer could be.

Was it really a half million dollars? No, so that's a great one. It wasn't half million dollars a year. It made quite a bit of money, but it wasn't quite that much.

It was, I guess I would just say it was low with six figures per year. And I eventually sold that business. Can we camp out on the game sheets for a second? Cause that, that has my interest.

Yeah. So when you said that, I usually thought like game genie back in the day. But this was like web games. Can you explain to how, how are you cheating the games and how do you like as a 12 or 13 year old, how do you figure out you can do this and how to get into that?

Yeah. So it wasn't cheating like game genie, although I certainly had a game genie. And that was fun, but that wasn't what I was doing. I was cheating in the sense of bonding.

So I was, I wanted, I wrote programs that would play the game for you as if you were, as if it were a person. And that fascinated me in a lot of ways. And so the game I was cheating at the time, primarily was Neopets. Not because I cared about it in any particular way.

I don't know that game. What is it? It's just like a web game that you, it's sort of like, you know, you get a pet, you play games, you get virtual currency, you buy things, I don't know. It's, you live like, it's, it's like a really weak second.

Wasn't there also like a device you can take with you that was part of the Neopet? It's common. Not what I played. Maybe they went that directly.

OK, eventually. But I mean, I wasn't that interested in the game itself, actually. Like I found it because it seemed like an interesting target, so to speak, of, of bonding. So I just wanted to see if, if using bots, could I make a ton of this virtual currency and win the game, basically, and, and I had a lot of fun doing it.

Does someone teach you how to bot or would you just figure it out? Were you going to JavaScript or were you coding it? I was coding in Visual Basic. And I found it by, so my first Google search ever, I remember Googling for it, was how to, not Google search ever, but Google search related to this ever, was how to make an EXE, all the windows at the time.

And I just wanted to know, I mean, I had this weird realization when I was 12 at the time that, you know, I was double clicking these EXEs and using them on my Windows computer. And I was like, wait a minute, someone made this. And so I suddenly began curious, I was like, if someone made this, then how did they make it? And why can't it be me to make something like this?

So I started Googling, how to make an EXE, which I remember also had awful results. Like didn't really solve anything for me. But I just kept poking around at Google searches until I started finding a little bit more, um, it led to Visual Basic eventually and I used Visual Basic. I'm also kind of curious about the, the business that you were running or starting in, uh, unless, unless you got more on the, on the game speech, when I dive into, I want to take away from that.

No, I, I got to fail. Thank you. I'm curious in college, um, I'm reading back and the quotes actually says, um, I was pulling in about a half a million a year. He said, so that's you saying that's, that's what you told business inside when you're doing this thing, but what was the business?

Like what, what was the business you were doing and what kind of eyes and ears and what kind of thoughts that evoke for you to like produce this business and then like move on to what you're doing now? Where were, what was that business about? Yeah. Uh, well, the correction is, I told, I, the one I, the quote I gave them was it was making about half a million, uh, over its lifetime.

So that helps answer the business inside are not exactly known for their accuracy. Uh, yeah, it's certainly made for a flashy headline though. So, uh, props to that. But yeah, it was not correct.

I wish, I wish I had multi millions of dollars right now, but, um, um, and, uh, yeah, so the business I made was basically, uh, and again, I was scratching my own itch, uh, which will be a theme throughout everything, but I was scratching my own itch, uh, to the university I went to had a really terrible, um, registration system. So if a class was full, then there was no wait list. Uh, you just couldn't get in. Um, you could try to get in by going to the class once it started, but that was pretty risky.

Um, so basically what students would do is refresh the page every day, like, I'll just check every day when I am bored to see if there happens to be an opening and then I'll pick it up and, um, I didn't like that. So I wrote a program for myself to do that for me, to refresh the page for me and then get me into the class and I was in a dorm at the time. I was a freshman and, uh, the door on my floor suddenly like was gossiping that I had, uh, I had this technology and so I would get knocked on my door being like, so I hear you have a way to get into full classes. And then I was like, hmm, and so I gave it to everyone on my floor for free that asked.

And then while I was doing that, uh, I sort of built it into a self service website thing, um, and charged people, uh, five dollars per class, uh, to register a listener basically to notify them when there's an opening. And I did this my freshman sophomore year and then, uh, sort of the, I guess the change that happened, which was, uh, uh, the pivotal moment from a business perspective is that, uh, there was this critical, this critical mass when students suddenly realized that if they didn't pay this website, five dollars, there was a, they felt at least, I don't believe this is necessarily true, but they felt that there was a zero percent chance that they would get into the class because, uh, there's, uh, my thing was checking thousands of times a day. Students only check randomly. Like there's no, there's a very low chance that they could get in versus the robot.

So, um, it ended up, there was a very huge growth period where suddenly students were just paying me five dollars to hedge a bet basically, um, to, to give a chance. And so that, that's sort of how the business progressed. And then, uh, I ended up selling it, uh, when I started Hashi Corp, because I wanted to focus, uh, full time on Hashi Corp. I didn't want to be distracted by a side business.

So, yeah. So when you sold it, were you still in college? Did you graduated? I graduated, I'd been out of college for a couple of years.

Okay. So you continue to run it. And I mean, were you, let me ask another question on that part, were you inspired by that business? Were you like, uh, not really?

Like I can see. I've been inspired by Hashi Corp, right? Everybody can tell that, but were you inspired by that business? No, it wasn't a very inspiring business.

I think I was very proud of it. And I'm very proud that I was able to like get it to the point it was. And I learned a lot, but I wouldn't say I wouldn't describe it as inspiring. Um, it was, it was a nice secondary income.

Maybe, uh, now's a good time to maybe share a few updates. Since the last time you've been on the show, like we said, this is a three Pete for you, episode 72, episode 88. And the last time you're on episode 88, that was May 15, 2013. So lots changed, lots happen since then, just a little over, a little over two years, uh, two and a half years roughly.

So maybe catch us up with Hashi Corp with yourself, maybe some influences to the business. What's, what's changed in the last couple years with Hashi Corp? Oh, wow. Yeah, uh, so much actually.

I didn't realize it was that long ago. So yeah. Um, so since 2013, I mean, I guess I'm best known for creating vagrant. But since 2015, we've, as a company, created, um, eight open source projects and one commercial product and, um, the eight open source projects, which are probably the most interesting for this podcast are, uh, ranging from vagrant, which is very developer focused to something like Terraform, which is more, uh, operator focused, perhaps, and then to things like console and vault, which are things that run in your data center that run in production.

So they're more, uh, reliability focused in terms of like a reliability engineer would probably be looking at those, uh, as well. So I, we sort of built this range of tools that span this whole thing, uh, and since then sort of the, the adoption of all of them have been really awesome. So, uh, I guess the, the party trick that I have now is, is, you know, name, name, five semi popular, like five websites that are, that are not esoteric and, um, I could confidently predict that three of them will be using our software, um, which is a pretty cool place to be. So I'd say that's the, that's, that's developed over the past couple of years.

What about as a, as the company itself, well, the internals, the, the people, what's changed since then? Sure, um, the, the big thing has changed is we started hiring a lot more. So, uh, we just crossed the 30 person mark, uh, but, uh, 12, I guess like 18 months ago, there was only three of us. So we went from three to 30 in about 18 months and we've been hiring from the community primarily.

So core committers, people like people, like maybe our core committers, but contribute a lot, uh, people that are on the mailing list a lot. We've been hiring out of our community. Uh, it gives us a high degree of, you know, confidence that we already know how they work and, and they already like what we do and things like that. So, uh, that's what we've been doing.

So we have now, uh, at least one full-time person per project, um, but most have a couple that are overlapping on multiple projects. So full-time person that might be working on Terraform, but also working on Packer or something. Um, that's been the big thing. And then this year, the major focus, um, since the summer, so not too long, um, a few months has been, uh, really working on the commercialization angle.

So we, uh, announced our commercial product atlas and, uh, we, we more or less completed our initial open source portfolio with our conference. We had a conference last month. Um, so we had the eight open source projects and, and now we're really ramping up on the sales and marketing side and getting that going. I recall seeing word about that conference time until we had FOMO when I saw it was like, man, I didn't even know about it.

So, uh, next year, did you, I mean, maybe I don't follow you close enough. I mean, we are the change log around here. So we keep our ear pretty close to the ground, but how do we miss it? I don't know.

I don't know. I don't know. I would speak about it here and there. I heard about it while it was going on, but not prior to it to where I could have attended.

Yeah. Yeah. I felt like, I was like, man, I felt kind of slighted because I was like, I, if I'd have known about it, maybe, cause we've been trying to go to conferences more, like you mentioned earlier, uh, Mitchell, that you got a change all T shirt from August, so we're trying to do a better job of, uh, of supporting conferences and going to conferences. We can't, uh, you know, as Jared and I, two people, we can't go to every single conference, but, um, we might have gone, might have gone.

Yeah. Sorry. Sorry. I don't know.

I, I treated about here and there. I definitely didn't like shout it off the rooftops, uh, but yeah, we, we'd announce it back, I guess, I don't know, maybe early summer, like June, maybe just before June, uh, we started taking sales around June and, uh, we sold out, uh, in late July or early August. So yeah, it sounds like you, it was a success because you're talking about next year. Yeah.

I think it went really well. It was, it was the first conferences are always fun. Um, I've gone to a few first conferences for open source projects, uh, just a few, just, I think three and they're always really fun because the projects, at least the conference usually isn't mainstream enough that you get like the thousand people there. It's usually pretty small.

You just end up meeting people from the community, early users, really passionate users. And it's just really a fun vibe. And I think that over time, a lot of these conferences, uh, they gain, they remain really, really fun and entertaining and valuable, but they lose some of the initial, like it's weird to say this when it's like 300 people, but they lose the initial like small family feel of, of people that have been through this for a while together and they're sort of, uh, meeting each other for the first time. You sort of lose that more for the, uh, the, the more feeling of mainstream success and things like that.

And I think I hope that's where we're heading because, because that's where you want to get to, but at the same time, the first conference is always a special one. It kind of resists a little bit. So September 28th and 29th, if you missed it will be roughly the same, uh, same month roughly next year, what's the plan there? Do you have any details that you can share?

Uh, probably, but I, I, I really, we really have no formal plans. We just lay here late in the year. Yeah, probably not really. You're just because we're not planning it and I learned, I learned a lot about planning conferences and, uh, takes quite a while.

Well, maybe if you don't mind, we got to take a break here in a second, but run down, but, uh, you'd mentioned commercialization. So I'm, I'm wondering if I'm sure at some point through our conversations around auto and vagrant, which is pretty much what we're going to camp out on during this show, although we can't take left and rights as we need to do. Um, I'm wondering if maybe when we come back from this break, if we can talk about commercialization a little bit, what do you think? Is that all right with you?

That could be. Yeah. Cool. All right.

Well, let's take a break quick. Listen to a word from one of our sponsors for the show. When we come back, we're going to talk a bit about commercialization of open source software and how you are making money there at HashiCorp and, uh, we're back. Braintree is all about making developer lives simpler with code for easy online payments.

If you're searching for a simple payment solution, check out brain tree for mobile out developers out there, the brain tree, the dot zero SDK makes it easy to offer multiple payment types, start accepting PayPal, Apple Pay, Bitcoin, Ben Mo traditional credit cards and whatever's next, all with a single integration into a simple secure payments that you can integrate in minutes and developers. They've got you. Don't worry about taking days to integrate your payments. The brain tree is done in minutes.

And if you don't have time, you have them a call and they'll hand the integration for you and walk you through it. Braintree supports Android iOS and JavaScript clients. They have SDKs and several languages. .NET, Node.js, Java, Perl, PHP, Python, and Ruby.

And their documentation is comprehensive and it's easy to follow to learn more and for your first $50,000 in transactions fee free. Go to braintree payments.com slash changelog. Or back from the break, um, and Mitchell, you know, I know what you said before. Commercialization.

And I read into that and I think sustainability, I think building a company. So obviously that's what you're doing. You know, when we started the show, we talked about the article from, uh, business inside that said you just raised 10 million dollars for startup. I imagine that startup was HashiCorp.

So you got some, some money there, but you're also trying to learn how to commercialize software. So what have you learned that you can share with us today? Well, yeah, this is my first time, you know, actually commercializing, uh, this kind of software, I mean, like software for engineers. Um, but I guess the thing I've learned since starting HashiCorp is that people want to pay for software, uh, you know, open source is really, really popular, but that doesn't mean people don't want to pay for things.

Uh, I think open source is a lot more about, uh, depending who you ask, I mean, this is going to be true or false, depending who you ask. But it's, you know, it's a lot more about, um, legal protection. It's a lot more about, uh, avoiding vendor lock in. It's, um, the ability to, uh, security, like ability to audit things in the open.

Um, it obviously communities a big aspect, being able to ask for help from people other than the vendor itself. Um, so I think like that's what it's about. It's really very rarely about, I just want something free, um, at a certain level, like even small companies, like even people that have, uh, companies that have 10 employees or something, they're very, very willing to pay for software. And I think that the good evidence of this is actually like SaaS is like every small company pays for SaaS, somewhere like they, they're open to spending money, uh, uh, get up, actually, they're definitely paying for get up.

So, uh, that's, that's what I've discovered. And at the bigger, the sort of enterprise level, um, they're not only comfortable paying for software, but they don't, they're comfortable paying a lot for software that works well and solves their problems because it might seem like a lot to, you know, outsider, but it's, it's, it's very reasonable in terms of like what that software is doing for them, uh, what, what are, are, um, sort of senior director of marketing here, like what he likes to say is like, we want to be able to go to Tesla, for example, just using them as an example. They're not, uh, they're not necessarily a customer. So, you know, we want to be able to go to Tesla and be like, just focus on building great cars and let us handle all the infrastructure and deployments that for you.

Like we don't want you to even think about it. We want it to just work for you and let you focus on building cars. And like imagine all the engineers you have hired right now to, um, worry about stuff that isn't your core business. Like what if they were instead of building your car software?

Like that's way more valuable. So, um, that's sort of where, uh, commercialization comes in. People want to pay for that peace of mind. They want to pay for, um, knowing they do have a phone number.

If things go wrong, they want to pay for features that they know don't make sense for non enterprise companies and things like that. And that's where we're focusing our commercialization effort. So you got your roots, your company, in open source was found. And what was the very first, I think vagrant was your very first thing, right?

And that was open source. First successful thing. There was a lot of failures. Okay.

So let's maybe let's skip the failures, but like what was the first thing you guys commercialized and what was that process? Like what have you learned from it? Um, so the first thing we commercialized was we made the vagrant VMware plugin, which is still available today. And it does very well.

So the vagrant VMware plugin pays for a number of salaries and it does well. And the thing I've learned is that there's the, there's a difference between doing something that'll make a small business work well. And then there's a difference between doing something that will build you a large business. And it's neither or wrong.

It just matters what you want. And so when we did the vagrant VMware stuff, I was still very much unsure what I, what my ultimate business goals were with HashiCorp. Um, I had a lot of technical goals, but, you know, was, was HashiCorp going to be like the business side of college where it made a good amount of money. It could pay a few salaries.

We could, um, just sort of do what we want and build it or did I want to build a company that could potentially, you know, be a multi, multi-million dollar company, maybe towards, you know, even for the size of something like VMware or something, like a very large company. And, um, I think the, the main motivator for, for me there was that I had sort of an audacious goal of wanting to build software that would change the way people manage data centers and deploy software. And, and you can't, that's really like that goal is a big goal. And that goal is, it's not enough to convince, you know, every hobbyist developer to do it differently.

I wanted to convince, um, banks. I wanted to convince, you know, Amazon. I wanted to convince these like big giants to like change the way they're doing some stuff. Um, and it's sort of like a naive view of the world.

Like I, there's obviously a lot of stuff I didn't know then that I've learned since then, but with that goal, like I didn't have a chance of talking to these people or convincing them. All right. I'm much smaller chance. Let's say, then if I go the route of raising money and building a larger company, I mean, even the fact of just having money in the bank will give people a talk to you.

I, I, a very eye opening moment was before we raised the series A, um, we were talking to a telco and they were going to deploy, I think it was console and they were going to deploy console, which came out before we raised our series A and, uh, we had to fill out this form and it was the first time I'd ever seen it, uh, a risk assessment form. So we filled it out and they came back and they're like, console's great. It's fantastic. We really want to use it, but you failed risk assessment.

And we were like, how did we fail risk assessment? And they're like, well, we only work with companies that either have this much in revenue or have a bank account with this balance and you have neither. So we just can't work with you as a policy. And like that was a pretty eye opening moment where I was like, okay, we need to, that wasn't what motivated me to like raise money, but that was another factor where I was like, okay, we're going to fail risk assessments for companies because we're so small.

Well, it's like you said, you're looking for ways to, to commercialize, right? And so these are hurdles are getting over until he makes sense on, like, yeah, we didn't even charge the money. Yeah, they were, they wanted to pay us and they couldn't pay us because we were so small. Um, so we needed to sort of raise money.

That was a factor. We needed to raise the, to prove to them, um, that we had intentions of sticking around and growing because it makes sense. You don't want your vendor to be like a four person in a garage. Like when you call the phone, it's going to like their cell phone sort of thing.

You want a real dependable large company sort of to, to depend on when you buy software. I wouldn't mind talking a bit more about raising money. I don't think you got a question on your side. And I know you're waiting to ask it on the transitional piece, but I wasn't mind talking a bit about you learning to raise money.

Did you get some influencers? Did you have a, uh, a mentor, like how, who, who guides you through what you're doing and how did you learn what you're doing to, to build this company? Uh, sure. So I lived in San Francisco, I moved to San Francisco after college and worked here for a number of years and a few years.

And, uh, I use that time in San Francisco to, um, you know, meet a lot of people, network a lot, um, and inevitably sort of working in the startup world, just learning how these things work and, uh, meeting other founders, meeting venture capitalists, um, just, yeah, just really being in the thick of it, even as a developer, just being exposed to a lot of it. So, um, I was really lucky when I went to go raise, I, uh, uh, just reached out to a bunch of people that had done it before and asked, uh, for advice. And a lot of them introduced me to, uh, to, to venture capitalists and to other folks that could give me advice to press and things like that. And that's just how I got started.

I think past that it's a lot of stumbling, like I've just been stumbling my way and hoping, you know, I make a few mistakes during the process, like inevitably will, but that's, that's, I think the nature of doing something for the first time was before the, before the, I guess, abrasion with the company who you feel the risk assessment with was that, was that what kind of like motivated you to raise money or before you're just like, well, we're going to grow. No, it was, uh, no, we were, we were getting motivated over time. So yeah, that wasn't a single factor, but I think, uh, I think what actually really motivated us was that, uh, when we started Hochicorp, we, we did it because we cared a lot about this problem and opposite in particular wasn't, you know, wasn't a, uh, I guess, attractive industry, you know, it wasn't, it wasn't really this jewel that VCs wanted to invest in or anything. We just did it because we wanted to solve problems there, um, and then, you know, thanks to companies like Docker and things like that, uh, suddenly ops became this really fast moving, uh, thing.

And we were contributing, you know, in a small part of that, by coming out with things like console and pushing people faster than they had been before. Um, but it suddenly became very fast moving and we wanted to raise in order to realize sort of our goals and dreams of the software we wanted to build, uh, faster because we were, we suddenly saw the industry speed up and we didn't want other people to come and swoop in and do something differently than, then we sort of philosophically believed in and mess up our goals. So one more business question before we get to the, to the subject matter, which is vagrant auto, uh, I've been looking at your contributions graph here. Well, you guys have been talking because you said you went from three to 30 employees at Hashi Corp in the last 18 months.

So now you have, you know, you're the boss of 29 people and yet you have, uh, 49 commits in publicly this week. Uh, you, you've merged six pull requests, uh, you had a streak of 27 straight days, contribute an open source this year. How do you be someone's boss and yet still get to code so much? Uh, we, so my particular role in the company, um, is really sort of currently being in charge of all the products that's so, uh, I don't have 29 people reporting to me.

Thank goodness. Um, I, I sort of, I sort of work with a lot fewer teams that are working on these open source projects and our commercial product and guide that. Um, but I still love programming. So, um, I just sort of work where I can.

And, uh, yeah, I think that for me, that's the role that I'm trying to carve out for myself is I still think that there's work that I could do, uh, on the programming side. So, you know, the traditional, uh, viewpoint of a startup is you have your, your sales guy and your technical guy, um, does Hashi Corp have that style? And are you the technical side of a team or are you just everybody? No, so, well, with 30 people, you stop being everybody, which is, which is awesome.

Uh, but you, yeah, you definitely, I definitely was everybody for a long time. Um, but, um, to answer your question, uh, Hashi Corp's a unique, not unique company, but I think like IT DevOps, like where VMware is like this, we're, we're creating software for other engineers and it's highly technical. So your salespeople really need to be, have engineering backgrounds as well. And, and there's a number of, I mean, I've learned this, I've discovered this.

There's just a number of salespeople, like they've been doing sales for 15 years that have CS degrees and code for almost, excuse me, code on the side and, um, and understand the stuff and you need to, because at least for us, a core part of our, um, culture is, is trying to be genuine. So trying to go into a company and, and be honest with them. And, and some customers have told us this where we've gone in for a meeting and they've, uh, the sales type meeting and they've asked us like, well, we sort of want to do this with your product and this. And we've just told them like, this is not the right product for you.

This won't do that well. Um, and there was, and some people are taken aback by it because they're like, did you just say, no, in a way? And, and that's just kind of what we do because, because I think our first principles are as engineers and as engineers, we believe in the right solution. And so we need salespeople who are engineers that also believe that, that it's more valuable for a potential customer to like you than it is to close the deal no matter what, because our viewpoint is if we're talking to them, they'll probably need us, we hope that they'll need us eventually anyway.

We have a broad enough set of tools that, uh, maybe that solution doesn't solve something for them, but we're certainly not going to walk out of there without showing them the rest of what we have and trying to find something else at work. So there's still an aspect of, you know, trying to get to say yes and there, but there's also, um, a goal of being honest. The worst sale too though is, is the sale where you implement the wrong solution. You know, like you said, you have a broad enough product line that you're working towards that eventually, uh, you may or you will, uh, have a solution for them really fits.

And if you lose that trust early, then, you know, regardless of what you produce in the future, they're going to be like, eh, they, they kind of, I think it was the right advice early on. And, you know, I mean, yeah, and maybe we're lucky that way, given that we have so many different things. I mean, I imagine it's a lot harder if you're a, like a database company and the data doesn't really fit your model, but there's other, you know, sort of unlikely to change their data model. So you might not have a chance to come in again.

So you might be more inclined to say yes. Um, whereas we're a lot less concerned or offended or anything. If it's like, we're, we're more ready to admit like, okay, the console isn't right for you, but maybe vault is. So let's take a look at that and stuff like that.

We mentioned you got many things, but we are only here really to talk about our beloved tool, vagrant, uh, getting, getting succeeded by auto. And it's, it's an interesting topic. And for the listeners out there, we have a couple of breaks during our show. We're probably gonna have to do a break during the main conversation.

We try to time it so that we don't have to like put a break in it, but we're gonna have to break in like 11 minutes. So give us some forgiveness there. But auto is really interesting. Uh, we obviously love vagrant.

When we had done the show before back at 72, I know Andrew and I went deep on what vagrant was then, but for the listeners out there that are maybe unfamiliar, uh, let's open this up. Maybe with what vagrant is to a degree and what auto is, I guess that's probably, would you say that's the best way to open this conversation up? Just to sort of describe what vagrant is? Yeah, I think you can't really understand auto without understanding vagrant as it builds on top of it.

So let's start there and then he can differentiate auto from there. Maybe pay some history too. Like when it, I think during this conversation, we pinned it back to the origination of Fashikor, but give us some timelines and help us understand what vagrant is before we go into auto. Uh, yeah, cool.

So vagrant is a six year old open source project that is, uh, in one sort of sentence, though it's a one sort of phrase development made easy. So the goal of vagrant is to run one command and get a complete development environment for whatever application you're working on. Um, the problem it was solving was, uh, you know, I was, I was, I was developed for the consultancy and I was switching between a lot of different customers and, uh, different technology stacks and getting that all to work together nicely on my laptop, which is a very different environment than what they were ending up on, you know, in a server, um, was, was a pain, to say the least. So, uh, vagrant was a solution to that where everything, a sandbox and a virtual machine, um, you run vagrant up every single project you have, it's a separate virtual machine.

It's completely isolated. So you could have different versions of web servers and libraries and databases, all coinciding a commingly, I guess, on your own machine, um, and not causing any conflicts. And when you're done working with that project, you could destroy the environment and it's a clean slate, you know, you're not left with craft on your machine. You're not, uh, using any more resources actively.

It's just gone completely in, but you can make it again very easily. So, uh, that was vagrant. It's been growing sort of over the past six years, uh, to effectively be our, our flagship open source project at HashiCorp, it gets millions and millions of downloads, um, a month and it's, it's kind of a monster on its own. And, uh, so six years ago, that was created.

And I guess what, what problems were out there that made auto be a solution to succeed or a vagrant. Cause the, yeah, the block that was planned along ago was the successor of vagrant is, is auto. So this is the successor. So vagrant will go away eventually or we'll sort of, I don't know, maybe you can help us understand that too.

Yes. Okay. So, um, yeah. So the, it's great to the backstone on HashiCorp because that gives a good idea that over the past three years, we've been focusing a lot on operations and making deployment easier, managing servers easier.

Um, and so we've been, during the same process, we've been consistently releasing new vagrant versions, adding features, iterating. Um, but we haven't focused on developers in a few years, like they haven't been the, the focus of our company in a few years. And, and we don't want to feel like they're neglected in one, but we also felt that vagrant was at a really good spot. It was very stable.

It worked really well. But after three years, we, we, we use vagrant obviously every day here at HashiCorp and, and we were sort of discussing, uh, sort of a year ago, I guess, we're like, so we've done all this work to make all these other people's lives better. We hope we hope that's our goal. Um, like, is there any like sort of revolutionary new things we could bring to the development angle, have we learned something that we could significantly change vagrants and make it better?

And so the conversation started with what would we do if we could sort of vagrant from scratch? Like, how would things be different today? And the three sort of things, um, I picked up on from, and this is sort of based on, you know, working with vagrant for six years and, and, uh, and walking in the company and seeing how they use it and, and just seeing thousands of users really, the three things I picked up on was, uh, one, um, development environments are really, really similar to each other. Uh, I think it was funny because on Hacker News, one commented that they think the statements false, but, but I mean, I, I really believe it's true.

I've seen it in a while. Like if you're a Ruby developer and you go to another company in another country and they're a Ruby developer, your development environments are 90 plus percent similar. You have some version of Ruby, you have Bumbler, you probably, if you're the web application, you're going to have a database, you're going to have something like passenger, um, and they're just really similar. The last 10% is like differing versions or passenger versus unicorn or something like that.

And, and they're really details that don't matter too much in the development environment. Um, so what, and it's hard to solve this at the vagrant layer because vagrant is so, uh, low level, uh, relative auto, which we'll get to, but it's, it, you describe sort of the machine it runs on, you describe what server to install, you describe what database to install, you do this from scratch on your own. So it's hard to get rid of this, uh, duplication. So that was sort of the first thing.

And then the second thing, and we could cover, you could ask questions about these in a second, let me just sort of try to say all three. Um, the second thing was that, uh, developers wanted to deploy. So this is really no surprise. Anybody, um, vagrant had a issue, I think, for five years, uh, well, it's probably, it's probably been closed for a while, but it, it, an issue open five years ago, at least that people wanted to vagrant up to production.

It, vagrant up is a really nice, really frictionless way to get development environments. And they were like, why can't deployment be just as easy as a vagrant up? And honestly, we, yeah, so honestly, we tried for a bunch of years at various different points to fit this into vagrant. We tried a bunch of different things, um, and it just never really worked well.

Um, and I, and the realization I made was very similar to number one, which is that the vagrant file itself is just fundamentally not the right. Approach to describe a deploy. Yeah, I do think it was, it is, continues to be a great way to describe development environment, but it's not a great way to describe deployment environment because they're so different. You run multiple web servers, you run a low-down server production, you have monitoring systems in production, um, you have different security requirements, like it's so different from development that you can't safely map a vagrant file to web goes up into production.

So that just needed to be filed out. Um, and then the third and final thing is that, you know, we live in a world with, with microservices now, we live in a world with containers. We live in a world with really lightweight applications that are all working together to do one bigger thing. Um, and that's really different from the world that existed six years ago when I made vagrant.

Um, six years ago when I made vagrant, um, you know, the best practice or the standard practice at least was to just make a giant monolithic grails application or PHP application that does everything that has everything. And over the past six years, uh, that's slowly been changing back to more of a service-oriented model of smaller services that communicate together to mitigate failures. You could use smaller servers. You could, uh, you could develop faster.

You know, they have all these other promises. I'm sure you have or will talk about microservices like as its own podcast at some point, um, but as its own episode at some point, but, um, um, these are coming. And I'm talking about that with Peter McGon microservices. Oh, yeah, that's, that's a great person to talk to about that.

Yeah. So microservices, I don't claim I really don't claim their mainstream today at all, but I, I do think it's inevitable that they will become mainstream. So the third thing I really thought of was like vagrant is not a good tool for microservices. It's, it's build one VM, describe one directory of application files.

It's really hard to describe dependencies and how to install them and, or it's not hard so much as it's very manual and very tedious. And so again, it was like, how do we fix that? And so those were the three things that identified with vagrant that we, that we went on to address in, in auto. Well, I think that's actually a really good setup.

Let's take that break now here from one of our sponsors. We'll get back. We'll find out how auto solves these three problems and probably more. Uh, we'll talk about that on the other side of the break.

If you've ever restored data from a hard drive, you know, it's complicated, you know, it's messy and it's probably something you never want to do again. And backing up is just so much easier. Backlays, a new sponsor of the show offers online backups for your documents, your music, your photos, even videos and so much more go to backlays.com slash change while you're free to be trial, you might be using an external USB hard drive. And that's a good start, but it's better to be safe than sort of safe.

Put your mind at ease knowing your data is backed up securely in the cloud. You get online access to your files from anywhere in the world. You have internet connection, you have Android and iPhone apps for mobile access. And backlays runs natively on Mac and PC, including your external hard drives.

There's no add-ons. There's no gimmicks or additional charges. It's just $5 a month, literally $5 a month per computer for unlimited unthrottle backup and change all listeners to a free to be trial by going to backlays.com slash change law. All right.

We are back speaking with Mitchell Hashimoto about vagrant and auto. So before the break, you said vagrant had three, not necessarily problems, but three things that are different now than when you first started six years ago. Development environments are really similar to one another, at least you've noticed that since then, developers wanted to deploy to which I say, amen. And number three was that we live in a world with containers and microservices and vagrant really can't solve these three problems, hence auto.

So can you lead us into auto? Give us the elevator pitch and tell us how it succeeds vagrant. Yes. So the elevator pitch of auto is that whereas vagrant is development made easy, auto is development and deployment made easy.

And the key difference we made in auto was sort of moving, I would say, is in this configuration format, actually. So instead of a vagrant file with vagrant, you have an app file with auto. And you might be able to tell from the name how it's different already. So the fun exercise I like to do with vagrant users is like, what's the first thing you do when you make a vagrant file?

And the answer is choose the box that you're going to use. Whether it's always the same or not, you write down the box that you're going to use. And that right there is fundamentally the difference between vagrant and auto. With auto, the first thing you do with an app file, if you even write one, and I'll get to that in a second, but the first thing you do with an app file is specify what application type it is.

It's a Ruby application. It's a Rails application, or it's Node, or it's just a custom other thing. And that sort of gives you a hint of the difference. Auto cares a lot more about the application and a lot less about the underlying details of that application, which sort of goes back to the first thing I mentioned with how I would improve vagrant.

So that your development environments are just very similar. It's less important for you to tell auto how to install and set up a go environment when they're all similar, auto might as well just know on its own how to set up. And that's what we've done. So the abstraction chain up one level.

Yes, it's specifying IP addresses and MySQL server or whatever. You're just like, hey, I got a Ruby on Rails app. So you're just a little up. Yes, exactly.

Exactly. And so the way, and I mentioned earlier that app files are even, you know, optionally, you might not write one. So if you run auto in a directory with a bunch of Ruby files, it'll actually detect. It'll be like, well, this looks like a Ruby project to me.

So I'm just going to assume it's a Ruby project. So one thing that's really cool is we've been using auto more at HashiCorp is our designer went into one of our go back and services and ran auto dev to get a development environment and he was like, whoa, like, this just worked. Like, I got a go development environment. I have no idea how to install go.

I have no idea how to compile things and auto not only set it up for me with zero configuration, it also told me how to compile the project. And he was like, I didn't know once he got running, he was like, I'm not running it because I don't want to run it. But he wanted to see it work. And then the flip side, he also had like some really old Ruby projects from years back that he hasn't touched it.

And he went back into those and was like, what's this going to do if I auto dev here? So we auto dev then he was like, yeah, set up a development environment. Ruby bundler auto bundled my things, like set it all up. He was like, it just worked with zero configuration.

And so that's the direction we're really heading. The zero configuration thing really isn't, again, it works and we intend to make it even better going forward. We want you to be able to go into a project with no configuration and not only develop, which I've been talking about, but deploy. So that's, that's the thing.

And then the sort of last major difference, obviously auto could deploy. So we could talk about that in a second. But the philosophical difference between vagrant and auto because people ask me, I guess, why did you make a completely different project? Why didn't you just make a vagrant like 2.0 that has a different config format or something for a lot of reasons.

But the major, major reason is that auto has a really big philosophical difference in vagrants. So if you take a vagrant file from five years ago and you run vagrant up today, it'll probably work. We worked really hard to make sure that that works. But what you get is exactly what you configured five years ago.

You'll get the same version of a patch you configured to get the same version of the language. You'll get the same operating system version you specified. And what we call this is a fossil. So what vagrant files are a form of a fossilization.

So you fossilize and snapshot it. What the state of the world was five years ago and vagrant gives you that today. And that's, that's sometimes a good thing. But the approach we've taken with auto is instead of a codification or codification, depending on how you pronounce it.

The idea is that the app file itself is just declarative of the type of application you're deploying, but the knowledge of how to create development, how to deploy is centralized in auto itself. So not in the vagrant file, but it's in the core of auto itself. So that when you run auto deploy today, you're going to get something. But if you run auto deploy five years from now, it'll probably, it'll hopefully very likely be very different, but the end goal is your application will run.

But with best practices from five years from now, not from today. And so security patches and technology changes and things like that. And, and the people making this happen as the community. So it's a, it's a centralization of knowledge.

So we want the person who's a professional Ruby developer to tell us to contribute to auto and tell us how the best practices of Ruby development are. And we'll encode that into auto so that you get that. And sort of the, my favorite example is that our, our, the person who's up the AWS integration with auto used to manage a top 10 by size infrastructure in AWS. And now if you're just a hobbyist that's running auto deploy in AWS, you're actually getting an infrastructure designed by somebody who was the lead infrastructure person for a top 10 AWS property, but you're getting it for your side project.

And we want that to eventually be true for every technology in auto. If this works as advertised, I think I want to kiss you. This is amazing. When you said that Mitchell, I was like, I know June likes that.

Oh man. I like all of this, Mitchell. This sounds spectacular. So that's, this works right now.

Like zero config, fired up. Yeah. Okay. Yeah, you can go download auto right now to work on.

So the only part that's like not, it'll work as a demo, but isn't ready for like production is the deploy, the, the maintenance part of deploying. So we eventually want auto to completely replace how you deploy things. But for now it'll deploy at once, but it's not good at deploying it multiple times. We, we purposely are focusing on making auto a better development experience first.

And then we're targeting auto 0.3 as the major super production ready deployment stuff. And, and the main reason for that is just that it's complicated. But we believe from the beginning, given the fact that vagrant was never designed for the beginning to deploy, from the beginning, auto was designed to deploy. So we believe we have the fundamentals right and can make this happen in a really nice way.

So let's stick with the develop first, because I mean, I'm super excited about the play stuff, but we need to clarify a vagrant a little bit here, because it says, like on your guys is auto getting started, that first you run this auto command, auto compile. And it says, the first time you run it, it may be asked for permission to install vagrant, which it uses under the covers. In this case, it probably also downloads a base image for your environment. So it's a successor to vagrant, but vagrant's still in the mix.

Do you want to speak to that for us? Yeah, yeah, I'd love to. So there's, so we didn't want to read about the wheel. Like a vagrant is, is really mature.

The bugs it has generally are very, as a terror today, they're usually not very mainstream. And so it works really well. And we don't want to rebuild all that for auto. So auto actually uses vagrant under the covers for a lot of the final, bring something up, but it does a lot more on top of it to make things nice.

So the best example I can give is actually the upcoming version of auto. Auto 0.2, where we focus a lot on development experience. So for a go development environment with auto 0.1, or vagrant, it's just a vagrant file. So or vagrant 1.7 is, it takes about five minutes to get a complete development environment.

It's pretty slow and takes some time because it's installing go, it's installing a bunch of other stuff. So it takes time. And with auto 0.2, we're able to make the go development boot up in 30 seconds. So five minutes to 30 seconds.

And the way we're able to do that is we still use vagrant under the cover for parts, but auto is starting to offload some of the stuff vagrant used to do, and do more clever things, do it with architecture, that would have been difficult to do in pure vagrant. So this is starting to move more logic away from vagrant into auto. And I guess you'll start seeing this over time, is that we could do fancier things in auto. So another example is people who use vagrant have complained.

And rightly so, that vagrant SSH is pretty slow. So a lot of this is Ruby, of course. But if you run vagrant SSH, the time it takes to SSH into the machine is sometimes multiple seconds. And even with auto 0.1, if you were to download auto right now and get a development environment, auto data SSH, which is the equivalent to SSH into the development environment, is a couple hundred milliseconds.

So we went from a few seconds to a couple hundred milliseconds. And the reason we're able to do that is auto is the sole controller of that development environment. So it knows that your SSH information isn't changing. So it caches SSH information and just executes SSH in process directly.

So it's just a lot faster. Whereas what vagrant does is, there's a lot of other commands that can affect the SSH information. So what vagrant does is every time you run vagrant SSH, actually inspects the virtual machine, inspects various things to try to detect the right IP, detect the right password, detect the right key. And that's all in Ruby, and that all takes a bunch of time.

And then some processes into SSH. So we got rid of all that. And now we're just going directly in SSH. And so it's a lot faster.

So these improvements will continue over time to make auto just a lot better development experience than vagrant was. So I would speak to the virtualization environment that auto uses on your machine that seems vagrant or different? Yep. Yep.

So I'm saying, and that was a lot of the reason why we didn't want to sort of rewrite those aspects, yes, at least in auto, because vagrant has a great community around it with support for virtual locks, VMware, Parallels, Hyper-V, KVM, all these different providers. And you get all that same stuff with auto. So it's immediately going to work on your system that way. But what if I don't care?

Like, I just want to run auto compile. What's it going to do? So this is the kind of cool part we did with auto is that auto, kind of like you said in the Getting Started Guide, it installs and manages vagrant for you. So if you don't care, then when you run auto, it'll just ask for permission because it's going to download like an 80 megabyte thing.

But it asks for permission. And then it just manages it for you. So if you're just like sure, just do something like sure, then it'll install. And the one improvement we're making is it'll actually the next version will install virtual locks for you if you don't have a hypervisor on your system.

So that's the idea is you only need to install auto, ever. And it'll do the rest for you. How does it play with containers and Docker and whatnot? Well, so the idea behind auto is that if the best practice is containers, which I would say for a lot of things is right now, then we're going to use containers more on the deployment side and less on the development side.

And I'll talk about that in a second. But so yeah, when you auto deploy, it builds a container and actually will use Docker to run a bunch of things, not everything right now, but a bunch of things. And then on the development side, containers are just, we work with a bunch of people who use containers to development. And they're fast, which is what the nice part, but you lose the sort of save, reload, review, sort of cycle of development, the mutability, like containers on their own are usually a pretty immutable sort of thing.

And you can set up shared volumes with containers and things like that. You can work around these things. But with auto, since we have so much more control over the development environment, we could just set that all up for you. And the containerization part of the container isn't as important.

So the development environment currently just isn't in a container because it doesn't give you a lot. And most people are developing on non-linx systems that you would need a virtual machine anyway to run the container. So instead of starting the virtual machine, then starting the container, like we'll just start the virtual machine and run it there. The main improvement we made over vagrants for this is that even for projects with a ton of dependencies and other multiple services, we're sort of creeping on the microservice part of auto right now, but for things with a bunch of services, auto basically installs all those for you onto a single virtual machine, whereas with vagrant, you might have tried to use multiple virtual machines, which would have been much slower.

So auto handles this complexity for you. So each environment is only one virtual machine for everything you're working on. And that brings a lot of the benefits as well without having to use container sort of element. So what do you say to the people out there right now thinking, I don't want your shiny new auto.

I love vagrant. I love vagrant files. I just want to use them. We didn't need a successor to vagrant.

You're the worst. What do you say to them? Just say that. Yeah, I would be a little bit sad.

But at the same time, vagrant is not going away. So vagrant 1.8 is coming out next month, and it's going to be a huge awesome release. We get link clones support. We get snapshotting support stuff like that.

Vagrant is a really mature project. And auto, there's very few people out there because I know the download numbers from back then, but there's very few people out there who use vagrant 0.1. But vagrant 0.1 was awful. And it came a long way since then to be the product it is today.

And likewise, I think auto 0.1 is definitely a lot better than vagrant 0.1 was. But I think we'll look back and say, even in a year of being like, well, auto 0.1 is pretty bad compared to where we're going to get to. And for the people who want something that they know is going to work, that they don't want to be early adopters or risk takers, then they should use vagrant. And we're going to keep bug fixing vagrant releasing vagrant, especially because auto still uses vagrant.

And the long-term plan for auto is that, yeah, we hope that 90 plus percent of developers using vagrant over the next few years will shift to auto. But there's also use cases for vagrant that auto is never going to attempt to cover. So it also just can't disappear completely. So a good example is for ops people.

People who use vagrant for testing, chef and puppet and things like that. That's really not a goal of auto currently. It doesn't give you the same control of, I want this specific operating system and this specific state to test this stuff. It's a lot more opinionated about setting things up.

So it's really not going to be great for that. And then the other thing that vagrant will continue to to ranking is very similar is just sort of custom really custom environments. So maybe you're doing something with a really strange OS or you're doing embedded development or actually I know a company that does game development in vagrant. So they spin up Windows machines on really beefy hardware and actually do 3D game development in a vagrant environment.

And that sort of stuff like auto is not really going to touch. So we're super motivated. We have people working full-time on vagrants and we're going to keep it that way for years. One question I think that you can probably speak to is you talked about microservices earlier, how they weren't really a part of the world really when vagrant was around, when vagrant first came out.

And auto is built to do that on its own. So it's built for microservices. Can you speak to the built for microservices part? Yep, so in the app file itself, you can specify dependencies of your application.

So these dependencies might be things like a database, but they could also be other services. And what you point to specify the dependency, what you actually do is specify where that dependency's app file is. So you create this chain of dependent's app files. And so what you can do for the source of practically is give it a GitHub address or give it a HT address or even S3 or something.

And what auto manages for you is fetching that file, compiling that file, figuring out how to install that thing. And the practical benefit of this is that the app developer only needs to worry about how to install, develop, and run their application. And they just specify what they depend on and auto manages how to get that into the environment. So as an example, if you have a web service and you depend on a billing service, then when you run auto dev, you don't specify anything about the billing service except that you depend on it.

And when you run auto dev, when you go in there, we'll have the billing service running for you. We'll have fake data already in it. It's just sort of ready to go. And the onus of how to install that billing service, like how to auto know how to do that, goes on the billing services app file.

So auto might just know implicitly by being like, it's a Ruby application, here's how I'm going to set it up for development. Or you might customize auto and say, this is exactly how you get your fake data into this thing, and auto will do it for you. So that's a big difference. I think today, I don't think anyone would say microservice development is easy today.

But some of the practices that are emerging today are, for example, using Docker for microservice development. And the main pitfall I found there is that while Docker does have a really nice thing called compose in order to start a bunch of different containers and link them as needed as a single unit, basically in one file, the problem is as a developer, you still need to know all your dependencies, but not only all your dependencies, you also need to know all the dependencies, dependencies, and you're just going to flatten the tree in that in every file. And so that's really brittle if an upstream just changes what they depend on. Then it affects every downstream.

The other thing is you not only need to know them, you need to know how to install and configure them. And so it pushes all this effort out to the edge to the final application. And the approach auto takes instead is more of a pointer like approach. It's like, I depend on this thing, and it'll tell you how to set itself up.

And it'll tell you what it depends on. And so this is what this is the complexity that auto now matters for you. This is probably a good place to break. We got the, this is our final break before we clear the show, but we got, yeah, we got a couple more topics for, for Mitchell on auto.

So we're going to keep going. So let's break real quick here from sponsor and we come back. We'll go even deeper into auto and then close out with Mitchell. So we're back.

We're excited about our new sponsorship with Linode. They're huge fans of the show and are excited to support what we're doing here. And they want to invite every single listener to the channel and the fastest, most efficient SSD cloud servers on the market get a Linode cloud server up and running in seconds with your choice of Linux distro, resources, and the location. They've got eight data centers spread all across the world, North America, Europe, and Asia Pacific.

Plans started just $10 a month with hourly billing and a monthly cap on all plans and add-on services like backups, node balancers, Longview, and even Linode managed. And for those who were already familiar with Linode, they recently switched from Zen to KVM. And the latest Unix benchmark show eight plus 300 percent performance increase. We'll drop a link in the show notes for those benchmarks for you to check out, get photo to access from more control, run VMs, run containers, or even a private get server, into a native SSD cloud storage, a 40 gigabit network, and Intel e5 processors, use the code, change log 10 with unlimited uses, tell your friends, it doesn't expire this year, it expires the end of next year.

So use it as much as you want. Again, that code is change log 10 head to the node.com slash change log and tell them the change log sent you. I remember we're here again with Mitchell and Jerry earlier, you kind of aim in and you laugh and you were excited about. You giggled, maybe you giggled something.

You were excited about Mitchell's promise of auto simplifying deployment for developers. So Mitchell, maybe you can lead us into what auto is doing for deployment. Sure. So if you recall or when I talked about why vagrant wasn't good at deployment, it was that you couldn't, your description of development environment just wasn't a good description of a production environment.

And the difference that auto makes is that since we've moved up to this application level of abstraction, we could change things for you in production. We know what the app is so we can do different things. So as an example, when you deploy a PHP application, Ruby application, we do support PHP, but I'll use Ruby as an example, just because I'm more familiar with it. When you deploy Ruby application, we set up on Amazon, currently only Amazon.

We can't support other instructors later. So on Amazon, we'll set up a server. We install Fusion, the passenger. We configure all the permissions.

We bundle your application for deployment. We do all the stuff and then get it up and running. There's also knobs to set up load balancers, deploy multiple server counts. I want three behind the load balancer.

And then with the microservice stuff, we actually configure automatically for you. We configure our other project console. So consoles are service discovery tool. That's sort of all you need to know.

It'll tell you where your services are. So you can find them. We automatically install and configure that so that when you deploy your web application, the billing API, for example, is always going to be at billing.service.console as a DNS entry. And you don't need to worry about where that is, like auto manage that for you, but it's always there for you.

And that's sort of the idea behind deployment currently in its current state. We get a lot fancier in some upcoming versions around auto scaling and doing some other things. But for now, the idea is that we will get that application into production. You can go to a URL and see it running.

And yeah, that's the idea. That sounds like a good opportunity for community involvement. Are you guys ready for different infrastructure people to come and get involved? There's still two early days for that kind of help.

Yeah, we're super ready. So we're focusing on different the ways the right way to set an application when you deploy right now. We're not we're we have actually already pull requests for open stack support and something else. And it's just we're not going to merge those yet.

We're holding back on those because we want to make one infrastructure really, really good before we move on to others. So the main focus right now is and I'll give you a real example of the PHP community notice that we were deploying PHP with Apache and ModPHB. And apparently the best practice today, again, I'm not a PHP developer. So of course, I messed this up.