Transcript
Nwodo: I'm going to be talking about my story and how Python empowered my infrastructure beyond YAML. I used to be a full stack software developer. I used to be a software engineer. I used to work at Microsoft. When I joined in 2019, I was working in the Microsoft Mesh mixed reality, the team of the people building the Metaverse, so I was more in my Unity, C#, a little bit of C++. I only knew what I needed to know about cloud engineering because we used to automate deployments anyway. One thing led to another and I found Pulumi. How I found Pulumi was, there were a lot more people working on the device things at the time, I was writing code for the HoloLens. I wanted to try something new, because you hear people sitting right beside you, and you're hearing them talk about ARM and Azure, things are just flying over your head. You're like, ok, this seems interesting. I remember that at the time, we were trying to switch from ARM templates to using Pulumi. One of the first infrastructure engineering or cloud engineering tasks I ever got, was to turn a bunch of our ARM infra into Pulumi related infra so that we could move from ARM to Pulumi, sort of do that migration. Obviously, before that, anything that was ARM related, wasn't necessarily my business, because I wasn't considered a cloud or a DevOps or an infra person. I wanted to build stuff for the HoloLens. I wanted to write C++, and then I wanted to just go home after that. Writing Pulumi made me realize that I could still do everything that I wanted to do, which is write code, because I love writing code. I still love writing code today. I could also manage infra while doing it. It was a very easy way for me, who was a full stack developer at that time. I had done things on Android. I was building apps for the HoloLens. I had built full stack web apps, and different things, and now coming into the cloud, it was a lot easy for me to get into that, because Pulumi made it easy. It greatly impacted my workflow, and I could manage my infra while I was writing code.
I was a bit younger at the time. This was in 2019, early 2020. I became very eager to learn about cloud engineering principles, because when you're trying to use a tool like Pulumi to provision your infrastructure, you would get into some errors, because Pulumi bridges that gap between the cloud engineer and the cloud infrastructure and all of that stuff. It puts you as a software engineer in the middle. Things that I wouldn't have known as a software engineer prior to that moment, I found myself learning about them. I found myself being on the Azure portal, pay more attention to different kinds of infrastructures. Prior to that time, I knew of VMWare and I knew how to put things and just run my application, but I didn't really care about distributed engineering systems, building stuff at scale, infrastructure engineering, and things like that. This opened my eyes to other cloud engineering principles. My perspective on cloud infrastructure engineering actually changed. I became that person that started evangelizing about the cloud, if you call it that. I had to author two books on cloud engineering, because I was learning more about the cloud. I found it more interesting. I decided to tell the world that there's this beautiful thing called cloud engineering or infrastructure engineering that you should pay attention to. Over time, I became the team's subject matter expert on Infrastructure as Code, IaC, our team infra. This actually got me three promotions in the last 4 years. I quit my job at Microsoft a few months ago, right after my third promotion, but this was between the space of 2019 and 2023. I cannot tell my cloud story without talking about how Pulumi was a very huge part of that story. I'm here to show you how Pulumi works, and why you should love it as much as I do.
My name is Adora. I am now a senior software engineer currently working on cloud infrastructure and developer platforms. I am an award-winning tech woman recognized in different continents in different parts of the world. I speak at different conferences. I am a multi-published author. I consider myself an ecosystem advocate, especially where I'm coming from, which is Lagos, Nigeria, because I try to advocate for tech in that region, and someone nicknamed me an ecosystem advocate, and I liked the name. I love tech, community, education, and music.
The Rapid Growth of Cloud Innovation
Cloud innovation is rapidly growing, and managing resources have gotten more complex over time. We see this a lot today. You hear things flying over your head, observability, metrics, Docker, no-shared, Kubernetes, and all these things. We are building a lot more on the cloud than we've ever done before. COVID contributed to this. Everyone is moving their business to the internet. Everybody is doing some kind of innovation on the cloud. Everybody is doing something as a service, one way or another. Building things have gotten more complex over time. If, in 2003, it was easy to do FTP uploads to your server, and in 2015, it was easy to do manual configurations on your cloud portal, it doesn't cut it anymore, for different reasons. Your deployments are slower as your infrastructure gets bigger, because it is human beings, team members that are doing these things over time, especially when you're trying to replicate multiple environments. There are larger risks of errors because as human beings, we can make mistakes. As we make these mistakes, we can replicate these mistakes in the different environments where we are supposed to be running our cloud applications. That can become problematic quickly.
Everyone relies on the documentation. If there's documentation for the application that you are supposed to be provisioning, and you have documentation or configurations for your infrastructure, and somebody mistakenly doesn't update that documentation, nobody knows that the documentation is not updated. Somehow everyone is stuck. If you have to roll back for whatever reason, it requires manual work as well, which can be tasking. Let's not even start talking about configuration drift, and how terrible configuration drift can be. I'll tell you what happens with configuration drift.
Let's look at these three different environments right now, we have dev, we have staging, and we have production. In an ideal world, not always 100% the case because your production environment should be more resilient than all these other environments that you're using to test. For the sake of this example, you have your dev, your staging, and your production that somewhat mirror each other. If you are doing CI/CD, you deploy to your development first, then you go to staging, and you would go to your many production environments. In this presentation, we have just one to show. Over time, what happens is that people fix things. Let's say something happens and you check your monitoring and you realize that something is happening in prod, I need to fix it quickly. You go into your Azure portal, you go into the subscription or the AWS dashboard, AWS environment, you go and you fix what you're supposed to fix, but you don't actually document or notify where you've changed what you've changed. Somehow you forget about it and you move on because it was a small change. Your production and your staging and your development no longer mirror each other, which can be problematic, because if you try to test something in staging, and you assume that because it works in staging, it would work in production, and you actually push, you're in trouble somewhat.
Let's talk about how we can fix this problem. There's something called Infrastructure as Code. This fixes these problems for us. There are lots of Infrastructure as Code tools. One of the reasons why I'm talking about the tool I'm talking about, is because of its ability to allow you transfer your programming skills into your cloud career, if at all you want to build one. Infrastructure as Code helps you specify your configurations in code, automate your infrastructure deployments. You can treat your infra declarations the way you would treat code, so you can test, you can version, and you can roll back your infrastructure, and transferable skills from programming. What this means is that if you write C# or TypeScript or Go or Python, you can write your infrastructure declarations using these languages. That's why I'm talking to you about Pulumi, because Pulumi is the open source Infrastructure as Code platform that allows you to write your infra declarations in these different languages. If you know Python already, you don't have to use YAML to do infra. Even though Pulumi allows you do YAML now, but there are other languages, if you know Python, you can stick to your Python. The amazing thing is that it allows you be full stack completely. Let's say you are a TypeScript developer, you use Node.js in your backend, you write with either Sails or Express or any of all these JavaScript platforms that exist, or TypeScript platforms that exist, and you use Vue.js normally, you could actually have TypeScript be that language that you use full stack. When I say full stack, I mean for your frontend, for your backend, for your cloud infra, and for your cloud security declarations. For your frontend and your backend, we know that TypeScript already does this for us. Now for your cloud and for your cloud security declarations, Pulumi is helping us do this with Infrastructure as Code and Policy as Code. These are some of the languages that Pulumi offers here: TypeScript, Python, Go, C#, Java, and YAML.
Demo (Code)
I have code in a GitHub repo, but I'd like to do a demo. I'm going to switch to my terminal now just so that everyone can see how this works. I'll show you Pulumi in action. I'm trying to do an easy login just so that I can log into the Azure portal, which I have done. I want to make a new directory, let's call it test-pulumi. I also want to cd into my test-pulumi directory. I have installed the Pulumi SDK and I have Pulumi CLI already, so I will just go ahead to do a pulumi new. Typically, you'd have to install Pulumi and set it up. I think the Pulumi documentation is so straightforward that you can literally go to pulumi.com and have all of these things set up in like 5 minutes. I'm going to do a pulumi new. I'm trying to deploy a serverless app, so I want to have a new serverless Python code base that I can deploy to Azure. I'm just going to hit pulumi new just so that I can also show you the different things that Pulumi can give us, like the different samples that Pulumi has. I'm just going up to serverless-azure-python because that's the one that I actually need. As we can see here, there's a lot, serverless-azure-python, TypeScript, YAML, GCP as well. There's stuff on Redis and different things. I'm going to do serverless-azure-python. My name can be test-pulumi. This is fine. I can leave my stack as dev. You can consider a stack like a project. Your stacks can be your different environments. You can have a stack for dev. You can have a stack for staging, for production, and things like that. I'm just going to provision a dev stack because I want to show this pretty quickly. I've set my location as well. My app has all of the things needed to bootstrap this for me. It's going ahead to create the virtual environment and building up my sample for me. Then, once it's done, I would show you what it looks like. Now it's done.
I'm trying to get my VS Code here. I want to open this folder. It's in my home folder. I need to go to my home folder. I just want to show you what's actually inside. This is the project that Pulumi just created. It has pulumi.dev.yaml, which signifies what my Pulumi stack is. These are configurations for my dev environment. It has a pulumi.yaml, which shows that it is a Pulumi project. Every Pulumi project has a pulumi.yaml, the same way every Node.js project has a package.json. I have my www folder, which is the web app that I want to deploy, the static web app. Then I also have my serverless function, which is in my app folder. I have a data function that just returns the time, basically. This is the sample project that Pulumi has gone to bootstrap for me. If I look at this main__.py in the root directory, this is all Python code. This is me writing Python to declare my infra. This is me writing Python to create a resource group, Python to create a storage account, a static website. This is Python for creating a resource group, a storage account, a blob container, and the different things that I need, a web app as well. I'm going to deploy that function up into an Azure serverless infrastructure, an Azure Function. I'll show you everything in a bit. I want to change this name to my-resource-group, so that we can find it in Azure.
I'm going back to my terminal now, and I'm going to run pulumi up. I've logged into Azure already. I came out, so test-pulumi, I'm going back in. I'm going to run, pulumi up. First of all, it's going to preview all of my changes. It's going to say, these are all the things that you want to create. Do you want to go ahead? I'm just going to say yes, and Pulumi is going to create all of those things. It would interact with the Azure Resource Manager, and all of these resources will get provisioned in Azure. If I go to the Azure portal, that is linked to my Pulumi account, I'll be able to see all of these things when I am done creating them. Another thing that I want to highlight while all of this is going on is about Pulumi state. Pulumi has an inbuilt way of managing state. If I create all of these infrastructure things, I don't need to go to the Azure portal to manually delete them if I want to replace or do something. If I remove that block of code from my code, Pulumi knows exactly to take out that piece of infrastructure away for me. Now that we're done, I, first of all, want to click on this site. I want to click on this site which is the frontend site, the static website, so that we can see that we have it, and Pulumi has provisioned that for us. Yes, it's asking, what time is it? Let's ask the cloud. If I say, ok, fine, let's ask the cloud. It says 6:59, because my computer is in BST. The cloud says that it's 6:59 p.m. Let's say I want to add a new infrastructure, or let's go back into the code. Let's say for whatever reason, I don't care about the static website so I want to take it out. I can come here and delete it. I want to show you what happens when I try to run another pulumi up. I can come here and delete this. Let me check if it's referencing it anyway, so it doesn't cry to me. I can just write anything here, just so that it doesn't cry to me. Hopefully, that works. I came and I removed the static website. It's going to ask me for a valid storage account name. I might not run it all the way to the end, but I removed something. Now let's go back into the terminal. If I attempt to run pulumi up again, it's going to tell me that, this is something you want to delete. You want to replace some things. Do you want to go ahead or not? I can choose to continue or not. Now let me also just leave this place and show you the Azure portal that has these resources that we provisioned initially. We called it my-resource-group. I'll go here to look for my-resource-group. This was the resource group that we created. Here, we have a storage account, we have a function app, and we have an app service plan. If we want to add other infrastructure like Azure Front Door, we can come and do this here. If we want to add availability tests, App Insights, Key Vault, we can do it through Pulumi, and we can do it while writing code.
There's documentation to help you if you want to do this. I also have a small thing that I wrote in the GitHub repo that I talked about. You can go into that. This repo here has more stuff. The README is also really good in case you want to set up the repo and try it out for yourself. You can download the Pulumi SDK and set it up. If you don't want to use the Pulumi cloud for storing all of your Pulumi state, you can store it in your own storage account as well for free. If you're using Azure, you can store it in the Azure storage account. If you are using AWS, you can store it in S3, you don't have to integrate with Pulumi, or pay for Pulumi cloud if you're just trying this on for yourself for the first time. This is the link to the repo, https://github.com/AdoraNwodo/pulumi-adventures.
Questions and Answers
Participant 1: You started off not as an infrastructure engineer and learned to become an infrastructure engineer. How long did that journey take? Because there's a lot of people who find it quite scary when they're application developer and trying to move, many people trying to avoid understanding infrastructure for a long time. It's really difficult. I'm really interested in that.
Nwodo: I think it depends on who I'm talking to. I'm still on the journey, because I'm still learning about the cloud every day. I would also tell you that the journey took one PR, so it depends on how you look at it. I opened my first PR, where I was switching from ARM to Pulumi. What happened was, it was a stateless service, so it was very good for an experiment. What I did was the same infra that we had, replicated that same infra in Pulumi, and checked in the PR and told everybody like, are we really doing this or not? From that point, was when I started digging deeper and learning more. You fix some things. You break more things. You learn along the way. I wouldn't call myself there yet. I think I'm still learning. It's a journey because things evolve all the time. At least now, I think I'm confident enough to stand up and actually talk to some people about some things even if I am a bit nervous, I can still do it. Short answer or realistic answer, I don't think it takes that long if you already have prior understanding of how computers work, and if you're a backend engineer, for example, because I believe that most of all these skills are transferable. If you are writing Python or JavaScript or Go, you've probably had to deal with VMs at some point. You've had to deal with integrating with databases at some point. You've had to maybe find a way to deal with managing traffic and a bunch of all these things. Even if theoretically, you might have that idea, but you've just never had to do it in the infra context before. Pulumi allows you to now find a way to bring those things together, your theoretical knowledge, your programming knowledge, and actually see what you can do. It doesn't take that much time. I think that's one of the reasons why. It took 2019 to 2023.
Participant 2: I'm wondering if you could tell us a little bit more about the process of migrating from ARM templates towards Pulumi? Did you guys use tooling, automation, or did you do everything by hand? What did it look like?
Nwodo: Migrating from ARM to Pulumi, at that time? Number one, it was a stateless service. Number two, I started with the smallest service just because I didn't want to get fired. Everything, the first time, was me doing it manually, to find like, this is what it is in ARM, and this is what the equivalent is in Pulumi. You would read JSON, you would read the Pulumi script and you just know exactly what everything goes, and how it's supposed to go. It was straightforward. There are ways that you can migrate as well, and this is something that Pulumi does for you as well. You can import all of your infrastructure into the CLI. There are ways to migrate from ARM, from Terraform, from other things that you've been using into Pulumi. Pulumi gives you different tools to aid your migration.
Participant 3: I would like to know, what's your ideal use cases for doing migration? Or you have projects for maybe reading projects in the wild, like you won't migrate, but is there really other use cases for these?
Nwodo: It depends on your team, and what your team is optimizing for at the end of the day. One of the biggest selling points for Pulumi, for me, is transferable skills. Especially for smaller things that are just like, these are the engineers building these services, and this is all they're doing, and we have a few DevOps people, or we don't really have so many DevOps people. These skills are transferable. If your software engineers were writing Python or TypeScript in their day-to-day, and they had to do infrastructure automation, you probably wouldn't have to do much to get them up to speed to do infrastructure automation, and infrastructure engineering, and things like that. If you didn't want to hire somebody else, you also wouldn't have to. That's the one selling point for me. The other selling point for me is the era of Infrastructure as Software. When we think about Infrastructure as Software, Infrastructure as Code, how platform engineering is becoming a very big buzzword topic in different cloud communities that you join, and things like that. Pulumi takes you one step closer into building these self-service developer platforms for your teams as well, because you are coding and you're using programming languages to create your infrastructure, whether you're doing it within the Pulumi CLI, or you're doing it within something called the Pulumi Automation API, where you can even call Pulumi's API in your regular backend code to provision infrastructure for you. Apart from the cost perspective that I talked about, there's also an industry trend bit to it when we think about platform engineering and where the cloud industry generally is going.
Participant 4: My question is about, so current trends to operate infrastructure, and I have a secret [inaudible 00:34:55] in Pulumi, like integrated with other secret vaults to be able to keep the secret in, or not being in a vault.
Nwodo: Pulumi does secrets management in different ways. Pulumi has encryption built-in. If you wanted to build a chatbot, and you want to use OpenAI's API, because that's just what you want to do. You can take your OpenAI token and put it in your Pulumi state, the pulumi.dev.yaml file that I showed you, your Pulumi config file, and Pulumi can encrypt that secret for you. However, if you are not very sure about doing that with Pulumi, and you want to do it yourself, Pulumi has ways to manage these different vaults. Pulumi is integrated with these resource managers for these different cloud platforms. What this means is that you can use Pulumi to create a vault and store a secret, in like a Key Vault, for example. You can use Pulumi to create the Key Vault, store the secret in that Key Vault and get the reference to that secret. Then you can put it maybe inside your configuration for your app, or you can put it in your serverless app settings as well, depending on where you want to put it. Pulumi does encryption in its own thing. Pulumi also integrates with all these other cloud platforms, and you can manage your secrets using Pulumi within those platforms.
Participant 5: I don't have enough knowledge to do Infrastructure as Code as much. Then looking at this app, does this enable us to have everything in a single vehicle, even the infrastructure part of it as well? The second part, like the Pulumi setup, all that, is that more towards a CI/CD tool, that's where you have that setup going, which would actually then allow us to do the deployment, all that?
Nwodo: Yes, you can have your Pulumi stuff in the same repo as your source code. Different people do that. I've seen people that like to have their infra for all their different services in one repo, and they manage it there, and they have their source code in different repos. That's one of the reasons why you can treat your infrastructure declarations the way you treat code. It depends on how you've decided that you want your architecture to be. It depends on how you've decided that you want not just the technical architecture, but the workflows, how your team should manage things. Do you want to put it in the same repo? It's possible. Do you want to put it in a different repo, and just connect both of them together through Azure, or through those deployments, or things like that? It's also possible. That depends on you and your team.
The second thing is about CI/CD. With Pulumi, you can hook it up with all these other different CI/CD platforms. If you are doing GitHub Actions, or Azure DevOps, or TeamCity. If you are doing that, you can hook it up with these different CI/CD pipelines as well. You can write YAML, and then put these different Bash scripts in those YAML commands to run pulumi up for you. Or you can write PowerShell. There are different ways that you can integrate the Pulumi ecosystem into your CI/CD pipeline, and it works.
Participant 6: We have a platform engineering team, and have been working through trying to figure out who to do CDK, who to do Pulumi, what do we do? One of the concerns that the team has is, how do we get all of these federated teams that are now writing Pulumi to stay up on the latest version of the code base? They're writing their own classes for infrastructure, and AWS, or Google, or Azure is updating theirs. How do we keep that running for that at all?
Nwodo: Are you asking about Azure, AWS, GCP's updates for their SDKs and how you manage that with Pulumi?
Participant 6: If all these teams are writing classes that use Pulumi to create their infrastructure, and those base classes suddenly change, how do you keep them up to date to make sure that they're writing against the latest, for example?
Nwodo: That's an interesting software engineering problem that has now become an infrastructure engineering problem. The same way you would think about it as a software engineering problem, it's how you would also solve it in the context of infra. You might want to decide that you don't necessarily want to be tethered to the latest version, because of breaking changes, unless you have to. If that time comes when you know there's a new version in Azure, or AWS for XYZ, they've added something into lambda, so now we want to move from this to this, you can migrate that whole team. You don't have to if you don't want to. You can create these things where you are wired to a particular version, and you know that this version is what we are using, just so that we don't create problems for ourselves, or get into breaking changes. If we have to move because something is deprecated, or there's something new that we need that we don't have access to in these old versions, then we can now think of a migration plan that works for us, slowly. I wouldn't even advise you to always want to be at the new version, unless you have to.
Participant 7: How do you compare Pulumi with other Infrastructure as Code products like Ansible, or Chef.
Nwodo: When I think of Ansible or Chef, I think configuration management, not necessarily Infrastructure as Code. Yes, you can also use them to do IaC, but they're more configuration management tools in the context of your cloud infra, Kubernetes, and things like that. Pulumi is a tool that is allowing you to provision your infrastructure. If you go through Pulumi registry, there are different providers, even beyond the AWS, GCP, Azure, that I've been talking about, there's Digital Ocean. You can even do things, and if you are a frontend developer, you have a frontend team, you can provision to tools like Vercel, using Pulumi. You can write these provisioning scripts or these provisioning declarations in programming languages that the engineers on your team use every day. That's the spotlight. That's the main difference for me. That's what differentiates it from everything else is the fact that you can use Pulumi as a tool to treat DevOps or infrastructure engineering, like software engineering.
Participant 8: I see how it's a jump over something like Terraform. The pattern is similar, but you got all this proactive power of a programming language. I'm curious, the demo you have to show a simple example. How does it look when you scale up to these Pulumi applications? I'm thinking both from how to culture and a technical perspective, because then it becomes a complex piece of software, and all of a sudden you have to test it. I think our DevOps people they're not natural software designers, like I would expect to see, yes, this is great, but some people, I find a lot of 5000-line functions. I wonder if you can comment on any experience you've had of scaling up the Pulumi applications and complexity.
Nwodo: How you would scale the applications, and like I said, in the beginning, where, if you think about how you would write code, every single code you write doesn't have to be in one very big Program.cs file, for example. You can take things out and create that single responsibility, ok, if I am doing things relating to my application. I will talk in the context of Azure. If I am doing things relating to my application, so I want to create an App Service plan and I want to create a function app, and I want to do App Insights and put in an availability test. I can do all of that in a module. Then if I want to do secrets related things, I can do it in a module. If I want to do role assignment, I can do it in a module. That's more a code organization problem. You might think the code is organized, until you hire a new person, and you tell them to look at it, and they're like, "I really don't understand what you're writing." Code organization as well as documentation. That's how I would look at that problem. In the context of deployment and testing it out, you can deploy those things and have Pulumi run it. The truth is, the bigger the infra that you're trying to deploy, the longer it takes, but Pulumi manages all of that for you. You can actually start the deployment and decide that you want to go and drink coffee or watch something nice on TV, and come back eventually when it's done.
You mentioned deployment, you mentioned scale, and testing. In the concept of testing, for example, there are different ways that you can test out things. I was talking about security declarations at some point when I was saying Infrastructure as Code and Policy as Code. IaC tools have what they use to do for Policy as Code. I'm of the opinion that Policy as Code is going to be a very good way for people to test their IaC, because then you can use your security declarations to test specific things that you want your infra to have. For testing, you can decide that you want to write Policy as Code, and you want to use those policies that you've written to test the infrastructure that you have. These are in the form of writing unit tests. Because you're writing programming languages, you can write tests the way you would write tests for your code, and also validate that, if I do this thing, this thing gets called in the way that I want Pulumi to call it, things like that. The final thing is, you can build up infra. Because sometimes you want to test things end-to-end as well, not just about the infrastructure being able to get provisioned. That when you put your application inside the infra, everything works the way it's supposed to work and you've not mistakenly broken something with your new infra change. Sometimes you want to run something we would call a test stack, and depending on how your team is, if you have a full platform team, you might want to make it an auto test stack. When you open a PR, automatically a test stack gets created, and then your code is deployed to that stack. Then you run a bunch of tests on your code. If everything works, you can destroy that stack and know that, yes, your Pulumi change works as well.
Participant 9: In your presentation, you talked a bit about configuration drift, which I'm very interested about. I'm curious how you think about learning on mitigating that more generally, or with using Pulumi.
Nwodo: With using Pulumi, it's very nice because you don't have to attempt to prevent anything. That's why I showed you what happens when you delete a block of code in Pulumi. It's like Pulumi knows that, ok, this thing that you've taken out of your code, you want me to delete. Should I go ahead and delete it for you, basically? The point is, your code, the way it is, is the single source of truth for your infrastructure. Basically, at any time, anyone that comes into your organization, old or new, into your team, should be able to look at your Pulumi declarations, and see the exact resources in your infrastructure. There isn't a possibility that Pulumi doesn't have a Key Vault in the Pulumi declarations, and somehow there's a Key Vault in your resource group. That's not possible, except you went there to create it by yourself, which you shouldn't do. Because the hope is that everything you do that is infra related, you can track it and Pulumi helps you manage it better. If you are going to use an IaC tool, you wouldn't need to worry about configuration drift because that's no longer your problem.
See more presentations with transcripts
