Christian Nunciato works on a system called Pulumi, which is a system that allows you to build infrastructure with code. This is usually aimed at the cloud and allows us to use tools to manage infrastructure and do setups and updates.

Panel

Guest

Sponsors

Picks

Special Guest: Christian Nunciato.

Sponsored By:

AIMEE_KNIGHT: Hello and welcome to another episode of JavaScript Java. I have to say I'm especially excited about this episode because it falls in line with what I've been doing more recently, which is like a mixture of JavaScript and infrastructure. But anyways, enough of that. So I am coming at you from Nashville and our panelists today, we have Steve Edwards. 

STEVE_EDWARDS: Hi, and by the way, what's your name? 

AIMEE_KNIGHT: Oh, Amy Knight, thank you, sorry. I'm excited. 

STEVE_EDWARDS: Hello, this is Steve coming at you from actually sunny and very cold Portland.

AIMEE_KNIGHT: We have AJ O'Neill. 

AJ_O’NEAL: The thing I've been getting into recently is pomegranate juice with Mountain Dew. 

STEVE_EDWARDS: That's a pick, isn't it? 

AIMEE_KNIGHT: That sounds interesting. I'm game to try that. Maybe diet Mountain Dew. And our guest today is Christian Nunciato. You want to introduce yourself and maybe tell us a little bit about you? 

CHRISTIAN_NUNCIATO: Uh, yeah, yeah. I'm Christian Osiyato. I am, I'm a programmer and doing full stack development with mostly with JavaScript and, uh, kind of a little bit more front end and full stack for about 20 years, so now a long time. And, uh, yeah, I work up here in Seattle on, uh, an open source project called Bloomi, which I'm also writing a book about. And so I'm just here today to talk about infrastructure as code and for developers and why we, why we can begin to care about that and all that sort of thing. So that's what I'm here to talk about.

 

This episode is brought to you by Dexecure, a company that helps us developers optimize images, JS, HTML, fonts, videos on your own website automatically. With Dexecure, you no longer need to constantly chase new compression techniques. Let Dexecure do the work, and you can focus on what you love doing, building products and features. By integrating Dexecure in 10 minutes, you'll get a lower CDN bill, increased website traffic, and faster website than your competitors free trial offering 20 gigabytes CDN bandwidth and 110,000 optimization requests free every month. 

 

AIMEE_KNIGHT: Awesome. We should probably start with a definition of infrastructure as code and I will, I'll let you take that and then I can maybe chime in. 

CHRISTIAN_NUNCIATO: Okay. Well, it's kind of a big, a biggish topic, but like you can infrastructure as code is, is a way of describing and producing some infrastructural outcome with, with code of some kind. So like, so whereas our normal practice as, as developers is often to go and create a virtual machine and like sort of by hand and sign into that machine and configure it, install things on it. Or, uh, go into a dashboard and create a database and, and configure that thing by hand using a web browser, for example, or, you know, actually install a machine somewhere in Iraqism. So infrastructure by hand is the way we've, we've typically done it, you know, create computers and configure those computers at the command line with our, with our, with our hands in real time. Infrastructure as code takes a step back from that and allows us to use different kinds of tools to do all that work for us so that we don't have to do it by hand. We can write programs that we run with tools to produce those outcomes. So you can, one of those tools is Pulumi. There are lots of other tools that do that do this in various ways, but that's sort of the high level definition is doing infrastructure things with computers and servers and databases and stuff, but with code and tools that run that code. Does that make sense? 

AIMEE_KNIGHT: Awesome. Yep. So one thing I'll add there too, to that, for people to kind of like understand the why, I think one of the biggest why's when you first getting into this is people talk about environment drift, which is basically, you know, when people were doing this by hand in the past you really didn't have a way of knowing like the current state of your infrastructure. And you had no way of like reproducing that easily if something went down. Now we can just like from the command line, you know, call out to an API in AWS or Google Cloud or Azure, whatever you're using and just easily create what you need. So my very first question, most of what I've been doing is in Terraform. Can you tell us like how maybe I should I'll let you take what Terraform is, and then maybe I'll chime in with just like any beginner thoughts there. And then I'll also let you probably answer, how Pulumi, I can't say it, Pulumi. You got it, Pulumi. Pulumi is different than Terraform. 

CHRISTIAN_NUNCIATO: Sure, so let's say that you have an idea for a thing that you wanna build, a web application, for example, like a typical web application, and you know that you're gonna need a virtual machine for that web application. It's just a typical example. You're going to, you're going to need, you're going to want to put no JS on it. For example, you're going to want to put some files on it. Maybe you have a web server on it and stuff. You're going to need to do something with that machine. Terra Terraform is a tool that you can use to, to produce that for you. So earlier I described, you know, I mentioned in infrastructure as code, you write programs and then run those programs with different tools to produce those infrastructural outcomes. Terraform is a command line tool and it expects you to write little text files. Basically, you can think of them as sort of JSON blocks, you know, that describe the different parts of the infrastructure that you want to create. So if you were going to create this example web application, that might, the text blocks you might write for that would just be like four or five lines of JSON-like syntax that say, I want to use AWS, I want to use a virtual machine using this, a virtual machine image, like this base image with this set of properties that should have a public IP address and things like that. You put some right different properties into this block of text. You save that file as just the flat file and then you run Terraform, pointing it at that file. And Terraform will then call out to Amazon Web Services to create that virtual machine for you. And when it's done, it'll give you the public IP address and all the stuff. Here are the keys to your virtual machine. Now go on and sign into it. Does that make sense? 

AIMEE_KNIGHT: Yep. I guess one thing I'll add to that in case people have like looked at this before. So when you talk and describe like the JSON like syntax and something called HCL, which is a HashiCorp configuration language. So I guess that actually brings me to the question. So is Pulumi basically a way that I no longer have to write HCL? Or am I wrong on that? 

CHRISTIAN_NUNCIATO: Yeah, yeah. It's a Pulumi is, is you can think of it and this is what brought me to it kind of early on when I came to Pulumi. I had been using Terraform on a team at Chef. So I worked at Chef before starting to work on the Pulumi project on an application packaging platform. And we used Terraform to provision and manage all of the cloud infrastructure that we used to deliver that platform to users. And so we would write these HCL files. We'd run those files with Terraform and it would create our virtual machines and our containers and all that stuff. And it was great. The language you described, this HCL language, it's fine, it's like you can think of it like JSON, like I said. The thing about those files is that they kind of pile up over time. And if you aren't someone who's very familiar with the HCL syntax and what Terraform kind of expects of you, like as I was, as a developer. I was not familiar with it. And every time I would kind of have to come back to it, I have to kind of relearn it, brush up on it. So that was a bit of a pain for me, but I just sort of accepted it as a fact of life. But when I discovered Pulumi, the idea there was that you could sort of do all the same stuff that you're doing in Terraform, but do it with like JavaScript or TypeScript or yeah. 

AIMEE_KNIGHT: Absolutely amazing. Like I know with HDL, they have like, you know, some logic that you can embed, but it's not as powerful as a language. 

CHRISTIAN_NUNCIATO: Yeah. For me, that was the, that was all it took. I mean, when I, when I saw it, when I saw that this thing existed, I was like, I got to go work on that thing because that I've wanted to exist for 10 years. And now it exists. So you can very much think of it like, like Terraform, but for, if you're familiar with Terraform, you can think of it like Terraform, but with whatever language you want to use, I mean, a subset of languages, there's JavaScript and TypeScript, of course, and then the.net family of languages. If you're a.net person, you can use C sharp or VB or F sharp or go or Python stuff like that. 

AIMEE_KNIGHT: I have one more super quick question. I know Steve has a question. So is this completely independent of Terraform? You don't leverage Terraform at all? 

CHRISTIAN_NUNCIATO: Yeah, so we currently, it's built on top of the Terraform providers, which are basically like clients. Yeah, they're open source API clients that know how to talk to AWS and Azure and Google Cloud and all of that. So we do for a handful of the major cloud providers because those so many humans have spent so much time building those API clients. They're just solid and reliable. And so many of the, many of our libraries are built on top of those Terraform cloud clients, basically. Yeah. So we don't, we don't use the Terraform tool itself. We just, we definitely leverage some of those API clients because they're, like I said, they're, they're pretty good. 

AIMEE_KNIGHT: Yeah. That's what I was going to say. That even makes me like more so excited about it because knowing that, you know, you're already, it sounds like it just would like allow you to build even more and you're not having to recreate something that's already been created. But anyways, I should let Steve jump in. 

STEVE_EDWARDS: So yeah, so I'm going to play the role of the clueless when it comes to infrastructure person who just does web development and lets other people set up their background for them. So we're talking about Terraform and Pulumi and how you automate your infrastructure setup. So how does something like this compare to say Docker? Okay, are they app-Grapes and watermelons completely separate. Are they, and say Kubernetes as well, are they sort of related, not related at all? Cause that's what I think of automating things because you can script a Docker container and have all your stuff in it and so on. Does that make sense? Just trying to get my head around and relate what you guys are talking about versus the little that I know of infrastructure. And I'm sure many other people know is just as little as I do. 

CHRISTIAN_NUNCIATO: Yeah. Assuming that you know what Docker does, like assuming, assuming you're, you're, and I know that many developers are so super new to this, that that in itself is, is kind of a new concept, but assuming that, you know, that you can write this Docker file to, to create a Docker image and run that, run that image and create a container from it and so on. And then inside of that container, some stuff can run in various ways. You can either create a service that listens on a particular port, or you can just run some command and so on. A Docker container is a, is just a runnable thing. That thing has to run somewhere. And so sometimes it, sometimes it runs on your local machine. Sometimes it runs in, in a cloud like DigitalOcean or AWS in various ways. So Pulumi is a tool that you would use to kind of direct the places, create the places where that container would run. So if you, if you wanted to run that container image in AWS, you would use Pulumi to write a program that says what you want to use in AWS to run that container. So your program would describe, you know, what AWS services you want to use to run that container, for example. Does that make sense? 

STEVE_EDWARDS: Yeah, absolutely. So now you've been mentioning AWS, is this specific to AWS or can it work on something like Azure or Google Cloud Platform or some of the other providers like that? 

CHRISTIAN_NUNCIATO: Yeah, Pulumi runs on all the major cloud providers. And so like, you know, Azure and Google Cloud and Digital Ocean, AWS of course. The book I'm writing is very AWS centric. So it's, you know, AWS is a very popular example and very popular among our users. I think significant portion of our users are just using AWS, but it runs on any major cloud provider. And on top of that, there are also sort of, you can write your own providers if you so choose. So if you encounter something that say, isn't supported yet by Pulumi, you can like say if you had a cloud provider that was sort of just up and coming and a provider didn't exist in the open source community for it yet. You could write one of those yourself in a couple of different ways. So it's kind of provider agnostic in that sense. 

AIMEE_KNIGHT: What is Pulumi itself written in? Is it Go or something else? 

CHRISTIAN_NUNCIATO: Go, yeah. Okay. Yeah. And there are various components, but yeah, the major components are all written in Go. And then as a developer, when you use it, if you're a JavaScript developer, the programs that you would write are JavaScript programs that run on Node.js. But if you're writing, say, if you wanted to use C sharp or some other language, you could write the programs in a different language using libraries that are specific to that language. So when you're interacting with Pulumi, whatever language you're doing it in, the idea and the intent of Pulumi is to let you manage that infrastructure in a way that's comfortable to you. This is usually, this has been the biggest pain for developers entering the world infrastructure is all these tools are totally foreign and strange. And like, I'm not familiar with what these tools expect of me. I don't think in their terms and so on. And so the idea with Gloomy is to bring that up to the level developers are comfortable working with. And so that, that definitely is what drew me to the project. 

AIMEE_KNIGHT: It's just like, I don't know. I have so many questions and thoughts. Like one of my pain points that I've been having, I don't know, as a JavaScript developer, when I'm writing HCL, like one thing that pains me is like, I can't lint my, I mean, I think there are some linters out there, but not to the level that I'm used to. Like I have, if I'm creating you know, variables in HCL, like I can't lint for, you know, unused variables. Like one thing I was looking at is kind of trying to write my own because it bugs me that much. I'm just very much like a clean code, you know, really like to keep everything neat and tidy. And that's been bugging me. So, and then one thing I haven't really done much with infrastructure's code is testing. So I imagine like, you know, the world of like linting and testing is probably a lot better too.

CHRISTIAN_NUNCIATO: Yeah. I mean, if you're comfortable working in VS code, writing JavaScript programs or TypeScript programs, especially in VS code, yeah, you, you just get all of that goodness for free the length, the Pulumi libraries are typed really well. So you can, not only can you write programs, you know, easily detect things like you described, like unused variables and things like that. And because you're writing in JavaScript, you can write tests around that stuff using the standard tools that you're already familiar with, but you also, you get, you get all of the the type hinting and such for all of the cloud platforms too. So not only do you get to do that, but you can sort of like, you can say, var Foole equals new AWS S3 bucket, and then bucket dot, and then you get a type hinting that kind of exposes all of the S3 infrastructure to you, or API service to you. 

AIMEE_KNIGHT: That would be amazing. 

CHRISTIAN_NUNCIATO: Because like, as we know, the easy part is kind of, the hard part is API surfaces are massive. 

AIMEE_KNIGHT: Yeah, yeah.

CHRISTIAN_NUNCIATO: awesome, but the worst at this because it's just so huge. There's so much of it. And so to have that developer focus, like experiences really, it just changes the whole, the whole experience for us as, as for me, 

AIMEE_KNIGHT: Yeah, because I feel like whenever I'm doing anything in Terraform, like I, I always have three things open. I have my editor open. I have like, I do a lot in GCP is have the GCP docs open. And then I have the Terraform docs open. And it's always usually like a mental mapping going back and forth between like, you know, what does, you know, what. What does this attribute that I have in Terraform, like what does that equate to in the GCP docs? And to be able to like have some of that hinting would be amazing. 

AJ_O’NEAL: So in one way, this sounds like the age old argument of imperative versus declarative. Like the industry waffles back and forth on this like every six months, you know? 

CHRISTIAN_NUNCIATO: Yeah. 

AJ_O’NEAL: And so this sounds like we're saying actually it turns out the declarative meaning data based or markup language based configuration is hard. Let's switch back to declarative, meaning line by line scripting or programming based configuration. 

CHRISTIAN_NUNCIATO: Yeah, this is where it gets kind of interesting and because Pulumi, even though you're writing it in an imperative language, say if you're using TypeScript or JavaScript, what you're producing is actually a declarative thing at the end. And this is a bit, a bit in the weeds, but like declarative is basically correct. I think like everybody's sort of in most ways, like what you want, I think ultimately is a way to express what the end results should be. And so, so at the end of the day, when I run my program and I produce my infrastructure, it should have, you know, a virtual machine and a database and they should be configured to talk to one another and the virtual machine should be accessible over a public internet. And like you want to sort of be able to utter that in some way. And that concept is a declarative thing. You could draw it out. You could sort of draw an architecture diagram, for example, that described the end result of what you wanted to get at. So I think that still holds. I think we still kind of want that to be. The difference between Terraform and Pulumi is that with Terraform, largely what you're doing is writing that out in text for the most part. There's some logical constructs you can use to do loops and things like that, but...For the most part, you're writing out the declarative thing in mostly static, in a mostly statically expressed way. When you're writing a Pulumi program, you can write it that way, but what we often end up doing is we need those, those of us that have come to sort of Pulumi, for example, from Terraform, we needed those logical constructs to be able to capture more complicated rules that we wanted to apply to the creation of that infrastructure. So when you're writing a pollute, but at the end of the day, you're still, you still need a declarative thing. You still need kind of an end state that needs to be. 

AJ_O’NEAL: I mean, I'm not saying that one is better than the other, but this, this is not declarative from what I'm seeing on the Pulumi.com slash product. That's not declarative. That's imperative because you're writing code. Now, does it produce a config file or whatever? Well, sure. But it's, it's producing it for like six different platforms or services or whatever, right? So I mean, it is like to shoot straight. It's imperative, not that that's a good thing or a bad thing. 

CHRISTIAN_NUNCIATO: Yes. 

AJ_O’NEAL: That's what it is. 

CHRISTIAN_NUNCIATO: It's totally. I, yeah. I mean, what I was getting at was like, I, you're totally right. I think you are expressing it imperatively. 100%. 

AJ_O’NEAL: It's just that the, the, I mean, you could, you could say that about anything, right? I mean, like all code ends up as something that you could at some point called declarative. Like if we look at machine code, you know, we could say, oh, yeah. It is this like I don't know, you will put it in XML. Now it's, now it's, uh, now it's declared. 

CHRISTIAN_NUNCIATO: Right. Yeah. 

AJ_O’NEAL: Anyway. 

CHRISTIAN_NUNCIATO: Um, yes. 

AJ_O’NEAL: So getting back to trying to understand what's going on here. So I see that there's like an AWS dot EC2 in the example on the homepage, AWS dot EC2, AWS dot EKS, Kate's dot service. So are these libraries provided by Pulumi? And this is what is ultimately generating those config files or is this talking directly to, is this actually the AWS SDK doing AWS things and the Kate's SDK doing Kate's things? 

CHRISTIAN_NUNCIATO: It is, it is. It's Pulumi libraries are, are what would do that for you. So like we, the, the libraries do package up and the AWS SDK for you to use, if you want to use it and very imperatively to like, you know, do, you know, things that you might do with the AWS command line, but in JavaScript, you can do that inside of Pulumi program using the bundled AWS SDK. 

AJ_O’NEAL: Well, when, when I look in at this thing that says AWS.ec2.vpc. EKS net is that the official AWS SDK, or is that a wrapper that's provided by Pulumi to create config? 

CHRISTIAN_NUNCIATO: It's the second thing. Those are Pulumi classes and types and things that are, are what expose the surface, the API surface of say AWS or Kubernetes or whatever to you as a developer, but those are Pulumi libraries. Yeah. Those are the open source Pulumi libraries that you can download off of NPM or, or GitHub or what have you. 

AJ_O’NEAL: Okay. All right. So I think I kind of, gosh, there's just so many pieces to all this stuff. Like, yeah. I mean, cause you gotta, you gotta set up DNS so that it points to a server. You gotta tell the server that it needs to have a database. You gotta, I mean, I'm trying to imagine. 

CHRISTIAN_NUNCIATO: Yeah. Sorry. I didn't mean to cut you off. 

AJ_O’NEAL: No, it's, it's fine. I'm just, I'm just looking at the examples and I'm just trying to think like, I don't know, this, this is one of those problems where my fear with things like this. And I get, I know it's just the layers of abstraction that you run into, but I, I mean, I think the same thing is true with, with Terraform and other stuff. It's just, there's a lot of there ends up being a lot of layers because you're defining your infrastructure, but at some point your infrastructure has to, you know, connect with something that's accessible to people. There's always variables. Like there's, there's always some thing that requires a human to come in and say, like, this is what I want. Well, a human has to write this stuff in the first place, but like this, what I see in the examples is config for the infrastructure, the platform, the hardware, the software, the services. Does this also define how you connect that to domains that a user interfaces with, or is that done somewhere else? I don't know if that question was clear. 

CHRISTIAN_NUNCIATO: Yeah, if you're describing like, you know, if what you mean is, you know, when you go, you know, you're gonna, if you have a virtual machine, say, and you want that virtual machine to be running a service that you can access over a certain domain name, is that what you mean? Is that what you're describing or am I, did I misunderstand?

AJ_O’NEAL: Yes, but I may not be asking the right question because I'm coming from the perspective that like, if I set up a service, the reason I'm setting up a service is because there's going to be an end user that's using it, but that may not be the case. I'm sure there's tons of services that are just purely on private networking and they do like internal things that. Maybe through another service, get exposed to a user at some point, but maybe not the initial service does. Like, you know, if you've got some sort of machine learning, I don't that's the buzzword of the day, but you know, some, some big machine learning platform that's behind the scenes on a private network and you've got some web interface somewhere that connects in and then fires off a batch job and then it goes into an SQS queue. And, and then it gets consumed by this thing that's completely private that never sees the light of the internet. And so I, I guess I'm just, I am asking that question of like, how much of this is geared towards stuff that's. Like internal that doesn't see the light of day and how much of it is geared towards stuff that's external or is it both? Yeah. I'm sorry. I'm totally muddying up what I'm saying, but hopefully even less clear than it was before. 

CHRISTIAN_NUNCIATO: Yeah. I mean, in some ways there's like, there are so many ways I, and this gets into areas that even as, as a person who uses these tools, uses these tools all the time, I don't know, there are many ways of course that you can use like AWS, you know, semi privately co-located things like that. So if that's kind of what you're getting at, like the idea still is that in a given program, you should be able to describe all of those pieces and their relationships in code. You should be able to say, you know, you should be able to write class or an object that describes the whole, the network, for example. And then you should be able to write another class that can accept maybe when it's instantiated a reference to that network so that it can get created in the proper place. You don't see what I'm getting at. So like you should be able to express all of this stuff with a given programming language in a way that makes sense to you. And that can be understood by other humans, you know? 

AJ_O’NEAL: Um, yeah, I get that. It's like, so this looks like it's describing an instance of the thing. Like, so for example, I have example.com is my production site. And then I've got example beta.com is my beta site. And staging.example.com is my staging site. And I'm imagining, and maybe I'm thinking about this wrong, but I'm imagining you run this and then you have an instance of infrastructure that has all the pieces. And so it's like, if I wanted to spin up staging to dot example.com, I could use this exact same config file. And then I'd like tweak one variable to say the domain that all of this should end up connecting to is staging to.example.com and I run it. And then 15 minutes later or 10 seconds later, or however long it is later, I have staging to.example.com that is an exact replica of the, what example.com is or what staging.example.com is or what example beta.com is. 

CHRISTIAN_NUNCIATO: Yeah. So what you've described is exactly, exactly the the goal of Pulumi is made to do. And so that like you've just, what you described is how, what Pulumi calls stacks, which are, which are basically collections of infrastructure that are produced from a program. So the idea is exactly as you describe, Hey, I just want to write a single program that describes, you know, my website, you know what I mean? And all the parts of that website. And I want, I want a dev version of that, that I can hack away on and mess with and tear down when I'm finished. I want a production version of that. That's based on the same exact code, it's produced from the same program. I want a staging version, I want a test version. And each of those is what is called a Pulumi stack. So when you run a Pulumi program, you produce a stack or a collection of cloud resources. And so as you described, each stack has its own configuration file, and so that's like a YAML file. And so you might say the YAML file, the config file for my dev stack is, dev.aj.com and then, the production one is just www.aj.com. And so on. So that the, 

AJ_O’NEAL: I would never put a dub dub dub in front of something. How dare you? 

CHRISTIAN_NUNCIATO: Pardon me. Yeah. But so you, the way you describe it is exactly how it, how it, it does work. And, and, uh, because I think by and large, this is kind of what we, how we think of things, you know? So, 

AJ_O’NEAL: Okay. I think, I think I get it. I think, I think what you're getting, what you're, what you're saying is, is making sense for me. So generally, okay. If I've got something in production, I don't, I don't want the database to be recreated. If I like, I basically, I don't want to redeploy production. I want something to update in production. So, and maybe I'm getting too deep into what this tool is and what it does, but how I mean, it makes total sense. If I'm going to say, like, I want to spin up something new that didn't exist before. I want staging three.example.com. But what doesn't make sense to me is if I ran this on example.com. Bye bye database. I mean, like what's the process to update or make sure that it's not, there's not like 15 minutes of downtime while this is running and recreating. Like how does that update or the deploy new feature process work with this? 

CHRISTIAN_NUNCIATO: Yeah, it's if you're familiar with Terraform, it works just like Terraform, but- 

AJ_O’NEAL: And I'm really not, I gotta be honest. 

CHRISTIAN_NUNCIATO: To take a step back from that, there is a way, there is an approach to infrastructure as code. We talked about declarative infrastructure as code. I want to describe what the outcome should be in some, in a program or a text file or something like that. This is what the topology should be at the end of the day. The idea with, with tools like Pulumi is that they are, they are called desired state tools and so their, their purpose is to produce an end result, a graph, like a config file as you described earlier, so to speak, that says what that end state should be. If you, when you run it for the first time and say, you know, that file contains a on our DS database, the virtual machine, a bunch of stuff. You run it for the first time, Blue will go out and create all those things for you. If you run it immediately thereafter, nothing will happen because the desired state that that program describes will have already been achieved. Does that make sense? So like you can run it against production all day long. And if nothing has changed in the program to produce a different status sort of in the end result, then nothing will happen. So this is why it's sort of like popular to run these tools and continuous integration delivery environments because they can just keep on running. And as long as like until anything changes, just nothing will happen. But when just one little thing changes, then only that one little thing changes. Does that make sense? 

AJ_O’NEAL: Well, yes and no, cause the caching problem, like it seems like knowing that something has changed is one of the fundamentally catastrophic misunderstandings of computers in the world. So like I would imagine if I push new code to master and I merge it into production, then you know, it could have a beat on that something has changed. And so therefore it should run the rebuild and redeploy process and, and do some sort of like graceful restart. I imagine there's some way that it can like start up a new instance and then register that the old instance should be taken offline when connections are severed. Or maybe that's just part of the cloud platform, the EKS and whatnot or ECS EC2. It's so no, it is EKS, right? 

CHRISTIAN_NUNCIATO: Yeah. Well, yeah, there is an EKS. Yeah. 

AJ_O’NEAL: I'm just trying to, one of them handles that. I think that particular process of like you spin up a new server and you let the old server die. So both the old and the new server persist for some amount of time while it's changing out. 

CHRISTIAN_NUNCIATO: Correct. Yeah. So there's, so the. The way that, that Pulumi works, for example, is that if you, let's say that you have a, you need to make a change that results in, you know, let's say like take the database, for example, like this is a, maybe not a great example, but like, for example, if you, if you have a database, you've, you've used Pulumi to write a program that creates an RDS database, for example. And for some reason, the update that you're about to make is going to require that, that database be destroyed, but it has to be replaced with a new one, you know, in that case will do by default unless you tell it otherwise, is it will create the new thing before destroying the old thing. And if that old thing was connected to other things, Pulumi will connect the new thing to the other things before destroying the old thing. Does that make sense? 

AJ_O’NEAL: That was super clear. There's the thing and the thing, and when it connects the things, then the things can get connected. Got it. Crystal. 

CHRISTIAN_NUNCIATO: So that concept of create before delete is where you get zero downtime, which is kind of important to some people. And so like, that's how it works by default. You can make it not do that for some reason, but you just use it the way that it, the APIs guide you, your new infrastructure will be created before the old infrastructure is destroyed. 

AJ_O’NEAL: And the good news is that all the problems, it's easy to test them out. Hopefully in the beta and staging environment. So that if there is some problem where the new version of Redis is somehow slightly ever so incompatible with something that you've got set up in the old version of Redis that you're gonna catch that before it goes into production and it's not gonna be a problem. 

CHRISTIAN_NUNCIATO: Right, yeah, I mean, this is why it's super valuable to have all of your infrastructure expressed in code and therefore, you know, in Git and reviewable by other humans and continuously delivered by automated processes because A, if you got you know, you want to make sure that you have the same version of Redis or whatever it is running in all the environments, the exact same version. Because for those to fall out of sync, as you know, kind of like creates the possibility for mishap. So when you, what you described is exactly right. You want to, ideally you have multiple environments, multiple plumey stacks, so to speak, multiple environments running all the same stuff. So that when you, when you merge something say into an environment that is not. The, you know, your production environment, cert problems with those configurations get surfaced. Immediately and non catastrophically. So that's the whole idea. Yeah. To, to let you deploy lots of things really often and really safely. 

AJ_O’NEAL: I like that. I like the non catastrophic part. 

CHRISTIAN_NUNCIATO: Yeah. And this is tricky too, because like, you know, part of this has part of the, you know, when, when say a tool like Pulumi and the other, even tools like Terraform, when they run, they need to, they need to sort of interpret what you've written in your program and they, and then compute the changes that have to take place on the infrastructure based on what it's best guess. And, and so what it, the way that that works is the, the, the tools need to rely on some concept of the last known good state of what the infrastructure was in order to figure out what the changes ought to be. And this is where it gets kind of dicey when, so when you can run tools like Pulumi and Terraform and others in a way that will produce an actual file, like a state file. At the end of a run. So if you write a Terraform program or a Pulumi program and you run it. When that is finished, that instructors code tool will kind of take a snapshot, so to speak of what the end result was. The environment that I just deployed has this virtual machine with this ID in it. And these, this database of this IP address and all that stuff is kept captured in a state file. So literally a big old JSON file. That file will needs to be, whoever runs Terraform next with that program or Pulumi next with that program. Needs that file. They need to know what the last known good state was because that they're going, that run will then decide what it needs to do based on the last known good state of the infrastructure. So that. That's 

AJ_O’NEAL: So it's not, it's not querying the infrastructure to determine the truest most real version of the state. It's relying on the fact that you didn't do a cowboy hot fix to something. 

CHRISTIAN_NUNCIATO: Correct. If you do the cowboy hotfix, there's no. There's no notion of that captured anywhere except at the infrastructure layer, except in AWS. So if you go into like route 53 or something, you change some DNS settings and you have a program that was initially responsible for creating those DNS settings, you have a problem. So that, that reconciliation needs to happen. Now there are ways that you can, you can ask Pulumi and other like Pulumi Terraform Give me the most recent version based on, from the provider's perspective. So you can do what's called like a refresh with Pulumi. Literally it's a command that's Pulumi refresh, and it will go out and ask AWS, for example, or whatever other provider. Here are the, here are the things I, my program cares about. Has anything changed? And if so give me the changes and it will then incorporate those changes into the last known good state before you run it again as a, as a safety. So there are ways to kind of assist with this, but still the thing that is used to determine the set of changes to be made is a snapshot of some kind. So where that snapshot lives is often pretty important. 

 

Hey, you know how your ops team keeps a pile of scripts and wiki documents explaining how to perform those routine and emergency tasks that keep your applications running? They might call them runbooks or playbooks. Our friends at Octopus Deploy were thinking, DevOps is about collaboration. So doesn't it make sense for runbooks to be automated from the same place as deployments? Well, Octopus Deploy is now the first deployment tool with native runbook support. And the best thing is your runbooks can share configuration settings and automation steps with your deployments. So go find out more at octopus.com. 

 

AJ_O’NEAL: Okay, so let's say that I, let's define the person that most needs this information that we're talking about. Because it seems like most of the time you come into something that exists and you're just sitting there and you're trying to make choices to help the team or yourself or whatever, get things more manageable. So what is the ideal state of a person and a company when they would be looking at Pulumi or something like it and say, now is the time that we're going to start using this type of thing. Or now is the time that we're going to migrate specifically to Pulumi. What might that look like in terms of company size or developer role or that, what's the state of the universe when that is the choice to be had? 

CHRISTIAN_NUNCIATO: Yeah. Well, I mean, in some, in some ways like you're, you know, it's a, it's a, I'm biased because I would never, if I can provision, create some infrastructure with code, even me myself, like I, you know, I'm, I'm like a dad, I got a website that I post pictures of my kids on. I write the infrastructure as code code produce that website because I just, I don't want to have to manage everything manually on my own. That's only one little thing of my own. I could certainly do that. I could just go into AWS and poke buttons and things like that to go and, and produce my S3 buckets and things like that to hold my website. But I would much rather express that in code so that I can always have a reliable, consistent outcome. And I can continuously deliver with, you know, GitHub actions and things like that. And just have it work. So like even for small teams, even, even for individuals, it makes a lot of sense to, to try to do this if you can. Very early on it's much harder to do later because, you know, you've got a bunch of infrastructure that's kind of already out there and running. You can import that infrastructure into programs, but it's a lot harder to do that. So my answer to that question is kind of like as early as possible. If you believe in these concepts and you can find a tool that you like. I would advocate pretty strongly for writing infrastructure as code from the very beginning, if you can, just because as you grow, it will become harder and harder to manage that stuff by hand, much more error prone and, and that just creates problems and waste people's time and kind of also has them doing things that they kind of would most of the time rather not do, you know what I mean? So does that kind of answer that question? 

AJ_O’NEAL: I'm going to go with no actually. Okay. Because, so you're, because you're saying, well, Everyone should use this all the time. And I'm just going to push back on that. Cause I don't think that's true. Like, I don't think that anybody that wants to host their blog should go through the effort of learning AWS stack and put things in S three buckets. I think they should use our sync, put it in the server path and let it be, you know, you get caddy or Netlify or, you know, and you put some files and you get pushed and you're done or you are sinking. You're done. So I want a more thoughtful answer than it's the panacea that everybody should use at all times. 

CHRISTIAN_NUNCIATO: Yeah. I mean, I totally, yeah. I feel a little bad even talking to developers who already have like, we have so much stuff that we have to learn as it is. And to sort of say, now go off and learn all there is about infrastructure is sort of like, oh my God, like I've spoken to others before, like this is what I get. I get resistance because it's like, man, like I'm interested in this. Like I would love to do this. But like it's just a lot to bite off and it truly is. It really is like that. So I 100% agree. And I would say that when, to the extent that you are interested in doing this, these tools will help you help make it easier for you. There's, I don't have a great answer to your question other than, well, 

AJ_O’NEAL: how do I sell it to my manager? Right. Like I go into work today. I listened to the podcast. I'm convinced like we have problems. We have reliability problems. We have deployment problems. I know this because I'm on the team. I see it. And I'm saying, okay, I think that I should go check out Pulumi or Terraform or both or whatever, and make a decision and, and bring this up a ladder, like what might that experience look like? Could you, could you maybe think it from, from that perspective? 

CHRISTIAN_NUNCIATO: Yeah. I mean, when, anytime you're collaborating with other people, you know, as you know, just as a developer, like it's best when you can express, when you can use code or it goes well, I guess I would say when you can use code to to communicate with one another code and get and code reviews and stuff. This is sort of like patterns that we've just become comfortable with. I assume many of us, most of us are comfortable with this whole idea of collaborating with other, other technical people in code. So anytime you're in a team of people that is going to be interested in anything related to infrastructure, doing that in code is just going to be more understandable by people and more manageable and so on. So like certainly in team environments, it is a good practice to do as much as you can do in code. And so, you know, whereas to leave it to individual developers to kind of manage this stuff manually, certainly doable. Like I said, especially at a small scale. I don't want to, I don't want to kind of convey this is the only way that you. It doesn't make sense to do it any other way. It's certainly reasonable to on a small scale, kind of, you know, work in dashboards and things like that. The overall point though, is that when you do that, you, it makes, it's just a lot easier to make mistakes. Um, to spend a lot of time doing things by hand that you would probably rather spend your time using for other, other reasons. And, and when you do all of this stuff by hand, try to manage it all by hand, even if your job is entirely to manage this stuff by hand, you still have situations where environments may differ slightly because, you know, in prod we had, you know, we want to kind of, you know, configure things slightly differently than in staging or in dev. And so these, these environmental differences create potential for confusion and mishap as I just, as I said earlier and so on. So, so like in team environments, it's, this is kind of just the way that it's much more reliable and consistent to use code-based tools to produce these outcomes than it is by hand. I think just at the end of the day, too much can go wrong too easily when you're managing things manually. Make sense? 

AJ_O’NEAL: Yeah, that, that makes sense. I get that reasoning.

CHRISTIAN_NUNCIATO: But I just want to reiterate, it's like, I can say this because I've been doing this for like 10 years. And so to me, I'm comfortable in this area, but somebody that is new to this is it's very, it's a lot. I mean, it's a lot to ask of anyone who's already like got a ton of stuff that they're trying to absorb just to do their actual application development job. Now I got to go and think about infrastructure and all these other infrastructure tools and declarative versus imperative and all this stuff. It's like, but. 

AJ_O’NEAL: Oh, the declarative versus imperative. You've got to fight that battle at some point. Like you're going to get, you've got to get the sword out and have words at some point, because everybody's got, well, not everybody, but on any team, somebody is going to have a strong opinion about that. 

CHRISTIAN_NUNCIATO: Yeah. But the thing about Pulumi, I think that kind of is, is great. And what led me to, to work on it. I mean, like I was driven to go and work on this thing because, you know, it, it really, it makes this for a developer about as easy as it can be and familiar as it can be, because like I said, you're using a language that you already. You already know that, you know, and when you do that, when you do kind of get that kind of leg up or toe hold into the, into the cloud with that language that you already know, it opens up a lot of interesting possibilities for ways of building applications that you may not have even thought of, which was the case for me when I came to Pulumi, I started using it. I was like, cool, I can do, I can do Terraform things, but with TypeScript I'm in. But what I didn't realize was that when, when you start to compose with the kind of application oriented parts of the cloud. You can write programs that are very different from the types of programs that you're used to writing with like, you know, running services, long running services on virtual machines, for example, that kind of way of composing applications shifts in a major way when you start using quote unquote cloud native ways of composing that are a lot easier to do in a program and a lot harder to do by hand because there's so much stuff in like, for example, the AWS console that you have to go and manage by hand in that way of thinking. But when you, when you can use these tools to compose in that way, it just, it opens a ton of opportunity for you as a developer, not professionally, certainly professionally, but also just creatively that you just didn't have before because you know, it's a whole other way of working. Does that make sense? 

AJ_O’NEAL: Yes. Per chance. Does this support digital ocean? 

CHRISTIAN_NUNCIATO: Absolutely. Yeah. So digital ocean and DN simple and sort of all those other things, GitHub. Like, so you can write a program in Pulumi that pulls in some of AWS, pulls in some of digital ocean, pulls in some DN simple pulls in some GitHub, whatever, and because you're just using JavaScript libraries, for example, that abstract all of those providers as like TypeScript classes and things like that. So absolutely. Yes. That's where it becomes really. Really great is that if you don't want to use, say the DNS provider that AWS provides, you want to use yours or something else, you can, you can do that in a single program, you can express that in a single program. 

AJ_O’NEAL: So I got, I think two more questions. One, I just slipped off of my mind. So I'll go with the other one. So looking at Pulumi, that's $50 a month, $225 a month enterprise call us. Community free. So I'm now I'm a little bit more confused about what Pulumi is. Cause I thought Pulumi was a command line tool and that it's just interfacing with AWS. So I'm going to like, I don't know, create some environment file that has my AWS keys or my digital ocean keys, apparently, which that's awesome. Cause I love digital ocean. Cause it's really simple. Like I feel like anybody can, anybody who has some basic knowledge of how the internet works can go into the digital ocean console and get to work. Whereas AWS, it's like, you got to go get your degree, your bachelor's in AWS before you can figure out what the heck's going on. So anyway, so I'm thinking of it as a tool like that. That's what we've been discussing, but then I come here and there's a pricing page. What the heck is that about? Like, am I paying for this the command line tool or what am I paying for? 

CHRISTIAN_NUNCIATO: Not at all. No. So like there are what you're paying for. Remember earlier I mentioned the the state snapshots that are produced at the end of say a Pulumi run or a Terraform run. You have this file that describes the last known good state of the infrastructure. 

AJ_O’NEAL: Yes. 

CHRISTIAN_NUNCIATO: That file needs to go, needs to live somewhere. And so what people will often do is like, may use a, like an S three bucket or something to store that file. So that if I run Pulumi on my machine, I, I can run it in such a way that it will request that file from the S three bucket. And use that as the last known good state. And if you're on my team and you want to run Pulumi with my program, you can use that same S3 bucket to query the last known good state so that we can work together. Okay. That's entirely free like this. So like that, I, and that idea of a state, a state file that is either managed on your local computer or in some remote data store that multiple people can use is entirely free. The, the other way that you can use Pulumi is it has a service component, which which you can use if you want to store that file for you. And also like keep, keep track of your, you know, your runs over time, your, your updates over time to your infrastructure and like the diffs that changed between runs and all of that stuff. If you want to use that service, you are welcome to use that service as, as an individual, just the hosted free service as an individual, you can use that for free forever in any, for as many stacks or projects or whatever, as you want. If you want to use Pulumi in a team setting and use the service as your backing store, then like you, you pay for the number of people that are using it on your team, for example. So that's where, that's where the commercial aspect comes in. That's how like Pulumi makes its, makes its money is by teams using it in ways that have the service manage the state files instead of, you know, sort of managing that on your own, which you can totally do. It's just a little easier, a little nicer, and you get the kind of historical change stuff in the service as part of that. Also locking is important. So like if I'm running my program and you're running your program at the same time, that can be a little tricky to handle when, when we're kind of manually managing our state files on our own. But the service will kind of handle that lock in for you and prevent multiple updates from happening at the same time and things like that also. So, you know, 

AJ_O’NEAL: that actually reminds me of my other question, which is so if I create something, say on digital ocean or on Amazon or wherever, I'm going to get back an IP address. And so if I'm going to update some DNS records, I can't know what the DNS records are, like I literally couldn't create a quote unquote, declarative file myself because the IP address doesn't exist until I've created the service that the IP address is connected to. So how is this handling things like that where you're talking to different services and you say go create a server and go update this thing, but the pieces that need to be connected don't exist yet until the configuration is run. 

CHRISTIAN_NUNCIATO: Right, and one thing you can do in your program is let's say that you have a virtual machine and a DNS record in your program. You just have two parts. I want a virtual machine. I have a DNS record and the DNS record should use the IP address that is produced by the virtual machine. That's kind of that speaks to the scenario you're thinking, right? 

AJ_O’NEAL: Yeah, exactly. 

CHRISTIAN_NUNCIATO: Yeah. So then the way that this works is, and it's hard to do this without showing code, but the block of code, the instance declaration, you say like new AWS dot EC2 dot image or not image instance. Uh, and you pass it some parameters, you know, and, but when you do that, you, you create a variable that holds onto a reference to that object that was created from that class, that plume class. So you say var foo equals new EC2 instance. And then you have foo, right? That, that is sort of the variable that contains a reference to your AWS virtual machine, which has not yet been created a couple of lines down, you can write your, you know, var bar equals new DNS record from DN simple or something, whatever it is. And as part of the IP address input to that DN simple resource declaration, you can say, you know, for the IP address, you know, food.ip or food.public IP and pass that variable reference to the creation command or the sort of, um, the instance, the instantiation of the DNS record. Does that make sense? And when the program runs, it will compile all this stuff together and say, Oh, okay. The DNS record relies on the virtual machine. So I need to make sure that thing exists first. 

AJ_O’NEAL: And it sounds like there's not too much abstraction at this level. Like if I'm using the config wrapper library for AWS or digital ocean, it's going to be pretty specific to that. Not, not made generic. So I'm going to get the exact details for what, you know, cause an AWS EC2 instance, like the Jason that comes back from the API or the XML that comes back from the API on that is different from the JSON that comes back from the API on digital ocean or the XML that comes back from Azure or whatever it is. So it sounds like these are, these are specific to the provider, not abstracted. Is that correct? 

CHRISTIAN_NUNCIATO: Yeah. But you can still use that to the extent that those properties are kind of primitive properties like like the output and IP address of the virtual machine instance that was created on on EC2 is a string, for example, you know? 

AJ_O’NEAL: Yeah, yeah, yeah, yeah, yeah. 

CHRISTIAN_NUNCIATO: Yeah, and then the input to the DN simple record or whatever is also a string, then you can, that works just fine. So- 

AJ_O’NEAL: Well, I actually, yeah, I actually like the idea that it is not abstracting that part away, that it's, you know, so this is not a tool that you'd use if you wanna like do a quick, you know, cause there's some tools out there that's like, oh, you can use this with Amazon. But then if you just, you know, switch a config file, then you can use it with Azure. And, you know, so there's this theory that you could just switch from Amazon to Azure with a config file change this, you would go through and you'd rewrite all of your code for Azure or Amazon, you'd have to rewrite it for Azure or whatever, which I think is, you know, you don't normally change these things. And when you do, it's for a particular reason. It's a lot easier if things map to the documentation of the service rather than an abstracted documentation in many cases. So.

CHRISTIAN_NUNCIATO: Yeah. Yeah. And the thing about this though, that even can go, you can go a step further. So let's say that you have a, let's say that you're programming to, you know, your API that you want is a, a web, a website, you know, like a very high level abstraction website, you know, and a config you could, you can, because we're writing in JavaScript, you could go that extra level, you as, as the developer of the infrastructure code could say, write the first version of that, that high-level website abstraction to use AWS. But you could also then write another version of that that used Azure and then allowed, you can write your high-level class, for example, to just take a param that says Azure AWS and you pass in Azure and it goes out and uses your Azure specific module to create the infrastructure or your AWS. 

AJ_O’NEAL: Is there like a cookbook or, I mean, it seems like that's something that somebody would probably do pretty early on. Is there something like that already that's like a community, somebody on GitHub as a...Pulumi abstracts VPS service module. 

CHRISTIAN_NUNCIATO: There are a couple of those. Yeah. I don't know. I think it's more common as you say that like, you know, you, you're going to pick a provider and kind of use that provider there are, I think. I think there may be a couple of blog posts on the Pulumi blog that, that kind of show how this is done. But I think it's the kind of thing that like, if you're comfortable writing, you know, classes and so on, you could probably write that yourself. It, you know, you can know both clouds, of course, which is. That's the real pain is like knowing how to do something that you did in AWS also in Azure, because the clouds themselves are so different these days too. 

AJ_O’NEAL: Yeah. And the nomenclature and 

CHRISTIAN_NUNCIATO: yeah. Yeah. So that's a hard problem, but you know, because it's programming languages, it's all easily solvable, but it, but it's. 

AIMEE_KNIGHT: The question I was going to ask really quickly when we were talking about the remote state, I feel like most places that I've seen usually just typically, you know, if it's a you know, if they're interacting mostly with AWS, the, they'll store their stuff in the S3 bucket. If they're using GCP, then you know, cloud storage, but is there a benefit to storing it with Pulumi versus like the, the provider I'd be using? 

CHRISTIAN_NUNCIATO: The couple of the benefits I mentioned are just that, you know, the service, the Pulumi service will keep track of all of the changes to a particular stack or environment over time. So if that's something that you're interested in keeping kind of a historical view on, that's super valuable. The other reason is, one of the other reasons, I guess, is also locking, as I described. If you have multiple people that are using the same program, then the service will handle the, making sure that no one is stomping on one another by running at the same time. And then you can also apply more granular access levels to things. So if you're kind of on a team that manages or that wants to manage, you know, what different developers on, on other teams have access to, you can do that really easily in the service by. Just, you know, adding groups and permissions at the stack level and stuff like that. So role-based access controls or whatever like that, that's, that's easy to do in the service also. So those are a few, a few of the reasons. Why you want to use the service. Yeah. But again, like all this stuff is doable as you describe, like, you know, you, it's kind of open source and free by default, but if you want kind of more teamy things and more permissions, granularity and policy checks and things like that, then you can use the service to make that easier for you. But I think you get to a certain point in your team development where that becomes useful and you don't necessarily need to start out there. Although it is really easy to start out there and it's kind of nice, but you don't have to do that.

AIMEE_KNIGHT: Awesome. I'm already pinging people and asking if the team has kind of like looked into this or not before. So, because I made up a team of like a lot of just like hardcore, you know, infrastructure engineers, but then there's two people that come from a dev background. So I think for him and I, you know, we're really excited about it, but the infrastructure engineers usually want to like up their chops on, you know, like application development. So this might be a good way for them to do that too. But anyways, it sounds like we don't have any other questions. Is there anything that you want to share before we get into Picks? 

CHRISTIAN_NUNCIATO: No, I mean, I think that just the, the re just to reiterate, I mean, like, you know, as a developer myself, who kind of discovered this just a couple of years ago, I really, I really am excited about, and this is the reason why I chose to even write a book, which is like a huge pain. I mean, if you've ever written a book, it's actually takes a lot of time, much more time than you think it ever would. But I still believe in this idea that for us as developers, this is a really useful and powerful tool that kind of allows us to do a lot more than we could ever really do before with the language that we that we really love. It's that that's why I'm so happy to speak to this group because I'm in this group of JavaScript developers and you know, this is this is good stuff. So we should we should take a look. There are other tools out there too, by the way, like the Pulumi isn't the only one there's tool called AWS CDK or cloud development kit, which is JavaScript based tool that you can use if you just want to only do AWS things. So there's, so there's more and more JavaScript oriented tools that are beginning to emerge for developers. But I think Pulumi is really kind of, it's a great one. It really kind of opens a ton of possibility to you. And so I would just encourage people to like be brave, use the type hinting in VS code and go forth and have some fun. 

AIMEE_KNIGHT: So I should have asked one other question that came to mind as you were saying that I'm curious, have you guys seen like one of the languages be more popular among users versus others? I'm just curious.

CHRISTIAN_NUNCIATO: Yeah. I mean, the TypeScript language is definitely the most popular. Yeah. Because, you know, it's, it's just the most, the JavaScript being like this flexible language that it is. There's so much that we can do there. When we didn't talk much about like AWS Lambda or API gateway and that kind of stuff, like that with, when you're using JavaScript and TypeScript, the ability to write inline functions that ultimately get like serialized into AWS Lambdas and things like that. That's absolutely delightful to do in TypeScript and JavaScript. It's a little harder to do in some of the other languages just because of the nature of those languages and the way that AWS kind of expects you to use it. So definitely TypeScript I think is our, our most popular. It's also the most, the APIs are the most developed. Um, but I think we're seeing a lot more uptake in Go also, particularly infrastructure teams that are familiar with Go, they'll pick up Go. Python is also pretty popular. Dotnet folks are kind of coming on gradually. So C sharp kind of bring it up the third, the fourth level there, but like, yeah, for sure. JavaScript type scripts are kind of across the board, the most popular still. 

AJ_O’NEAL: So I'm going to circle back around to the question. I, the question I asked earlier about, you know, what's the ideal state. I'm just looking at the price of this and I'm, I want to hear if you can make a better argument, but I'm thinking like, if I buy a car for $2,000, I'm not going to spend $2,000 on tires because they're an accessory to the car. And, you know, like I equate value of accessories or usually in the realm of, you know, 10% or something of what the cost of the thing is. Maybe you could challenge me on that with like game consoles and controllers, which end up costing about the same as the console when you're done. But anyway, so I'm thinking if a team is spending $500 or more in infrastructure costs currently that might be a good frame of when they're at a level of production that it would make sense to transition into something like this just based on the price. If it's going to cost me $50 to get started with a team of three members, then as an accessory to my services, then maybe if I'm spending around $500 or more, that would be a time where this would be like I'm at the level where I'd be really productive or this would be worth getting into. Do you have a better argument on that? I think you can.

CHRISTIAN_NUNCIATO: Yeah, I think I mean, I could maybe if I were like, I don't think of this, I guess I don't, I don't really have a great answer for you that I don't see that those two as necessarily kind of connected, I guess. And maybe that's just because I'm not seeing it as you're imagining it. But like, I don't see, like, I think even if you're like, obvious, we want to keep our AWS costs are like our cloud costs low, you know, and, and so the, so even if we're just spending, you know, 10 or $20 a month or something on the actual infrastructure to say produce our not heavily traffic AWS lambdas and things like that. I still think it's valuable to have a team that can have a plan or whatever that lets you work as a team without, you know, so I don't see those things as necessarily connected that what you're spending on infrastructure, maybe the amount of infrastructure you're using, the amount of code you're trying to manage, certainly that, that definitely the amount of resources you're trying to manage. Certainly that makes sense to me. Like if you're, if you're just, you know, a couple of, you know, few developers and you've got one virtual machine that is your production instance. And, you know, one that's, you know, uh, your, each of you has a dev instance and you're just kind of doing that manually. Like that's, I say, go keep doing that if that that's fine, you know, but when you've got, you know, you're using some easy two and you're using some Lambda using some API gateway and some buckets, maybe you've got three or four or eight buckets, okay, that's when it's like, you should do it in code as we described. And then if it makes, if you're all wanting to use, you know, iterate on the same code base constantly or often, it makes sense to use, you know, the service, for example, to keep you off from, you know, overriding one another's work and things like that. And then, you know, beyond that, as I described, when you have larger teams that, you know, need to have their access to different things controlled, then it definitely makes sense to look to something with the service to be able to control that access. So I hope that answers your question. I mean, I don't, I'm not trying to dodge it in any means, by any means. I just don't, I don't, I don't have it. 

AJ_O’NEAL: No, I think I was. You kind of said what I was, what I was looking for, which is don't think of this in relation to your server costs. Think of this in relation to your team productivity costs. 

CHRISTIAN_NUNCIATO: Yeah. Team productivity definitely. And I think that that team productivity is definitely related directly to like the amount of time the team would need to spend managing infrastructure stuff. So yeah.

AJ_O’NEAL: Yeah. Is it, if this is saving you $50 a month in terms of manual processes or team communication or, you know, cause what one person is going to be somewhere between, you know, 20 and $60 an hour. So if, if you've got, if it saves, if it saves one or two people, one hour per month, then it's, it's worth it. 

CHRISTIAN_NUNCIATO: Yeah. I think that's a good way to sum it up. Yeah.

AJ_O’NEAL: Cause I did, I did want to get some sort of resolution on, on the idea of, you know, what's, what's the ideal scenario or how can we frame this as, as what, when somebody should go for it. And I feel like through all of that conversation, hopefully that got tied up. Steve, what do you think? Are you sold? 

STEVE_EDWARDS: Absolutely. What am I sold on? 

AJ_O’NEAL: Oh gosh. I might, I'm at, I'm at a point where I might give this a try myself. So don't, don't call it a celebrity endorsement yet, because there's not any celebrities on the show, especially not me, but 

CHRISTIAN_NUNCIATO: that's great. I mean, again, like. And I work for Pulumi, but like it's, you know, I don't care. I don't care if you pay for this or anything like that. Like I, I just want to, I want to get people to want to try to do infrastructure things with code, especially with JavaScript because it's just awesome. Like I, so like, if you're going to go and try it, that's great. That, that makes me like, I'm, I'm legitimately smiling right now because like, I want, I want to encourage developers to try this stuff. 

AJ_O’NEAL: I'm going to look up how, how I might be able to use it with name.com and digital ocean. Cause that's, that's what I like to use. Cause I find them to be the simplest to use in their web interface. 

CHRISTIAN_NUNCIATO: Yeah. I mean the, the, uh, the digital ocean provider for Pulumi is definitely first class provider. So like, you know, you'll see lots of examples in the docs and stuff that deal with digital ocean. 

AJ_O’NEAL: So, and if name.com isn't in there, I'd be willing to try DN simple. I've hear good things about them. But anyway, yeah. So I, yeah, I understand this wasn't a sales pitch for Pulumi, but I'm just I often on the show, as you probably heard in the past, because you said you've been a listener, I bring in the hard hitting questions about, how do we justify the value of this? 

CHRISTIAN_NUNCIATO: I was expecting that, yes. So, yeah. 

AJ_O’NEAL: So anyway, cool. Thank you. 

CHRISTIAN_NUNCIATO: Yeah, absolutely. 

 

Hey, folks. I don't know if you've noticed, but I've been working a lot on figuring out how to help people become the most valuable developers on their teams, or becoming the top 5% of developers in the field. If you're looking to level up, figure out how to contribute more get the career you want, get the career that you want that will support the lifestyle you want, then you should check out the Most Valuable Dev Summit. I've invited some of my friends across the community, people that you've heard of, people that have worked on systems that you use on a daily basis, people who have invented new ways of doing things over the years in programming, and I've asked them one question, and that question is, how do you become a top 5% developer? How do you become one in 20 of the best developers out there. And so we're gonna go ahead and have that conversation with them in interviews on the Most Valuable Dev Summit. And you can find that at summit.mostvaluable.dev. 

 

AIMEE_KNIGHT: I guess it's time to push us into picks. AJ, do you wanna go first? 

AJ_O’NEAL: No, because I actually don't have my picks ready yet today. No, no. Give me a minute. 

AIMEE_KNIGHT: Steve? 

STEVE_EDWARDS: So gonna go with the simple as usual. So I was listening to another tech podcast, a pretty well known one. And one of the topics that was brought up was called nerd sniping. It's basically getting somebody, uh, the idea is that, you know, you're working on something and then something comes to your attention. That's like right up your alley. Something you're really interested in. You forget what the heck you were doing and go just focus on that. So probably one of my all time favorite classic SKCDs is called nerd sniping. That's one of the goes way back to, I went first once number 356. If you know how his user URLs work cracks me up every time I see it. I'm also into the real physical type of humor. But yeah, check it out. XKC.com number three, five, six. 

AIMEE_KNIGHT: Awesome. AJ, are you, are you in a place to have some? 

AJ_O’NEAL: Give me 30 more seconds. 

AIMEE_KNIGHT: Okay. I am combing my GitHub stars recently and someone passed this to me at work yesterday. It looks pretty good. It's awesome. All these people have like the different awesome GitHub repositories and this one is awesome network automation. I'm curious if I see Palomi on here, but I don't have time to look right now, but if not, you guys probably should get yourself added and it looks like there's a lot of good resources on here. So that will be it for me. And hopefully AJ is now in a good spot. 

AJ_O’NEAL: You know, Amy, I've been really meditating over the past 30 seconds and I feel like I'm in a good place to share some pics. Okay. No, I really had this, but I'm in a good place now. Okay. So first of all, I'm going to pick the bound app because as many of you know, I hold off on new technology as long as I can. So I finally updated my laptop to Catalina, which is where I've got most of my audio books that I sync to my phone. And, you know, of course Catalina screwed up everything about my computer. Now it, it crashes instead of going to sleep and you know, all sorts of stuff, because it's a 2012. I like having the ports on the side and not the dongles. 

STEVE_EDWARDS: And anyway, just making sure it really goes all the way to sleep. 

AJ_O’NEAL: Yeah, I guess so. Except when it wakes up, it's always like computer shut down, unexpectedly submit a crash report, or rather when I plug it into power and hit the button and whatever anyway, so a lot of people that are in the audio books have been complaining about, you know, Catalina just screwed up the audio book stuff and you can no longer management and iTunes. And it's just and you have to have duplicate copies and it has to put in its own folder. It doesn't work the way it used to. So the Bound app has this really cool feature where it lets you upload just the files to your phone through a web browser. So you go into the setting and you say like, start web upload server, and then it gives you your IP address on your local network and you type in 192.168.1.105 or whatever. And then you drag and drop and you can, you know, drag and drop folders and you can get audio books onto your phone that way. And it's actually, some of the features of it are a little bit nicer than the native iBooks app or the audible app, especially the, um, the speed settings and the sleep settings were pretty intuitive for me. I mean, not that they're like that earth shattering thing. And then also I found out that the VLC app has the same feature for your music. So you can actually, and both of them work with like Dropbox and Google drive and some of the stuff like that as well. But they both have this neat feature where you can web upload and the VLC app actually has, you know, the source code online. So you can go check out how that kind of thing is done in an iOS app, which is pretty cool. And then since we've been talking about, you know, this deployment and infrastructure stuff, you know, I, I work mostly with, with your startups and smaller teams and smaller companies. And, and so I I'm realizing I need to get on this, you know, infrastructure is code bus. I'm like having that moment of humility. It's been working on me, but I'm getting there. I'm getting there. But me and a buddy of mine, what we've been using for a lot of our client work is Git deploy, which is something that we created ourselves. But it's really simple. It works with webhooks like GitHub and GitLab. I don't remember if it's GitLab or Bitbucket. We've got like three or four of them integrated in there because we just work with various clients and then we add one. But you just set the thing up. You put it behind caddy for...You know, so you get the HTTPS or whatever. So we've got a bunch of sites where it's like get deployed dot whatever.com. And we set up the web hook to that. And then it fires off a bash script that runs the build process whenever a push comes in, according to a couple of rules. So if that sounds, you know, more your speed, you're something to check out, but, but, you know, in the day and age and where we're at, you're probably better off spending that time on something like polo me, if I'm being honest, but just, you know, if you want it, it's there that's web installed.dev slash get deployed. 

CHRISTIAN_NUNCIATO: Cool. Should I go? 

AIMEE_KNIGHT: Go ahead with your picks. 

CHRISTIAN_NUNCIATO: I have non-technical picks. The one is I haven't been here for, I haven't listened to this podcast in a little while, like a few months. And so I just want to share, like we just finished watching a series called called shits Creek. So if you, and I'm probably late to this, but like my wife and I absolutely loved this series, so if you haven't seen it, if your listeners haven't seen it, it is an, it is absolutely lovely comedy series on Netflix that I can't recommend highly enough. It started out a little bit rough for us, and we weren't sure if we were gonna like it, but at the end, man, it's just such a beautiful story. So like, I recommend that as a thing to watch on Netflix, shits Greek if you're so inclined and haven't seen it yet, because there may be two or three people that haven't seen it yet. The other thing that I would recommend is a book, and it's called The Sense of Style by Steven Pinker. If you're interested in writing yourself and maybe writing a book or just writing, sort of nonfiction stuff in general. This is a fantastic book written by a really excellent writer who's just a ton of fun to read. And it's all about just crafting good nonfiction that is coherent and easily read by people. It's, but it talks about grammar. It talks about the way that we read and how we understand and assemble meaning as we read. And it's particularly geared toward, like I said, nonfiction writers that are explaining how something works and so on. So I cannot recommend this book highly enough. I've probably read it three times myself in the last year as I've been working on this book. So if you're interested in writing The Sense of Style, Steven Pinker, you will love it. It's great. 

AIMEE_KNIGHT: Awesome, thank you. I guess with that, we will wrap up. Thank you so much for coming. Hopefully people are also convinced now. Sounds like AJ is, maybe Steve too. I know I'm trying to convince people, so appreciate it. 

CHRISTIAN_NUNCIATO: Awesome, thank you so much. I'm so grateful to have been able to talk to y'all. So I...Appreciate it so much. 

AIMEE_KNIGHT: Let us know before we say goodbye, where can people find you or more information about all this? 

CHRISTIAN_NUNCIATO: Yeah, I'm just on, I'm cnunciato on Twitter. So c-n-u-n-c-i-a-t-o on Twitter. I don't do a lot of tweeting. When I do, it's usually about JavaScripty things or Pulumi related infrastructure things. So you'll find me there and my website is linked from there too. Or I post a lot of pictures. I take a lot of pictures of the Northwest and so on and my family stuff. So if you're interested in the Northwest and the geography here and the beauty of it and stuff. You can see some pictures of that on my website, but yeah, just I'm on Twitter. You'll find all the important things there, I think. 

AIMEE_KNIGHT: Awesome. With that, we will see everybody next week. Bye. 

STEVE_EDWARDS: Adios. 

 

Bandwidth for this segment is provided by Cashfly, the world's fastest CDN. Deliver your content fast with Cashfly. Visit C-A-C-H-E-F-L-Y.com to learn more.