From c9077c2699dc51a554527c4192aa21cd13dec834 Mon Sep 17 00:00:00 2001 From: Alex Leventer Date: Mon, 18 May 2026 16:33:43 -0700 Subject: [PATCH 1/4] content(what-is): expand the Infrastructure as Software explainer Rewrites content/what-is/what-is-infrastructure-as-software.md from a marketing-leaning overview into a substantive reference that honestly distinguishes IaS from DSL-based IaC. New structure: - Bold quotable definition + question-driven TOC. - Three problems that drive IaS adoption: sophisticated cloud- native architectures, ephemeral/dynamic infrastructure, self- service platform engineering. - DSL-based IaC vs IaS comparison table across 9 dimensions including types, abstractions, sharing, testing, programmable lifecycle, onboarding. - Seven engineering capabilities IaS adds: types, abstractions, package management, testing, IDE tooling, policy as code in the same language, composability with non-infra code. - Six concrete use cases where IaS shines. - Dedicated section on the automation API and its use cases (IDPs, multi-tenant SaaS, custom CI/CD, chatbots, ephemeral environments). - Honest trade-offs section covering when IaS is more rope than signal, language onboarding cost, side-effect anti-patterns, ecosystem maturity gaps. - Pulumi-IaS section: first-class languages, typed SDKs, components, CrossGuard, ESC, automation API, CI/CD-native. - Ten FAQ entries covering Terraform vs Pulumi, CloudFormation CDK comparison, ops engineer adoption, YAML, testing, platform engineering, migration, multi-cloud, performance. - Cross-links to IaC, DevOps, platform engineering, IaC for DevOps, IaC for Kubernetes, infrastructure testing. Co-Authored-By: Claude Opus 4.7 (1M context) --- .../what-is-infrastructure-as-software.md | 164 ++++++++++++++---- 1 file changed, 131 insertions(+), 33 deletions(-) diff --git a/content/what-is/what-is-infrastructure-as-software.md b/content/what-is/what-is-infrastructure-as-software.md index 3de83df20827..343c05ffb234 100644 --- a/content/what-is/what-is-infrastructure-as-software.md +++ b/content/what-is/what-is-infrastructure-as-software.md @@ -1,8 +1,6 @@ --- title: What Is Infrastructure as Software? -meta_desc: | - Infrastructure as Software (IaS) is the next step in managing your cloud environments by adopting - tried and true software engineering best practices. +meta_desc: "Infrastructure as Software is IaC written in general-purpose programming languages. Learn how it differs from DSL-based IaC and where it fits in practice." type: what-is page_title: "Infrastructure as Software: The Next Step in Cloud Management" @@ -31,60 +29,160 @@ customer_logos: authors: ["zack-chase"] --- -[Infrastructure as Code (IaC)](/what-is/what-is-infrastructure-as-code) is now a widely adopted practice. With IaC, you describe your infrastructure programmatically using a tool that provides its own domain-specific language (DSL). IaC is a huge improvement over earlier ways of managing infrastructure, such as using a web console or having a collection of batch scripts. With IaC, you can apply many of the best engineering practices, which you already use with application software, to your infrastructure. Some best practices include: +**Infrastructure as Software (IaS) is the practice of defining cloud infrastructure in general-purpose programming languages and applying the full toolchain of modern software engineering to it: real types, real abstractions, real tests, real package management, real APIs, and real CI/CD.** It's the natural next step after [infrastructure as code (IaC)](/what-is/what-is-infrastructure-as-code/), which uses domain-specific languages (DSLs) or markup formats like HCL, JSON, and YAML, and which makes most of these engineering practices either awkward or unavailable. -- Versioning -- Tracking changes all the way from code commit to deployment -- Encouraging collaboration among developers +The two terms overlap in intent. They both aim to replace manual cloud operations with reviewable, automated, reproducible code. They differ in *how much code engineering* you can do once your infrastructure is in code. IaS treats every cloud resource as a software object whose lifecycle can be programmed, abstracted, tested, packaged, and called from other programs. That last property is the one that opens up automation patterns DSL-based IaC can't reach: building self-service portals, embedding `pulumi up` inside a SaaS product, and using the same APIs internally that Pulumi itself uses. -## Is IaC Keeping Up? +In this article, we'll cover the key questions about infrastructure as software: -These are great benefits but changes in how businesses want to use the cloud are making it necessary that the tools you use evolve to keep pace. Here are a few of those changes. +* What problems is infrastructure as software solving? +* How is IaS different from DSL-based IaC? +* What engineering capabilities does IaS add? +* Where does IaS shine in practice? +* What does the automation API enable? +* What are the trade-offs of IaS? +* How does Pulumi support infrastructure as software? +* Frequently asked questions about infrastructure as software -### Sophisticated Architectures +## What problems is infrastructure as software solving? -After organizations migrate to the cloud and gain some experience, they tend to look for ways to deliver value faster. They might adopt more sophisticated technologies such as serverless, containers and Kubernetes. Creating and maintaining these environments can be complicated. +DSL-based IaC was a big jump forward in the 2010s. It introduced versioning, code review, and reproducible environments to cloud operations. Three pressures since then have stretched its limits and motivated the move toward IaS: -### Ephemeral Architectures +* **Sophisticated, multi-layer architectures.** A typical service today spans containers, Kubernetes, serverless functions, managed databases, message brokers, secrets, IAM, DNS, and CDN. Composing all of those in a DSL turns into thousands of lines of templates and external glue. A general-purpose language can express the same composition in dozens of lines of typed code. +* **Ephemeral and dynamic infrastructure.** Cloud resources change daily or hourly. Templating engines and string interpolation in YAML weren't designed for that pace; real loops, conditionals, and types are. +* **Self-service platforms.** Platform engineering teams need to expose cloud capabilities to product teams through forms, APIs, and chat commands, not by handing them HCL files. Doing that on top of a DSL means writing a templating shim; doing it on top of a programming language means importing the IaC as a library. -Cloud architectures are changing from being long lasting to being ephemeral, which means that there are frequent infrastructure changes. Today, many teams manage thousands or tens of thousands of resources that change daily or even hourly. +## How is IaS different from DSL-based IaC? -### Increasing Velocity +Both describe the desired state of cloud resources. The difference is what's around the description. -Developers are always looking for ways to deploy their applications as quickly as possible. How quickly you can provision an architecture and make sure it’s working can affect release times. +| Dimension | DSL-based IaC (HCL, YAML, ARM) | Infrastructure as Software | +|---|---|---| +| Language | Domain-specific | TypeScript, Python, Go, C#, Java, etc. | +| Types | Limited or none | Full static types over cloud APIs | +| Abstractions | Modules, limited generics | Classes, functions, packages, generics | +| Sharing | Per-tool registry (Terraform Registry, etc.) | Standard package managers (npm, PyPI, etc.) | +| Testing | Limited unit testing, mostly integration | Standard test runners, mocks, full TDD | +| IDE support | Good | Excellent (autocomplete, jump-to-definition, refactor) | +| Programmable lifecycle | Limited | Full programmatic API for `up` / `preview` / `destroy` | +| Conditional and looped logic | Restricted (`for_each`, `count`) | Native language constructs | +| Onboarding for software engineers | New language to learn | Same language they already use | -## Infrastructure as Software +The most consequential row is the second-to-last one. Because IaS programs are ordinary code, the IaC engine can be called from another program, which is the foundation of [Pulumi's automation API](/docs/iac/packages-and-automation/automation-api/) and the reason IaS reaches use cases DSL-based IaC structurally can't. -Infrastructure as Software (IaS) is the next step in managing your cloud environments. The biggest difference between IaC and IaS is that while an IaC tool requires you to learn its DSL, IaS allows you to program in a standard language, one that you already know. For example, if you’re a Python programmer, that’s the language you use. If you’re a Go programmer, then that’s what you use to create and manage your infrastructure. Once you adopt a platform that supports IaS, you gain a host of benefits. +## What engineering capabilities does IaS add? -### Shorter learning curve +The everyday capabilities that come for free with IaS are the ones DSL-based IaC has to either approximate, regenerate, or hand off to external tools: -With IaS, you don’t have to learn a new language. You can concentrate on creating and managing your infrastructure. You’ll also be able to use the same IDE that you use for other development projects and take advantage of its features such as autocompletion and the ability to look up methods and their parameters. +* **Real types.** A misspelled property name, a missing required field, a type mismatch, or an invalid enum value all fail at compile time rather than at `apply` time. +* **Real abstractions.** A reusable VPC pattern becomes a class whose constructor takes typed inputs. The class can be parameterized, subclassed, and shipped as a package. A repeating module becomes a `new MyVpc(...)`, not a folder of copy-pasted templates. +* **Standard package management.** Internal components ship through npm, PyPI, Go modules, NuGet, or Maven, depending on the language. Versions follow semver. Dependencies are locked. +* **Real testing.** Use the test runner that already works for your application code (Jest, pytest, `go test`, xUnit, JUnit) for your IaC. Pulumi's [test mocks](/docs/iac/using-pulumi/testing/unit/) let unit tests run in memory without touching the cloud. +* **IDE-grade tooling.** Autocomplete, jump-to-definition, refactoring, inline error squiggles. The same VS Code, JetBrains, or Neovim setup that works for the app works for the infra. +* **Policy as code in the same language.** [Pulumi CrossGuard](/docs/insights/policy/) policies can be written in TypeScript, Python, Java, or OPA's Rego against the actual resource model. The same engineers who wrote the infrastructure can write the policies that govern it. +* **Composability with non-infra code.** Pull configuration from an internal service, fetch a list of allowed regions from a database, compute a resource name from a feature-flag value. Any of those is one library call away in IaS; they require an external preprocessing step in a DSL. -### More powerful programming techniques +## Where does IaS shine in practice? -DSLs tend to be limited. They often don’t support standard programming constructs. With IaS, the full functionality of your chosen programming language is available. For instance, you can use conditionals and for loops. In other words, you’ll be able to program your infrastructure just as you do your applications. +A few use cases consistently benefit from the IaS model: -### Reusability +* **Cloud-native architectures.** When the topology is a graph of microservices, Kubernetes manifests, IAM roles, queues, and managed services, expressing it as typed code with shared abstractions scales better than templating. +* **Multi-cloud and SaaS-cloud setups.** A single program can mix AWS, Azure, Google Cloud, Cloudflare, Datadog, Snowflake, and GitHub in the same model. +* **Platform engineering.** Platform teams ship typed components that product teams consume. Component versioning, dependency management, and IDE assistance all work through ordinary package managers. +* **Self-service portals.** A platform team wraps Pulumi programs in a service or CLI using the automation API. Product engineers run "create a new staging environment" or "spin up a load-test cluster" through a UI rather than by editing IaC. +* **MLOps and data infrastructure.** ML pipelines, training clusters, feature stores, and serving infrastructure all touch a lot of cloud surface and benefit from the same general-purpose language used by the data team. +* **Tightly-tested infrastructure.** When a security-critical control (an IAM boundary, a network ACL, a key policy) needs unit tests for every conceivable input, the test runner that already works for your application code is the right place to run them. -IaS allows you to generalize your code so you can build and share reusable components. You’ll be able to use standard package managers to distribute those components. +## What does the automation API enable? -### Advanced orchestration +The automation API is the most distinctive capability that comes with IaS. It exposes the Pulumi engine as a library that other programs can call, which means infrastructure operations can be embedded in any code path you'd otherwise embed a database call in: -IaS allows you to incorporate data from monitoring services such as Prometheus into your deployments. That means you can check metrics to make sure everything is healthy before you deploy to production. +* **Internal developer platforms.** A web UI that lets product teams provision approved infrastructure on demand. +* **SaaS product features.** A multi-tenant SaaS that provisions per-customer infrastructure (a dedicated cluster, a per-tenant database) as part of customer onboarding. +* **Custom CI/CD.** Pipelines that run `pulumi preview`, post the diff to Slack, and apply on approval without invoking the CLI. +* **Chatbots and runbooks.** A `/deploy staging` command in Slack that calls the automation API and reports back. +* **Ephemeral environments.** A test runner that spins up an isolated environment for every PR, runs the test suite, and tears down on completion. -### Test-driven infrastructure +Doing any of these on top of a DSL-based IaC tool typically means shelling out to a CLI, parsing text output, and hoping the next CLI release doesn't break the parser. The automation API replaces all of that with a typed function call. -Most DSLs have few resources for testing your infrastructure. Of course, with IaS, you can use the frameworks and techniques you already know to make sure your infrastructure is behaving as it should. You should also be able to do blackbox testing because you can mimic the requests and responses that come from your cloud provider. +See [the automation API documentation](/docs/iac/packages-and-automation/automation-api/) for the supported languages and patterns. -### More Automation +## What are the trade-offs of IaS? -IaS broadens your ability to automate tasks. A good IaS platform lets you automate many jobs, such as secrets management and security audits with just a few commands. +IaS isn't a free win in every direction. A few honest trade-offs: -### Multi-cloud infrastructure +* **A general-purpose language is more powerful than a DSL, and the same engineer can write less-readable code with it.** A poorly written TypeScript Pulumi program with nested conditionals and side effects is harder to read than a flat HCL file. Coding standards and reviewer discipline matter more, not less. +* **The team has to know the language.** A pure ops team that's been writing HCL for years has a real adoption cost. The win comes when the team already has TypeScript / Python / Go skills, or when the platform team can mediate. +* **Programmatic flexibility makes some patterns easy that you shouldn't use.** Imperative side effects inside an IaC program (talking to external systems mid-apply) are tempting and rarely a good idea. IaS programs should still describe desired state, not script imperative steps. The discipline has to come from the team. +* **DSL-based tools have a longer history and a larger module ecosystem in some categories.** Terraform's public module registry is still bigger than Pulumi's component ecosystem for many niche providers. The gap is closing, but it exists. -With IaS, you can use a common API to create an infrastructure that will work for multiple cloud providers. Your IaS platform should hide the details and low-level functionality so that you can concentrate on operating consistently and reliably on any provider you choose. +The pragmatic answer for most teams: start with the language they already use, write IaS programs that read like code review-ready software (small functions, typed inputs, components for repeated patterns), and treat the IaS advantages as a way to do less work, not as a license to do more. -## Learn More +## How does Pulumi support infrastructure as software? -Pulumi is the leading platform for Infrastructure as Software. It supports multiple languages, multiple cloud providers, and has many other features such as built-in secrets management. Want to learn more? Visit [pulumi.com](/) or [get started](/docs/get-started/) for free today. +Pulumi was built around the IaS model from day one. + +* **First-class languages.** TypeScript, JavaScript, Python, Go, C# (.NET), Java, plus YAML for teams that want a markup format. Every language has full SDKs, full test mocks, and full ecosystem support. +* **Generated, typed SDKs for every cloud.** AWS, Azure, Google Cloud, Kubernetes, plus 100+ other providers (Cloudflare, Snowflake, Datadog, GitHub, MongoDB Atlas, etc.). Types are generated from each provider's API so they reflect the real cloud surface. +* **Component model.** Reusable [Pulumi components](/docs/iac/concepts/components/) ship as ordinary packages in your language's package manager. +* **Policy as code with CrossGuard.** Write policies in the same language as the infrastructure. Run them in CI and as a deploy gate. +* **Secrets with Pulumi ESC.** [Pulumi ESC](/product/esc/) keeps secrets out of code and state, pulled at runtime by IaS programs, CI jobs, and applications. +* **Automation API.** Embed `pulumi up`, `pulumi preview`, and `pulumi destroy` inside any program that needs to provision infrastructure programmatically. +* **CI/CD-native.** Pulumi runs in every major CI/CD system. The [continuous delivery guide](/docs/iac/guides/continuous-delivery/) covers the common patterns. + +[Get started with Pulumi](/docs/get-started/) to provision and manage cloud infrastructure in the language your team already uses. + +## Frequently asked questions about infrastructure as software + +### What's the difference between IaC and IaS? + +IaC is the broad practice of defining cloud infrastructure in code. IaS is the specific style of IaC that uses general-purpose programming languages and applies the full software-engineering toolchain (types, tests, abstractions, packages, programmatic APIs). All IaS is IaC; not all IaC is IaS. + +### Is Terraform IaS? + +No. Terraform's HCL is a DSL designed specifically for IaC. The CDK for Terraform (CDKTF) layer on top of Terraform is closer to IaS because it lets you write TypeScript, Python, Go, or Java that synthesizes HCL. Pulumi differs from CDKTF in that there's no HCL layer in the middle: the IaS program drives the Pulumi engine directly. + +### Is CloudFormation IaS? + +Plain CloudFormation YAML is a DSL. The AWS Cloud Development Kit (CDK) is an IaS-style layer on top of CloudFormation: you write TypeScript/Python/etc. that synthesizes CloudFormation templates. As with CDKTF, the synthesis step is the structural difference from Pulumi, which has no template synthesis layer. + +### Do I have to be a software engineer to use IaS? + +Not exclusively, but it helps. The model assumes basic competence in a programming language. Ops engineers without that background take longer to ramp up than they would on HCL. The flip side is that the same skills then carry across the whole platform; you don't have two languages to maintain. + +### What about teams that write all their infrastructure in YAML? + +YAML works fine for small footprints and simple configurations. Most teams that hit the limits of YAML do so when they try to express conditionals, loops, or per-environment variations and end up running YAML through a templating engine (Helm, Kustomize, jsonnet). At that point, an IaS language is usually a cleaner answer than another templating layer. + +### How does IaS support testing? + +The same way any other software does. Use the language's standard test runner (Jest, pytest, `go test`, xUnit), use Pulumi's test mocks to replace cloud calls in unit tests, and use the automation API to spin up ephemeral stacks for integration tests. See [how to step up cloud infrastructure testing](/what-is/how-to-step-up-cloud-infrastructure-testing/) for the layered testing model. + +### Does IaS replace platform engineering tools? + +No, it enables them. A platform engineering team uses IaS to build the components and automation that product teams consume. The IaS programs are the platform team's product; the automation API and components are the interface. See [What is Platform Engineering?](/what-is/what-is-platform-engineering/). + +### Can I migrate from Terraform to IaS? + +Yes. Pulumi can [import existing resources](/docs/iac/adopting-pulumi/import/) without recreating them, and `pulumi convert` can translate HCL source into a Pulumi program in the language of your choice. Most teams migrate incrementally: new infrastructure starts in IaS, existing HCL stays in place until it changes. + +### Does IaS work for multi-cloud? + +Yes. One IaS program can mix resources from AWS, Azure, Google Cloud, Kubernetes, and any of 100+ other Pulumi providers. The general-purpose language gives you a single place to express the cross-cloud dependencies and types. + +### Is IaS slower than IaC at scale? + +In `pulumi up` runtime, no. The engine plans and applies the same way regardless of which language the program was written in. In developer iteration speed, IaS is usually faster because the IDE tooling (autocomplete, types, jump-to-definition) shortens the edit-debug cycle on every change. + +## Learn more + +Pulumi is the leading platform built around infrastructure as software: full programming languages, typed cloud SDKs, real tests, real package management, and an automation API that lets you embed `pulumi up` inside any other program. [Get started today](/docs/get-started/). + +Related reading: + +* [What is Infrastructure as Code (IaC)?](/what-is/what-is-infrastructure-as-code/) +* [What is DevOps?](/what-is/what-is-devops/) +* [What is Platform Engineering?](/what-is/what-is-platform-engineering/) +* [Infrastructure as Code for DevOps](/what-is/infrastructure-as-code-for-devops/) +* [Infrastructure as Code for Kubernetes](/what-is/infrastructure-as-code-for-kubernetes/) +* [How to Step Up Cloud Infrastructure Testing](/what-is/how-to-step-up-cloud-infrastructure-testing/) From 204512ef0cb26a66564be1e143e34ec8b51b1461 Mon Sep 17 00:00:00 2001 From: "claude[bot]" <41898282+claude[bot]@users.noreply.github.com> Date: Tue, 19 May 2026 04:00:25 +0000 Subject: [PATCH 2/4] fix(what-is): correct CrossGuard and CDKTF language support lists MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit CrossGuard supports TypeScript/JavaScript, Python, and OPA Rego — not Java. CDKTF supports C# in addition to TypeScript, Python, Go, and Java. Co-Authored-By: Claude Sonnet 4.6 --- content/what-is/what-is-infrastructure-as-software.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/what-is/what-is-infrastructure-as-software.md b/content/what-is/what-is-infrastructure-as-software.md index 343c05ffb234..c45b5ee394a8 100644 --- a/content/what-is/what-is-infrastructure-as-software.md +++ b/content/what-is/what-is-infrastructure-as-software.md @@ -79,7 +79,7 @@ The everyday capabilities that come for free with IaS are the ones DSL-based IaC * **Standard package management.** Internal components ship through npm, PyPI, Go modules, NuGet, or Maven, depending on the language. Versions follow semver. Dependencies are locked. * **Real testing.** Use the test runner that already works for your application code (Jest, pytest, `go test`, xUnit, JUnit) for your IaC. Pulumi's [test mocks](/docs/iac/using-pulumi/testing/unit/) let unit tests run in memory without touching the cloud. * **IDE-grade tooling.** Autocomplete, jump-to-definition, refactoring, inline error squiggles. The same VS Code, JetBrains, or Neovim setup that works for the app works for the infra. -* **Policy as code in the same language.** [Pulumi CrossGuard](/docs/insights/policy/) policies can be written in TypeScript, Python, Java, or OPA's Rego against the actual resource model. The same engineers who wrote the infrastructure can write the policies that govern it. +* **Policy as code in the same language.** [Pulumi CrossGuard](/docs/insights/policy/) policies can be written in TypeScript, JavaScript, Python, or OPA's Rego against the actual resource model. The same engineers who wrote the infrastructure can write the policies that govern it. * **Composability with non-infra code.** Pull configuration from an internal service, fetch a list of allowed regions from a database, compute a resource name from a feature-flag value. Any of those is one library call away in IaS; they require an external preprocessing step in a DSL. ## Where does IaS shine in practice? @@ -140,7 +140,7 @@ IaC is the broad practice of defining cloud infrastructure in code. IaS is the s ### Is Terraform IaS? -No. Terraform's HCL is a DSL designed specifically for IaC. The CDK for Terraform (CDKTF) layer on top of Terraform is closer to IaS because it lets you write TypeScript, Python, Go, or Java that synthesizes HCL. Pulumi differs from CDKTF in that there's no HCL layer in the middle: the IaS program drives the Pulumi engine directly. +No. Terraform's HCL is a DSL designed specifically for IaC. The CDK for Terraform (CDKTF) layer on top of Terraform is closer to IaS because it lets you write TypeScript, Python, Go, Java, or C# that synthesizes HCL. Pulumi differs from CDKTF in that there's no HCL layer in the middle: the IaS program drives the Pulumi engine directly. ### Is CloudFormation IaS? From 441cc0329385ece0d4cc990b5fdac8f8492b675d Mon Sep 17 00:00:00 2001 From: "claude[bot]" <41898282+claude[bot]@users.noreply.github.com> Date: Tue, 19 May 2026 16:12:56 +0000 Subject: [PATCH 3/4] =?UTF-8?q?fix(what-is):=20apply=20@CamSoper=20review?= =?UTF-8?q?=20changes=20=E2=80=94=20remove=20CrossGuard,=20fix=20schema/pr?= =?UTF-8?q?oviders=20wording,=20add=20docs=20links?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - Remove all "CrossGuard" references (deprecated term); use "Pulumi policies" with /docs/insights/policy/ link - "from each provider's API" → "from each provider's schema" (more precise) - "100+ other providers" → "hundreds of other providers" (stays current) - L129: add ESC docs link (/docs/esc/) alongside product marketing link - L167: link `pulumi convert` to /docs/iac/guides/migration/converters/ Co-Authored-By: Claude Sonnet 4.6 --- .../what-is/what-is-infrastructure-as-software.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/content/what-is/what-is-infrastructure-as-software.md b/content/what-is/what-is-infrastructure-as-software.md index c45b5ee394a8..540967c4847d 100644 --- a/content/what-is/what-is-infrastructure-as-software.md +++ b/content/what-is/what-is-infrastructure-as-software.md @@ -79,7 +79,7 @@ The everyday capabilities that come for free with IaS are the ones DSL-based IaC * **Standard package management.** Internal components ship through npm, PyPI, Go modules, NuGet, or Maven, depending on the language. Versions follow semver. Dependencies are locked. * **Real testing.** Use the test runner that already works for your application code (Jest, pytest, `go test`, xUnit, JUnit) for your IaC. Pulumi's [test mocks](/docs/iac/using-pulumi/testing/unit/) let unit tests run in memory without touching the cloud. * **IDE-grade tooling.** Autocomplete, jump-to-definition, refactoring, inline error squiggles. The same VS Code, JetBrains, or Neovim setup that works for the app works for the infra. -* **Policy as code in the same language.** [Pulumi CrossGuard](/docs/insights/policy/) policies can be written in TypeScript, JavaScript, Python, or OPA's Rego against the actual resource model. The same engineers who wrote the infrastructure can write the policies that govern it. +* **Policy as code in the same language.** [Pulumi policies](/docs/insights/policy/) can be written in TypeScript, JavaScript, Python, or OPA's Rego against the actual resource model. The same engineers who wrote the infrastructure can write the policies that govern it. * **Composability with non-infra code.** Pull configuration from an internal service, fetch a list of allowed regions from a database, compute a resource name from a feature-flag value. Any of those is one library call away in IaS; they require an external preprocessing step in a DSL. ## Where does IaS shine in practice? @@ -123,10 +123,10 @@ The pragmatic answer for most teams: start with the language they already use, w Pulumi was built around the IaS model from day one. * **First-class languages.** TypeScript, JavaScript, Python, Go, C# (.NET), Java, plus YAML for teams that want a markup format. Every language has full SDKs, full test mocks, and full ecosystem support. -* **Generated, typed SDKs for every cloud.** AWS, Azure, Google Cloud, Kubernetes, plus 100+ other providers (Cloudflare, Snowflake, Datadog, GitHub, MongoDB Atlas, etc.). Types are generated from each provider's API so they reflect the real cloud surface. +* **Generated, typed SDKs for every cloud.** AWS, Azure, Google Cloud, Kubernetes, plus hundreds of other providers (Cloudflare, Snowflake, Datadog, GitHub, MongoDB Atlas, etc.). Types are generated from each provider's schema so they reflect the real cloud surface. * **Component model.** Reusable [Pulumi components](/docs/iac/concepts/components/) ship as ordinary packages in your language's package manager. -* **Policy as code with CrossGuard.** Write policies in the same language as the infrastructure. Run them in CI and as a deploy gate. -* **Secrets with Pulumi ESC.** [Pulumi ESC](/product/esc/) keeps secrets out of code and state, pulled at runtime by IaS programs, CI jobs, and applications. +* **Policy as code.** Write [policies](/docs/insights/policy/) in the same language as the infrastructure. Run them in CI and as a deploy gate. +* **Secrets with Pulumi ESC.** [Pulumi ESC](/product/esc/) keeps secrets out of code and state, pulled at runtime by IaS programs, CI jobs, and applications. See the [ESC docs](/docs/esc/) for setup and configuration. * **Automation API.** Embed `pulumi up`, `pulumi preview`, and `pulumi destroy` inside any program that needs to provision infrastructure programmatically. * **CI/CD-native.** Pulumi runs in every major CI/CD system. The [continuous delivery guide](/docs/iac/guides/continuous-delivery/) covers the common patterns. @@ -164,11 +164,11 @@ No, it enables them. A platform engineering team uses IaS to build the component ### Can I migrate from Terraform to IaS? -Yes. Pulumi can [import existing resources](/docs/iac/adopting-pulumi/import/) without recreating them, and `pulumi convert` can translate HCL source into a Pulumi program in the language of your choice. Most teams migrate incrementally: new infrastructure starts in IaS, existing HCL stays in place until it changes. +Yes. Pulumi can [import existing resources](/docs/iac/adopting-pulumi/import/) without recreating them, and [`pulumi convert`](/docs/iac/guides/migration/converters/) can translate HCL source into a Pulumi program in the language of your choice. Most teams migrate incrementally: new infrastructure starts in IaS, existing HCL stays in place until it changes. ### Does IaS work for multi-cloud? -Yes. One IaS program can mix resources from AWS, Azure, Google Cloud, Kubernetes, and any of 100+ other Pulumi providers. The general-purpose language gives you a single place to express the cross-cloud dependencies and types. +Yes. One IaS program can mix resources from AWS, Azure, Google Cloud, Kubernetes, and any of hundreds of other Pulumi providers. The general-purpose language gives you a single place to express the cross-cloud dependencies and types. ### Is IaS slower than IaC at scale? From 37218df51fd6b5f375111ce334fab67173c32dab Mon Sep 17 00:00:00 2001 From: "claude[bot]" <41898282+claude[bot]@users.noreply.github.com> Date: Tue, 19 May 2026 18:04:04 +0000 Subject: [PATCH 4/4] fix(what-is): apply suggested phrasing for L117, update author to cam-soper Co-Authored-By: Claude Sonnet 4.6 --- content/what-is/what-is-infrastructure-as-software.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/what-is/what-is-infrastructure-as-software.md b/content/what-is/what-is-infrastructure-as-software.md index 540967c4847d..6d58921b2daf 100644 --- a/content/what-is/what-is-infrastructure-as-software.md +++ b/content/what-is/what-is-infrastructure-as-software.md @@ -26,7 +26,7 @@ customer_logos: - webflow - supabase - ro -authors: ["zack-chase"] +authors: ["cam-soper"] --- **Infrastructure as Software (IaS) is the practice of defining cloud infrastructure in general-purpose programming languages and applying the full toolchain of modern software engineering to it: real types, real abstractions, real tests, real package management, real APIs, and real CI/CD.** It's the natural next step after [infrastructure as code (IaC)](/what-is/what-is-infrastructure-as-code/), which uses domain-specific languages (DSLs) or markup formats like HCL, JSON, and YAML, and which makes most of these engineering practices either awkward or unavailable. @@ -114,7 +114,7 @@ IaS isn't a free win in every direction. A few honest trade-offs: * **A general-purpose language is more powerful than a DSL, and the same engineer can write less-readable code with it.** A poorly written TypeScript Pulumi program with nested conditionals and side effects is harder to read than a flat HCL file. Coding standards and reviewer discipline matter more, not less. * **The team has to know the language.** A pure ops team that's been writing HCL for years has a real adoption cost. The win comes when the team already has TypeScript / Python / Go skills, or when the platform team can mediate. * **Programmatic flexibility makes some patterns easy that you shouldn't use.** Imperative side effects inside an IaC program (talking to external systems mid-apply) are tempting and rarely a good idea. IaS programs should still describe desired state, not script imperative steps. The discipline has to come from the team. -* **DSL-based tools have a longer history and a larger module ecosystem in some categories.** Terraform's public module registry is still bigger than Pulumi's component ecosystem for many niche providers. The gap is closing, but it exists. +* **DSL-based tools have a longer history and a larger module ecosystem in some categories.** Terraform's public module registry has a longer history and more entries in some categories. The gap is closing, but it exists. The pragmatic answer for most teams: start with the language they already use, write IaS programs that read like code review-ready software (small functions, typed inputs, components for repeated patterns), and treat the IaS advantages as a way to do less work, not as a license to do more.