 All right, thank you very much It's a huge honor to be here. It's really cool to see talks Like those given by the banks Because as many of you here know my life currently is heavily involved with open source But maybe sort of lesser known is that I was really only able to start getting involved and learning to code because of open source So as a quick sort of story leading into this talk I started to learn to code around 11 or 12 years old and we had one Dial-up line and I was not allowed to connect to the internet during the day because my dad needed that line So I really only had two ways to learn to code and one way is super not open source at all my dad would drop me off at Borders bookstore, which I think is now out of business, but Will drop me off at the bookstore. I would run to the corner where the computer books were I would like crack open the book to not crease it because I couldn't afford to buy the books I would I would crack it open read and read and read and I would read the same like five pages Over and over because I had to memorize them because I couldn't take this book home And then I would run home and then try to sort of apply What I learned and I would repeat that sort of weekly And then the other thing was when I discovered that open source existed And you know github doesn't get github didn't exist Google was relatively new So I tried all these different search engines, but eventually found out you know people uploaded Tar balls and stuff of code and so I would download a bunch of tar balls at night and then during the day when I couldn't Dial up. I would just read the source code and learn sort of how to Apply these abstract concepts books are really great at abstract concepts open source is really great at applying those concepts and showing me Sort of how it could work. So that's how I really got started and and so it's very fitting And I'm very happy that I'm able to sort of build my career around open source software And around eight years ago. I started a project called vagrant and As the bank said in the talk it wasn't my first open source project There was many before that that no one knows or cares about But vagrant ended up being something a little bit more special Became a lot more popular than I could have imagined But also taught me a lot about you know community the non coding side of open source I had to learn about the challenges of building a community the challenges of bringing on contributors Governance those sorts of things and the success of vagrant and and getting into DevOps is also what led me to found Hashi Corp, which is a company aimed at building Striving to build you know the best infrastructure automation tools and I Started this company with my best friend Armand and together We've built seven free and open source licensed products that we've built our company on which Do development environments infrastructure automation cluster scheduling? Security software there's a pretty wide array of things and and When we started Hashi Corp We knew for sure we were building around four or five of these things and we started that process And when we started it was just the two of us and when there's two of you And especially when yours as as close as we were It's it's easy like you have a mutual vision a mutual understanding You know how you want these things to work how you want them to feel and you can be really really productive But we knew that to really you know reach the goals and ambitions that we had for a company Like Hashi Corp, which is to make a much broader industry impact That it was going to be more than the two of us and very likely much much more than the two of us So our biggest fear was how are we going to scale? our Not not company vision, but product Development and design vision like how how we're going to build an engineering Organization that really understands why we do some of the things the way we do some of the things we do not necessarily just what the problems are solving, but how we solve those problems and so Very early on in the company and to most very surprisingly early We wrote a document called the Tower of Hashi Corp. I think we wrote it when we were still around five Employees so it was really early. We published it about a year later. I think we published it in 2014 But I'm not a hundred percent sure if that's right But what the Tao is is really sort of the principles that guide sort of our vision our roadmap and product design of our products and When you know, I've worked in companies where when I hear the word principles I think it's some HR checklist that the company just has and with something like the Tao I think it's it's important to know that we wrote it when we're five people. It's important to know That we've applied it really rigorously sort of to our tools And so what I want to do in this talk is go over the principles of the Tao Explain what they are why they matter to us and how we've applied them to our tools and my hoping with my hope with That is that you could take this and it's more broadly applicable to not just building tools But also a design decision and in when you're adopting tools like is adopting this tool Is it are certain elements of the Tao important to you? And so an architecture? You know issue with this tool is not going to work for you and Yes, so let's get started going through the Tao There's eight of them a few of them are really similar so they'll be very fast and some I'll spend more time on So the first thing in the Tao is workflows not technologies and it's not a mistake that we put this one first It's really really important to us. And so the idea behind this is that technologies both software and hardware Continue to shift like continuously will shift if you expect that anything is going to remain constant you're in for a rude surprise and so with this idea The the core thing is that product design should start with an envisioned Workflow to solve a problem. And so I use a few words here I say product design and I'm probably going to say that a lot when we start a new tool Whether it's a new open-source tool or a new internal sort of back-end service We don't start with directly with algorithms or architecture things like that We ask ourselves. What's the problem? We're trying to solve and then we start designing and and I use the word design not in the in the meaning of visual design, but actually holistic design of how is it going to feel but also how is it going to work and so the examples I have here from our industry are Sort of looking at you know mainframe to server server to VM VM to container or if you look at physical data centers to cloud All these are huge paradigm shifts that have happened sort of over 10 to 15 year periods and in all of them lots and lots of software was replaced and If you look though the core problems that people are trying to solve just didn't really change And so the idea behind this is that most problems don't disappear some do but most problems don't disappear Some problems are created of course, but there's a big group of problems which stay the same And so if you work if you aim at work close first You could often create software that could span Multiple paradigm shifts, and that's really important to ease the adoption and transition into these different Different stages, and so the best examples for our software here are terraform and vagrant Terraform is a tool for creating infrastructure With terraform you could create VMs you could create Physical servers you could create containers you can manage sass applications, and we have people from hobbyists all the way up to You know the world's largest on any given day company I'm using terraform to manage Vastly different things, but using the exact same workflow And so the last thing I'll say about this against really important So spending a lot of time on this slide, but is is this is how we also start our software terraform and vagrant actually both started as Bash scripts and when I say that people usually think I built like a minimum viable product in bash I didn't I just put a bunch of echo statements and pretended something was happening when nothing it did absolutely nothing But the reason I do that is I as I write it in bash, and then I use it for a day I use it given it does nothing But I use it and try to see if it feels right like is this how I actually want to work on a day-to-day basis Because I'm gonna commit to sort of like building something that I'm gonna you know work on and use for years Is this how I want it to work? That's really the focus on workflows The next thing much simpler much more obvious I think is is the concept of simple modular composable This could kind of be described as the Unix philosophy in a way, but I think that's That the Unix philosophy is always interpreted to the speakers like you know The most beneficial definition so instead of saying that the goal of this is really just to prefer Smaller components with well-defined scope That are functional on their own but can be integrated and composed with other tools to do new and interesting things And I think this is really obvious in our and in our in the ethos of our company We are sort of one of the few startup companies that Built so many pieces of software that do vastly different things instead of bolting features on to different products Vault is a good example We built vault because people were putting secret information in console Which is a key value store and we didn't feel console the console security story It's just not built for that and so we felt sort of guilty in a way that people were putting secret information in there And we didn't have a better option to give them We could have bolted on encryption to console and certainly from a pragmatic standpoint That is the way we started the design But as we started thinking through the turtle tower of security problems You know beginning with where does the key stored? How do you rotate the key who has access to the key? How is security bootstrapped? You know as we went through these turtle problems. We realized that it would be a humongous problem Solution to just bolt on to console and would be way out of scope for what that project was trying to do And so that's an example of building vault The next thing is communicating sequential processes So if you're building these modular components is built on modular They have to be able to communicate with each other and for that We just follow this model where all our software should be a standalone process that runs well on its own with a well-defined Sort of communication interface An API that the use that they use to compose each other. I think that's fairly straightforward The next thing is immutability and so immutability is of course the idea that things should not be able to be changed And the most popular and and very appropriate for this conference Example is version control right with things like get we we get the Benefits of immutability which is sort of the idea of atomic You know it's changeable with some surgery But these atomic units that represent a version and in a history behind that and who did you know a sort of blame trail And these are only possible if you can't just change things whenever you want in the middle And so immutability is really important to us because these concepts are really beneficial to other things And a good example is infrastructure if you consider sort of each stage of your infrastructure as an atomic unit That's driven by a specific change then you could see the history of your infrastructure You could see who Impacted that history when the change was created But you could also reason about desired states Current state and sort of how to get between them if you know that what you should look like is exactly this and not This with these little changes It's exactly this and you're in this other worldview you could transition to that and that's really important for infrastructures Next thing the next two are really the idea of codification so Codification is the idea of encoding knowledge as code and so with infrastructure Historically knowledge is passed on via oral tradition You join a company in their you know system in or it or ops or whatever group You look at the infrastructure and you ask, you know, why are things networked this way? How does you know from from a web user to this service? How does how to what what applications that go through how do things work and the most common response has historically been Oh for that you should talk to this person and for this you should talk to that person because they're the subject matter experts on that And the problem with oral tradition is is it's slow It's also just fickle because human memory is fickle and so you don't quite get you know the truth usually And so we ascribe very heavily to the idea that knowledge should be represented in code and use that as a source of truth so with tools such as Begurant for example, how do you create your development environment the answer before used to be read this? Humongously large read me and follow this series of steps and the answer today can be We have this code that is also executable like the document and description of what is your dev environment is also the configuration for the creation of that environment and So that is the second thing which is automation through codification The idea that manual processes should be encoded as code and automated And this in our industry is just necessary and I heard talks yesterday talking about just growing scale When you're this this sort of scale of Infrastructure growth and the scale of application change in the data center is has already exceeded the point of human capability And so we need automation as a tool to leverage ourselves to be able to manage that and From the talks I saw yesterday, you know if you imagine a world if you believe in a world where there's only gonna be You know an order or more orders of magnitude more devices whether they're Whether they're my refrigerator or I really don't want my refrigerator to ever be connected to the internet But whether it's my refrigerator or you know a car or a watch or whatever it is This is just gonna put more and more burden And so we're gonna need automation to be able to scale these processes properly. So automation is Absolutely critical and the vehicle for automation that we choose is codification Which is different than simple scripting, which is the type of code It's this idea that sort of the knowledge and processes is the same document that is automated And the next thing is the idea of a resilient system. So we're deploying more and more things We're moving more and more to Cheaper less reliable whether it's hardware or just heart, you know infrastructure providers and Distributed systems smaller devices things like that and so in building this systems have to be resilient It's not a matter of You know if there's gonna be a failure It's a matter of when that's always been the case, but the when happens to just happen all the time Nowadays in large enough infrastructures and so you have to consider resiliency and there's various approaches to resiliency But the approach that we like to take is this desired state model It's the idea that to build a resilient system the system needs to be capable of understanding a desired state it needs to be capable of Determining its current state and it needs to be capable of creating a plan or a path to get from its current state To the desired state and if you consider that abstractly that describes leader election systems that describes infrastructure Configuration and desired state that describes configuration management This is sort of how we build resilient systems and if you could build this property into your software The idea is that they all should Strive and automate to being in the correct state all the time And so you could see examples of this with terraform which is tear when you run terraform There's a plan sub-command and when you run plan what it actually does is inspects the current state inspects your Desired state and shows you what it would do to reach that because changing infrastructure is scary So it shows you that before you could apply it With things like console leader election like I said Could move to his desired state of having a server a leader And then the last element of the towel which is really my favorite But also the one that has actually been the most challenging for for some people that have worked at our company We've actually had some people leave the company which which have left because we're just we're just too pragmatic but it is pragmatism and Pragmatism is the understanding that Everything I said before is a set of ideals and there are ideals that we should aspire to and ideals that we should fight for and build into our tools, but if it's just simply not the right pragmatic solution then we need to be able to be You know understanding enough to re-evaluate those ideals for the given problem set at hand and so a good example of things like this is That not everything we do is immutable Immutability introduces a number of challenges and immutability is not always practical And so the biggest Offender of this is console is our KV store console doesn't actually have Versioning sort of built-in doesn't have this concept of immutable Chainsets it has idea of transactions and things like that But but to some people that's not enough and so they'll reference our towel and say you know You're violating this principle you had Which is fair, but at the same time. It's it's a practical. It was a pragmatic decision at the time and we certainly You know got built features around that more and more as time has gone on So pragmatism is absolutely important when building these building against ideals and so that is really the towel of Hashi Corp and and I hope that if you've used our software You could see it every day and what you're using All the tech leads or projects all the engineers of our projects continually sort of apply this on a on a RFC by RFC basis when new features are being developed But this is also the principles that we use when evaluating software that we don't write when there's five different choices out there We tend to choose the choices that align Closest to our ideals and by having them written down and having them clear You know our opinion isn't isn't changing and isn't Isn't just what's best for the moment. It's actually really clear of what we care about and what we're looking for So I hope this helps. Thank you