The Changelog: Software Development, Open Source - Otto, Vagrant, Automation (Interview)

Episode Date: November 4, 2015

Mitchell Hashimoto joined the show to talk about HashiCorp's new tool - Otto, how it compares to and compliments Vagrant, Automation, and we even talked to Mitchell about his history with software development in the beginning of the show.

Welcome back everyone this is the changelog and I'm your host Adams Dukovic this is episode 180 and on today's show Jared and I are joined by Mitchell Hashimoto vagrant fame auto fame HashiCorp 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 they're doing to share all they're 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, CodeShip, Braintree, Backblaze, and also Linode.

Our first sponsor is CodeShip, a longtime supporter and huge fan of the changelog. Head to CodeShip.com slash the changelog to check out what they do in continuous delivery, continuous integration. Check out their blog. We feature every single week in changelog weekly. You can easily set up continuous integration

for your application in just a few steps and deploy your code when your test passes in codeship. Get started today with their free plan. When you upgrade to a premium plan, use our special code, TheChangeLawPodcast. That will get you 20% off any plan you choose for three months. Head to CodeShip.com slash TheChangeLaw to get started. And now onto the show. Welcome back, everyone. We're here with Mitchell Hashimoto, founder of HashiCorp.

And Mitchell, you have to 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 creator of Auto and Vagrant and Packer and Surf and Console. You're an O'Reilly author and a developer that's obsessed, as you say, with automation. So this is a three-peat for you. Welcome back to the show. Thanks. Thanks again for having me.

And we, of course, got Jared Santo on the line. Jared, say hello. Hey, everybody. Happy to be here. Happy to... This might be our third three-peat guest, which would be the triple three-peat, which is... I think he should win something

don't you think i i wish we had something more than t-shirts to give away i did get a t-shirt from from you at uh gopher con i think so all right cool well we can uh i'll send you three more we'll send you three more so yeah this is this is a three-peat for you mitchell if you didn't know uh third time on the changelog. First one was with Wynn back in episode 72. That was February 9th, 2012. So that was not very long after you founded HashiCorp or HashiCorp. And episode 88 was your second one.

So not far after that. That was May 15th, 2013. That was me and Andrew talking to you then. And like I said, for reference, 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 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 intro you to the to the audience of the changelog uh i think i think it matter if you're a developer i think that the the most like uh the most well

known thing would be as the creator of vagrant um 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. In the intro, I said hashy, hashi hashi which one is it well if you're speaking japanese it's uh hashi but if i mean either way is really fine it's it's phonetically fine to me okay i always wonder if i'm like because i know you would it's it extends from your last name so, 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 incorrectly. So if there was a right way, let's, uh, let's establish that so we can not deviate. Um, sure. I mean, it's the correct way. It's HashiCorp. Okay. I think maybe developers were used to, or even influenced to say HashiCorp

because we're used to doing things with hashes. Oh, yeah, that could be it. And 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 me, I 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 stumbled on this article from Business Insider.

So I thought it would 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 and your company produce, but a bit about who you are first. And 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? You've got your parents opposition and just some things that happened when you were young. I mean, the first tech startup you did was 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 thoughts and some history of who Mitchell is to the audience. Sure. I want to start by making – if you do go back and read that article, I want to start by making a few corrections. The 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'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 circumventing certain things. So I was actually playing the game but using computer code, I guess. And that's how I sort of got 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 uh legal things after that and and created a small business that automated the setup of php forums i created um a small business in college that automated getting you into classes

you want um i for fun created continue to create sort of like game bots, but just for myself, just for fun. And it sort of led to where I am today, where if you look at all the stuff I've 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 like 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.

As a naive 18-year-old, I had no idea how good of a job being a programmer could be. Was it really a half a million dollars? Oh, so that's a great one. It wasn't half a million dollars a year. It made quite a bit of money, but it wasn't quite that much. I guess I would just say it was low six figures per year and uh i eventually sold that business yeah can we camp out on the game cheats for a second because that that that

has my interest uh yeah so when you said that i usually thought like game genie back in the day i don't know anybody knows that but this was like web games can you explain how how are you cheating the games and how'd you like as a 12 or 13-year-old, how did you figure out you could do this? And how did you 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 botting. So I wrote programs that would play the game for you 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 even know that game. What is it? It's just like a web game.

It's sort of like you get a pet, you play games, you get virtual currency, you buy things. I don't know. It's, you live like a, it's like a really weak second life. Wasn't there also like a device you can take with you that was part of the Neopet? It's Tamagotchi, right? Not when I played. Maybe they went that direction. I don't know.

But not when I played. 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 botting. So I just wanted to see if using bots, could I make a ton of this virtual currency and win the game, basically. And I had a lot of fun doing that.

Did someone teach you how to bot? Or would you just figure it out? Were you using 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. I was on Windows at the time. And I just wanted to know, I mean, I had this weird realization when I on windows at the time and i just wanted to know i mean i had this weird realization

when i and 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 became curious where 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 uh 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 business that you were running or starting in, unless Jared, unless you got more

on the games piece you want to dive into, I don't want to take away from that. No, I got my fill. Thanks. I'm curious, in college I'm reading back in the quotes, it actually says I was pulling in about a half a million a year, he said, so that's you saying that. So that's what you told Business Insider when you were doing this thing. But what was the business?

What was the business you were doing and what kind of eyes and ears and what kind of thoughts did it evoke for you to produce this business and then move on to what you're doing now? What was that business about? Yeah, well, the correction is I told, the quote I gave them was it was making about half a million

over its lifetime, so that helps answer. As a business insider, they're not exactly known for their accuracy. Yeah, it certainly made for a flashy headline, though, so props to that. But yeah, it's not correct. I wish I had multi millions of dollars right now, but I don't. And yeah, so the business I made was basically, and again, I was scratching my own itch, which will be a theme throughout everything. But I was scratching

my own itch to the university I went to had a really terrible registration system. So if a class was full, then there was no wait list. You just couldn't get in. You could try to get in by going to the class once it started, but that was pretty risky. 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 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 the door on my floor suddenly was gossiping that I had this technology. And so I would get knocks 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. website thing and charged people $5 per class to register a listener basically to notify them when there's an opening. And I did this my freshman, sophomore year. And then sort of the, I guess, the change that happened, which was the pivotal moment from a business perspective is that there was this critical mass when students suddenly

realized that if they didn't pay this website $5, they felt at least, I don't believe this is necessarily true, but they felt that there was a 0% chance that they would get into the class because 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, ended up, there was a very huge growth period where suddenly students were just paying me $5 to hedge a bet basically, um, to, to give them 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 HashiCorp because I wanted to focus

a full time on HashiCorp. I didn't want to be distracted by a side business. So, yep. So when you sold it, were you still in college? Had you graduated? I'd 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, ah, not really. Like I can see with your output now you've been inspired by HashiCorp, 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. It was it was a nice secondary income. Maybe 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-peat for you. Episode 72, episode 88.

And the last time you were on episode 88, like we said this is a three-peat for you episode 72 episode 88 and the last time you're on episode 888 that was may 15 2013 so a lot's changed what's happened since then just a little over oh wow a little over two years uh two and a half years roughly so maybe catch us up with hashi corp with yourself uh maybe some influences to the business what's what's changed in the last couple years for you with HashiCorp? Oh, wow. Yeah, so much, actually. I didn't realize it was that long ago. It's been a bit.

Yeah, wow. So since 2013, I mean, I guess I'm best known for creating Vagrant, but since 2015, we've, as a company, created eight open source projects and one commercial product. And the eight open source projects, which are probably the most interesting for this podcast, are ranging from Vagrant, which is very developer focused, to something like Terraform, which is more 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 reliability focused in terms of like a reliability engineer would probably

be looking at those as well. So we sort of built this range of tools that span this whole thing. And since then, sort of the adoption of all of them have been really awesome. So I guess the party trick that I have now is, you know, name five semi-popular, like five websites that are not esoteric. And I could confidently predict that three of them will be using our software, which is a pretty cool place to be. So I'd say that's what's developed over the past couple of years. What about as the company itself, the internals, the people, what's changed since then? Sure. The big thing that's changed is we've started hiring a lot more.

So we just crossed the 30-person mark. But 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 that maybe aren't core committers, but contribute a lot, people that are on the mailing list a lot. We've been hiring out of our community. It gives us a high degree of confidence that we already know how they work and they already like what we do and things like that. So that's what we've been doing. So we have now at least one full-time person per project, 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. That's been the big thing. And then this year, the major focus since the summer, so not too long, a few months, has been really working on the commercialization angle. So we announced our commercial product Atlas, and we more or less completed our initial

open source portfolio with our conference. We had a conference last month. So we have the eight open source projects, and now we're really ramping up on the sales and marketing side and and getting that going i recall seeing word about that conference and i totally had fomo when i saw it i 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 would

tweet about it here and there did you hear about it jared i heard about it while it was going on right 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 because we've been trying to go to conferences more like you'd mentioned earlier uh mitchell that you got a change all t-shirt from us when we were at gopher gone 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 tweeted about it here and. I definitely didn't like shout it off the rooftops. But yeah, we announced it back, I guess.

I don't know. Maybe early summer, like June, maybe just before June. We started ticket sales around June and we sold out in late July, early August. So yeah. It sounds like it was a success because you're talking about next year. Yeah, I think it went really well. The first conferences are always fun. I've gone to a few first conferences for open source projects,

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 a 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 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 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 meeting each other for the first time. You sort of lose that more for 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. You kind of resisted a little bit.

So September 28th and 29th, if you missed it, will it be roughly the same month roughly next year? What's the plan there? Do you have any details you can share? Probably, but we really have no formal plan. So maybe just late year, late in the year? Yeah, probably not early year just because we're not planning it and i learned i learned a lot about planning conferences and uh takes takes quite a while well maybe if you don't mind we gotta take a break here in a second but maybe when we come back we can talk a bit about this wasn't on my list the rundown but

uh you'd mentioned commercialization so i'm wondering if i'm sure at some point through our conversation around auto and vagrant, which is pretty much what we're going to camp out on during this show, although we can take lefts and rights as we need to do. 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's good with me. Yeah. Cool. All right. Well, let's take a break real quick. Listen to a word from one of our sponsors for this 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 we'll be right 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 braintree for mobile app developers out there the braintree b.0 sdk makes it easy to offer multiple payment types start accepting paypal apple pay bitcoin venmo traditional credit cards and whatever's next all with a single integration enjoy 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 all with a single integration. Enjoy 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,

but Braintree is done in minutes, and if you don't have time, give them a call and they'll handle the integration for you and walk you through it. Braintree supports Android, iOS, and JavaScript clients. They have SDKs in seven languages,.NET,js java pearl php python and ruby and their documentation is comprehensive and it's easy to follow to learn more and for your first fifty thousand dollars in transactions fee free go to braintreepayments.com change log slash changelog. We're back from the break. And Mitchell, I know when 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. When we started the show, we talked about the article from Business Insider that said you just raised $10 million for a startup. I imagine that startup was HashiCorp. So you got 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 actually commercializing this kind of software. I mean, like software for engineers. But I guess the thing I've learned since starting HashiCorp is that people want to pay for software. Open source is really, really popular, but that doesn't mean people don't want to pay for things. I think open source is a lot more about, depending who you ask. I mean, this is going to be true or false, depending who you ask, but it's a lot more about legal protection.

It's a lot more about avoiding vendor lock-in. It's the ability to security, like ability to audit things in the open. Obviously, community is a big aspect, being able to ask for help from people other than the vendor itself so i think like that's what it's about it's really very rarely about i just want something free at a certain level like even small companies like even people that have companies that have 10 employees or something they're very very willing to pay for software and i think that good evidence of this is actually like SaaS. Every small company pays for a SaaS somewhere.

They're open to spending money. GitHub, actually, they're definitely paying for GitHub. So that's what I've discovered. And at the bigger enterprise level, they're not only comfortable paying for software, but they're comfortable paying a lot for software that works well and solves their problems because it might seem like a lot to an outsider, but it's very reasonable

in terms of what that software is doing for them. What our senior director of marketing here, like what he likes to say is, is like, we want to be able to go to Tesla, for example. I'm just using them as an example. They're not necessarily a customer. So 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 deployment stuff 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. Imagine all the engineers you have hired right now to worry about stuff that isn't your core business. What if they were instead building your car software? That's way more valuable.

That's sort of where commercialization comes in. People want to pay for that piece of vine. They want to pay for 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 for your company in open source. It was founded. 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 maybe let's skip the failures. But what was the first thing you guys commercialized? And what was that process like? And what have you learned from it?

So the first thing we commercialized is 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 a difference between doing something that'll make a small business work well. And then 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 are wrong. It just matters what you want. And so when we did the Vagrant VMware stuff, I was still very much unsure what my ultimate business goals were with HashiCorp. I had a lot of technical goals, but was HashiCorp going to be like the business I had in college where it made a good amount of money, it could pay a few salaries, we could just sort of

do what we want and build it? Or did I want to build a company that could potentially be a multi-multi-million dollar company, maybe even towards the size of something like VMware or something like a very large company. And I think the main motivator 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 banks, I wanted to convince, you know, Amazon, I wanted to convince Amazon. I wanted to convince these big giants to change the way they're doing some stuff. And it's sort of like a naive view of the world. There's obviously a lot of stuff I didn't know then that I've learned since then. But with that goal, I didn't have a chance of talking to these people or convincing them, or I had a much smaller chance, let's say, than if I go the route of raising money building a larger company i mean even the fact of just having money in the bank will get people to 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, a risk assessment form. So we filled it out, and they came back and they were 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're gonna 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 you're getting over it totally makes sense on like yeah we couldn't even charge them money yeah they 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 to prove to them 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 depend on when you you buy software i wouldn't mind talking a bit more about raising money jared i know you got a question on your side and i know you're waiting to ask it on the transitional piece but i i wouldn't mind talking a bit about you learning to raise money did you get some influencers did you have a a mentor like how

who who guides you through what you're doing and how did you learn what you're doing to build this company? 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 I used that time in San Francisco to meet a lot of people, network a lot, and inevitably sort of working in the startup world, just learning how these things work and meeting other founders, meeting venture

capitalists, just really being in the thick of it, even as a developer, just being exposed to a lot of it. So I was really lucky when I went to go raise, I just reached out to a bunch of people that had done it before and asked for advice. And a lot of them introduced me 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, I think the nature of doing something for the first time. So was it before the, I guess, abrasion with the company who you filled the risk assessment with, was that what kind of like motivated you to raise money

or before were you just like we'll organically grow no it was uh no we were we were getting motivated over time so yeah that wasn't the single factor but i think uh i think what actually really motivated us was that uh when we started hashicorp we we did it because we cared a lot about this problem and ops in particular wasn't you know wasn't a i guess attractive industry you know it wasn't it wasn't really this jewel that 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 thing.

And we were contributing in a small part to that by coming out with things like console and pushing people faster than they had been before. 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 faster because we suddenly saw the industry speed up and we didn't want other people to come and swoop in

and do something differently than we sort of philosophically believed in and mess up our goals. So one more businessy question before we get to the subject matter, which is Vagrant and Auto. I've been looking at your contributions graph here while you guys have been talking

because you said you went from three to 30 employees at HashiCorp in the last 18 months. So now you're the boss of 29 people, and yet you have 49 commits publicly this week. You've merged six pull requests. You had a streak of 27 straight days contributing to open source this year. How do you be someone's boss and yet still get to code so much? So my particular role in the company is really sort of currently being in charge of all the product stuff. So I don't have 29 people reporting to me, thank goodness. I sort of work with a lot fewer teams that are working on these open source projects

and our commercial product and guide that. But I still love programming. So I just sort of work where I can. And 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 on the programming side. So, you know, the traditional viewpoint of a startup is you have your your sales guy and your technical guy. Does HashiCorp 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 awesome. That's nice, yeah. But, yeah, I definitely was everybody for a long time. But to answer your question, HashiCorp's a unique, not unique company, but I think IT, DevOps, where VMware is like this, we're creating software for other engineers and it's highly technical. So your salespeople really need to have engineering backgrounds as well.

And there's a number of, I mean, I've learned this, I've discovered this, so there's just a number of salespeople, like they've been doing sales for 15 years that have CS degrees and code for on the side, excuse me, code on the side and understand this stuff. And you need to because at least for us, a core part of our culture is trying to be genuine. So trying to go into 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 they were and and some people are taken aback by it because they're like, did you just say no in a way? And that's just kind of what we do 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 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 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 that works. So there's still an aspect of trying to get to say out of there without showing them the rest of what we have and trying to find something else that works so there's still an aspect of you know trying to get to say yes in 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 may or you will 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 gonna be like yeah they kind of didn't give us the right advice early on and yeah 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 like a database company and the data doesn't really fit your model, but they're 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 somehow. Whereas we're a lot less concerned or offended or anything

if it's like, 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. You had 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 there but we're gonna have to break in

like 11 minutes so uh give us some forgiveness there but Otto is really interesting uh we obviously loved Vagrant when we had you on the show before back in 72, I know Andrew and I went deep on what Vagrant was then. But for the listeners out there that are maybe unfamiliar, let's open this up maybe with what Vagrant is to a degree and what Otto is. I guess that's probably, would you say, Jared, that's the best way to open this conversation up is 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 paint some history too of like when it i think during this conversation we pinned it back to the origination of hashicorp 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 in one sort of sentence, 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. it was solving was, you know, I was switch, I was a developer at a consultancy, and I was switching between a lot of different customers and 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 was was a pain to say the least. So vagrant was a solution to that where everything is sandbox and a virtual machine. You runagrant was a solution to that where everything is sandboxed in a virtual machine. You run Vagrant up, every single project you have gets a separate virtual machine. It's completely isolated.

So you could have different versions of web servers and libraries and databases all coinciding, co-mingling, I guess, on your own machine 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're not left with cruft on your machine. You're not using any more resources actively.

It's just gone completely, but you can make it again very easily. So that was Vagrant. It's been growing sort of over the past six years to effectively be our flagship open- source project at HashiCorp. It gets millions and millions of downloads a month, and it's kind of a monster on its own. And so six years ago, that was created. And I guess what problems were out there that made Otto be a solution to succeed over Vagrant?

Because the blog that was put out a long ago was the successor to vagrant is is auto so this is the successor so vagrant will go away eventually or will sort of i don't know maybe you can help us understand that too yes okay so um yeah so the it's great we did the backstory on hashi corp 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. During the same process

we've been consistently releasing new Vagrant versions, adding features, iterating. But we haven't focused on developers in a few years. They haven't been the focus of our company in a few years. And we don't want to feel like they're neglected in one on developers in a few years. They haven't been the focus of our company in a few years.

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 use Vagrant obviously every day here at HashiCorp. And we were sort of discussing 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. That's our goal. 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 Vagrant to make it better? And so the conversation started with what would we do if we could start vagrant from scratch like how would things be different today and the three sort of things 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 into companies and seeing how they use it and just seeing thousands of users, really.

The three things I picked up on was, one, development environments are really, really similar to each other. I think it was funny because on Hacker News, someone commented that they think this statement's false, but I mean, I really believe it's true. I've seen it in the wild. 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 Bundler. If it's a web application, you're going to have a database. You're going to have something like Passenger. And they're just really similar. The last 10% is like differing versions or passenger versus unicorn or something like that. And they're really details that don't matter too much

in a development environment. So what, and it's hard to solve this at the Vagrant layer because Vagrant is so low level relative to auto, which we'll get to, but 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 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 to anybody um vagrant had a issue i think for five years well it's probably it's probably been closed for a while but it an issue opened 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 a development environment. And they were like, why can't deployment be just as easy as a Vagrant Up? And honestly, we tried for a bunch of years at various different points to fit this into Vagrant. We tried a bunch of different things, and it just never really worked well. 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. I do think it continues to be a great way to describe a development environment, but it's not a great way to describe a deployment environment because they're so different. You run multiple web servers.

You run a load balancer in production. You have monitoring systems in production. You have different security requirements. Like, it's so different from development that you can't safely map a vagrant file to what goes up in the production. So that just needed to be thought out. And then the third and final thing is that, you know, we live in a world 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. And that's

really different from the world that existed six years ago when I made Vagrant. Six years ago when I made Vagrant, you know, the best practice or the standard practice at least, was to just make a giant monolithic Rails application or PHP application that does everything, that has everything. And over the past six years, 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 develop faster. They have all these

other promises. I'm sure you have or will talk about microservices as its own podcast at some point, but as its own episode at some point. But these are coming. We talked a bit about that with Peter Bragon, microservices. That's a great person

to talk to about that. So, microservices I don't claim, I really don't claim they're mainstream today at all, but 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 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 identified with vagrant that we that we went on to address in auto. Well, I think that's actually a really good setup. Let's take that break. Now hear from one of our sponsors, we get back, we'll find out how Otto solves these three problems and probably more. 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. Backblaze, a new sponsor to the show,

offers online backups for your documents, your music, your photos, even videos, and so much more. Go to backblaze.com slash changelog to start your free two-week 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 an internet connection. They have Android and iPhone apps for mobile access and Backblaze 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, unthrottled backup. And Changelog listeners get a free two-week trial by going to backblaze.com slash changelog. 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.

Develop 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 its 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 it's you might be able to tell from the name how it's different already so the fun exercise i like to do with uh with vagrant users is like what's the first thing you do when you make a vagrant file and and the answer is 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 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 i which sort of goes back to the first thing i mentioned with with how i would improve vagrant which is that your development environments are just very similar um it's 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 it up and that's what we've done so it kind of moves up a level of the abstraction chain up one level yes instead of specifying you know ip addresses and my sql server or whatever you're just like hey i got a ruby on rails app so you're just yes exactly exactly, and so the way, uh, and I mentioned earlier that app files are even, you know, optional, you might not write one. So if you run auto, um, 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, as we've been using Auto more at HashiCorp, is our designer went into one of our Go backend services and ran AutoDev to get a development environment. And he was like, whoa, this just worked. I got a Go development environment. I have no idea how to install Go. I have no idea how to compile things. I have no idea how to compile things.

Auto not only set it up for me with zero configuration, it also told me how to compile the project. And he was like, once he got it running, he was like, I don't know how to run it because I don't know how to run it. But he wanted to see if it worked. And then the flip side, he also had some really old Ruby projects from

years back that he hasn't touched. And he went back into those and was like, what's this going to do if I auto-dev here? So he auto-dev'd, and he was like, yep, set up a development environment, Ruby bundler, auto-bundled my things, set it all up. He was like, it just worked with zero configuration. That's awesome. So that's the direction we're really heading.

The zero configuration thing really isn't a gimmick. 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 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 Vagrant. So if you take a V vagrant file from five years ago and you run vagrant up today, it'll probably work. We've 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 Apache you configured. You 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 are a form of fossilization. So you've fossilized and snapshotted what the state of the world was five years ago, and Vagrant gives you that today. And that's sometimes a good thing.

But the approach we've taken with Auto is instead of codification or codification, depending on how you want to 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 environment and 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 the security patches and technology changes and things like that. And the people making this happen as the community. So 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 my favorite example is that the person who set up the AWS integration with Auto used to manage a top 10 by size infrastructure on 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 is 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 Jared likes that. Oh, man. I like all of this, Mitchell. This sounds spectacular. So this works right now, like zero config, fire it up.

Yeah. Okay. Yeah, you can go download auto right now. It'll work. 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 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 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 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 from the beginning to deploy, from the beginning, auto is 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'm super excited about the deploy stuff. But we need to clarify Vagrant a little bit here,

because it says on your guys' auto getting started that you first you run this auto command auto compile um and it says the first time you run it you 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. You want to speak to that for us? Yeah, yeah, I'd love to. So there's, so we didn't want to reinvent the wheel. Like Vagrant is, is really mature. The bugs it has generally are very esoteric today. They're usually not very mainstream. And so it works really well. And we didn'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 could give is actually the upcoming version of auto, auto 0.2, where we focused a lot on development experience. So for a Go development environment with auto 0.1 or Vagrant, it's just a Vagrant file, or Vagrant 1.7, 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 were able to do that is we still use Vagrant under the cover for parts, but Auto's starting to offload some of the stuff Vagrant used to do

and do more clever things due to its 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 dev 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 the 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 so that all takes a

bunch of time and then subprocesses into SSH. So we got rid of all that. And now we're just going directly into 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 speak to the virtualization environment that auto uses on your machine same as vagrant or different yep yep same same and that was a lot of the reason why we didn't want to um sort of rewrite those aspects yet at least in auto because uh vagrant has a great community around it with support for virtual box vmware parallels hyper v um you 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. 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 then it'll install and the one improvement we're making is it'll actually the next version will install virtualbox for you if you don't have a hypervisor on your system. So 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's, 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, they were just, we worked with a bunch of people who use containers for development. And they're fast, which is the nice part. But you lose the sort of save, reload, you know, 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 development environment, we could just set that all up for you.

And the containerization part of a 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-Linux systems, so you would need a virtual machine anyway to run the container. So instead of starting the virtual machine, then starting the container, we'll just start the virtual machine and run it there. The main improvement we made over Vagrant 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 you. So you're always each, each environment is only one virtual machine for for everything you're working on. And that brings a lot of the benefits

as well, without having to use containers for development. 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? Who said that? Hypothetically. Yeah, I would be a little bit sad,

but at the same time, Vagrant's not going away. Vagrant 1.8 is coming out next month, and it's going to be a huge, awesome release. We get linked clone support. We get linked clone 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 thinkrant 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 being like, well, Auto 0.1 was 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, 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'll phase... 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 few years will shift to Auto. But there's also use cases for Vagrant that Auto's never going to attempt to cover. So it also just can't disappear completely. So a good example is for ops people. Ops people 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 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 ranking and 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 Vagrant, and we're going to keep it that way for years. One question I think that you could probably speak to a bit 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. It's built for microservices.

Can you speak to the built for microservices part? Yep. Yeah. So in the app file itself, you could 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 in that, to specify the dependency, what you actually do is specify where that dependencies app file is. So you create this chain of dependent app files. And so what you could do for the source practically is give it a GitHub address or give it a HTTP address or even S3 or something. And what auto manages for you is fetching that app file,

compiling that app 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 did Otto know how to do that, goes on the billing services app file. So Otto 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 Otto and say, this is exactly how you get your fake data into this thing, and Otto 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 like 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 just need to flatten the tree in every file

and so that's really brittle if an upstream just changes what they depend on all the dependencies dependencies, and you just need to flatten the tree 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 manages for you. This is a probably a good place to break. We've got the,

this is our final break before we clear the show, but we got, Jay, we got a couple more topics for, for Mitchell on auto. So we're're gonna keep going so let's break real quick hear from a sponsor and when 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

lenode 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 of the change law to try out one of 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 node location they've got eight data centers spread all across the world north america europe and asia pacific plans started just ten dollars a month with hourly billing and a monthly cap on all plans and add-on services like backups node balancers long view and even linode managed and for those who are already familiar with linode they recently switched from zen to kvm and the latest unix benchmark showed a plus 300% performance increase. We'll drop a link in the show notes for those benchmarks for you to check out.

Get full road access for more control, run VMs, run containers, or even a private Git server. Enjoy native SSD cloud storage, a 40 gigabit network, and Intel E5 processors. Use the code changelog10 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 changelog10 head to linode.com slash changelog and tell them the changelog sent you all right we're here again with mitchell uh and jared earlier you kind of amened and you laughed and you were excited about.

I giggled maybe. You giggled something. You were excited. You can say it. I giggled. You giggled. 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, sort of when I talked about why vagrant wasn't good at deployment it was that you couldn't your your description of a 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 um we could change things

for you in production we could we what the app is, so we could do different things. So as an example, when you deploy a PHP application, sorry, 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 a Ruby application, we set up on Amazon, currently only Amazon. We can support other infrastructures, but later. On Amazon, we'll set up a server, we install Fusion Passenger,

we configure all the permissions, we bundle your application for deployment, we do all this stuff, and then get it up and running. There's also knobs to set up load balancers, deploy multiple server counts, like I want three behind a 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 could find them. We automatically install and configure that so that when you deploy your web application the billing you know API for example is always going to be at billing dot service dot console as a DNS like 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, 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 you ready for different infrastructure people to come and get involved? Or is it still too 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 up an application when you deploy right now. We're not where 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, the PHP community noticed that we were deploying PHP with Apache and mod PHP. And apparently the best practice today, again, I'm not a PHP developer, so of course I messed this up, but the best practice today is Nginx and a longer living process, not like mod.php. So they made

a pull request, which is to change it to Nginx, and so the next version of Auto will use Nginx for PHP, which is the right way to do it. And sort of like I mentioned before, Auto's deployment stuff isn't ready for maintenance yet. It's not ready for redeploys and stuff like that. But once we get Auto 0.3 out there, the idea is that you will have already deployed your application.

You download the new version of Auto. You recompile your app file. That's the safety mechanism so that every update, like things don't change. But you recompile your app file. That's the safety mechanism so that every update, things don't change. But you recompile your app file, you redeploy, and then auto will, minimal or zero downtime, will spin up new servers with Nginx rather than Apache and slowly spin drain and spin down the other ones for you

so that your infrastructure just became better by upgrading auto, which is the long-term idea. So here's the point where I make you really uncomfortable by asking you to tell me when auto deploy is going to be ready for me to put it into production. Yeah, so I do want to make clear that auto deploy definitely works today. You could download auto right now. You could deploy something. It'll run your application.

You can visit it in a browser. It works. What it isn't good at, just again, just trying to be super clear, I know I've said it, is maintenance. So redeploying an application, changing your infrastructure, how do we do that with minimal downtime, that sort of stuff. And that's the major focus of Auto 0.3. So 0.2 is going to come out next month. And 0.3, I hope I could do before the end of the year. But if not, I would commit to sort of January next year. We're pushing really hard to get it out there because we want this dream to be completely real for people. Some folks adhere to semantic versioning and they want to see a 1.0. Is there

a roadmap to 1.0 or do you consider 0.3 is going to be production ready. What's your thoughts on versioning? Yeah, so at HashiCorp, we don't follow semantic versioning for our end user products. I think we follow semantic versioning for all our libraries. I think it's really important, but sort of for end user stuff, we just maintain backwards compatibility

really heavily. So we probably won't break app file compatibility. And 0.3 is around the point for all our projects where if you're an early adopter, but you want things to work, like that's the release that you should be comfortable with.

And we hopefully will come out with a 1.0 of a lot of our stuff next year, but probably not auto, but a lot of our other stuff. Real quick before we wrap up here, getting started. What do I do? You just go to autoproject.io and go through the getting started guide, which will in simple steps is download auto, find a project you care about, run auto compile auto dev, and

you got a full development environment. Next step, run auto deploy and it'll deploy it for you. That sounds too easy. Is there anything harder we can do? It sounds like 10 minutes too, not even. Yeah, most of your time is just waiting for cloud platforms and things like that. So pretty relaxed process.

Okay, last question before we go to our closing questions is Vagrant, six years old now, is a Ruby project written in Ruby. Auto, the brand new project from you, is written in Go. Your thoughts? So all our projects since Vagrant have been in Go.

And I don't regret at all writing Vagrant in Ruby. It was the right choice at the time. But I do think that if Go had existed in a stable production-ready form like six years ago, then I probably would have used it. Go is just, I really like the language a lot, and I think that Ruby itself is a good language, but for writing end-user applications

that run on multiple platforms that you want to be performance and sort of you want lower level control over things, Go is a much better way to do it. Also, a lot of our projects, not auto as much, it's certainly in there, just not as prominently, but a lot of our projects care a lot about concurrency and parallelism. And Go just makes that, you know, it being natively part of the language makes it quite a bit better. And I don't think anyone in Ruby would argue that point too much.

I guess Jared kind of lied. It's not exactly the last question. Um, and it won't make you feel uncomfortable either. Um, but I was wondering if you can share some stories or just any, any, you can share on who's using auto right now that is noteworthy and any noteworthy ways they're using auto? I would just honestly say that nobody noteworthy is using auto right now. A lot of people are playing with it, and I'm actually glad to say nobody noteworthy is using it right now.

I like early adopters to be more tinkerers and things like that. So from the auto side of things, nobody yet. But I don't consider that a bad thing. Gotcha. But I guess on the flip side, auto, from a vanity metric, auto got almost 3,500 stars. It got 3,000 stars in less than a week of it being released. So there's a ton of people interested in it.

I could see the download numbers and they're doing really well, but I think rightfully so. It's a bunch of experimentation right now and it'll probably be that way until auto 0.3. Just to go back to the semantic versioning, 0.3 is what we think production ready will be? Yeah, yeah.

Well, Mitchell, it's obviously been a ton of fun having you back on the show and we close the show with some interesting questions. Sometimes we ask the hero questions, but since you're a three Pete, we won't ask those questions again. question, which is this question actually has some history with me personally, because I began podcasting probably late 2006, early 2007. And this show, we had this question at the end of the show called the super secret question. And I can't even take onus of it. I didn't begin it, but I liked the question. So I figured it would make sense to ask you this. So what is something super secret that no one knows about that either you, HashiCorp, your team,

something you're building, something that's happening? It can be big, it can be small, but whatever. What's something super secret that no one knows about that you can share with the audience here today? I'll just share something personal that's super secret

that I think will entertain people. It's super secret in the fact that I think just nobody realizes it or I've only ever in my entire time people. It's super secret in the fact that I think just nobody realizes it or I've only ever in my entire time of like visiting community speaking had one person ever figure this out.

But I used to be a core committer and worked for a while for Zend, the PHP company. And I worked on Zend framework, the PHP web framework, like the enterprise PHP PHP company. And I worked on Zend framework, the PHP web framework, like the enterprise PHP web framework. And I did

a lot of blog posts on PHP development. And they got a good amount of traffic. So I guess my super secret is that I came from a pretty heavy PHP background that nobody realizes. That's interesting. That's super secret too you ever go

back and just read your old articles and laugh uh i i went back last year and found my commits and i was curious if that code still existed in the project which it doesn't but uh i did that but yeah only at one conference ever i gave a talk and after the talk someone was like so are you the same Mitchell that did PHP articles? And I was like, what? How did you know? You're the person that read them. And our other favorite question that we like to ask, it's not always the same question, but it seems to be a good question to ask someone like you, which someone that's a thought leader someone's a visionary um we're curious to know what's on your open source radar so it could be

a project it could be a technology it could be just something out that's that's happening in the developer space uh what's on your radar if you had a weekend to hack on something what would it be um i think the thing that is most interesting i don't think i would want to hack on it on a weekend. But what I would want to play with, I guess what I'm most interested in is all the sort of monitoring like startups that are popping up right now are not startups, but like they're usually starts by an open source project. So I'm just super interested in in the mature, like when these projects become mature. So to give a couple examples, like InfluxDB for storing time series data seems really interesting to me. And a much younger project, Sysdig, I think it's S-Y-S-D-I-G. I think that's really cool. I'm just sort of, HashiCorp's not in the metrics or telemetry or time series sort of business, and we don't plan to be anytime soon,

but it's still a really interesting technical problem, and I just like playing with these tools. I still think that finding anomalous data out of time series, like how do we teach computers to just detect for us that our request per second is abnormally low right now like that sort of stuff is really fascinating and i wanted to get somewhere interesting so i gave you a couple projects but uh the whole field is pretty popular right now so i'm just paying attention to that all right just a couple of promotional items that are related. changelog.com slash 168. We had Julius Volson speaking about Prometheus

and service monitoring. We're kind of related to that, Mitchell, as well as 170, which was Ben Johnson talking about BoltDB and InfluxDB. So a couple of episodes if those are things that are also on your radar. Cool. And we use bolt for a lot of stuff at HashiCorp.

So cool project. Nice. Well, Mitchell, as much as it pains me to say, that is pretty much all we wanted to talk to you about. I mean, I'm sure we can keep going on.

I mean, you're, you're a deep fella and it's easy to, to pull things out of you, but it's been a blast having you on. Thank you so much too, for just, uh,

sharing so much that you do share with the community and then coming back on this show three times. I mean, you're always welcome back. So we look forward to more success for you and your team in the future, but thank you so much for all the work you do in open source and all the insights you give and just all the ways that you serve the men and women out there hacking on software. Cool. Thanks for having me. It's fun. It's always fun. I like, you know, your changelog is definitely one of the highest quality sort of thing that does this. So it's always fun to come on here. Awesome, man. Appreciate you saying that too. And to our listeners out there, we have listeners, we have members,

and without you, it would not be possible because who would listen to the show right that that wouldn't happen so thank you for listening and to our sponsors we have sponsors that make the show possible sponsors of this show are code ship brain tree backblaze and linode brain tree backblaze and linode are new sponsors code ship obviously huge fans of the changelog and longtime supporters of the show. But got to say thanks to all those sponsors making this show possible. But Mitchell, it's been awesome having you back on the show.

But for now, fellas, let's say goodbye. Bye. Goodbye. Goodbye. We'll see you next time.