Today we are excited to announce the general availability of Pulumi 1.0. Pulumi is a modern infrastructure as code tool that lets you declare infrastructure using real languages, with a SaaS management console for configuring identities, organizations, and related policies. By using real languages, developers and operators are able to work better together, sharing and reusing best practices, accomplishing new levels of automation, and unlocking access to ecosystems of existing tools.
Testing your infrastructure using familiar tools like Node.js’s Mocha framework allows you to ensure configuration is correct before provisioning, and that the resulting infrastructure has certain desirable properties afterwards. This can enforce team standards, ensure security guidelines are being followed, and so much more. Because Pulumi uses general purpose languages, you can just embed tests alongside your infrastructure-as-code definitions themselves, using a familiar authoring style and reporting experience. In this post, we’ll explore the ins and outs of unit testing your infrastructure.
Amazon offers multiple solutions for running containers in AWS, through its managed Elastic Container Service (ECS). This includes three major approaches: ECS managed automatically with Fargate, ECS backed by EC2 instances, and Elastic Kubernetes Service (EKS), delivering the full power of Kubernetes. It’s not always easy to choose between these, so in this article we provide some basic guidance on the tradeoffs you’ll encounter when choosing.
One year ago today – on June 18, 2018 – we open sourced Pulumi, a new approach to multi-cloud infrastructure as code using your favorite languages. And what a year it has been!
The Docker Getting Started tutorial shows how to develop,
build, and run a modern containerized application, from a single custom
Docker container published to the Docker Hub, to a scaled out service
with load balancing. But there are challenges: it requires you to
program in YAML, run (or script) many CLI commands, and manage your own
Swarm or Kubernetes cluster. There is an easier way. By using Pulumi’s
infrastructure as code, we can build a custom Docker image, publish it
to a private AWS container registry, and spin up an AWS Fargate load
balanced service running that container, all in 28 lines of TypeScript
code and a single
pulumi up command. The result leverages the best of
what AWS has to offer, with the entire platform at your fingertips, with
a single approach. In this article, we’ll see how.
Since launching last year, thousands of users and hundreds of companies, from startups to Fortune 500 Enterprises, have chosen Pulumi for cloud applications and infrastructure delivery across AWS, Azure, Google Cloud, and Kubernetes. Today we are announcing important changes to better align our product and pricing with how we’ve heard you want to use Pulumi in production. We’re optimistic that these changes will help companies of all sizes choose Pulumi, enabling their teams to deliver cloud applications and infrastructure faster and more reliably.
Using Pulumi and general purpose languages for infrastructure as code comes with many benefits: leveraging existing skills and knowledge, eliminating boilerplate through abstraction, and using the same ecosystem of tools like IDEs and linters that your team already knows and loves. In general, these are all attributes of software engineering, which not only make us more productive, but also improve the quality of our code. It’s only natural, therefore, that using general purpose languages unlocks another important software engineering practice: testing.
In this article, we will see the many ways in which Pulumi lets us test our infrastructure as code.
With Pulumi, you can create, deploy, and manage any cloud resource using your favorite language. This includes application and infrastructure related resources, often in the same program.
One area this gets really fun is serverless. Because we’re using general purpose languages, we can create resources, and then wire up event handlers, just like normal event-driven programming. This is the way serverless should be!
In this article, we’ll see how. There’s a broad range of options depending on what you want to do, and how your team likes to operate. We’ll be using AWS and TypeScript, but other clouds and languages are available.
As we close out 2018, and enter into a New Year, I was reflecting on our progress here at Pulumi this past year and wanted to share some thoughts. It’s been an incredible year and we are hugely thankful to our passionate community, customers, and partners.
We founded Pulumi because of a deeply held belief that the cloud promises to change all aspects of software development and that there remains an incredible opportunity to reimagine the entire experience, from idea to creation to delivery to management, with one person in mind: you, the engineer.