Episode 088: Pulumi in Action with Christian Nunciato | CloudSkills.fm

In this episode I catch up with Christian Nunciato full-stack developer and staff software engineer at Pulumi. We discuss Infrastructure as Code (IaC) and how developers can use languages like typescript to write their infrastructure code.

Christian Nunciato is a full-stack developer and staff software engineer at Pulumi. Previously, he was a principal engineer at Chef, where he helped build Chef’s open-source application automation platform Habitat.

Win a copy of “Pulumi in Action”:
https://kingsumo.com/g/0zxps1/pulumi-in-action

Don’t forget to subscribe to our mailing list at cloudskills.io/subscribe for weekly updates, exclusive training, and advice on how to amplify your career.

Full Transcript:

Mike Pfeiffer:
Thanks. All right, Christian, it’s good to meet you, man. I know that a lot of our listeners are super excited about Pulumi and everything you guys are doing over there. Welcome to Cloud Skills FM.

Christian Nunciato:
Thanks. Thanks for having me. I’m really happy to be here.

Mike Pfeiffer:
Yeah, it’s an exciting time to be doing Infrastructure as Code. Like I said, everybody in our community loves what you guys are doing. I’m excited to hear some stuff about Pulumi. Also to hear about the book as well that you’re working on. But maybe before we start, we could get your backstory. What is your role in IT? How did you end up at Pulumi and writing a book on Infrastructure as Code basically?

Christian Nunciato:
Yeah, boy, I’ve been doing web development primarily now for about 20 years. I got started as sort of back in the .com era after kind of teaching myself all I needed to know, kind of to get my first job as a programmer. I actually went to school for English, kind of studied writing and did some film stuff too in college. So I came to this stuff, just teaching myself entirely.

Christian Nunciato:
And kind of getting started in web app development early on, what I kind of eventually came to find was that I needed to be able to understand more about how to deploy my applications if I really wanted to be able to kind of do everything that I wanted to do. For many years, I’ve kind of worked in the kind of web app box where you kind of build your web apps, build your front end pieces, maybe a little bit of backend code, but then you kind of hand it off to someone else, cross your fingers and hope that that team can deploy that stuff for you.

Christian Nunciato:
And I always kind of found that a little unsatisfying, because I like to kind of make the whole thing myself. And so what this ultimately meant for me was I kind of had to figure out how to manage my own infrastructure. I was working on a project at a music streaming service for a while kind of trying to build an API platform. And I reached this point of needing to be able to do it, to do the infrastructure deployment on my own. And so that led me actually to learn how to … sorry, can I take pause?

Mike Pfeiffer:
Yeah, absolutely. Yeah, sure.

Christian Nunciato:
Sorry. So while I was working on that project, I kind of came face-to-face with him with my lack of understanding of how to deploy software in the cloud. I really just didn’t know how to do it. And that led me to a company called Chef, which is kind of where I learned about the concept of Infrastructure as Code and kind of the tools that were available at that time. And so Chef was amazing. Chef taught me about how to think about Infrastructure as Code, how to use those tools, how to write cookbooks and recipes that would manage servers, provision those servers to some extent. And I just kind of got bit by that bug. I just got really excited about managing all that stuff on my own.

Mike Pfeiffer:
Yeah. It sounds like a fun set of projects you’re working on, and getting into Chef, that’s really cool. I didn’t know about that. And that’s awesome.

Christian Nunciato:
Yeah. Chef was kind of mind altering for me. It really kind of opened my mind to just the-

Mike Pfeiffer:
A whole new world.

Christian Nunciato:
A set of possibilities that I … yeah, a whole new world really. And of course, being a developer entering the world of kind of operations automation was pretty daunting. It was a lot to try to kind of learn. Not just the tooling, how do I use Chef? How do I write Chef cookbooks and things to manage servers? But what is DevOps and what is DevOps culture and how do you know development teams and ops teams work better together? All of this stuff, it was a ton of information to try to ingest, but over a period about five years or so I did, and it was great. I love this stuff.

Mike Pfeiffer:
Yeah. That’s really cool, man. Yeah. It’s interesting too, because things have adapted a little bit. It seems like four or five, six years ago, all you heard about was Chef and Puppet and now, we have got so many different platforms that have taken off, what you guys are doing is insanely cool. So let’s circle back to Pulumi. Maybe not everybody listening knows what Pulumi does. We were chatting before we hit record Joe Duffy, the CEO of Pulumi was on this show way back in the early days. It was probably like one of the first 10 or 20 episodes we ever did. But what is Pulumi for anybody listening that hasn’t heard of it?

Christian Nunciato:
Yeah. So Pulumi is an Infrastructure as Code tool. It’s literally a command line tool, an open source tool that lets you write infrastructure code in your language of choice. So, I happen to be really into JavaScript and TypeScript so I can write JavaScript and TypeScript programs that describe cloud infrastructure that I want to use to create and manage. And I just write these programs and Pulumi will run those programs for me and then create that infrastructure on my behalf. So provision resources on an AWS or an Azure, or Google Cloud platform. So I write the program code and in TypeScript and that code describes some infrastructure, Pulumi creates the infrastructure for me. So it is a declarative Infrastructure as Code tool that works similarly to others. But I get to use my own languages and, and treat my as a software.

Mike Pfeiffer:
Got it. Yeah. And that’s like the real big promise. So for your position, you’re a JavaScript expert, so you can bring that skill set into this world. But if you’re like a C# expert or some other language, Java maybe those are all things that are supported, right?

Christian Nunciato:
Currently supports TypeScript, JavaScript, the .net family of languages. So C# and F# and a little bit of BB script, I think. But that may still be in the works. Also Go and Python, no Java yet, and no Ruby yet. Those are kind of ones that we’re thinking about supporting, but they’re definitely asked for.

Mike Pfeiffer:
Yeah. Yeah. It’s still amazing language coverage. Because going back to what you’re saying before, everybody’s kind of getting pulled into this world where they’re now having to do two jobs. Before you were just doing web development. You personally had an interest to maybe doing more of the infrastructure yourself to close that last mile for your projects. But I think infrastructure people are getting sucked into the world of software development and the developers are getting sucked into the world of infrastructure. This is a really nice … doing Infrastructure as Code, using a strongly typed programming language is an interesting proposition, especially when there’s a lot of frustration about doing a YAML templates and JSON templates and stuff like that. Is that a big thing that you guys experience when you’re talking to users? Do they share their experiences of, it’s kind of refreshing to move over from that?

Christian Nunciato:
Yeah. I hear that people who use Pulumi really like Pulumi. And I say that as someone who works on Pulumi also, so I’m probably biased. But I don’t hear a lot of people sort of not enjoying the experience that Pulumi provides. Because I think the thing that it tries to give you, is what you end up facing when you work on large-ish infrastructure projects is a complexity that programming languages kind of help you to manage. I came to prevent me from Chef and having worked on an automation platform called Habitat. We used Terraform to deploy our infrastructure, it was great. Terraform is awesome. But the challenge with Terraform, for me as a developer was that I wasn’t using it every day, for one thing.

Christian Nunciato:
And so I would kind of use it now and then, and put it aside for several months and kind of not touch it. And when I would come back to it, I had to kind of learn it again. So it just wasn’t something I used every day. That was my personal issue with it as a developer. It was great when I used it, but I kind of constantly had to brush up on it. As well, the projects that I worked on with Terraform. This is not specific Terraform and sort of specific to just sort of descriptive languages, like HCL and YAML and so on. When you’re trying to kind of manage large projects with these config languages, inevitably you end up hitting issues where A, you’ve got like a lot of configured language that you’re just trying to manage.

Christian Nunciato:
There’s a lot of YAML or lots of HCL and there aren’t a lot of constructs that allow you to manage it that complexity easily. But when you can sort of move that into a programming language, like a TypeScript or a Go or something, where you can decompose the pieces of that infrastructure into software-like modules and primitive, so on. Refactoring and managing large projects just becomes really easy because languages are made to do that. You know what I mean? So I might begin with a static website deployment script, but that will grow over time. It’ll grow to kind of add serverless components or a database or something-

Christian Nunciato:
Serverless components or a database or something, projects sort of grow and grow over time. Being able to manage that growth and complexity in a language like TypeScript is just joyful. It’s just nice and easy, refactoring is easy. It’s much harder to do that stuff with YAML and JSON and stuff like that. They aren’t facilities and languages that really let you do that.

Mike Pfeiffer:
Yeah. I’ve been in so many situations where I get an hour into a infrastructure deployment, some kind of templating system or whatever, and then realize that, I had a missing double quote at the end of a string somewhere, or I missed a closing or terminating character somewhere. When you’re not dealing with a real programming language, it’s so easy to miss that and then waste a bunch of times. Definitely a big fan of the value proposition.

Mike Pfeiffer:
The other thing that I picked up on what you were just talking there was, and I saw this in your book too, there’s a section in your book about building apps and you talk about static websites. As a developer, are you fascinated by the fact that static websites have made like a big resurgence now, especially since you started during the dot-com era where static websites in the beginning were a thing, and then they went away, now they’re back. Are you a fan of that? I’m curious to hear your thoughts.

Christian Nunciato:
Oh yeah, definitely. First of all, I love the web platform, and I love the essential sort of basicness of a static website, particularly like, because you can do so much now in the client. Whereas years ago, you really couldn’t. We can build pretty rich experiences now in the browser with just HTML and JavaScript and CSS. Back in the day, when I started, you couldn’t really, there wasn’t that much you could do in the browser. It was really pretty static, but now I think static is… It takes on a different kind of meaning. Yes, we deploy statically, but the stuff that happens in the browser is very, very dynamic. But yes, I’m a huge fan of the JAMstack approach to building applications.

Christian Nunciato:
What’s neat about using Pulumi, especially for something like this, is that you can write a single program, for example, like a single TypeScript program that defines your static websites and that the components of your static website, but also just layers in serverless functions and so on all in the same program, all in the same language. You can write programs that are essentially programs that run on the cloud, where the cloud is like an operating system. You know what I mean? There’s a static website component to this and there’s serverless Lambda and so on, all wrapped up gracefully in a single program. That’s a pretty satisfying thing to do.

Mike Pfeiffer:
Yeah, especially when you can do everything almost in one language, almost the whole web application in JavaScript from serverless functions perspective and all this stuff. It’s really cool, man. If anybody isn’t a developer, they may have not heard of the JAMstack terminology. You might’ve heard it referred to as serverless. That’s an interesting thing. When we’re talking about JAMstack, we’re just talking about JavaScripts. What does the acronym stand for?

Christian Nunciato:
I think it’s like a JavaScript… Let’s see. What is it? It’s JavaScript…

Mike Pfeiffer:
I don’t remember either.

Christian Nunciato:
Something in markup. You’ve stumped me now.

Mike Pfeiffer:
Yeah, I don’t remember either. It’s just some people don’t pick up on it because if they’re not paying attention to that part of the industry, but there’s a ton of amazing content from front-end web developers talking about the JAMstack concepts, just static websites and stuff. For anybody listening, I’m just throwing it out there. I’ve seen so many good tutorials online and stuff like that.

Mike Pfeiffer:
The other thing I noticed in your book when I was going through the outline, I know it’s in early access right now through Manning, right?

Christian Nunciato:
Mm-hmm (affirmative). That’s right. Yeah.

Mike Pfeiffer:
Cool, yeah. One of the things you’re talking about is not just managed services and stuff. You’re talking about working with databases and messaging and virtual machines, containers, but also deploying through GitHub Actions, which is cool. Are you enjoying working with GitHub Actions and the stuff they’re doing over there?

Christian Nunciato:
Oh yes. We use it pretty heavily at Pulumi now. I’m a huge fan of GitHub Actions. In the book, one of the aims I have in the book is to try to take… The book is really written for developers who are maybe not so familiar with infrastructure, generally interested and willing to take it on in a way that brings you from a background of, say, in full stack application development through the journey of adopting the cloud, particularly AWS and getting a better understanding of AWS. And get you to that point of ultimately being able to do full CICD workflows with just Pulumi and TypeScript and AWS, for example.

Christian Nunciato:
I’ve been delighted to see what’s been happening with GitHub Actions. Like I said, we use it really heavily at Pulumi. I use it myself. I use it actually to deploy my book as I work on it, because I push chapters up to my book. I use GitHub Actions to actually build the PDFs, and so on, that I end up giving to my editorial team and so on at Manning.

Mike Pfeiffer:
Awesome.

Christian Nunciato:
I love it, and I think once you can get to a point of being able to write a little bit of code and push it to GitHub and have applications just be sort of deployed automatically, it’s just incredibly fun. It’s a great way to work.

Mike Pfeiffer:
Right, yeah. I’ve been watching what’s going on over at GitHub. It seems like they’re moving fast lately, and I’m excited to see what’s going to happen next, but it’s really, really cool to work with, GitHub Actions. That leads me into my next question. I haven’t done tons of with Pulumi, especially anytime in the last year or so. I was looking at it more when I was speaking with Joe last year and stuff.

Mike Pfeiffer:
I’m curious, how does somebody put a project together? Do they write their infrastructure code and use the Pulumi platform from there? Or how does everything get bundled together and deployed? Do I put everything in a GitHub repo or something like that? Or how does it play out?

Christian Nunciato:
Well, the basic piece of a Pulumi program, it sort of begins with a template, often begins with a template, a basic sort of set of files that contains your program. I’m using TypeScript, for example, so when I go to make a new Pulumi project, I use the Pulumi command line tool to say, Pulumi new AWS TypeScript project. Then, because I’m using TypeScript, Pulumi knows how to go and fetch its generator template to go and get the files that it needs to create a bare bones project for me.

Christian Nunciato:
That’s usually comprised of just like a single TypeScript file, a handful of JavaScript dependencies that the Pulumi program will need to run. It pulls down the Pulumi SDK, no JSDK, and then a config file that just sort of describes what some basic properties of your project, like its name and so on. You end up with three or four files, a config file with your project name and so on, and like an index dot TS file that contains a basic definition.

Christian Nunciato:
I think we give you a two- or three-line program that makes an AWS S3 bucket and then some node modules and a package JSON, and that’s it. Then you run Pulumi up, and provided that your AWS credentials are set up in the usual way, Pulumi will create that AWS bucket for you. From that point on, you can augment that program to, say, add various properties to that bucket. You can maybe turn that bucket into a website, and then you can maybe add more files to that website. You can define a custom domain to attach to that website and so on. It kind of goes from there.

Christian Nunciato:
All of these additional resources you just described as TypeScript objects, and so, new buckets and new cloud front distribution, and you associate them to one another, just like you would any sort of no JS program. When you run Pulumi against that program, Pulumi knows how to interpret that program and turn it into cloud infrastructure using just the APIs that the cloud provider recasts directly. You understand?

Mike Pfeiffer:
Got it. Okay. I can have like a repository maybe set up with, got my app code in there. Got my Pulumi program, and then if I’m building a workflow in GitHub Actions, there’s going to be an action for Pulumi, I guess, that can run my program, get my infrastructure deployed, and then I can deploy my app after that’s up and running?

Christian Nunciato:
Yeah. What I will do, and this is a typical way of doing this, is we’ll have a… The program code itself, so your Pulumi project file and your Pulumi application file and so on, that’ll be in your repo. If you want to use GitHub Actions to then deploy that program into the cloud for you, you can define a GitHub workflow, which is like a YAML file that contain some basic information about what branches you want to have it act on.

Christian Nunciato:
About what branches you want to have it act on and so on. So if you push up to, say, the main branch, you can then invoke bash commands too. One way we’ll often do it, when a merge happens to the main branch, for example, we will run a script. And that script will basically just say, “Pulumi up.”

Christian Nunciato:
And, provided that you have some secrets, say in GitHub that contain your AWS credentials and maybe your Pulumi access token, that GitHub action will run Pulumi for you and deploy directly to AWS. So you’re not actually deploying anything from your laptop. You could certainly, but if you want to be CI/CD driven, you can use GitHub actions to run Pulumi for you. Yeah.

Mike Pfeiffer:
Nice. And so I could follow that pattern in any other CI/CD system, right?

Christian Nunciato:
Yeah.

Mike Pfeiffer:
I could just utilize Pulumi somehow, like in anything I’m using probably, right?

Christian Nunciato:
Yeah. So, we still run a bunch of stuff at Pulumi on Travis CI, for example.

Mike Pfeiffer:
Got it.

Christian Nunciato:
So it’s the same thing, the same idea. As long as you have your secrets worked out in a way that is comfortable for you, your AWS credentials and your access token, and so on.

Mike Pfeiffer:
Got it. Okay.

Christian Nunciato:
That identifies you to Pulumi. It’s really just a matter of running the Pulumi command line tool in your CI/CD provider and the rest just gets taken care of. Yeah.

Mike Pfeiffer:
Makes sense. Okay. And then if I’m reading your book and following along with that, are you pretty much just using the open source version of Pulumi throughout that?

Christian Nunciato:
Yes. Yeah. So, Pulumi has various plans but the core Pulumi is open source. So the Pulumi CLI is completely open source. All the Pulumi language SDKs, so super JavaScript and Go and Python and so on, those are all open source. And the book uses all the Pulumi open source stuff. There is a cloud service that Pulumi provides to manage your state for you.

Christian Nunciato:
So, when you are using any, or most common provisioning tools, need to be able to capture the state of your cloud infrastructure when it’s finished provisioning it for you. Like a Terraform will create some cloud infrastructure for you and then keep track of what all of those cloud infrastructure resource IDs are and so on. That state is often captured in a file of some kind.

Christian Nunciato:
So, you can use Pulumi in a, what is called local node if you want to just produce a file that is like a Terraform state file. We call it a checkpoint. But it’s basically just a snapshot of the infrastructure that Pulumi created for you last. Or you can use Pulumi’s hosted SAS service, that tracks all of that for you. It’s just free if you want to use it as an individual.

Mike Pfeiffer:
Oh, okay.

Christian Nunciato:
In the book, I use that because I find that as a developer, it was one of the first things that I noticed about Pulumi that made me happy was that I didn’t have to manage my state on my own. It just worked. And again, that’s totally free for individual use and so on.

Mike Pfeiffer:
Oh cool.

Christian Nunciato:
So I just used that, but we’ll also cover, in the book, alternative ways of managing your state if you want to do it more manually.You can do local mode. You could use S3 as a backend and so on, various other options for storing your state. But yeah, we use just the fully open source and free stuff in the book, for sure.

Mike Pfeiffer:
Nice. Okay. That’s really cool. I didn’t realize that that online version of it or the SAS version, there was an open source tier of that. That’s really cool.

Christian Nunciato:
It’s a free tier. The SAS itself is not open source. It is closed source service code.

Mike Pfeiffer:
Oh I get it. That’s what I was trying to say.

Christian Nunciato:
You run it on prem if you want to run the service yourself, you can do that.

Mike Pfeiffer:
Got it.

Christian Nunciato:
But it’s not open source. [crosstalk 00:24:21] The free command line tool and SDK, that stuff is all open source though.

Mike Pfeiffer:
Got it. Yeah. I’m crossing the streams over here in my mind. That makes a lot of sense. Cool, man. So I guess next question is, what are your thoughts for somebody that might be an infrastructure focused person that is wondering, should I learn JavaScript and TypeScript so I could get into this?

Mike Pfeiffer:
What do you think for those folks listening? Do you think this is something where developers should be the main target? Or do you think infrastructure people should maybe start exploring a more traditional programming languages and maybe getting into some stuff with Pulumi?

Christian Nunciato:
As a developer, I see the world through the lens of the language that I use every day. So I’m a bit biased in this respect, but I think, A, just use what makes you happy is my overarching opinion about all of this. If you’re happy managing YAML files or writing bass scripts and everything that makes you happy, keep doing that thing.

Christian Nunciato:
But if you’ve begun to feel the pain of managing large volumes of effectively static config code, definitely consider looking to a programming language of your choosing to help you with that. Because I think that’s what those languages are made for. It’s amazing how hard it can be to simple things outside the context of a programming language.

Christian Nunciato:
For example, if I want to build even a static website with a bit of a service backend component to it or something, I can do a lot of that in just writing some Terraform code, for example. This is how we did it. But you get to this point where you’re like, “I really just want to go through the…” Pardon me and my language. Just a moment.

Christian Nunciato:
When you get to… You often find yourself stuck because you need to do something really simple, like map file extensions to mine types or something. Or get a file listing, a directory listing, so that you can iterate through a bunch of files. These kinds of things can be really irritatingly difficult to try to do it outside the context of programming language.

Christian Nunciato:
But if you’re used to writing note apps, for example, you can just go and NPM install some library, pull that right into your Pulumi program and be done. You know what I mean? So if you’ve begun to feel the difficulties of not having a programming language to be able to use, then I would totally encourage you to go and look at say whatever Pulumi supported language that looks appealing to you and just try it. You know what I mean?

Mike Pfeiffer:
Sure.

Christian Nunciato:
Because I think the reason that we have languages is to help us deal with complexity and Pulumi is definitely built for that. So, definitely I would encourage everyone to have a look at it. Yeah.

Mike Pfeiffer:
Yep. Yeah. I totally agree with that. I think that for some people, there’s going to be people that are interested in maybe learning a little bit more about programming, and then that would make sense. But if you’re stuck or if you’re challenged for time, probably ramping up on a new language and trying something completely new is not the right direction.

Mike Pfeiffer:
But I think for the people that are interested and feel a calling towards it, then totally go for it. I think ultimately we’re all becoming software engineers anyways, if we’re being practitioners in IT anyways. So anyways, that’s my take on it. Yeah.

Christian Nunciato:
Yeah. Yeah. I mean, philosophically for me, I think, I always end up at this place where, no matter whether you’re a developer or an operations person or whatever, we are all trying to construct systems of things. And to capture and manage the complexity of those systems of things, whatever they are.

Christian Nunciato:
And so, inevitably we’re going to need tools that help us capture the kind of abstractions that we’re imagining. And it’s much easier to do that when you have constructs that are software oriented constructs, are much better at capturing that complexity and helping you to manage it. So it doesn’t really matter whether you’re a programmer building apps, or an SRE, or a release engineer or something trying to figure out how to ship software more safely.

Christian Nunciato:
Ultimately you’re creating abstractions and trying to manage the complexity of those obstructions. And I find that that programming languages, they’re just made for this. They’re built for handling those kinds of challenges. And the more we try to avoid using programming languages to do those kinds of things, I think the more painful it becomes over time, because ultimately we’re just building higher and higher. We want to be able to build higher and higher levels of abstraction. And you can’t do that without the right tools.

Mike Pfeiffer:
Right. Yeah. I was just really wrapping that last thought up. I was looking at the table of contents for your book. It looks like really the last part of the book is all about packaging up your programs. Doing your deployments and stuff like that. In the book-

Mike Pfeiffer:
Packaging up your programs, you’re doing your deployments and stuff like that. In the book, are you just deploying to AWS, or is it kind of a mix?

Christian Nunciato:
So just to keep the book focused, it’s purely TypeScript and AWS.

Mike Pfeiffer:
Got it.

Christian Nunciato:
Because otherwise it would have just been … I find that usually, A, many of such a broad set of users are using AWS, so it makes sense to speak to that group. But many of these concepts you can map to the other cloud providers also. It’s just to keep the book focused.

Mike Pfeiffer:
That makes sense.

Christian Nunciato:
I do plan on having code examples from the book presented in other languages, rather than just TypeScript, for those that are, say, Python oriented, and I’ll do that kind of outside the scope of the book. In the GitHub repository that contains all the code examples, there’ll be examples in other languages, but mostly the book itself is just around TypeScript and AWS, again, just to keep it focused.

Mike Pfeiffer:
Got it. Okay. Yeah, that’s awesome. And when it comes to Pulumi, then, obviously major platforms, I’m assuming beyond just AWS, Azure, GCP, probably just Kubernetes, what else can we deploy to as a target?

Christian Nunciato:
Yeah, so we support, Pulumi supports AWS, Azure, and GCP, straight up Kubernetes, and then DigitalOcean, and then sort of it goes on from there. So DNSimple and even GitHub, you can describe your infrastructure as code, your GitHub services and so on, repos and organization and so on, in code, as well. So dozens upon dozens beyond the major cloud providers, but certainly all the major cloud providers.

Mike Pfeiffer:
Very cool. Can you do a GitHub workflow? Can you generate a workflow?

Christian Nunciato:
I don’t know if we support a GitHub workflow as a Pulumi resource. I’m not really sure. I would have to look that one up.

Mike Pfeiffer:
That’s interesting. It’s probably way too early for that, anyways. People are just, it seems like people are just now, for the most part, getting into GitHub actions. So that’d be cool to see.

Christian Nunciato:
Yeah, it was really neat to be able to write like a single program, for example, that uses a little bit of AWS, a little bit of DNSimple or something, or some other services, to be able to sort of like pick and choose from the different cloud providers is, it’s just really neat to be able to write a single program that kind of does all of that stuff in one shot.

Mike Pfeiffer:
Very cool. In terms of one of the other big questions, especially when I’m talking to people about infrastructure code, I think testing infrastructure code is still very much a dark art. You know, I think there’s some major platforms and places where they’ve got their ways of doing it, but I think overall there isn’t a lot of guidance in the ecosystem for people doing infrastructure code and how to test that code. For you guys, doing stuff in Pulumi and using these traditional programming languages, it’s easier. Is that something you cover in the book, like doing testing and things like that?

Christian Nunciato:
Yeah, so it is made much easier just because of languages, and there are various approaches to it. You can do sort of traditional mocked out kinds of testing. So because you’re writing in languages, you can mock out parts of the cloud providers and so on, if you want to just sort of test how your infrastructure code behaves, or you can go a step further and actually deploy some of that stuff ephemerally and then run behavior tests against the end results to make sure they match your expectation, that sort of thing, also. So there’s various ways that you can approach this testing problem, and I will be writing about that.

Christian Nunciato:
I haven’t covered, I’m not an expert in this area yet, so I don’t know all the details about what the book will cover in that respect. But I do know that yes, this is definitely an area that Pulumi cares a lot about, because it’s obviously very important, and languages do give us a lot of options there, I guess.

Mike Pfeiffer:
Yeah, absolutely. Yeah, that’ll be fun to see. I think a lot of people are still learning and trying to find their way there. So that’ll be fun to see, but I think anything that can provide some inspiration for people is nice, because like I said, I don’t see tons of guidance out there. So looking forward to that, but it looks like your book is really end to end. So for the people listening, of course, check the show notes, there’s going to be tons of stuff. There’s a giveaway, the MEAP, the Manning Early Access Program, you can start reading Christian’s book right away, and as he works on it, I think provide feedback and stuff like that.

Mike Pfeiffer:
And then Christian, for people listening, coming out of this episode, where do you think they should go in addition to checking out the book? Is there other places you’re out online, sharing stuff, or is there other places to send people that are interested in Pulumi?

Christian Nunciato:
Yeah. I mean, you can find me on the Twitter, at cnunciato on Twitter. I don’t do a ton of tweeting myself, but I do share lots of stuff about JavaScript and kind of full stack web development in general. So definitely follow me if you’re interested in that sort of stuff. I also tweet a lot about my kids. So you’ll get some of that from me, too. But also other places you can go, I mean, definitely just go to pulumi.com and try the little getting started guide that we have that takes about 10 minutes to get through, that shows you what it feels like to build a Pulumi program, a real simple one. And then Pulumi has a community Slack, and so on, that you can find also, to help get some guidance on getting started and checking it out. Those are probably the main things I would say. I would encourage people to just go in and have a look at Pulumi, and then go to the community Slack and hang out and sort of see what people are talking about there.

Mike Pfeiffer:
Perfect. Yeah. I love it, man. Get in a community, everybody. So everybody listen and go follow Christian, hit the show notes, check out the book, Pulumi in Action. Christian, love what you guys are doing, man. This was a really fun conversation. Thanks for being on the show.

Christian Nunciato:
Yes. Thank you so much. I really appreciate it.

Mike Pfeiffer:
All right. That was awesome, man.

Subscribe to the CloudSkills Weekly Newletter

Get exclusive access to special trainings, updates on industry trends, and tips on how to advance your career in the tech industry.