The Python Podcast.__init__

Share on social media:

[00:00:13] Unknown:

Hello, and welcome to podcast dot in it, the podcast about Python and the people who make it great. When you're ready to launch your next app or want to try a project you hear about on the show, you'll need somewhere to deploy it. So take a look at our friends over at Linode. With 200 gigabit private networking, node balancers, a 40 gigabit public network, fast object storage, and a brand new managed Kubernetes platform, all controlled by a convenient API, you've got everything you need to scale up. And for your tasks that need fast computation, such as training machine learning models or running your CI and CD pipelines, they've got dedicated CPU and GPU instances.   Go to python podcast.com/linode,   that's l I n o d e, today to get a $20 credit and launch a new server in under a minute. And don't forget to thank them for their continued support of this show.  

You monitor your website to make sure that you're the first to know when something goes wrong. But what about your data?   Tidy Data is the DataOps monitoring platform that you've been missing.   With real time alerts for problems in your database, ETL pipelines, or data warehouse, and integrations with Slack, PagerDuty, and custom webhooks, you can fix the errors before they become a problem.   Go to python podcast.com/tidydata   today and get started for free with no credit card required.   Your host as usual is Tobias Macy. And today, I'm interviewing Luke Hoban about building and maintaining infrastructure as code with Pulumi. So, Luke, can you start by introducing yourself?  

[00:01:35] Unknown:

Hi. Yeah. My name is Luke Hoban. I'm the CTO at Pulumi. Previously,   spent time at Microsoft doing sort of application developer tools and at Amazon doing, cloud infrastructure RDC too. And do you remember how you first got introduced to Python? Yes. I've worked in sort of the programming languages space for a lot of my career and, even, you know, back in sort of in in college and things. Kind of got introduced to Python mostly from some sort of academic perspective. Just seeing it as sort of another programming language, another interesting space in the spectrum, and, and just using it from that kind of perspective. I think my my next sort of deeper engagement with it was actually working at Microsoft on sort of dot net and, worked with a lot of the teams building Iron Python actually at the time. And so really sort of seeing Python through the lens of kind of the Microsoft developer ecosystem, which was sort of an interesting lens to to see Python through. And then I think more recently, just personally, I got a lot more exposure to Python just as a as a lens into kind of machine learning and that kind of thing, just learning that from a personal perspective.   And then I think, with with Pulumi was where we've really gone I've personally really gone the deepest in my career so far with Python, which is really kind of building and designing APIs and programming models for Python developers to, program the cloud and work with cloud infrastructure.  



[00:02:45] Unknown:

And so in terms of the concept of infrastructure as as code, can you give your definition of that and some of the ways that it manifests?  

[00:02:53] Unknown:

Yeah. So I I think of infrastructure as code is really about kind of applying, sort of software engineering principles,   that we kinda use in software development. So when we're building our, you know, Python, server applications or our JavaScript web browser, you know, applications,   we use a set of sort of software engineering,   you know, principles. We we use code to to to write these things down. We use source control. We use IDEs to get sort of completion and error checking. We use,   a whole bunch of different things that are sort of part of being able to scale up the complexity of the software we build, to sort of tackle complex problems in our application development.   Infrastructure as code is really being that same trend, bringing that into the cloud infrastructure space where there's all these amazing building blocks that are available from these cloud providers.  

But to really take advantage of them, you've got to bring them all together,   build complex things on top of them.   And to do that and scale up that complexity, what we do with our cloud infrastructure, we really need to bring to bear a lot of those same kinds of tools,   that we use kind of for application development. And so, so for me, infrastructure as code is really about, doing that, bringing all those tools to bear. And I think, you know, in the industry today, infrastructure as code is sort of largely I'd say, infrastructure is text.   It's sort of taking that very first step of being code and making it something you can write down in a file.  

You can put it into source control. You can version it in source control.   That starts to give you some of these benefits of being able to repeatedly,   deploy a thing, and be able to version it and be   So So can you give a bit more of the background of what Pulumi is and some of the story of how it got started and how you've got to where you are today? So Pulumi is we sort of think of as a modern infrastructure's code tool. So really, taking the ideas of infrastructure's code and taking them to where kind of modern cloud is today. We've set it from a few different perspectives. So 1, Pulumi lets you use existing programming languages, not sort of very constrained DSLs like JSON or YAML or HCL, but real programming languages like Python, to describe your cloud infrastructure. And as well as doing that and all those software engineering benefits that you can kinda get from that, literally focuses on sort of some of the modern cloud scenarios.   And so things like the ability to work with serverless, the ability to work with containers, the ability to work with Kubernetes.  

These kind of technologies that organizations are, moving increasingly quickly towards in as they sort of move into the cloud. And making it really easy to take all the different building block pieces you need in all these domains, and bring them together,   to support this cloud infrastructure that your applications need. There no longer has to be as much of a divide between   the way that you do your application development and the way that you do your cloud infrastructure development. These things can now become more integrated, both because you can use Python for both,   but also because   the same, you know, team, the same engineering   principles   can be used across the team. In terms of the the kind of backstory,   behind it, I'd say, you know, from my personal perspective, you know, I as I mentioned, worked on kinda application developer tools.  

I worked at Microsoft for for a long time, worked on dot net, worked on Visual Studio, worked on creating the TypeScript project at Microsoft and and on some other,   tooling projects there. And and so I've I've spent a long time kind of building tools that enable application developers to sort of scale up the complexity of what what they can build and seeing what that enables,   enables developers to do in the the JavaScript ecosystem and the dot net ecosystem, with Windows, etcetera. And so then, you know, when I moved over to kind of work in the the cloud space, I sort of saw that there were all these great building blocks in the cloud providers, but the developers were still really struggling. They had to be very advanced, have a lot of very specialized skill set to figure out how to build the kind of things that people want to build on top of these cloud platforms. And so sort of, I think the the story behind Pulumi was really seeing that there was this huge gap, that there was this inevitable   shift towards the cloud for a whole bunch of great, you know, productivity and, you know, economic reasons. And yet, you know, developers weren't being empowered to fully take advantage of all that value that was there, and then there was a big opportunity to to help with that problem and help with it in a way that that, we felt like we understood, how to how to sort of bring developer tools and and and, software development practices to this space. And 1 of the elements  

[00:07:01] Unknown:

that I wanna draw out from there is this idea of empowering developers to be able to manage the infrastructure   where for a while, the servers   and the infrastructure was the domain of systems administrators.   And now it's largely being relegated to the quote unquote DevOps engineer where the intent is to try and bring the operational   aspects   closer to the software development aspects so that you have people working together and collaborating on that. And I'm wondering what your thoughts are on the background   and the   context and the specific skill set that's necessary for developers to be able to adopt to be able to effectively design and build out these infrastructures   as part of the,   application life cycle and what you see as being the breakdown in responsibilities   of developers versus operations engineers for being able to design and manage this infrastructure?  



[00:07:56] Unknown:

I think it's, you know, it's great, it's great framing there. And I think there is, you know, there's a couple of big trends that we kinda see,   generally. I mean, 1 is, of course, just more and more cloud adoption,   and so more and more, usage of these sort of cloud APIs and things. But at the same time, we see kinda 2 2 layers on top of that. 1 is that, you know, as folks move, into some of these modern cloud technologies,   it it means that there's sort of more and more cloud resources that they're managing. Right? So it's not no longer you know, few years ago, it might have been that you had a handful of VMs. They were managed by some, systems administrator,   and the development team, you know, either SSHed in and and did their deploy inside there or ran some very simple kind of CI process onto that. But the infrastructure didn't change all that often. You know, you you added a new VM or a new database server or whatever, you know, once a year, and you rarely kinda made changes to it. And so it's a fairly static kind of environment in which your cloud infrastructure worked. And so, you know, the the sort of operation of that didn't have to sort of move at the pace of the application development team or the pace of the kind of business,   itself. And as we move towards sort of more modern cloud technologies, I'd say that iteration cycle infrastructure speed at which infrastructure changes is, you know, has shifted fundamentally towards many layers of this actually   iterating at the speed of the application development team. So if you look at technologies like serverless or Kubernetes, for example, a lot of the infrastructure associated with those projects being deployed on the Kubernetes or on the serverless technologies   actually has to change nearly as fast as the application code itself. So for serverless, kinda every time you wanna deploy your application, you're actually changing resources in AWS.  

Or for, you know, Kubernetes,   you know, you have to sort of write, specifications of the sort of the the environment variables and, you know, context in which your containers are going to run and how they're gonna be wired up into load balancers and services and things inside, inside Kubernetes. And so we see that more and more that ownership is sort of shifting closer to the application development teams just from a you know, at the speed of iteration and the the the place at which the affinity is with the sort of ownership of the, delivery,   is moving so that the application development teams have to have a better understanding of some of cloud primitives if they wanna take advantage of the value of some of these sort of modern cloud technologies.  

And then the other part of that is just as that complexity rises generally, even within the sort of traditional platform teams or DevOps teams or even sort of traditional infrastructure teams, the amount of cloud infrastructure being managed is just going up dramatically, both because of just the shift in the cloud and also because of the, you know, shift towards these more modern cloud technologies where there are more more moving pieces and more managed services and that sort of thing. And so that complexity leads to the need for more of these software engineering principles. So even those traditional,   DevOps or or sort of systems administrator teams are finding that they need to bring in more sort of software engineering practices and and controls   into the way that they do their jobs because the complexity is going up there as well.  

And so both of those trends that, you know, the traditional folks doing this work are finding they need more software engineering tools and a new class of folks coming into the space from the developer end of the spectrum are kinda coming with a developer and and software engineering mindset. We think both of those trends are kind of, leading to a need for, this kind of tool. Another element of that dynamic is the fact that infrastructure engineers and platform engineers are generally trying to optimize for stability  

[00:11:16] Unknown:

and   the sort of continuous operation of those systems,   and developers are trying to optimize for rapid release cycles and rapid change. And sometimes that can come into conflict if the engineers are put in charge of   managing the infrastructure because they might not be optimizing for some of the types of controls that the platform engineers are trying to incorporate   and enforce. And so I'm wondering how they can work together effectively in this   new landscape of managing the infrastructure   as a software artifact and some of the ways that they can enforce some of the things like security policies  

[00:11:56] Unknown:

or infrastructure consistency so that it's easier to manage in the long term. Yeah. So it's it's a really big part of kind of what we focus on actually with Pulumi. And I'd say there's 2 key ways that we sort of think about that problem, that opportunity really to empower kind of both of those teams, to, to to succeed at different goals you just highlighted. And 1 of them is just the sort of core software engineering idea of being able to build reusable components   and abstract   away complexity and abstract away best practices in security and compliance things   behind reusable components. And so 1 of the things we see a lot of teams who end up using Pulumi,   doing is actually taking their platform team or build some of these components that have those best practices built in, have the sort of, you know, the security layout for their networking infrastructure or   the I'm policies,   defined that they want to allow folks to use in different situations within applications.  

And they'll build those reasonable components, build the the sort of packages and and, and components that can be used by application development teams to deploy, infrastructure   into the AWS accounts and into the cloud environments managed by,   that that sort of platform team. And so that ability to create sort of reusable components that abstract away some of those best practices is a really important sort of software engineering tool generally. I mean, that's how that's how we have the, you know, software we have today. You know? Like, Apple provides great APIs for iOS that don't just give you raw access to the primitives of of of the device, but they also give you best practices around,   sort of security and and, and and clients with, with things in the platform. And so so here, it's the same thing, and then we, you know, we want both ourselves provide some of those libraries, but even more important, empower those platform teams to build those best practices into reusable libraries that they can then use to to empower their application development teams to use those. And the second part is, you know, that using those components is a good thing just to to kind of for ease of use for for for, you know, not having to kinda copy paste that that compliance criteria all over. But we really wanna also enforce some of that and help the help those platform teams to enforce that anyone who does deploy into this environment must meet all of these compliance criteria. And so Pulumi does also actually a a new, new capability that's coming with that Pulumi 2 0, which is launching very soon,   is the ability to add policy as code. So not just to describe your raw infrastructure as code, but also to describe policy about your infrastructure,   using code. And so that would let you say, nothing is allowed to successfully deploy, with with Pulumi inside my organization or inside these projects within my organization unless it passes all of these checks.  

And so it checks that, you know, ports haven't been opened,   on my security groups or that certain images,   or, you know, only certain blessed images are allowed to be   used inside containers.   Any of these sorts of, criteria that you have within your organization that platform team wants to enforce,   they can then enforce through, through kind of this policy offering. And so so we do see sort of multi multilayered approaches to this, but, but all of it sort of fundamentally empowered,   by using real code at all these different layers, and providing the tools for for both that platform team and the the kinda ultimate application with Opti. And where does the name come from? Yeah. So it's actually,   you know, our founders,   Joe and Eric, you know, worked at Microsoft as well for a long time. And they had a colleague, there who was 1 of our early advisors when we started the company, and he unfortunately,   passed away actually. But his last name was Broom and sort of as a tribute to him, the name,   is Broom in Hawaiian.  

So, Pulumi is is Broom in Hawaiian. So, sort of attributed to him, but also a a name which, sort of stood out. You know, SEO for it is pretty good. So, you know, it kind of, kinda caught caught our eyes.  

[00:15:35] Unknown:

And in terms of the overall landscape of infrastructure as code, 1 of the most notable   entrance to that is Terraform, which has grown a fairly large following.  

[00:15:45] Unknown:

And then there are some of the platform specific tools such as cloud formation, and there's some measure of capability built into a number of configuration management frameworks. And I'm wondering if you can compare and contrast some of the capabilities of Pulumi and how it fits into that overall ecosystem. Yeah. So I mean, you know, to them broad strokes kinda sit in the same sort of space in the infrastructure as code space as as many of these tools. And we're seeing overall, like, a ton of growth in that infrastructure as code space and a lot of folks kind of moving from, you know, managing infrastructure by point and click or by, you know, using a s SDK directly to to using infrastructures code. I'd say the biggest, kinda difference for Pulumi   is, you know, this idea of bringing kinda real programming language, real software engineering capabilities, and taking that infrastructure's code thing kind of beyond infrastructure's text and towards, like, a real, you know, software based, discipline.  

And so so that's really the kind of core, you know, technical difference, and it leads to lots and lots and lots of, you know, practical, practical, pragmatic differences that the folks experience when they're using   it. Kind of just around, you know, having IDE support   and having the ability to debug and having the ability to unit test, having the ability to package and version, reusable components and and build abstractions on top of those things. And so so all of these different, you know, second order benefits you get once you embrace kinda software engineering are really, like, the core things that differentiate the day to day experience kind of using something like Pulumi. So I think of those as sort of superpowers that Pulumi gives you, to go beyond just the role infrastructure's code and what are all these things which are gonna accelerate and enable, your ability to really take advantage of, the cloud infrastructure you sit on top of. 1 thing that is kind of notable, though, is while Pulumi does give you these rich, you know, kind of imperative program languages, it does still have the same kind of desired state model that many of these other infrastructures code tools have. So whether it's CloudFormation or Arm or or Kubernetes, YAML, or Terraform,   they all have this model that they're sort of a desired state that you specify with your your code,   and the deployment orchestrator, whichever 1 of those it is, is gonna help make sure that your infrastructure ends up in that state. So it's gonna try and drive from the state it's in to the state you want it to be and figure out the minimal amount of changes it has to make inside the cloud environment to accomplish that. And so Pulumi has that same model, and so it still is sort of declarative in a meaningful sense in the same way that these other infrastructure's code tools that folks may be familiar with are. The key difference just being,   that you get to use a richer model for how you describe that desired state. And so you can sort of harness some of those software capabilities and harness and and tame complexity in front of that declarative model. But you still get all the benefits of sort of desired state declared models.  



[00:18:16] Unknown:

In terms of being able to manage this infrastructure   and control the complexity of being able to   deploy it and   enforce the different policies and figure out the different interrelations between all the services that you're trying to leverage. What are some of the common patterns that you've seen as far as being able to address that complexity   and some of the challenges that come up because of the nature of infrastructure  

[00:18:41] Unknown:

and some of the fundamental principles that exist in that space? Yeah. So I mean, there's a couple interesting things here. So 1 I'd say is just the the overall complexity of the cloud platform is is pretty impressive. You know, there's just an enormous amount of kind of value in these cloud platforms. And it's I I often think of it like comparing it to other things which folks think of as complex. Like, you think of, like, the browser, for example, as as a big API that has a lot of different capabilities and empowers a lot of different very rich experiences that the application developers, expose. And yet these cloud platforms have probably an order of magnitude more API surface area, than the browser does. You know, just an enormously larger amount of capabilities and properties and APIs   that, that they exposed. And they're growing just still at an incredibly fast pace. So, you know, every year, re:Invent, AWS announces another couple hundred, new capabilities   and and plus throughout the year. Right? And so so all these platforms are, incredibly rich, incredibly complex APIs,   that that are growing incredibly quickly. And so 1 of the fundamental challenges is just, hey, how do you how do you even, like, understand that whole surface area and provide access to it and provide, you know, simpler abstractions over it. And so, you know, so Pulumi,   does that a through just making sure that everything is available in a really canonical way by auto generating wrappers around the the cloud platforms themselves based on the cloud providers, sort of schemas and and models for their platforms. But then also making sure that, you know, where there is specific complexity that we can add these libraries on top that sort of present that complexity in a fundamentally simpler way. And so, for example, we have, you know, libraries like, we have an AWS x library, which is a part of our crosswalk for AWS that makes it just easier to work with things like, you know, ECS and containers. A lot of folks work trying to kinda use, containers on AWS, and it's quite hard when you just you work with the raw primitives that AWS provides you. You know, it requires   4 or 5 pages of cloud formation just to sort of bootstrap a basic environment for running a container. And so Pulumi can make that kind of a 1 liner, right, by abstracting away a lot of the defaults and complexity in those underlying pieces. And then progressively, you can you can fall back into all of the details and complexity of that as you want. But for the easy things, we can make that easy, and then you can sort of opt in to when you wanna pick up more and more of the platform's complexity to take advantage of it. But the other sort of side of that is actually the thing that makes this, you know, a fundamentally more challenging problem, I'd say, for, infrastructure is just,   you know, folks do typically want to tweak a lot of these little settings. And so, you know, compared with if you look at if you look at IO APIs, for example, Python has some really nice, you know, I IO APIs just for working with, you know, the file system and it's it's cross platform. You know, it's pretty rare that that folks writing Python code need to reach for a Windows or a Linux or a Mac specific API,   in terms of working with the file system, even though, those file systems are fundamentally fairly different, underneath the hood. And yet, in cloud infrastructure, we haven't gotten to that point yet where we kinda have any meaningful standardization   of cross platform or lowest common denominator APIs, surface area that's broadly used. Folks are still heavily specializing for individual,   individual services and individual cloud platforms. And so offering these kind of higher level abstractions,   is still meaningfully harder, than it is, I'd say, for typical, you know, Python machine learning frameworks or or file system APIs or what have you, where it's it's become pretty easy to to offer nice   cross platform, higher level generalized APIs. And so that's a that's a key problem that we're working on is on kind of what are the tools that you need in the infrastructure world to empower you to have these these generalized things, but still let folks take advantage of,   smaller level details when they need to, where they want to really get a specific benefit out of AWS or out of a particular service. And so we have a few tools we've built to kinda help with that. And 1 of the  

[00:22:30] Unknown:

common stances   of people who are using some of these, as you put it, infrastructure as text tools is that they are more declarative   and that by using a non touring complete language, you can avoid some of the complexities and problems that can arise as a result of the sort of big ball of mud pattern that can arise or some of the dynamism that can end up being a foot gun in Python.   And I'm wondering what you have found to be some of the potential dangers of using these full programming languages to manage infrastructure and how Pulumi is working to address those dangers? And then on the converse, what the outsized benefits are of using those full programming languages that would motivate somebody to wanna use Pulumi over some of the available  

[00:23:15] Unknown:

tools? Yeah. So kind of 1 of my deep beliefs is sort of that we can actually get the best of both worlds here, that we can get sort of all the expressivity   of kind of full programming languages,   but we can still get the reliability   of desired state infrastructure as code. And so I think the way that we do that is by kinda separating the 2. The the way that we author our, infrastructure   can be using expressive program languages and expressive   frameworks and components and and packages and that sort of thing. But it can ultimately turn into something where that program, what it does is it builds up a a model for the desired state. So when I run my Pulumi program, it builds up. Here's the desired state I want to be in and then compares that with the state that we are in and then figures out what changes it need to make. And because of that, we can still provide things. Like, we can provide a preview. When you when you go to run your Pulumi deployment, the first thing that Pulumi does is it shows you a preview of what's gonna change in your cloud environment. So you can review that. You can say, oh, I didn't expect that thing to change. Let me go make sure that my code is correct. And so so we can still get that reliable thing where we can get a preview, we can diff, between different states of our, infrastructure. As I mentioned earlier, we can run sort of compliance validation on that before we deploy it. So so we can do a lot of the things to verify and validate and have confidence in our deployments,   really still from that that declarative model. So we don't have to give up the idea that we kinda have a fundamentally declarative approach. It's just that we gain stronger tools for authoring what that declarative,   approach is. And for me, the, you know, the thing   that I found is, you know, when folks talk about,   you know, the benefits of it being just as a YAML document or a JSON document or something like that, that is really declarative, and you can just look at it and see exactly what it's gonna be. That, I totally get the value of that for when you have 10 or 20 resources total. And you can kinda look at it. You can really understand it just by looking at that JSON file and kinda understanding here's the full set of resources I have. But these days, you know, most   the most the folks I see working in the cloud space have 100 or 1, 000 or tens of 1, 000 of resources that they're managing, both because of just the complexity of their applications going up, but also just the granularity of some of the building blocks they're working with going up. I mentioned that just using ECS to deploy a container, you're gonna have 50 or so resources,   deployed in AWS just to do that. And so at that point, you know,   having   100 of thousands of lines of of JSON to look at is no longer really the reliable and and best practice way to to author anything. You're not gonna really be able to get a clear understanding of the behavior of of that piece of, infrastructure   by sitting there and reading a 100000 lines of JSON. And so you're gonna have to find ways just like we do with software engineering   to   take pieces of that, give them clear names, give them clear interfaces, describe the contracts they have with the rest of the world, and then trust that the implementation of those has been tested and validated to meet that, that description.  

And now go and use that abstraction instead of the raw building blocks and we're copy and pasting everywhere. And so I sort of fundamentally think that for anyone working at a meaningful level of scale, and I think that everyone will be working at a meaningful level of scale with where the cloud is going. The the idea that it's gonna be sustainable to just have giant JSON documents   as the way we do this just doesn't doesn't resonate with me in terms of how I've seen kinda software engineering,   evolve over the last few decades.  

[00:26:25] Unknown:

And 1 of the   common   aspects of what you have built and what Terraform is doing is this maintenance of the state of the infrastructure   as it's been provisioned by those given tools. And I'm wondering   why that is seen as a desirable or a necessary aspect of the design of these tools for being able to maintain that statefulness as opposed to relying on the state as it's represented through the APIs of the different cloud providers so that it's able to be a little bit more dynamic or able to   more easily   incorporate existing infrastructure without having  

[00:27:03] Unknown:

to control it all from day 1? Yeah. So, I mean, the the need to kind of maintain state is actually mostly rooted in just the cloud platforms themselves. Oftentimes, they don't actually provide access to all of the information that you need to to create a resource. They don't necessarily give back all that information when they when you read the resource out of the cloud provider. And so because we have to be able to diff the desired states, to be able to provide this sort of reliable infrastructures code model, we need to know, you know, here's what I specified previously, and here's what I'm specifying now, and here's how those things are different. And, unfortunately, we can't go and ask the cloud provider, what did I specify as the as the inputs to this thing the last time I, I provisioned it? Because even though 80% of that is available, there's that is, for from from many APIs and across all the different cloud providers, there is enough of that information that that they do not provide back. And unfortunately,   we do have to maintain   of kinda what did we ask for the last time and how is what we're asking for now gonna differ from that and what might change because of that. And so I think that's something where, you know, ideally, the the cloud providers would evolve to where their APIs,   did let you see what was the configuration that got used for every, for every resource being managed, last time. And this is something that, you know, for things like CloudFormation, they take care of this kinda internally inside AWS since you don't see it as much. That's why you kind of see it more in tools like Terraform or Pulumi because it's managed outside of the cloud provider. But it the same concept has to apply for for those tools as well, where they have to track kind of what are the diffs and the inputs that were specified between different iterations of the deployment. And so it is it is something that Pulumi does need to do is manage, that state and understand kinda what you deployed the last time and what state things are in. And I'd say 1 of the things that Pulumi does kind of differently is by default, Pulumi   stores that state, in the Pulumi back end service itself. So,   you know, any user of Pulumi, when they get started, they don't really have to think about the state file at all. They don't have to think about managing it on their local machine or storing it themselves. It's just transparently handled by Pulumi. And then if they need to, for kinda compliance reasons or whatever, take ownership of that file and manage it themselves, they they can do that. But we try to make that not something that the developers really have to worry about,  

[00:29:07] Unknown:

initially when they get started. And the maintenance of that state does add a bit of complexity   and sort of upfront planning in terms of how developers   think about how to structure their infrastructure code because of the possibility of having such a large amount of state that is tightly coupled and so needing to determine what are the dividing lines between different aspects of the infrastructure.   I'm wondering if you can talk through some of the design considerations   that they should be thinking of and some of the useful practices that you've seen   for ensuring that that statefulness   doesn't end up being  

[00:29:45] Unknown:

a liability instead of a benefit. Yeah. So I mean, generally, in terms of sort of, you know, how how folks we work with with Pulumi sort of think about breaking up their infrastructure and things. That's it. For me, I often sort of analogize it to sort of the monoliths versus microservices   kind of debate kind of from a server application development perspective. And in terms of that, it follows a lot of the same kind of lines of reasoning. So monoliths, you know, in all cases tend to be sort of easier to reason about, up to a certain scale, and where we just have kind of 1 unit that's versioning cohesively   and can sort of have boundaries within it that are we still have sort of software engineering practices in terms of we we we have good good boundaries between APIs inside that monoliths, but they don't have to be   versioned boundaries. They're backwards and forwards compatible and that kind of thing because we're all versioning as single unit. We're all you know, the the team is all working in a single code base, that sort of thing. And so in some sense with Pulumi, it's it's easiest,   still to kinda keep things in 1 1 unit of deployment as long as team working on it is sort of working together and as as long as it makes sense to be deploying that in a single version unit. But, as teams grow and evolve, and as the the software being deployed grows and evolves, it often becomes valuable to split these things up into multiple units that have maybe different teams working on them that are delivering and versioning at at different cadences   and that are ultimately   going to have boundaries between them that are well defined interfaces that have, they're they're much more sort of fixed, in a sense. Those those interfaces are things which have to have high levels of compatibility because they may intermix in various directions,   with other components, and they may not even a 100% know all of their consumers since they have to have some very clean,   versioning guarantees around them. And so with Pulumi, we can do all those same things. We can break up our our infrastructure into into multiple pieces that are owned maybe by different teams or that kind of a version at fundamentally different cadences. And we can define those those, contracts between those layers. So I can expose a set of infrastructure   definitions   from a lower level stack, for instance, and then consume that from a higher level stack, effectively define that API in between those 2 components. And so we see things like like maybe the sort of core networking and security infrastructure is is 1 stack that is owned by a platform team somewhere and it versions fairly slowly. And then there's potentially   application related stacks that include specific things about how that application gets deployed into the compute,   infrastructure or, you know, what the I'm roles and policies related to that specific application are or maybe even some of the data stores that it might wanna use. Like maybe it uses a queue or a DynamoDB database or something like that that are application specific and those things are gonna iterate more with the speed of the application delivery itself. And so can be owned by that different team, have that different cadence of delivery. But they may need to reference that lower level stack and understand, hey. What was the what was the network that I wanna run-in or what was the core security groups that I wanna apply to run my compute within this environment. And so is that something that we support. And in general, I think people's intuitions from kind of the monolith first microservices   lines of thinking and how that applies into the way they build their services and apply very, very cleanly into their infrastructure as well. Digging further into the specifics of Pulumi itself, can you describe a bit about how it's implemented and how the overall system is architected and some of the evolution that it's gone through since you first began working on it? Yeah. Definitely. So, you know, the core of the the the tool is actually just a CLI tool, the Pulumi CLI. And that Pulumi CLI,   there's sort of 2 deep things that it kinda wants to scale really well with. So 1 is with cloud platforms. So we support, you know, AWS, Azure, GCP, Kubernetes, but also 50 or so other   SaaS and cloud platforms. Like, if you wanna work with Cloudflare or you wanna manage users and databases in MySQL or you want to, I don't know, work with Okta.  

There there's lots and lots of different cloud infrastructure you may want to, interact with, and and Vlumie has providers for all those. And so so a lot of different providers, and we wanna make sure that we have kind of a a nice plug in model around how it's easy to build new providers and have those get consumed inside Pulumi. In the other direction is is languages, of course. So Pulumi supports today Python,   JavaScript,   and with 2 0, which which is launching again   very soon. We're we're GA ing our support for dot net and, and Go as well. And so we, you know, we have a variety of different languages today. We're expecting that to to keep growing over time. And so we wanna make sure that Pulumi kinda scales well both on the cloud platforms and on the languages side. And so both of those, we have kind of a a plug in model where that Pulumi CLI can can know how to launch a language plug in. You know, if if the if the users   Pulumi application says it's a Node. Js application, we'll go and launch,   a Node. Js host to run their code, and then, that host will communicate back to the engine what resources are being defined by that code in a in a language agnostic,   way. And then where the engine will figure out what the previous state of that was, what the how that differs from the current state. And if it wasn't there in the previous state, we'll go and ask the cloud provider to create it. If it was there, we'll ask the cloud provider to update it. And so the the Ploomi CLI effectively just does this sort of orchestration job in between   languages, which actually run the user code, and cloud provider,   resource providers, which know how to you know, create, read, update, and delete resources inside,   the cloud providers. And so the architecture of Pulumi is really an engine which sits in the middle and then a bunch of different, language hosts, for each of these different language ecosystems and then a whole bunch of cloud providers for each of these cloud provider ecosystems.  



[00:35:03] Unknown:

And I know that another element of the Pulumi ecosystem   that is more focused on the business side of it is the managed platform that you provide for hosting the statefulness of   those different deployments,   and also handling some of the collaboration capabilities. So I'm wondering if you can talk a bit more about how that fits into the overall life cycle of working with Pulumi   and some of the ways that you're approaching the business model to ensure that this is a sustainable project.  

[00:35:33] Unknown:

Yes. I mean, 1 1 key thing actually to note is that the, the Pulumi Sass. So, app. Pulumi.com is our is our console that basically provides,   users access to all the different deployments they've done, the history of kind of what resources have been under management, links into the cloud providers, a whole bunch of capabilities too as well as sort of driving your deployments from the CLI to actually understand the state of the infrastructure that you're managing. And, and that's available. There's a free tier of that. So every everyone who who uses Pulumi   has access to those capabilities. But but like you said, it's also part of, you know, kind of where we offer paid offerings as well for Teams and enterprises. And so, you know, we see a lot of teams who go and use Pulumi to deploy their infrastructure.  

At the point where they're sort of taking that into production, they they kind of find they wanna be able to have a team of folks collaborate,   on, some infrastructure, and they wanna bring some more controls into that environment. So they want role based access control for the different users within their team and and what role what what access those users should have. They want the ability to sort of automate things around the service, so webhooks and and rest APIs and that sort of thing. And, ultimately, for enterprises, they want the ability to enforce policy organization across everything they're doing. And so those paid offerings in the in the service side really focus on helping   teams and enterprises to apply Pulumi at scale. We really try to make sure that every all sort of core core capabilities of Pulumi are available as part of the open source project and as part of that free tier, including the the back end service. But, really, the things in those paid offerings are about enabling organizations at scale to really apply Pulumi successfully as they apply it across different parts of the team. And given the fact that you have this  

[00:37:09] Unknown:

many to many   engine in terms of mapping the different languages to the different providers, So I'm wondering how you approach maintenance   and feature parity across those different languages   and ensuring that the providers  

[00:37:24] Unknown:

are properly tested and validated to ensure that there aren't any surprises for people who are trying to use it? Yes. I mean, this is, I think, 1 of the 1 interesting kind of core challenges of of kind of what we do with Lumi is is is that and I think it we really   do lean on the ability to sort of auto generate and drive off of sort of schematized models, both from the cloud providers and, and even within our language SDKs,   so that we can sort of build,   you know, instead of m times n, we can build, like, m plus n, right, things and and validate those and make sure that they they work really reliably. And and so we've we've put a lot of investment in the sort of the tool chain that we use internally around doing that, around making sure it's easy for us to light things up for all languages at once. So when when a capability comes in in a in a cloud provider, for example, that automatically gets lit up across every language that Pulumi supports. And making sure that, you know, as we add new capabilities   into the core platform, in the core Pulumi programming model, that we have a sort of consistent approach to how we do that across all the different languages that respects the ways in which languages are different and the programming models in different languages are different, but still is able to express all the same sort of core concepts that we want to in the Pulumi programming model so that it's easy for us to add in new capabilities   into all those different programming models in a natural way. And so that's that's sort of a key   API design,   challenge. And and luckily, you know, we've got a handful of folks, on the team who have have spent, you know, a good amount of time in their careers working on API design in in a lot of different environments. And so, doing that here with Pulumi is sort of a a fun challenge just because of the the the sort of, 2 dimensional matrix here. And you mentioned the fact that you're working to maintain some of the idiomatic principles of the different languages rather than just sort of spitting out a bunch of auto generated code for these different providers. I'm wondering how you are managing  

[00:39:14] Unknown:

the sort of mapping of what those idioms are and the different languages  

[00:39:18] Unknown:

to just the base schema that's actually driving a lot of this logic. Yeah. So I think, you know, some of it was just for each 1 of these languages. We before we bring up the language in the first place, we we we go pretty deep on,   experimenting with a lot of different API designs and how we could embed that sort of core Pulumi model into,   that language in a way which would feel really natural for   users of that, programming language, but would also would also sort of faithfully and in a in a way which is gonna work well with Pulumi, let people express what they want to. And so, so I'd say that, you know, for each new language we bring up, that's a big part of of what we have to do is really spend the time kinda thinking about what it looks like to do Pulumi in that language in a in a really natural way. And and so yeah. So I'd say, you know, that that is an important thing. Once we once we kinda come up with a core model,   then we just need to make sure as we evolve, that core kind of gloomy   programming model that we do so in a way which kinda respects the constraints that apply in each of these different languages. And and that part that part, we generally found to be a bit easier. But there is there is some work to do to kind of find an API design that's gonna fit well in the first place, in each of these language ecosystems.  



[00:40:24] Unknown:

And 1 of the   main tests of the viability of any tool is how much the community rallies around it and how much community contribution there is to build out an ecosystem   for that particular tool or platform.   And 1 of the big successes of Terraform is that it has grown that community, and so there are a large variety of different providers for different platforms.   So I'm curious how you're approaching   the bootstrapping process   of building out the ecosystem for Pulumi, and some of the challenges that you're facing in terms of being able to build out some of that broad support that will help   to create a useful feedback cycle to bring more people in to continue growing that ecosystem?  



[00:41:07] Unknown:

Yeah. So, I mean, I think 1 of the key things is, you know, Pulumi is also, open source. And so all the pretty much everything we've talked about here, today is kind of open source components. So seeing a lot of folks jump into that ecosystems in in various different open source projects, make contributions everything from small things, to to,   significant feature capabilities. And, of course, by setting up that sort of kind of core open source of the the projects that that we contribute to, also seeing a lot of other projects pop up,   around Pulumi to sort of apply Pulumi in interesting ways. So to, you know, some test frameworks, some some higher level libraries, various different,   open source projects built by folks in the in the broader ecosystem   to enable people to take Pulumi kind of even further. And so we do we do very much believe in kinda trying doing things in in core to empower and enable folks in that ecosystem to kind of expand what they do. And we're seeing huge, growth there. I think, we've seen, you know, massive growth in just the usage and in in this contributions to the ecosystem, over the last year or so. And so we're seeing great growth there. Of course, you know, some of these other ecosystems have been around. You know, Terraform has a ecosystem has been around for for a while. And so there's a ton of great value there and and a really nice ecosystem.  

And so 1 of the things we do there is, you know, we say, hey. Because there is such a great ecosystem around   Terraform providers in particular, you know, we let folks kind of, use those Terraform providers as well if they want to. So the Terraform providers, you can wrap those in in kind of a Pulumi API, and now get that from your your Python or your JavaScript code. And so we don't wanna just compete head on with the kind of Terraform resource provider ecosystem. There's a great open source ecosystem there.   We wanna actually let folks take advantage of all the value being built in ecosystems like that, from Pulumi as well.  



[00:42:46] Unknown:

And in terms of the actual workflow of working with Pulumi to build and maintain infrastructure,  

[00:42:52] Unknown:

what's the overall process and life cycle of the code and how it fits into the development cycle? Yeah. So I think we see, you know, folks when they get started with Pulumi, they, you know, download the Pulumi CLI and they, you know, run Pulumi up, to to deploy some infrastructure they've authored locally on their machine. And so I think then they'll kinda iterate further while, making changes to that infrastructure, deploying it into their environment, as they're sort of doing   development of a new piece of infrastructure. And then at some point, they'll decide that that's ready to kind of be something which deploys into a staging environment or production, and they wanna have a reliable way to deploy that. And so typically move that into a CICD pipeline. And so they'll move from running that Pulumi up, you know, locally on their machine to running that Pulumi up, inside a continuous delivery environment. And so Pulumi plugs well into sort of any kind of CICD setup you have. We have kind of documented guides for doing that with with 10 or so of the the most popular, tools out there. But, basically, now once you've moved there, now you're gonna do something like either git push or some other kinda   workflow that where you push new code into some particular branch, that's gonna trigger a deployment,   into a corresponding,   environment, whether that's a staging environment or your production environment or what have you. And so once folks move in that kind of model, now   they're sort of doing proper kinda GitOps or CICD,   around their deployment.  

But they still may want   to actually as they're building up a new capability on that feature, they may wanna spin up a a dev environment, for example. And 1 of the things that that Pulumi makes really, really nice is in a sense that it becomes easy to spin up a whole another copy of your infrastructure   or some subset of infrastructure to iterate quickly on potential changes you might wanna make to that. And so might spin up a new stack,   that's for your your development environment   locally on your machine and   make changes locally, verify those, see if it's done doing what you want, and then open up a pull request or whatever to to contribute that those changes back into   the shared staging environment, for example. And so so we we see a lot of different kind of workflows   around that core idea. But in general, there's that combination of   using Pulumi as a deployment tool locally on your machine while you're while you're iterating and developing capabilities   and using it in CICD for that delivery into   fixed consistent infrastructure that exists over over a period of time. And as far as the testing of infrastructure,  

[00:45:13] Unknown:

what are some of the useful practices   and patterns for being able to do some of that validation without necessarily having to   deploy and destroy full stacks of infrastructure?  

[00:45:25] Unknown:

Yeah. So so we really see kind of 3 patterns that, you know, we worked with a lot of teams. I think when when when we talk about Pulumi to, you know, to different teams.   We talk about bringing software engineering practices into infrastructure, I'd say 1 of the first things that comes to people's mind is, oh, does this mean I can test my infrastructure?   And, you know,   today, the first approximation, nobody doing infrastructure is is really testing it. And this is sort of big hole that a lot of organizations feel a lot of   are concerned about, the fact that they're not validating, their infrastructure earlier. And so the idea that, hey. We can bring a lot of these testing capabilities that we're used to using for application delivery and bring those into infrastructure.  

This is sort of 1 of the first things that that comes to be people's minds. And so we we kinda see 3 patterns of how we can apply that, you know, with Blue Union. The first is just unit testing in sort of the traditional,   sense, which is writing tests that kind of validate,   individual pieces of,   your infrastructure but without having to deploy it. So so we can validate that if I provide these inputs to this component, it will create these resources with with these, configurations.   And so it's more about the correctness of the logic of my program than of the ultimate desired state of my program.   And so this is something that helps us tame some of that as we're increasing that complexity and and moving away from a declarative way of authoring, and authoring using some of these richer program model constructs, we can we can validate the correctness of of that logic,   using unit tests. And so this is the first thing that the teams reach for and is really kind of fundamentally something that Pulumi enables that's that's kinda hard to do if you're not using existing programming languages. And, of course, we can plug that into   any programming languages testing ecosystem. So you can go and use the Python integrated Python testing frameworks,   Python unit tests to to test your infrastructure,   using this. And, again, that that model doesn't actually deploy any resources, to your cloud. It just tests the logic of your,   of your code is is correct. The second 1 is sort of validating invariance that you want to be true, and so I talked kinda earlier about some of the policy enforcement we have. Some of that policy enforcement can also be used to validate just correctness in a sense of the infrastructure. So when you do end up actually going and deploying infrastructure into a cloud immediately before we actually deploy something, run some validation that we didn't violate an invariant. Like, you know, we didn't open up a port that shouldn't be open, or we didn't deploy that image that shouldn't be, deployed. Deployed. And so we can run that kind of testing, which is sort of,   testing or catch just before we deploy it, make sure that we didn't do anything to violate the variant. And then the last is actually deploying,   whole copies of my infrastructure and really doing I think we think of it as sort of integration testing.  

And, and this 1 is actually really valuable. I mean, ultimately, a lot of what you wanna test related infrastructure is   fundamentally about the behavior of the cloud provider and whether you've wired things up correctly, to get the behavior you want out of the cloud provider. And so some of the a lot of the validation that we might want to do of our infrastructure really does rely on,   spinning up the infrastructure. And so for that, you know, Pulumi provides some test frameworks and things which let you take some infrastructure you have, stand up a copy of it, run some validation against that to make sure it's it's behaving correctly,   and then tear it down, and to do that sort of ephemeral environment testing. And 1 of the things we found there as well is that,   you know, that that approach generally is is valuable, but it's particularly valuable when you do this sort of software engineering idea of building reusable components. Because now I can build that reusable component with that well defined interface,   and I can write a bunch of tests that sort of tests the parameterization of that interface. And so if I have a abstraction that makes it really easy to work with containers on on AWS,   I can sort of say, well, here's all the different ways I can parameterize that. I'm gonna write a set of tests which   try out, you know, a bunch of different points in that spectrum   and stand up copies validate that it works and tear it down. And so I can run, you know, a 100 of these tests,   in parallel. I can run those in a couple of minutes. The total cost of running that is is is cents because it's only last you know, the infrastructure is only up for for a couple of minutes. And I can validate that that component does what it says it does even even to the extent of validating the correctness against the cloud provider. And so this kind of testing we find is is really valuable and really kinda ties back into that idea of of building reusable components and and software.  



[00:49:32] Unknown:

And then as far as the infrastructure as code space itself, what are some of the limitations of it in terms of being able to actually get fully working sets of applications up and running?   And where do things like configuration management tools fit into this overall landscape? And what are some of the options for integrating them with Pulumi for things like SaltStack or Ansible?  

[00:49:55] Unknown:

Yeah. So I think, you know, kind of addressing the second part of that question first, and then I'll get into the first part. I'd say, you know, today, you know, Pulumi can work with sort of the wide variety of different kind of compute primitives out there, everything from kind of VMs to containers to serverless, what what have you. And and it also combine those all really well. And I think in particular, for folks working with kind of VM based, cloud deployments,   that's where they're they're sort of looking at some of these configuration management tools to sort of do the in-depth provisioning and, to be able to consistently apply kind of that that same infrastructure's code model, but to the things that need to run inside,   their VMs. I'd say when we look at sort of containers and we look at serverless, some of it gets a bit inverted because we don't tend to use configuration management tools as much anymore once we're using Docker or serverless. And instead, sort of the the cloud provisioning model that Pulumi tends to manage is actually the thing that that contains that specification. So my Kubernetes deployment and my Kubernetes service   effectively are my configuration management,   and that's something that I'm gonna define kinda using Pulumi. And so as we move to some of these these more modern,   kind of, cloud compute technologies, we find that a lot of the the sort of work to the infrastructure's code work to manage that stuff is actually moving out of some of these integration management tools and into the cloud infrastructure's code tools like Pulumi. But for folks who are working with VMs, you know, can certainly   mix and match, tools. And so at that VM boundary, you can sort of do whatever you want. So we kinda have the ability to connect user data and those sorts of things to bootstrap   VMs and bootstrap into, something like a salt stack or what have you. And,   high level integrations, like, if you we we have this concept of sort of dynamic providers where you can provide   custom providers effectively inside, the Pulumi model that can do things like SSH into a VM and then run some some bootstrap scripts or whatever. And so lots of lots of different ways to bridge between these 2 worlds, but we also see that generally a lot more of this this workload   is directionally moving into the cloud infrastructure's tool code tools and kind of modern, infrastructure's code tools like, like Pulumi.  



[00:51:57] Unknown:

And what are some of the most interesting or innovative or unexpected   design patterns   or integrations into the broader Python ecosystem that you have seen your   users use with Pulumi in their infrastructure projects?  

[00:52:10] Unknown:

Yes. I've seen a ton of really interesting things. You know, 1 is I think 1 pattern we've seen a ton of is actually folks moving towards,   managed cloud, so using AWS or Azure or GCP,   but also using Kubernetes. And so that combination   of getting the best of sort of managed services that are available inside these cloud platforms and getting the operational benefits of those, including of the sort of managed Kubernetes clusters. But then being able to use sort of the standards based API that Kubernetes provides over compute, I mean, just the richness of that API. And Pulumi sort of, really makes it uniquely easy to work with that combination of things and to take advantage of the best of both managed cloud and Kubernetes.   And so I've seen a lot of folks, doing really interesting things combining those 2, and using those to kinda get the best of both worlds, for   managed services and and Kubernetes. Other things I think we've seen that are really interesting. 1 1 that 1 pattern that I, you know, am kind of excited about is,   a shift from infrastructure's code just as a, you know, tool for for, you you know, a human in the loop kind of tool where a user is gonna make a discrete change and validate that change and deploy it, to a model where we're actually building software systems that drive, these deployment processes as well. And so we work with a lot of companies,   and and teams that are actually provisioning,   you know, provisioning tenants, for example,   in their back end for their customers or for internal teams in the organization,   and they're doing that through automated processes. It's not like a human is going and saying, oh, I'm gonna go and, provision this tenant or update this tenant. They actually have automation that's driving a lot of that. And so that that requires a much more reliable   tool chain around how we do these infrastructure deployments to be able to to do that. But we're seeing that as software engineers are taking over and as the complexity is becoming higher here, and they're really looking as well for how do I turn this from a human process into a automated process at even another level. And so Pulumi is fitting really well into those kind of patterns, and I've been excited to see some of the successes we've seen there. What are the cases when Pulumi is the wrong choice and somebody might be better served by either a different infrastructure as code tool or just avoiding that overall approach and design pattern in general? Yeah. So I think, you know, Pulumi, probably does try to make, a lot of things easier. But I'd say, you you know, if you only have a small number of resources or if, you know, if you're just managing a VM and you're primarily gonna be doing, you know, kind of, SaltStack or Chef or Puppet or something for your provisioning.  

Pulumi could well be overkill. Right? You might not need,   to sort of do some of the taming or complexity. You might not need to bring some of these software you're doing practices.   You might honestly be fine pointing and clicking in a console for for a small number of resources.   Or if you're using just you know, if you're gonna be using Elastic Beanstalk, for example, and you just wanna click a button,   to kinda stand up your Beanstalk instance, and now you're gonna work with with their customized tooling for their platform as a service   offering, you may not need Pulumi to to stand that up. The the incremental value around that may not, may may not be as significant. But we see as folks as folks sort of the complexity of their the cloud infrastructure goes beyond tens of resources.  

They they're almost always gonna be looking for some subset of the things that Pulumi   kinda brings and helps with. And so so we think kind of as as they hit, a certain level of kind of cloud complexity, they're they're gonna they're gonna be looking for tools like Pulumi inevitably.  

[00:55:26] Unknown:

What do you have planned for the future of the Pulumi  

[00:55:30] Unknown:

tool chain and the business itself? Yes. I mean, we're really just getting started still. I mean, the the company's been around for for a few years, and, and we've been growing really quickly. But we see we still see an enormous amount of opportunity,   around the core Pulumi toolchain and also around expanding from sort of just the core kinda infrastructure's code tooling to   provide software engineering focused tools for more of the cloud, you know, cloud engineering   jobs. And so so we we have a lot more, we expect to do over the coming years, but we're really excited right now to just continue to be growing how how people are doing software engineering,   for,   cloud infrastructure. And, yeah, I think there's a lot of, specific things there. I think, you know, we're continuing to support more cloud platforms, continuing to support more languages, continuing to support more richness in the kind of high level libraries that we, expose to users so they can more easily work with a lot of these these,   newer and more complex modern technologies? And ultimately, just making it more fun and easy to deploy infrastructure, making it something that developers are gonna love   working with instead of something they're gonna fear working with. And so we put a lot of effort into just making the CLI user experience nice, making the documentation nice, you know, these sorts of things to to make sure that infrastructure can be a kind of lovable thing for developers.  



[00:56:39] Unknown:

Are there any other aspects of Pulumi itself or infrastructure as code in general or the benefits  

[00:56:46] Unknown:

and integrations of using full programming languages with this space that we didn't discuss that you'd like to cover before we close out the show? Yeah. I mean, I think there's there's so many fun fun topics near. 1 thing that we we kinda didn't discuss that I think is is sort of a interesting thing, as we move forward is also kind of the way that the the infrastructure deployments   and the application deployments end up getting,   potentially merged together. Today,   most teams really think about their infrastructure deployments and their application deployments as being 2 totally different sort of trains. When they make updates to their their they deploy those through 1 CI pipeline. And when they make, updates to their applications, they deliver those through another CI pipeline. And 1 of the things we're seeing increasingly is,   especially, again, around serverless and and containers and Kubernetes,   that there's a lot of different ways in which the   application code and the infrastructure runs on are getting more and more tightly kinda coupled. There's dependencies on a managed queuing service or a managed database or a managed, you know, dynamo table or managed cache. The application code really wants to tightly couple into its versioning. And so so we actually see a lot of interesting things happening around how those 2 are getting merged, and and the application delivery and the infrastructure delivery are kind of moving into a single unit in some places. I think that's a really interesting trend. It's something that Pulumi is kind of,  

[00:58:00] Unknown:

is being used for quite a lot relative to kind of where that trend is in the industry, but I'm I'm kind of excited to see where that trend goes as well. Well, for anybody who wants to follow along with you or get in touch or get involved with the project, I'll have you add your preferred contact information to the show notes. And so with that, we'll move us into the picks. And this week, I'm going to choose an app that I found for being able to catalog the different books that I have because it's something that I've had in mind for a while. And now that I'm spending a lot more time at home, I'm starting to get involved with that and it's just makes it very easy to be able to   scan the ISBN code of your books and add it to your virtual bookshelf so you can keep track of what you've got and categorize them. So I'll add a link to that in the show notes. It's just called bookshelf. And so with that, I'll pass it to you, Luke. Do you have any picks this week? Yo. Give a kind of random 1. It it's something I was looking at over the weekend that I thought was was really neat.  



[00:58:53] Unknown:

Just a little, service called go binaries,   dot com, and, you know, we we, Pulumi work a bit in the with Go. That's sort of the language we use for for building our CLI and that sort of thing.   And so Go binaries is the little tool built by, TJ,   that lets you just serve,   Go binaries from a simple,   HTTP endpoint. And so instead of you having to build installers and that sort of thing as a as somebody building little little applications or services, you could point folks at GoBinaries, then they'll do the the build for the the the user's platform and deliver it. And just a really beautiful, simple little service. I think it's a fun thing to to go look at the code if folks are interested in kind of seeing a little bit of Go code or little service. I just had a kinda fun, nice,  

[00:59:33] Unknown:

nice little piece of software that they that he built. And, actually, over the weekend, I kinda played with kinda reimplementing that just as a pure Pulumi thing, just to kind of play with some ideas there. And I think it's just a neat little example to look at. Well, thank you very much for taking the time today to join me and discuss your experience of building Pulumi and working in the infrastructure as code space. It's definitely something that is very challenging and complex and something that a lot more people are having to get involved with. So it's great to see more projects coming into the space. So I appreciate all your time and effort on that and I hope you enjoy the rest of your day. Likewise. Thank you very much for having me.   Thank you for listening. Don't forget to check out our other show, the Data Engineering Podcast at dataengineeringpodcast.com   for the latest on modern data management.  

And visit the site of pythonpodcast.com   to subscribe to the show, sign up for the mailing list, and read the show notes.   And if you've learned something or tried out a project from the show, then tell us about it. Email host at podcastinit.com   with your story.   To help other people find the show, please leave a review on Itunes and tell your friends and coworkers.