Automation Tools Q&A

[00:00:00]
>> Does anyone have any questions about Terraform or Pulumi before I go forward, yes?
>> Is there any kind of testing framework for Pulumi?
>> Good question, whichever one you want. [LAUGH] The reality of it is, is because it's the language you're working on top of, it can use those same test suites, right?

[00:00:20]
So if you wanted to, you could say, all right, well, you could actually do just testing with Pulumi if you really wanted to, because it's just unit testing. You don't actually have to create those resources. But you could say, okay, I have a module that handles all of my, a common one is that I do a lot, which is called conventions, which is just a file of all of my conventions.

[00:00:43]
How I separate things, how I uppercase and lowercase things. And then I have functions that I just reuse in all of my code. Can I do that in Terraform? Not really, that's a little bit more challenging. So when we go back to testing and all that stuff, same thing applies.

[00:01:01]
So it depends on the language, but yeah, you totally can, yeah.
>> Are there any workflow differences between Terraform and Pulumi?
>> The biggest workflow difference is gonna be based off of the language. For example, if you build Pulumi automation in Go, you actually have to build that to a binary.

[00:01:21]
It can't just read the Go code like it can with TypeScript and things like that, and that's because of how it works. When you do it with Pulumi, you build it down to a binary, and then the CLI tool actually talks to that binary, which is pretty interesting.

[00:01:37]
Whereas with Terraform, it's still the same process of install your packages, you still have to do that. But there's no package, again, there's no package.json. There's no having to set up any of that stuff really at all specific to the language, yeah.
>> Do syntaxes change for Terraform and Pulumi based on the underlying APIs from the cloud providers?

[00:02:05]
>> Terraform, no, not really. Terraform is really good at not changing stuff. They know that we are a configuration-based system, if we change those configurations, everything breaks. [LAUGH] And so Terraform does actually do a really great job at this. With Pulumi, you're gonna always have a bit more work to do, depending on the language and the specific circumstance you pick.

[00:02:33]
>> Is this scenario of potentially migrating from one approach to the other, like going from Pulumi to Terraform, or relevant factor in choosing one to start with?
>> You should try and avoid it, you really should. The reason for that is, is because both of them maintain state, right?

[00:02:49]
In the moment you provision something, it's there, right? And now, Terraform or Pulumi are tracking that state. So for us right now at Hippo, we have probably like 30, 40 Terraform Repos, and they all have their own state. So if I wanted to move our networks to Pulumi, for example, I would have to write the automation identically so that when I apply it over in Pulumi, it doesn't change for starters.

[00:03:21]
And then the second thing I have to do is I actually have to import those resources into my state, because they exist, right? Otherwise, if I tell Pulumi to run it, it's gonna try and create something that it doesn't know about, but Terraform already created, right? So that's the caveat to moving from one automation tool to another, is if you have existing state, it can be very, very challenging, yeah.

[00:03:50]
>> How sustainable is it having infrastructure written in several different languages when using Pulumi, and when do you have a policy around choosing one language?
>> Yeah, you probably would. At Hippo, our languages that I was like, guys, we got to pick, are Node.js, Python, and Go. We have no interest in Rust, sorry.

[00:04:17]
[LAUGH] We have no interest in Rust, and we have no interest in Java, any of those other languages, because we've been building on top of them for so long. So I think it does make sense to kinda go to your team and be like, hey, yeah, feel free to use languages, but maybe don't get crazy.

[00:04:37]
[LAUGH] We have no infrastructure for, again, maybe a specific language. Then that becomes what we call at my work a snowflake, which is a unique experience that then has to be managed on its own, does anyone know what that becomes?
>> Tech debt [LAUGH].
>> Yes, but it's also another word?

[00:04:58]
>> Loser?
>> Something knowledge.
>> [INAUDIBLE] knowledge?
>> Tribal knowledge?
>> Tribal knowledge, yeah, close. But yeah, tribal knowledge, where it becomes like, if you want the guy who did it, you gotta find the guy who did it. [LAUGH] You know what I mean? So I do think being aware of those decisions will make sure that you can interrupt between multiple languages really well, yeah.

[00:05:21]
>> There's a good comment in chat around using the AWS CLI.
>> Yeah.
>> They're just saying that you could technically use AWS CLI to create your resources, but that's time consuming and manual. If you scale, you'll wanna automate your infrastructure to not repeat the same things over and over again.

[00:05:38]
>> Exactly, yeah, exactly, yeah, I mean, my job or DevOps' job is really just doing what you're doing manually and automating it. And that can be as simple as clicking a button to solving the problem. And if you look at it that way, then yes, they're absolutely right, and I agree with them.

[00:05:59]
If you really wanted to, if you wanted to go really, really crazy with it, you'd basically be recreating Terraform, [LAUGH] if you think about it, right, because that's what Terraform does. Underneath the hood, it contacts the APIs and it does all that for you. But if you wanted to, sure, you could write a for loop that runs this AWS CLI command over, and over, and over, and over, and over, and over, but I don't know how well that'll work, so, yeah.

[00:06:22]
>> Just on the topic of state management, I feel like every time I've worked with Terraform, that's been the biggest struggle?
>> Yes, it is.
>> Is this any easier than Pulumi?
>> No, [LAUGH] no, that's the burden of state. It's not easier in a React application that uses state management.

[00:06:42]
Unfortunately, state management is really annoying. And I will talk about it later with things like Kubernetes, right, cuz Kubernetes has its own state, but then you've also got Terraform state. How do you make those two work? Always try and have one source of truth, one, right? That will probably help you a lot with that kinda stuff, yeah.