Today we are launching Pulumi’s new Migration Hub, a comprehensive guide to help you seamlessly adopt Pulumi no matter where you are coming from, whether that’s Terraform, CloudFormation, … or even manually provisioned resources not yet governed by an infrastructure as code solution. Our new Expert Services group is ready to roll up their sleeves to help you adopt Pulumi faster. The Migration Hub also features many commercial offers for open source foundations, startups, and complementary migration, to minimize switching costs and risks. It’s never been easier to adopt Pulumi.
Pulumi stands with the open source community. We are unaffected by HashiCorp relicensing their software yesterday, and express profound support for many of our cloud friends who have been affected. Pulumi is true open source, uses the Apache 2.0 license, and does not and never will depend on BSL-licensed software in any way, HashiCorp owned or otherwise. We look forward to continuing to serve our new and loyal customers, always with open source and our amazing, fast-growing community at our core.
Pulumi makes it easy to flexibly deploy your cloud infrastructure using code. Usually deployments encompass a single slack and a single region in your cloud of choice. If you need to go multi-region, that usually means creating a stack per-region, which Pulumi’s configuration system makes easy. A stack per region isn’t required, though! Sometimes we want a single stack to span regions for performance, scalability, resilience, or just hard requirements. In these cases, Pulumi can seamlessly orchestrate deployments to, or even across, multiple regions, accounts, or clusters. In this article, we’ll see this in action by provisioning an AWS RDS primary database into one region and a read replica in an entirely different region – all from a single Pulumi program, stack, and
pulumi up incantation.
There are two primary kinds of infrastructure as code tools: configuration management, like Ansible, Chef, and Puppet, which configure, patch, or upgrade existing servers, and provisioning, like Pulumi, Terraform, and CloudFormation, which create, update, and delete the underlying infrastructure itself. Provisioning has taken over from configuration management as the dominant form of IaC over the past decade as we’ve shifted to modern immutable infrastructure architectures that use containers, serverless, and managed services. And yet, configuration management still remains important and relevant, especially for heritage, stateful, server-centric, and on-prem or hybrid solutions. The good news is that it doesn’t need to be either-or choice: the two approaches are complementary. In this post, you’ll see how and why you might combine them by deploying a WordPress Server to AWS by provisioning infrastructure with Pulumi and configuring the server with Ansible.
Unbelievably, we just celebrated Pulumi’s 5th birthday. To commemorate, we are publishing multi-part series on all things infrastructure as code, starting with why we’re so excited about it: All Roads Lead Back to Infrastructure as Code Standing on the Shoulders of Giants Infrastructure as Code Internals Bringing Applications and Infrastructure Closer Together Ringing in the Cloud Engineering Era (Bonus) The Future of Infrastructure as Code We published the first post today, and the others will soon follow in the weeks to come.
Our mission with Pulumi was to make it 100x easier to program the cloud. We saw amazing new architectures and capabilities made possible by the modern cloud, and new and exciting software and business outcomes fueled by adopting them. And yet, back in 2017 when we began, we found the models for programming, composing, and building modern cloud software sorely lacking. “Infrastructure as code” is widely accepted as the table stakes solution, yet most people were copy-and-pasting config scripts in bash, encoding architecture in thousands of lines of YAML, and the best in class technologies used proprietary domain-specific languages that lacked great IDEs and true sharing and reuse, and were simply reinventing the wheel.
Pulumi was designed to be highly extensible from the outset. That includes core languages and cloud providers, of course, but our community is often using Pulumi as a central part of building and connecting their cloud engineering and automation systems, using features like the Automation API. Today we are happy to announce the next major step in enabling these kind of scenarios: the Pulumi REST API. This REST API offers functionality to manage projects and stacks, cloud resources, policies, and more. It has, in fact, been there all along, powering the Pulumi SDK, CLI, and Console behind the scenes, although we haven’t fully documented or supported it until now. That changes today! We’ve already seen some amazing things built with this API and we’re excited to see what you build with it too.
Going from a containerized application to a service running in the cloud requires a few steps beyond an application’s normal build-and-test cycle. Namely, it means building and publishing a container image in a registry and then consuming that image from your target environment, whether that’s Kubernetes, Amazon ECS, or another container orchestrator. It’s not enough to just write a
Dockerfile — you will need to pick a container registry, decide whether that registry should be public or private, authenticate against it, and ideally automate deploying subsequent updates. Infrastructure as code to the rescue! In this article, we’ll see how to build, publish, and consume a simple container image across any cloud, using just a few lines of code.
Today I’m thrilled to announce that we’ve raised $37.5 million in Series B funding led by NEA with participation from existing investors, Madrona Venture Group and Tola Capital. We will use this funding to continue serving our fast-growing community of developers and infrastructure practitioners, making Cloud Engineering the new reality for organizations embracing the modern cloud in all aspects of how they ship software.
All software is cloud software. All modern applications interact with the cloud in some way, whether it’s using cloud for storage, compute capabilities, or with rich cloud services for data, AI/ML, and so much more, to deliver amazing new experiences. As a result, all developers today are cloud developers, and infrastructure teams are key to enabling innovation across the entire organization. I had a great time telling this story at the Cloud Engineering Summit today and wanted to take a moment to put pen to paper.