DOP 76: How to be a Cloud Engineer with Pulumi

Transcript

Joe: [00:00:00]
With Pulumi, it's easier because you have a full language. Now, of course, it's still complicated. Basically what I like to say is the easy things are easy and the hard things are possible and the hard things are possible in a first class way without having to resort to bash scripting or rewriting your YAML with some Python script that you wrote.

Darin:
This is DevOps Paradox episode number 76. How to be a Cloud Engineer with Pulumi.

Darin:
Welcome to DevOps Paradox. This is a podcast about random stuff in which we, Darin and Viktor, pretend we know what we're talking about. Most of the time, we mask our ignorance by putting the word DevOps everywhere we can, and mix it with random buzzwords like Kubernetes, serverless, CI/CD, team productivity, islands of happiness, and other fancy expressions that make it sound like we know what we're doing. Occasionally, we invite guests who do know something, but we do not do that often, since they might make us look incompetent. The truth is out there, and there is no way we are going to find it. PS: it's Darin reading this text and feeling embarrassed that Viktor made me do it. Here are your hosts, Darin Pope and Viktor Farcic.

Darin: [00:01:21]
So last week, Viktor, we were talking about what is code and we defined code as anything that can be interpreted by a machine.

Viktor: [00:01:33]
And instructing machine to do something just to exclude going to the database is also interpreted by machine, so that's excluded.

Darin: [00:01:44]
But one of the things we got into was not using programming languages to define state. Please forgive me if I'm telling it wrong, but correct what I just said there.

Viktor: [00:01:55]
I was arguing that I prefer declarative formats, whichever to define state of something and programming languages to define things when I want to control the flow. Right. Do this, then do that. And if this happens, then go to hell. That's a modern expression that says in Java, throw an error and see what happens.

Darin: [00:02:24]
So we figured we would bring on the other side of the argument. Today, we have Joe from Pulumi. Joe, welcome to the show.

Joe: [00:02:37]
Hey guys. Thanks for having me.

Darin: [00:02:41]
So, Joe, why don't you explain who you are and what Pulumi is.

Joe: [00:02:46]
Yeah. So my name is Joe Duffy. I founded Pulumi a little over three years ago. I wrote a lot of the initial code and now I'm CEO of the company. My background, I started with computers 20 something years ago, 25, something in that ballpark, but worked at Microsoft for a fair bit of time. I actually ran the programming languages organization there, helped build the early C# language, .NET framework, helped take it open source did a lot of, a lot of fun things there. But really with Pulumi came to, I think infrastructure with a little bit of a different perspective and background, which speaks to a lot of the conversation we were just having around, you know, using programming languages and developer platforms in a new way and bring that to infrastructure as code so that you get all the benefits of infrastructure as code, but all the great programmability, developer tools that we know and love from application development. So testing, refactoring, great IDE support, sharing and reuse, so you can actually share and reuse architectures using packages and components. And so that's what Pulumi is. It's an infrastructure as code platform. It's open source and we've got some great team and enterprise features in our SaaS product as well.

Darin: [00:03:53]
In full disclosure, I did a side project in mid to early 2019 and took advantage of the free side of things. And it was early on. It was a reasonably good experience. I am not, and I happened to use TypeScript. I think back then it was TypeScript and Python and I think Go was just coming out somewhere in that ballpark. I am not a TypeScript developer. I felt miserable writing that. It just wasn't, it wasn't natural and my fingers could not type those characters. But it got the job done and it was a heck of a lot better than writing CloudFormation.

Viktor: [00:04:36]
Hey. Wait, wait, wait. That's an unfair comparison. Everything is better than CloudFormation. I mean, Perl would be better than CloudFormation. XML as well.

Joe: [00:04:51]
We've come a long way since then. We now fully support Go. I think at the time Python, probably even though we supported it, it was still early days. Frankly, a lot of folks who are coming from the more declarative world, especially if they've worked with things like Chef, Puppet, Ansible, SaltStack in the past, will usually gravitate towards Python before TypeScript and even a lot of our TypeScript, you know, the Node.js users sometimes elect to use JavaScript instead of TypeScript. I mean, TypeScript is advanced in some ways, and in the sense that there's pretty advanced typing constructs that can feel foreign and unfamiliar that are frankly overkill in some cases, but you get generics and there's a lot of goodness there. I'd say Go, we've added C# support as well. So you can use any .NET language and to the declarative, I'm going to make an argument that even programming languages, all sit along a spectrum of declarative to imperative, and that you can actually use a real programming language and still get a fully declarative feel. So F#, for example, is a functional language, which taken to the extreme, something like Haskell has no side effects and so it is fully declarative. F# is a little bit more of a compromise. But I see it as a spectrum of possibilities rather than a binary, you know, this or that.

Darin: [00:06:02]
Now the one thing I do remember from the documentation is it was sort of bubbling up Terraform under the hood, especially that far back. And I haven't looked at it recently. Why were you calling out certain Terraform things? And it's, I mean, to me as somebody that was developing it at the time, it felt like you were just sort of not setting on top of Terraform, but you were being sort of Terraform compliant if you will.

Joe: [00:06:27]
If you look at the architecture of what Pulumi is, it's really at its heart is a cloud object model that's projected into many different languages. It's a many cloud, many language runtime at its heart. And so the way that the cloud interfaces work, that cloud object model, Pulumi has a notion of this in its engine and it just so happens there's a provider model and it's extensible, it's pluggable, and one sort of provider can be a Terraform provider. Basically we're just using the Terraform provider for the create, read, update, delete operations on different resource types. We did that in the early days because there are hundreds of Terraform providers and we saw that we were able to build this bridge and gain instant access to this entire ecosystem of great work that the whole community has put together. It's not just the Terraform developers themselves. It's a lot of cases, it's actually the community who's contributing to these. Even, you know, the Azure provider, for example, in Microsoft contributes a lot of great work into that. So we felt like we really wanted to build a bridge with the community and allow you to leverage all of that. So it helps if you're coming from Terraform, but it also gave us a lot more coverage on day one. I will say since then, we've added new native providers. So Kubernetes, for example, we were able to actually support 100% of the Kubernetes API by building that natively on Pulumi and using the OpenAPI specifications in Kubernetes itself. And by the time this airs, we will have launched the same thing for Azure as wellthat's based on basically the ARM API specifications allows us to get 100% surface area, basically with the push of a button so that we don't have to go manually implement all these crud operations. That's a very time consuming, error-prone, tedious process, frankly. And it means you can't get same day feature support when Azure ships something. The standard way of manually implementing it means you have to go implement every feature in that Terraform provider. Whereas our new provider, you just get full support immediately. And so that's the path we're going down in the future. I think the Terraform approach was really to get bootstrapped. The Terraform engine itself is not really in the picture. It's just the providers themselves.

Darin: [00:08:37]
So gentlemen, to your corners. Actually, come in from your corners. Let's have this debate about declarative versus imperative. Before we started recording Joe, you said that this is a question or statement or maybe sometimes argument that comes up. So Viktor, why don't you state it first, so there's a fresh statement from somebody that believes a certain way, and then Joe can defend.

Viktor: [00:09:10]
I mean, at least in my head, if I go to two extremes, I do prefer declarative way to define state of something and the other way around, you know, to write code, to define logic. Now, the real problem I believe is that those two extremes are rarely really happening. I rarely find myself in situation where I'm in either of the two extremes. Like, if I do Terraform, yes, big part of it will be declarative, but I eventually always end up doing hacks how to do an if statement. Like, for example, just this morning I was creating some definitions, which I had to actually also have the option through a variable to destroy stuff. So I had to put count with equals and then some strange syntax there to simulate if statement to get zero or some other value. Right. So I do feel still that I prefer declarative for state, but while at the same time acknowledging that it's not really a hundred percent in either side. That's that kind of trade offs I believe that we are all making, because as you mentioned before, yes, I can write code in some language that is somehow declarative, but it's not really, and I can write declarative statements that are somehow having logic, but are not really that either. Infrastructure is even the easiest example, right? If you go into build scripts, then I'm completely confused. I love Gradle, but then I hate it the next day and things like that. The real issue I think that it's that we are all in some gray area really. And it's more about whether you're more levitating towards left or right of that spectrum in a way.

Joe: [00:11:02]
I agree with a lot of that. I think the challenges, if you start from, take CloudFormation because we talked about that example earlier. It turns out CloudFormation has a domain specific language built into it. It's just encoded in YAML and JSON, right? There's the Fn::GetAtt or Fn::If for condition. And If you look at some complicated templates. For example, the one that's reference architecture for setting up a VPC in Amazon, it's four or 5,000 lines of JSON and you look at why that is the case. It's because there's no for loops. Conditionals are awkward. String concatenation is awkward. Everything beyond just what JSON and YAML were designed to do is awkward. Right? And so that's why you look at Helm. Helm kind of came at it and said, Hey, you know, why don't we just embed Go templates inside of YAML, then you have the full expressiveness of Go plus YAML. So it's like YAML by default and then you can inject logic where you need it. And I think Terraform is kind of going down that same path. Now there's quasi for loops and the conditional situation seems to be getting slightly better, but I still see people doing the count hacks, like you just mentioned and so we approached it and said, Hey, you know, we've seen a lot of these challenges before with programming languages. A lot of programming domains are declarative by nature and the fact that you can start declarative, especially in Python, you know, you look, and this is why I think you look at why Chef and Ruby were such a good match. It was a very declarative subset of Ruby that you start with, so it feels declarative, but then that second you need a for loop or that second you're sick of copy and pasting things all over the place, you can put it in a function or put it in a class. If you need to conditionalize and say, Hey, you know, my staging environment is different than my production environment, or maybe my production environment in Europe is different for GDPR reasons and so now I need some if branches in my code, it's better than having to copy and paste. We find a lot of people, even with Terraform, with some of the different constructs , having to copy and paste and maintain lots of different variants of the same configuration and that's a maintainability nightmare. That's a security problem waiting to happen. We basically said, Hey, let's take all this experience we've built up over the last many decades. Let's not try to go reinvent what a package manager is or let's just use all that stuff we know and love , but we'll basically marry that with a declarative model at its core. If we didn't have that latter part, I don't think it would work. Right. The Pulumi engine is fundamentally declarative in the sense that it understands the goal state. It can diff the goal state and so on. But I agree with you fully, that we're sort of in this gray area of, in between land. I think we just approach it from different starting points, maybe.

Viktor: [00:13:48]
Yeah, I was looking at, like Darin, it's been a while since I used Pulumi. And I looked at it recently and it's just what you said. I have a feeling that compared to what I think I remember from before, you're getting a bit more declarative while retaining all the benefits of the other side and yeah, it's similar to like all other tools. You kind of start from some point and then try to expand towards some middle ground, let's say.

Joe: [00:14:19]
Yeah, and I think we've worked with a lot of actual end users and that's helped us sort of stay grounded. We really listen to our customers in the community and kind of try to make them happy and that's really important to us. Also, what we're seeing is the more complicated the architecture, the more important some of these things become. You know, if you just set up handful of virtual machines and a RDS database, maybe it's fine that if you have some copy and paste, it's a little bit, it's not a lot. But once you're doing serverless functions, you're doing containers, you're doing an entire VPC set up with multi-AZ, potentially multiple regions, it starts to really break down and sort of the intersection between some of these technologies like Kubernetes and infrastructure as code, really starts to push the boundaries of what I think the DSL approach can really fundamentally handle.

Darin: [00:15:09]
One of the things you brought up in your newer versions or your current versions is your integration with Kube API. Why do you think that's important right now, other than the obvious everything's Kubernetes, right? What made you go down that path to where you went just beyond provisioning a cluster to the point to where you're now provisioning in the cluster.

Joe: [00:15:38]
Yeah, it's a great question. We sort of ended up there by working with the community. Here's a canonical example. Look at what it takes to just spin up a properly configured cluster even. Forget the workloads running in the cluster. Standing up a new EKS cluster in AWS for example, you provision the cluster, you often are having to configure inside the cluster itself, whether that's installing things on the nodes or configuring the worker pools then potentially you're going to do something around cert-manager or something around ingress. Maybe you're gonna install some CRDs. Maybe you're gonna install Prometheus because you want to use that instead of CloudWatch, or maybe you're going to take a Helm chart and use that to get Prometheus up and running. Then at the end of that, maybe you're going to go back and provision some additional AWS infrastructure. Maybe you're doing cert management using ACM instead. So what we find is a lot of people are trying to stitch together things like CloudFormation on one hand, and then writing a lot of bash scripting to do a delicate dance between CloudFormation and then go to kubectl and then do something with Helm and then go back to CloudFormation and then that sort of orchestration and then forget if you want to install Datadog on the nodes. Things get really complicated when you're stitching together dozens of different tools that were never meant to work together, each with its own authoring language, that is some YAML based thing, or maybe DSL, if you're using Terraform for some of that. What we're trying to do is really come in and say, Hey, we can handle all of that so that you don't have to dance between these different tools. We can handle the dependency tracking between the resources in Kubernetes and AWS, for example and it's one authoring language and by the way, you've got full history of everything that's been changed, down to the diffing on every single resource. Whereas in the previous model, if you're doing all this bash scripting, there's no ability to have a history audit log. There's no ability to apply policy. If you want to do policy as code, it's very difficult. It's obviously tedious, but it actually has these real world sort of quote, business impacts. And so that, that sort of pulled us that desire to be the one solution that can handle any infrastructure really forced us to think about integrating with the Kube API in a much more first-class way.

Viktor: [00:17:50]
I guess you're moving into managing applications, not only infrastructure, right?

Joe: [00:17:55]
I think that comes up with containers. It comes up with serverless. We find increasingly the application developer wants to do some infrastructure. Whether that's deploying to a private registry and then using that from a load balanced service inside Kubernetes or inside ECS Fargate. They might want to spin up some serverless functions. They may want to spin up a pub sub topic or even an RDS database. The infrastructure team often is okay with that provided there's kind of guard rails in place. Whether that's best practices in the form of packages or policy as code. That's what we're seeing now is it's really the developers plus the infrastructure teams and increasingly them working together is where we're seeing Pulumi be really a sweet spot. Developers can use the language they know and love. Infrastructure teams get a leg up compared to DSLs and really can help break down the walls between the two.

Viktor: [00:18:47]
You just said the magic word. Whatever makes operators and infrastructure and developers, throw in some testers over there, work together, then that's already a winner if you ask me.

Joe: [00:19:01]
Yep. I think that is the magic.

Viktor: [00:19:04]
Do you see the use cases where all the applications, for example, would be managed by Pulumi or a certain types of applications or.

Joe: [00:19:16]
Yeah, I think that the applications suited to using Pulumi are really those that are using cloud services in a first class way. I think of these managed data stores and data services like Redshift. I think of serverless for sure or Cosmos DB if you're an Azure or BigQuery on Google. These are all pieces of infrastructure that often you want to integrate closely with the application. Think of Firebase, for example. That really is part of the application in a meaningful way. Those sorts of things aren't the kind of things you just ignore while you're doing development and then add later. They have to be part of the development. That's how your application works. That's I think the sweet spot. There's still people that write a standard application and don't really think about the hosting environment. They don't think about observability. They don't think about service meshes. And so they can kind of put on their blinders a little bit still and not think about the cloud and then they can write all their code and then go talk to the infrastructure team and ask for a few virtual machines or whatever it is they need. For those it's maybe less relevant, but frankly we're seeing less and less of that and more of the first, definitely as people move to cloud native.

Viktor: [00:20:23]
What's your target infrastructure? Are we talking mostly about or exclusively about cloud or also on prem?

Joe: [00:20:33]
Yeah, both. I think public cloud. So we support the major public cloud providers. We have over 40 integrations now, everywhere from GitLab, MailChimp, CloudFlare. But we do support on prem as well. So vSphere and OpenStack and a lot of these others as well. So usually people picking Pulumi are doing it because they have a major cloud initiative. And so usually it starts with the public cloud, but the fact that we've got things that can work on prem and in a hybrid setting and really help connect them from where they are today, to where they're trying to get to is usually important. Speaking to my previous point of if you want one technology that works for everything, our customers don't want something that's completely different for on prem and public cloud, because they're trying to harmonize those two.

Viktor: [00:21:25]
Does it have some form of... is it always kind of from a server, from laptop or you have some form of agent that is pulling definitions from a Git repository maybe or something like that?

Joe: [00:21:41]
Yeah, we have a few different modes. The default when you download is that the state is being managed by the pulumi.com service and you're running your local client and all the authentication to your cloud providers happening locally. That's great from a security standpoint. You don't need to trust pulumi.com to talk on behalf of yourself to your cloud account, but Pulumi is doing all the state management. Basically the metadata associated with your cloud resources so you don't have to think, you know, in the Terraform case, you don't have to think about, Oh, where do I put the state file? How do I make sure I don't accidentally check in secrets? How do I make sure that I share it with my team correctly? So that's the default. You can use it fully offline if you want to store your state in S3 bucket, you can do that. So it's a client based architecture. It's not an agent base architecture. That said, we recently launched a Kubernetes operator that can run within cluster that gets triggered based on Git commits and things like that. Most people will start with the developer desktop, running everything locally, and then we have CICD integrations as well. So if you don't want to go to the fully full extreme of a Kubernetes operator, there's a middle ground.

Viktor: [00:22:46]
From your perspective, not in a way of trashing or really putting numbers of anything like that, but who are the players right now in, let's say infrastructure as code. I mean, obviously Pulumi, Terraform, cloud specific, like, uh, AWS, whatever. Is there anybody else? What's Puppet and Chef, is that still a thing? Ansible? Yeah.

Joe: [00:23:12]
Yeah, I would say we're more friends with Chef and Puppet than we are competitors. Chef and Puppet are great at what they do. Configuring the nodes, not really doing the provisioning. And so we actually integrate with those including Ansible and SaltStack. I think Terraform is the clear, obvious, competitor. I think the major cloud providers each have their own thing here. You know, Azure just launched Bicep, which is sort of an HCL like language for Azure. Obviously AWS has their CDK. Sort of similar to Pulumi. It's fundamentally different in its execution model and how it works at its core, but surface syntax looks very similar. Then I think there's the major folks who we partner with. You look at VMware kind of Rancher. They're really trying to make a lot more of the infrastructure experience more turnkey, and so that you don't need the full flexibility of say an infrastructure as code platform if really all you need to do is configure and provision Kubernetes clusters, for example, and don't want to go beyond that. A lot of people are using Pulumi to do that, just job itself and connecting it to surrounding infrastructure. They can handle a subset of it. Again, once you go beyond just standing up a cluster, like the more interesting things are connecting it to all the surrounding infrastructure, I think. I'm biased, obviously.

Viktor: [00:24:25]
Yeah, more interesting part is the part that is not the typical Hello World example. Like, here's a Kubernetes cluster. Look how easy it is. I can do that with a bash script just as well type of stuff, right?

Joe: [00:24:39]
Yeah, that is honestly, the other part of having code that I think is really exciting is it's simple on day one. So yeah, it's easy to spin up a Kubernetes cluster because we have a package that gives you a Kubernetes cluster. But then on day two and beyond when you need to do the complicated things, when you want to do blue-green deployments or canaries that integrate with Prometheus to do gradual rollouts of workloads or insert your favorite complicated thing, like zero downtime deployments with Kubernetes. I challenge you to upgrade your control plane version number in EKS without suffering downtime. But with Pulumi, it's easier because you have a full language. Now, of course, it's still complicated. Basically what I like to say is the easy things are easy and the hard things are possible and the hard things are possible in a first class way without having to resort to bash scripting or rewriting your YAML with some Python script that you wrote, which we see all the time, or even we even saw somebody recently it was rewriting HCL on the fly with Python because they don't have conditionals. So what do they do? They write their conditionals in Python to generate HCL. So I think it's really that's where the programming language starts to shine is these complicated real-world environments. And let me tell you every real world environment gets complicated eventually.

Viktor: [00:25:58]
That's true. Oh, that's that that is indeed true. Does it get complicated for good reason or, I mean, because in practice, I know it does, but is it for a good reason or because simply we start throwing trash into it?

Joe: [00:26:14]
Well, I think there's non-essential complexity in a lot of what we're doing, even on day one these days. And I think Kubernetes is definitely complicated. Early, when we were starting on Pulumi back when we were starting, it was still, Oh, who's gonna, who's gonna win the container orchestrator wars? Is going to be Mesos, Kubernetes, or Docker Swarm? Right? And I remember, uh, For the record. I, I always loved Docker Swarm because it was simple, but I always knew Kubernetes was going to win in the end because anything that comes out of Google with that amount of research behind it, it's just gotta be, have something going for it and I have a lot of friends at Google, so I trust that what they're doing.

Viktor: [00:26:54]
I had exactly the same feeling and I was kind of, yeah, Kubernetes is going to win, but I really want to cheer for Swarm. I still cannot, cannot get over it that we went from something so simple and user friendly into something so complicated. Let me state from the beginning, Kubernetes is awesome. What Kubernetes does, nothing else can do. But the part I don't like about Kubernetes is that we are moving, we hit the period of moving, let's say moving things towards being simpler so that people who are not selected five in a company can actually understand what's going on. And now we are back into that silos type of mode because there are on average five people in the company who really understand what the heck is going on in Kubernetes.

Joe: [00:27:48]
Yeah. And so, you know, I look back then, we approached it so naive. We said, I've got a containerized application. I'm going to run it in the cloud. What do I do? Okay. Step one provision an etcd cluster. Step two, create some worker nodes, have them join the etcd cluster. Set up Kubernetes on them. Step three, configure a private container registry. Build and publish to that and make sure you've figured out how to connect that to your Kubernetes cluster so you can pull the images. Many days later, and all I want to do is run a container. And thankfully in the last few years, we've gotten much closer to that vision, but still to this day, you know, the essential complexity or I'm sorry, non essential complexity of things that you have to do is still so high. To your point, some of the complexity I think is self inflicted. Some of it is just, Hey, Kubernetes is fundamental infrastructure that's going to get better over time and we're still very, very early days.

Viktor: [00:28:46]
The part I don't agree with you is when you said that right now, we, we got into less complexity and I really don't agree with that. I mean, less complexity for the same things we were doing three years ago? Yes. But now kind of now we've got service mesh, right? Kind of we got this and we got that. So the number of things keep increasing without any reasonable from my perspective, a way to decrease the complexity, assuming that you're following all of new stuff that is coming on, right.

Joe: [00:29:23]
Yeah.erv The funny thing is when I was at Microsoft, one of the projects I worked on was a distributed operating system. And from the distributed operating system, we approached it top down. We said, How is the developer going to write a distributed application and let's make that as easy as possible. And yeah, there's RPC, there's service discovery. There's all these things that are necessary. But when you approach it from top down, you try to make it as ergonomic and user friendly as possible. We're basically rebuilding something very similar from the bottom up. We're like, Oh, we've got a container orchestrator. Oh, we've got a service mesh. Oh, we've got all these pieces that have to integrate when the poor, you know, application developers, just trying to build an application that works. And now there's like all of these pieces to worry about. This is why I'm really excited about infrastructure teams and developers meeting in the middle with Pulumi because I think we'll end up with a much better programming model for the cloud when the dust settles, but you're absolutely right. We're nowhere even close to where we need to get to.

Darin: [00:30:23]
You told one of the horror stories of the guy that was writing Python to mutate his HCL. Let's ignore that ever happened. What's a good story. Like what has been one of your shining, you know, somebody came back. It's like, look, we could have done this, but because we used Pulumi, this was much easier. What's one of the, the happy stories?

Joe: [00:30:50]
Yeah, so a customer that we just worked with recently, Snowflake, who just went public a few weeks ago when this airs, which was a great success stor y. They had come to us and they , as many software teams had, was sort of a top down directive to ship a new product on a unrealistic timeline. I mean it was aggressive. It was not unrealistic. But with Pulumi it became realistic. What they were looking at was, Hey, we're building a cloud platform, right? Snowflake is integrated with the cloud in a very fundamental way. They're providing infrastructure and by using Pulumi they were able to empower their developers to really leverage the cloud and the architecture of the application. And they were able to have their infrastructure team really adopt Kubernetes at global scale and manage that complexity. It's not just about standing up Kubernetes infrastructure on day one, but having something manageable that can scale to very, very large scale in the future. We were able to work with them to set up the cloud resources, to set up the Kubernetes clusters, to set up the workloads in the clusters and all this came together and frankly, it was sort of record time from my perspective for such a complicated project. That was a great success story and a great partnership. We've got a few other cases like that. This is one that's a public case study that we're publishing and so that's the one that came to mind.

Darin: [00:32:12]
and you're talking about partnerships. Now at the time this episode is releasing, which this is October 7th, if you're listening on the release date, you have a conference you're doing. What's the conference about? Tell us the name, tell us the details.

Joe: [00:32:29]
We're calling this the Cloud Engineering Summit, and this is multiple days of cloud engineering practitioners and leaders. It's coming together to share best practices across what we're calling cloud engineering. And, you know, I've alluded to infrastructure teams and developers working closely together. We wanted to come up with a term that is inclusive of both sides of the organization. Inclusive of folks who have been practicing DevOps for the last 10 years, infrastructure engineers, security engineers , but also developers. We know that a lot of developers are now doing infrastructure. And so we're calling this Cloud Engineering. It's the intersection of infrastructure and application development, really using cloud native architectures. We have a few tracks. We've got an architecture track, policy for security best practices. We have a few panels. Pulumi sponsoring it. Pulumi is putting it on, but it's really an industry conference. Aside from me kicking off the keynote, we don't actually have any Pulumi talks for the entire conference and so trying to really just build this community. We really have loved the DevOps community. We've really felt welcomed into that community. Some of our best community contributions and community members come from that community. So we really want to see this as an extension of what's already come before, but really bringing more developers into the fold as well and so that's an explicit goal. So this is an annual thing. This is our first one. I think it's gonna be super exciting. We have an amazing set of speakers and it's free to attend as well. So definitely check it out. cloudengineeringsummit.com.

Darin: [00:33:55]
There you go. We'll have that link down in the show notes for today. Also, I want to restate back one thing that you said. You sort of glossed over it and you restated it, but I'm going to say it one more time. With Pulumi, easy things are easy, but the hard things are possible. That's a great marketing line. Whoever wrote that for you needs to be paid triple. Did you write it?

Joe: [00:34:21]
Actually, this is a phrase, my cofounder, Eric, I worked with him. He was at Microsoft for 20 something years and I worked with him on and off. He actually created .NET and Visual Studio and he's a fan of using that over and over again. So I think over the course of 10, 15 years or so, it was kind of drilled into me, but I love it as well.

Darin: [00:34:41]
It sums it up. Right? That's that's where it's at. So all of Joe's information is going to be down in the show notes. And again, cloudengineering summit.com. That's starting on October 7th. And it's just the 7th and 8th, correct?

Joe: [00:34:56]
That's right.

Darin: [00:34:57]
Okay. Just two days. Uh, so go sign up for that. If you're listening to this on Wednesday, go sign up for it now. Tell your boss, Hey, um, I'm going to a conference today. I'll talk to you later, right? That's that's what you need to do. Joe, anything else you'd like to say today?

Joe: [00:35:14]
No, I mean, just Pulumi is open source and so definitely check it out. The community is growing quite, quite significantly. We've got a community Slack, slack.pulumi.com where we've got many thousands of people actually. So not just about Pulumi. I think that we're really trying to build a community that shares best practices and helps each other. So there's an AWS channel. There's a Kubernetes channel. Azure channel, a Python channel if you have more affinity to languages than you do particular clouds. And so come see us there. The whole team's there. Definitely check it out. We'd love to know what you think and everybody's welcome.

Darin: [00:35:51]
And one more thing, if you're wanting to try this out as a end-user, there is a community edition that's completely free. $0. And if you've got teams, you can pay for it and other things. But again, my history was over 12 months ago. Sounds like it's gotten a lot better. I probably need to revisit, which means Viktor do we need to roll this into catalog?

Viktor: [00:36:13]
Uh, this will be the one on you

Darin: [00:36:18]
Oh, it is Maybe it won't be in catalog for a little bit of time. Maybe it will. I don't know. Yeah. Coward. That sounds pretty pretty about right. Okay. Thanks Joe. For joining us today. Hopefully we'll have you back soon.

Joe: [00:36:35]
Yeah, I had a great time. I'd love to come back anytime. Thanks guys.

Darin:
We hope this episode was helpful to you. If you want to discuss it or ask a question, please reach out to us. Our contact information and the link to the Slack workspace are at https://www.devopsparadox.com/ contact. If you subscribe through Apple Podcasts, be sure to leave us a review there. That helps other people discover this podcast. Go sign up right now at https://www.devopsparadox.com/ to receive an email whenever we drop the latest episode. Thank you for listening to DevOps Paradox.

DOP 76: How to Be a Cloud Engineer With Pulumi

Show Notes

Links from the episode

Guests

Joe Duffy

Hosts

Darin Pope

Viktor Farcic

Links

Rate, Review, & Subscribe on Apple Podcasts

Signup to receive an email when new content is released

Transcript