Talking Terraform With HashiCorp

Transcript

Scott McAllister: Welcome to Page It To The Limit, a podcast where we explore what it takes to run software and production successfully. We cover leading practices used in the software industry to improve both system reliability and the lives of the people supporting those systems. I’m your host, Scott McAllister, @stmcallister on Twitter. Today, we’re going to talk about managing SaaS service configurations as code. Terraform is an open source tool that allows you to define your infrastructure as code using a simple declarative language. With just a few commands, you can define, manage and deploy that infrastructure across a variety of SaaS providers and virtualization platforms. Our guests for the episode both come from HashiCorp. We have Paul Hinze, senior director of engineering for Terraform, and Robbie Th’ng, director of product for Terraform. Gentlemen, welcome to the show.

Robbie Th’ng: Thanks for having us.

Paul Hinze: Hi there.

Scott McAllister: So to get us started, describe Terraform for everyone and what’s new to using it.

Robbie Th’ng: Yeah. So, I’d say Terraform is… I think to most people, Terraform is the best way to provision infrastructure, no matter what you’re using. That, I think, was true for a fairly long time. But, I think it’s the best way to provision a lot of things other than infrastructure. You can provision services. You can provision external development tools, as well as just the infrastructure you can pay providers today. What would you add, Phinze, anything else?

Paul Hinze: Yeah. So, it’s essentially a tool that embodies this concept of infrastructure as code, this idea that you can capture the notion of any piece of infrastructure that you want to create as this declarative configuration, and it can drive anything with an API. And so, it’s a really powerful tool and it sits at a relatively low level that allows you to express a lot of different things and to provision a ton of different things.

Scott McAllister: Now, Terraform is pretty popular today. As it’s gaining in popularity, when you introduce, people say, “Oh, I work at HashiCorp. I work on Terraform.” What are some myths or common misconceptions surrounding Terraform?

Paul Hinze: Let’s see. I think the first misconception I would say that it’s important to try to get your head around is there’s this moment where it clicks for people that I think it takes a while to get to. I’ve definitely seen plenty of people pull up the Terraform website, hear us talking about Terraform and just go, “What?” It’s a very abstract space in the overall DevOps world. I think it really takes that trying it out and really playing with a little bit of configuration, provisioning your first thing in order for it to click. And so, a lot of those common misconceptions are not even having it all clicked in your brain. For those folks, I think, trying it out, really, you get that aha moment of, oh, this is what this thing does. This is a really powerful tool.

Robbie Th’ng: Yeah. I’d say let’s try it. I think the one that I come across the most is that people often think we only think Terraform is the way to do things. That is definitely not true. A lot of people who are doing quite maybe simple things within infrastructure or they’re doing things with smaller teams sometimes say, “Well, why can’t I just use console? Why can I just use this other tool that was using Ansible or something like that?” It’s like, “Yeah, you can.” There’s nothing wrong with that. It’s not bad to use other tools instead of Terraform if it doesn’t match your use case. I think the aha moment for Terraform is when you have to do something a lot or when you have to do something with a lot of people or a lot of different groups when it comes to infrastructure services. If you’re not there, that’s totally fine. You don’t need to use Terraform. It may not be the best thing for you, but I think we believe it’s the best way to provision stuff. So, that’s the thing we’re focused on. But, it doesn’t really matter if you use it in concert with other tools or if you don’t use it at all for some things.

Paul Hinze: Yeah. That ties back into the HashiCorp philosophy of the way that we build our tools is we build them in order to be incredibly interoperable and incredibly well-scoped to a specific problem space designed to be able to work alongside of the plenty of great tools that we have in our space. That’s been our philosophy from day one. I think really it’s a user-centric philosophy, which allows us to be able to go to our users and say, “Hey, let’s figure out what works for you. Maybe in this case, it’s Terraform. Maybe in this case, we should hand off to something else.” Yeah, I think it gets more users more successful.

Scott McAllister: I liked what you said about how you have a user-centric philosophy. I think in software today, none of our products can run alone, right? We all have to interact with each other. Even if we’re almost direct competitors, right, you still need to provide what best benefits the users. So, that’s a great philosophy to have. So, what are some of the common stumbling blocks that people have for getting started with Terraform?

Robbie Th’ng: Oh, man, so many. I’ll start with the first one, but I think that it goes in two stages where there’s two distinct stages for us. I think when you start with Terraform, wrapping your head around infrastructure as code is probably the very first one. Especially if you’ve come from a world where a point-and-click editor is how you’ve made infrastructure or you’ve come from a world where you go through a series of web forums to get infrastructure, if you’re coming from that infrastructure as code, then dealing with that initial hurdle is probably the biggest thing to get your head around. And then of course, HCL is an opinionated language. It’s an opinionated form of writing infrastructure. And so, you have to maybe cross that barrier as well. But, I think the trade-offs can somehow tell our languages like Go for doing infrastructure, provisioning are probably worth it when it comes to decorative stuff. But then, after you’ve got past those things, there’s another barrier waiting for you, which Phinze knows all of that.

Paul Hinze: Yeah. So, that first barrier of getting familiar with this idea of writing configuration to describe infrastructure and then using Terraform to provision that infrastructure, that’s stage one. So then, you’ve got this code, which has all of these great properties that allow you to version it. It allows you to share it with your team and they allow you to collaborate on infrastructure. As you start to take advantage of those values of infrastructure as code, you run into, honestly, a lot of the same problems that you do in application configuration or application authoring, which is how do I organize a larger set of configuration? How do I organize a repository? How do I share this repository with my team and how do I wire it up so that I know only one person is making changes at a time? We want to have approvals happening such that no one person makes changes at a time and you start to stack these on each other. Okay. Now, I’ve actually factored this into multiple repositories. I want to share code between these repositories. It’s so funny that every Terraform user goes on this journey of scale and it’s really easy to forget that we have this huge body of knowledge. The whole concept of infrastructure as code is this idea that we’re borrowing all of these practices that we’ve been using for years for managing complexity from application development, and so helping people link their brains back to the ways in which they solve these problems for application code because a lot of the solutions are going to be the same. You want to share code between repositories. Well, that’s very similar to having a library that you share between your application repositories, things like that. So, there’s this maturity model. As you scale, as you further invest in using Terraform, there’s new hurdles to jump over, but there’s a lot of help around.

Scott McAllister: I like how you compared configuration as code as application development because I think that’s one of the strengths of doing configuration as code. As a developer, coming from my background, as I was getting into Terraform a little bit, I came in backwards, I guess you could say. I was introduced to Terraform because I arrived at PagerDuty and someone said, “Hey, we have this thing called Terraform and the provider we have need some updating.” I said, “Okay, what’s this?” And so, I just jumped into it like every software engineer and just try to figure things out. But, I learned how Terraform worked by doing provider development first and then figuring out what this infrastructure as code or configuration as code concept was. But, that is the part the people start asking me questions about Terraform. They say, “Okay. Now, what’s the best practice about how to do this and how to organize my stuff?” That was where I stopped. I was like, “I don’t really know.” And so, I started talking about application development principles because it made sense. It was like, “Well, you probably want to separate concerns and put things, organize them a little bit, just like you do your code.” So, that’s the really good point.

Robbie Th’ng: Yeah. That’s exactly. I think the longer we’ve gone on, we’ve seen more parallels to the application development framework. In some ways, the organizational and the scaling challenges you have with Terraform now are similar to why application development got to CI/CD. You wouldn’t have done CI/CD if you’re just a solo or a small team. But, you probably do it in a larger group or in a larger organization. It’s similar with Terraform. You may not have used Terraform in the way that you maybe use it in a larger organization. And so, those challenges are pretty appropriate for where we’re at.

Scott McAllister: For sure. So, you all had a lot of experience watching customers and users use Terraform. What are some ways that have been surprising, some use cases that you didn’t see coming that users have been using Terraform for?

Robbie Th’ng: I have so many of these, I have so many of these. I think the number of providers is pretty staggering. I don’t think we… Like Phinze was saying, really, anything is API addressable. It’s something Terraform provide around. I don’t think we ever saw as many things being addressable and useful with Terraform as there have been created until the comedy ones, which is the ordering pizza provider.

Paul Hinze: Yeah. You got to mention that. Anytime you talk about surprising providers, you can order a pizza with Terraform.

Robbie Th’ng: Order a pizza with Terraform.

Scott McAllister: We’ll have to stop. Tell me how do you order a pizza with Terraform. I got to know about that.

Paul Hinze: It turns out, I think, is it Domino’s that-

Robbie Th’ng: Domino’s, yeah. It’s Domino’s.

Paul Hinze: … is API addressable. And so, I think it was April Fools this past year, an engineer puts together a fully functioning pizza provider and it works.

Robbie Th’ng: You should use it. It’s the only way to order food.

Scott McAllister: That is fantastic.

Robbie Th’ng: So, it’s Terraform.

Paul Hinze: Yeah. You’ll be sure of your order of the pizza. You know exactly before… Because you can do the Terraform plan, you can make sure that it looks right before you apply the-

Robbie Th’ng: You can collaborate on the pull request. We’ve been working with Domino’s for a while to get it in the adverse. The mobile app and the Terraform configuration side by side, I think, would probably be great marketing.

Paul Hinze: Yeah. They’re not taking our calls. We’re trying to cross-market Terraform and Domino’s.

Robbie Th’ng: But to a certain extent, I think something like PagerDuty is pretty surprising as well because it makes sense now. But, I think when you look at what PagerDuty does, the relationships that you set up within PagerDuty and the things that you want to alert on, when you get to a large scale, in some ways, like our configuration, they are repeatable. They are something that you want to be seen in a central manner and you also want to be able to have them shared. And so, PagerDuty in a way is surprising but in an awesome way because that makes a lot of sense. You would want to scale that. You would want to have that as something that’s not. So, I think the provider ecosystem is the constant source of surprise for me, I would say of obtuse product uses, which we’ve definitely seen a lot of as well.

Paul Hinze: Yeah. It gets to the point where essentially you realize that anytime you’re clicking more than five times in a UI, you’re really attempting to get some job done. If that job is modeling an idea, which in PagerDuty, it absolutely is, even when you’re ordering a pizza, what you’re doing is you have this idea of this pizza that you want. If there is an API addressable layer there, that is an opportunity for Terraform to consume that API and allow you to just say directly in a configuration, a declarative configuration, “This is what I want.” And then, that’s just a really powerful concept that can be applied in all of these different ways. I think complicated configuration in SaaS products, access control in SaaS products often becomes complicated. I think that there’s a surprise around every corner once you start to play out that concept across all of the incredible numbers and growing numbers of API addressable SaaS software.

Scott McAllister: I’m totally going to use that pizza analogy or at least-

Robbie Th’ng: You have to.

Scott McAllister: The fact that it’s an actual thing, you can use it as an analogy easily because everyone can picture a pizza and configuring what you want on a pizza. But, the fact that it actually is out there is just hilarious.

Paul Hinze: Yeah, it’s great.

Scott McAllister: That’s awesome. So, what do you see as the trends? Do you see more SaaS configurations being configured as opposed to virtual machines? What do you see on the horizon for Terraform?

Robbie Th’ng: I think the industry has followed Terraform, which is obviously nice. It’s a nice compliment to what Mitchell and Armon did. But, I think you’ve seen the cloud providers move in that direction. More things, more features seem to be coming out every year, every quarter now actually; Azure Blueprints, the work that Amazon is doing around strengthening cloud formation. I think everyone is starting to go along the line of configurations as the way to go in terms of deploying infrastructure because it’s necessary, I think, when you try to scale, when you have to do a lot of infrastructure provisioning or you have to do a lot of service provisioning. So, I think that will probably continue. I think we’ll probably see a lane where it starts to intersect with the old way of doing this kind of work, which is the the point-and-click tooling or some of them were graphical-based tooling. I think there will be an intersection there. There are some tools out there today, which are trying to make that happen, but I honestly don’t think it will stray too far. I think we’ll eventually stabilize into… This is just like you just have to wait for all of these configurations to interact and there’s hopefully a way for things to plug in. We’re of the opinion that multi-cloud is just going to be the way. So, I think making sure we have a way to reconfiguration again a lot of different services with Terraform being the answer that we’ve thought is the way to go. Whereas, I think other companies are looking at one service or maybe one provider as some target. But either way, it doesn’t matter. I think as long as people are writing code for infrastructure, I think it all comes out to be good in the end.

Paul Hinze: Yeah. I think if there’s one trend that’s been so resoundingly true, it’s there is no world in which there are fewer services. There’s no world in which there is less software. That trend line is not proving to change and doesn’t look like it’s going to. And so, I think when you have the number of average tools that a given shop is using to manage their infrastructure and all of the services surrounding that infrastructure, it has been going up for a while. I think the approach Terraform takes to give you a layer that allows you to configure, side by side configure your AWS account, your Azure account and your PagerDuty alerts and your observability platform and your logging platform, that’s where I think we’re really excited that we find ourselves in this very useful place for people, in a space where we can help them manage that complexity by providing a common workflow across this continually exploding set of software. As long as there are APIs, we can write providers and we can ask the community to write providers and get Terraform for them helping you out.

Scott McAllister: Where you said there, how there is not going to be a world with less software, that is so true and leads us right into talking about providers. When people write software that needs to be configured, a Terraform provider seems to be in their future. Each of these are open source. They’re built and supported by the communities surrounding Terraform, not necessarily by HashiCorp. In fact, the PagerDuty provider was created by a developer in Sweden three years ago. He continues to remain involved with the project and is one of the main maintainers today. He said he did so because of the positivity in the Terraform community. He was super scared to actually submit the pull request to merge the provider in to the point that he actually had to have his fiance click the button to open the pull request.

Paul Hinze: Adorable.

Scott McAllister: It’s a good thing she did because the PagerDuty provider for Terraform is hugely used, hugely successful. He’s still involved today. Even though he’s not an employee or anything, he’d still believes in the community and because the community has been so supportive. So, talk about how everyone or anyone can write a provider for Terraform and how they can get help from HashiCorp and/or the community.

Paul Hinze: Yeah.

Robbie Th’ng: Yeah. The PagerDuty provider is surprising. I think I was talking to someone from there recently and we were looking down the list of providers because we were looking at activity just in general. I think the PagerDuty provider was like a lot of people who were using it had some insane amount of downloads. I was like, “Wow, that is way higher than I thought it would be.”

Scott McAllister: Last I heard, we were number 19, I think.

Paul Hinze: Yeah.

Robbie Th’ng: Wow.

Paul Hinze: You’re right. I remember seeing PagerDuty in the top 25.

Scott McAllister: Yeah, pretty insane.

Robbie Th’ng: Yeah. We have a full team of people that are working on the SDK and honestly show it to the provider community in general. Also, our provider team at HashiCorp, they work really, really hard to try to make developing a provider as easy as it can be, especially in the last year when we had a major language change. It was 0.12. That team is doing a really good job. But, that’s not to say that there… It’s really hard to know, I think, what the new experience is like, especially when you’ve been working in it for so long. So, that person who wrote the PagerDuty provider probably could tell us a lot about what that’s like and I’d imagine you could know as well. I think we can always improve with that. And so hopefully, we’ll get more new people writing providers so that they can tell us where are the areas that we can improve. I think it’s good today, but I think you can always definitely be better.

Paul Hinze: Yeah. But, I think that story is so… That’s just such a great story of open source. I think that’s one of the special things about the origins of HashiCorp and the way that Mitchell especially as this very open source focused individual. He worked on Vagrant open source for almost five years before starting this company. The way in which he instilled in everyone here his philosophies around maintaining that sense of positivity in the community, that sense of welcoming, it’s so cool for me to hear that it’s really still having an impact years into HashiCorp and getting us the first version of the PagerDuty provider due to that sense of welcoming, that sense of positivity. That’s a Testament to how important that work has been and how important it continues to be to really maintain that community. So, that’s one thing. And then. I think from a tooling perspective, this is something that we want to take that sense of that community mindset and bring it into ever-improving tooling. Right? We want it to get easier and easier over time. That’s something that you’ll see us continuing to move on. So within the past year, we did a big overhaul of our extend documentation on the website. The documentation in order to write a provider got a huge boost. Now, we’re working on the SDK. We recently extracted the SDK from the core repository to allow us to iterate on it more quickly. And so, you’ll be seeing more improvements there. I think there’s a lot of bigger things in the works as well. We’re working on not only authoring providers but also publishing them, making it easier for community members to publish providers without having to coordinate with us as much to get their docs published and to get the providers available for downloading in Terraform and that. So, there’s a lot of gears turning on our side that we’re continuing to invest because we know that the providers make Terraform. They are the thing that makes Terraform do what it can do.

Scott McAllister: For sure. As a developer, getting involved with a provider project was my first introduction to go, which is what the providers are written in. I liked having or being involved in a project that was so well-structured. Right? You require the testing and things that are necessary in order for things to get published into the project. So, I really liked, I guess, you say having bumpers or guardrails to get me into a good spot and learn how to do it the right way, I guess you could say. So, that, I can attest to the well-structuredness of the community and of the tooling there.

Paul Hinze: Yeah, that’s a common story. We have a lot of folks who pick up Go in order to write a Terraform provider. You hit the nail on the head, which is there’s a ton of sibling structures that you can borrow from. If you’re adding a resource to an existing provider, you look at the other resources alongside. If you’re starting a new provider, grab the structure from a sibling provider. The docs are great too, but there’s also a ton of examples out there.

Scott McAllister: Completely. That’s exactly how I added my resource when I added the resource to that PagerDuty provider. I was going off the example of the other resources there, so that was exactly how it worked for me.

Paul Hinze: Cool.

Scott McAllister: So, what should listeners know about what’s next for Terraform?

Robbie Th’ng: I think that the next thing for Terraform is for us to try and give more back to the community in all honesty. Earlier, well, last year now, God, it’s a new year, you always forget. Last year now, we launched Terraform Cloud. Terraform Cloud was a way for us to try and tackle the second part of the problem that Phinze was talking about. It’s really easy to get going with infrastructure provisioning, but it’s pretty hard to collaborate or to find the best practices around sharing and collaborating and working together with other people in Terraform configuration. And so, Terraform Cloud was an answer to that. We wanted to give as much of it away for free as we possibly could. So, there’s a pretty generous free tier where people can get started. I think we’re going to try and continue to add to that. There are other challenges and there are other things that are coming into that product so that it becomes much easier to use Terraform with a group of developers, maybe a small group of people or a small team inside your company, just to get started with Terraform working together. We have improved user management, which just came out. I think we have a couple of more workflow improvements that we want to do as well. I think one of the things that Terraform Cloud introduced is a way to launch Terraform with a VCS, with a GitHub or GitLab or a Bitbucket connection. That’s something I think we want to try and improve as well over time. I think that’s the next immediate couple of things longer term. I suppose we’ll have to do another version of Terraform open source at some point, but who knows where that will be?

Paul Hinze: No, that’s not true. That’s not true. We’re working on-

Robbie Th’ng: Stuffing that 0.12.

Paul Hinze: … stuff all the time. Yeah. The thing is we’ve got teams working across for the providers, open source, Terraform Cloud and Terraform Enterprise now, and that we’re all making progress. It’s been really exciting to see what we can get done together with teams on all these various parts of what has become a pretty vast surface area for the overall set of Terraform functionality. But, I think Robbie’s right that the key thing for us is really continuing to invest in these more complicated problems that arise once you start to scale your Terraform usage. So when you’re getting started, it’s all about smoothness. We want to continue to smooth out that experience from I don’t know what Terraform is to I am, as an individual, successful using Terraform. That’s a sanding operation that we’re going to be continuing to work on. And then, the next step is I want to use Terraform with a team. That’s something we also want to be absolutely… The steps need to be totally obvious. And then, once you say, “Okay, my team has grown, I’m working in multiple teams on collaborating on infrastructure,” that’s where things get really interesting. Those are the problems that we’re solving in Terraform Enterprise, helping people share modules across multiple teams, version them across multiple teams, start to work on policy and governance stuff, and controlling for various things you want to be able to prove can or can’t happen against your infrastructure. So at each of these layers, there’s so much interesting meaty problem space for us to continue to work on, which is why it’s exciting to be able to have so many teams to make progress on all of these different areas. So yeah, there’s lots to do.

Scott McAllister: Sounds like it. So, this is actually the first Page It To The Limit episode that we’ve recorded that was not we were all being in the same physical room. Paul, Robbie, you and I, when all us are talking to each other over Zoom, and so-

Paul Hinze: The power of the internet.

Scott McAllister: Yes, exactly.

Robbie Th’ng: It’s become a thing, the internet, so cool.

Scott McAllister: So, I hear. So, we’re transitioning to this format and we have a couple of recurring questions that we ask each of the people in our show. They’re a little bit off the general main topic, but just everybody gets asked these. The first one is, what’s one thing you wish you would’ve known sooner when it comes to running software in production?

Robbie Th’ng: Oh, man, that list is pretty long.

Paul Hinze: Yeah. Pick one thing of the many you wish you had known sooner.

Scott McAllister: Right.

Paul Hinze: For me, I think the big thing I wish I could have instilled in my younger self is pivoting your understanding of failure, from failure in a system, failure in terms of bugs in a system, in terms of unforeseen events, as being less scared of it, being less freaked out when it does happen and accepting it. That’s been huge. Being able to do that perspective pivot on failure, I think, is something that was really important for me in the middle of my career that I wish I could have done earlier to say, “Failure is the system giving you new information. Failure is an opportunity to improve. Failure is natural. It is something that is always going to happen and it’s always something that you can expect.” And so, that is one insight that I wish I could smear earlier in my career because I think it would’ve saved me a lot of stress. It would’ve saved young Phinze a lot of stress to be able to have me say, “Hey, failure is okay. It’s part of it.”

Robbie Th’ng: Easy plug would be to get your reporting structure for PagerDuty correctly early on because having been woken up several times early in the morning because that wasn’t sorted as in the night, that is definitely one thing. But, I guess the most obvious answer for me is not switching up technology so quickly. I wish I could have told myself that many years ago. I think there’s always a feeling like you have to adopt something new or something that’s really hot based on how high it is on Hacker News or something like that more quickly. I don’t think that’s ever paid off any time that I’ve done it. It almost would’ve been faster and better and slightly more efficient if we just continued working on a stack that we were familiar with or on a tool set which we were more integrated with at that point, as opposed to trying to adopt something new. But, hindsight is 2020.

Paul Hinze: Yeah, totally.

Scott McAllister: Oh, the lamentations of every software developer everywhere, right? All of us have those projects that we got halfway done, three quarters away done, and said, “Oh, new shiny, new framework, new language, new this, new that.” I’m totally there. So, is there anything about running software in production that you’re glad we did not ask you about?

Paul Hinze: This is a trick question. This is a trick you’re trying to get us to-

Robbie Th’ng: I’m always glad when people don’t ask us how much we use Terraform because the secret is not at all. We absolutely not. It’s not true. I think the thing for me I’m glad people don’t ask often is how is Terraform Enterprise or Terraform Cloud built? Getting back to the first question, because I think it ultimately doesn’t really matter. I think the thing that matters the most is potentially now obviously how we run the service and if the product is answering the right problems that your company or team is facing. But, I think running software in production, asking what we use is a pretty poor indicator of maybe what is the best thing for you to use or what may be appropriate for your team. And so, it comes up quite a lot. I think we’ve seen more of a focus on this in the last few years where people are trying to learn what some companies do. But, it often isn’t the best way to make your choices about what you should do. I think sometimes that considering what’s more important for you in terms of what you’re trying to get done is a much of better place to start, as opposed to looking at people who’ve maybe done something differently depending on the challenges that they’re facing.

Paul Hinze: Yeah, that’s a really good answer. I think I’m going to dovetail off of that answer because I think it’s such a common and it’s natural too. I think we make these tools and I think the natural idea of saying, “Well, how does HashiCorp do it, right? Tell us exactly how your VPC is arranged in AWS because we want to copy, that’s probably going to be the best.” I think we spent a long time… We’re now getting to the size of a company that we’re starting to approach some of the problems of scale that for a long time we just didn’t have. We were a smaller company than many of our customers. And so, that was a constant back and forth. Them saying, “Well, how do you do it?” It’s like, “Well, at the time or whatever.” I was like, “We’re a 50-person startup. How do you think we do it? We do it like a 50-person startup. We don’t have the kind of constraints that you might have as a Global 2000 enterprise.” That gap is closing slightly, but I think Robbie’s got the right idea, which is we really have to constantly take that conversation and say, “You don’t want to know. We can tell you how we do it, but that’s not going to be all the information you need. We need to talk about the way that you do it.” Really, facilitating that feedback loop where the reality is that a lot of our customers are running our tools at scales, where they are generating the Vanguard of information, of what it’s like to run them at scale, and so for us to have really good relationships with those customers so that we can learn from them and we can bake that knowledge back into the product, back into the documentation and the best practices guides and stuff like that. But, the knowledge is not all coming from us. It’s coming from our users using the tools and us talking with them. I think ultimately that’s really exciting, but it is counterintuitive. It is common for people to come to us and be like, “Well, you’ve got all the answers.” It’s like, “No, we don’t. We have to figure all this out together.”

Robbie Th’ng: There are very few answers actually. We often don’t have many answers like experts and nothing. We’re trying to build the best provisioning platform that we can. So, we don’t know things like alerting or logging, our best practices for what a customer is trying to do. We’re never going to be good in those aspects as other people would be. We’re always just going to try and make the best provisioning platform that we can. That’s really all that we’re going to focus on.

Paul Hinze: That’s where you come back to the community sense, right, which is that’s where we can foster these relationships with other vendors, with other members of the community, with other folks just slinging software around online, and to be able to make those recommendations, make those connections to people. Because we do, we want to make our customers successful. The answer being not always HashiCorp knows the answer, but HashiCorp can maybe help introduce you to the folks that might be able to help you out, absolutely.

Scott McAllister: So true, so true. As we mentioned before about software, but even about our companies and our people, we don’t live in silos. The sharing of information is back and forth. None of us are experts on all things. We focus on one little thing or whatever our focus is. And then, we share that information around with each other. So, that’s a great point. Well, gentlemen, thank you very much for being on the show today. I think our listeners have definitely benefited from the knowledge and experiences you all have shared with us. So, thank you for coming on.

Paul Hinze: Our pleasure.

Robbie Th’ng: Thanks for having us.

Paul Hinze: This was great.

Scott McAllister: And thank you for listening today. This is Scott McAllister and I’m wishing you an uneventful day. That does it for another installment of Page It To The Limit. We’d like to thank our sponsor, PagerDuty, for making this podcast possible. Remember to subscribe to this podcast if you liked what you’ve heard. You can find our show notes on PageItToTheLimit.com and you can reach us on Twitter @PageIt2TheLimit using the number two. That’s @PageIt2TheLimit. Let us know what you think of the show. Thank you so much for joining us. And remember, uneventful days are beautiful days.