Pulumi Blog: General

Why Choose Pulumi Over Terraform?

Pablo Seibelt — Tue, 02 Jun 2026 00:00:00 +0000

Terraform is a proven infrastructure as code tool with a large provider and module ecosystem. Many teams choose Pulumi when they want to keep that infrastructure as code model, but write and maintain infrastructure with general-purpose programming languages, familiar package managers, IDEs, testing, and software engineering patterns, while still understanding the refactoring tradeoffs in Terraform’s own module refactoring guidance.

Why choose Pulumi over Terraform? Pulumi’s language SDKs let teams define cloud infrastructure in TypeScript, Python, Go, C#, Java, or YAML while adding first-class workflows for refactoring with Pulumi aliases, secrets, protect, retainOnDelete, deleteBeforeReplace, replaceOnChanges, provider resources, Pulumi stacks, testing, and incremental migration with pulumi import. Pulumi does not remove every hard problem in cloud infrastructure, but it gives teams stronger tools for many day-to-day pain points.

Executive summary

Pulumi is often a better fit when infrastructure code needs to behave like application code: reviewed, tested, packaged, refactored, and shared across teams. The biggest advantages show up when teams need safer refactors, encrypted secret values, reusable components, clearer provider resources, and guardrails around destructive changes.

The tradeoff is important: Pulumi is still an infrastructure as code engine. Provider bugs, cloud API eventual consistency, drift, preview-time unknowns, and poorly designed abstractions still require engineering discipline. The advantage is not magic. The advantage is a stronger programming model and a more familiar developer workflow.

Need	Terraform pattern	Pulumi advantage	What still needs care
Languages and tooling	HCL plus Terraform-specific functions and expressions	Pulumi supports general-purpose languages, YAML, and now HCL natively, with the normal IDE, test, and package workflows for each	Teams still need code review and shared conventions
Refactoring	Moved blocks or state commands for resource identity changes	Pulumi aliases can map old resource identities to new ones during refactors	Aliases must model the old identity correctly
Secrets	Sensitive values can still require careful state and plan handling	Pulumi tracks secrets and encrypts secret values in state	Secrets are still available to code at runtime
Lifecycle safety	Lifecycle meta-arguments and plan review	Pulumi resource options such as protect, retainOnDelete, deleteBeforeReplace, and replaceOnChanges make intent explicit	Provider behavior and replacement semantics still matter
Environments	Workspaces or separate configurations	Pulumi stacks model environments with per-stack config, secrets, history, and outputs	Stack boundaries still need thoughtful design
Code reuse	Modules and HCL composition patterns	Pulumi components and packages use normal language abstractions	Over-abstracted components can become hard to use
Imports and migration	Import blocks, generated config, and state operations	`pulumi import` and migration tooling support gradual adoption	Imported code still needs review and cleanup
Terraform state	S3, Azure Blob, or Terraform Cloud backends	Pulumi Cloud can serve as a Terraform state backend with encrypted storage, locking, history, and RBAC, while you keep using the Terraform or OpenTofu CLI	State still needs a clean migration plan as resources move to Pulumi
Provider wiring	Provider inheritance and aliases inside modules	Explicit provider resources make multi-region and multi-account wiring visible in code review	Provider versions and bugs can still affect deployments
Testing	Validation, plan review, and external test harnesses	Pulumi programs can use normal unit and integration test frameworks	Tests complement previews, they do not replace them
Drift detection	Refresh and refresh-only plans, plus external scheduling	`pulumi refresh` reconciles state, and Pulumi Cloud adds scheduled drift detection and remediation on a configurable cadence	Detection still depends on provider behavior and a healthy state backend
Caveats	Declarative planning still has unknowns and drift	Pulumi improves the workflow around many pain points	It does not eliminate provider bugs or eventual consistency

Use programming languages and familiar tools

Terraform modules are powerful, but larger HCL codebases can require teams to maintain separate conventions for composition, validation, and reuse. Pulumi lets infrastructure teams use the features of whichever supported programming language they choose, such as classes, functions, types, loops, package managers, linters, and test frameworks.

Teams with HCL muscle memory are not left out, either. Pulumi now supports HCL natively as one of its languages, alongside Python, TypeScript, Go, C#, Java, and YAML. Part of a team can keep authoring in HCL while the project still benefits from Pulumi components, testing, and the same engine and package workflows as every other language.

For example, a platform team can wrap a standard storage pattern in a ComponentResource and share it like any other TypeScript abstraction:

import * as pulumi from "@pulumi/pulumi";
import * as aws from "@pulumi/aws";

interface WorkQueueArgs {
 visibilityTimeoutSeconds: number;
}

class WorkQueue extends pulumi.ComponentResource {
 public readonly queueUrl: pulumi.Output<string>;

 constructor(name: string, args: WorkQueueArgs, opts?: pulumi.ComponentResourceOptions) {
 super("platform:queue:WorkQueue", name, {}, opts);

 const queue = new aws.sqs.Queue(`${name}-queue`, {
 visibilityTimeoutSeconds: args.visibilityTimeoutSeconds,
 }, { parent: this });

 this.queueUrl = queue.url;
 this.registerOutputs({ queueUrl: this.queueUrl });
 }
}

const jobs = new WorkQueue("image-jobs", {
 visibilityTimeoutSeconds: 60,
});

Refactor infrastructure without surprise replacement

Renaming a resource, moving it into a component, or reorganizing a project should not automatically mean replacing production infrastructure. Pulumi aliases let you tell Pulumi how a resource used to be addressed, so refactors can preserve resource identity when the old and new resources represent the same cloud object.

const queue = new aws.sqs.Queue("app-jobs", {
 visibilityTimeoutSeconds: 60,
}, {
 aliases: [{ name: "jobs" }],
});

Aliases are not a substitute for review. They work when the old identity is modeled correctly, including details such as name, parent, type, project, and stack when those changed.

Handle secrets with encrypted configuration and secret outputs

Secrets are one of the most common places where infrastructure workflows become risky. Terraform has sensitive values and backend guidance, but teams still need to understand how plans, state, outputs, and backend access interact. Pulumi treats secrets as first-class values, encrypts them in state, and preserves secrecy as values flow through outputs.

const config = new pulumi.Config();
const dbPassword = config.requireSecret("dbPassword");

const passwordParameter = new aws.ssm.Parameter("db-password", {
 type: "SecureString",
 value: dbPassword,
});

This improves the default experience, but it’s not runtime isolation. In the TypeScript SDK, config.requireSecret("dbPassword") retrieves secret configuration, and your program can still access the decrypted value while it runs, so reviews, least privilege, and secret-provider choices still matter. If a value starts as a plain input instead of coming from requireSecret, pulumi.secret(...) can mark it as secret.

For secrets that shouldn’t live in stack config at all, Pulumi ESC (Environments, Secrets, and Configuration) centralizes them in environments that your stacks consume through config. ESC can pull secrets dynamically from external stores such as HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, and 1Password, and mint short-lived OIDC credentials for AWS, Azure, and GCP. That lets you wire an environment into a Pulumi program instead of storing long-lived credentials in state.

Add safer lifecycle controls for destructive changes

Infrastructure mistakes are expensive when they replace or delete stateful resources. Pulumi gives teams explicit resource options for safety-sensitive intent, such as protect, retainOnDelete, deleteBeforeReplace, and replaceOnChanges.

const database = new aws.rds.Instance("orders-db", {
 instanceClass: "db.t4g.micro",
 allocatedStorage: 20,
 engine: "postgres",
 username: "app",
 password: dbPassword,
}, {
 protect: true,
 retainOnDelete: true,
});

These controls are guardrails, not guarantees. Provider bugs, cloud API eventual consistency, and replacement behavior still require preview review and operational judgment. replaceOnChanges applies to custom resources only, not component resources.

Model environments with stacks

Terraform workspaces can represent environments, but many teams eventually need stronger boundaries for configuration, secrets, history, and cross-environment outputs. Pulumi stacks make environment boundaries explicit and pair them with per-stack config and outputs.

const networking = new pulumi.StackReference("acme/networking/prod");
const vpcId = networking.requireOutput("vpcId");

const appSecurityGroup = new aws.ec2.SecurityGroup("app-sg", {
 vpcId,
 ingress: [{
 protocol: "tcp",
 fromPort: 443,
 toPort: 443,
 cidrBlocks: ["10.0.0.0/8"],
 }],
 egress: [{
 protocol: "-1",
 fromPort: 0,
 toPort: 0,
 cidrBlocks: ["0.0.0.0/0"],
 }],
});

Cross-stack references are cleaner than sharing an entire remote state file, but they are still dependencies. Keep stack outputs intentional and avoid turning one stack into a global variable bag.

Test infrastructure with normal language tooling

Because Pulumi programs are real programs, infrastructure testing can use familiar test runners and assertions. Teams can test component defaults, naming conventions, required tags, and policy assumptions before a deployment reaches production.

pulumi.runtime.setMocks({
 newResource: (args) => ({
 id: `${args.name}_id`,
 state: args.inputs,
 }),
 call: (args) => args.inputs,
});

Testing does not replace previews. It catches a different class of problems: broken abstractions, missing required inputs, invalid defaults, and regressions in shared components.

Wire providers explicitly

Provider configuration is another place where explicit code can reduce ambiguity. In Terraform, provider inheritance and aliases are often managed across module boundaries. In Pulumi, provider resources are normal resources that can be passed through resource options, which makes multi-region or multi-account deployments easier to follow in code review.

const west = new aws.Provider("west", {
 region: "us-west-2",
});

const east = new aws.Provider("east", {
 region: "us-east-1",
});

const primary = new aws.sqs.Queue("primary-jobs", {}, {
 provider: west,
});

const replica = new aws.sqs.Queue("replica-jobs", {}, {
 provider: east,
});

The provider object does not remove provider versioning or schema-change risk, but it makes provider wiring visible in the same language and review flow as the rest of the program.

Detect and reconcile drift

Infrastructure drifts when something changes outside your IaC tool: a hotfix in the console, another controller, or a manual break-glass change. Pulumi gives you first-class tools to find and fix it instead of leaving it to chance. pulumi refresh reconciles your state with what is actually running in the cloud, and pulumi preview --diff shows what the next update would change.

For teams that want this continuously, Pulumi Cloud adds scheduled drift detection and remediation that runs on a configurable cadence and can automatically remediate drift when it is detected. That turns finding and correcting out-of-band changes into a managed workflow rather than something a person has to remember to check.

Drift detection still depends on accurate provider behavior and a healthy state backend, so it complements review and operational discipline rather than replacing them.

Import and migrate incrementally

Teams rarely get to rebuild infrastructure from scratch. Pulumi supports incremental adoption with pulumi import, generated code, and Terraform interoperability paths. That makes it possible to start with one resource, one component, or one stack instead of forcing a big-bang migration.

Pulumi also supports interoperability paths for teams that need to bring existing Terraform assets forward over time, including Terraform provider access and migration workflows. That makes migration an engineering sequence, not an all-or-nothing rewrite.

const importedRepository = new aws.ecr.Repository("app", {
 name: "existing-app-repo",
}, {
 import: "existing-app-repo",
});

The CLI flow can also generate declarations with pulumi import. Generated code is a starting point, not a finished architecture. Review names, options, providers, secrets, and component boundaries before treating imported resources as production-ready Pulumi code.

You also don’t have to do it alone. Pulumi provides self-serve conversion tools and expert migration services, and for teams leaving HashiCorp, credits you can apply toward Pulumi to avoid paying for two tools at once, so budget and timing don’t have to block getting started.

Manage Terraform state in Pulumi Cloud

You don’t have to rewrite anything to start getting value from Pulumi. Pulumi Cloud can serve as a Terraform state backend, letting you store and manage Terraform state alongside your Pulumi stacks. Your team can keep using the Terraform or OpenTofu CLI for day-to-day operations while gaining encrypted state storage, update history, state locking, role-based access control, audit policies, and unified resource visibility through Pulumi Insights — with agentic infrastructure coding through Neo on top.

It uses Terraform’s standard remote backend, so you point the CLI at Pulumi Cloud without changing your infrastructure code:

terraform {
 backend "remote" {
 hostname = "api.pulumi.com"
 organization = "your-pulumi-org"

 workspaces {
 name = "_dev"
 }
 }
}

From there, Pulumi can also read outputs from that state, so a new Pulumi stack can consume Terraform-managed values such as VPC IDs and subnet IDs while you migrate one piece at a time. When you’re ready to bring resources fully across, pulumi import --from terraform reads a .tfstate file and generates matching declarations, and pulumi convert --from terraform translates the surrounding configuration into your chosen language.

Storing Terraform state in Pulumi Cloud keeps both tools pointed at one system of record, which is what makes a gradual, low-risk migration practical.

What Pulumi does not magically fix

Pulumi does not eliminate cloud API eventual consistency. A deployment can finish successfully while downstream reads, controllers, or other operators still see stale state for a short window. That is a property of the cloud control plane, not of the IaC tool.

Pulumi also does not eliminate provider bugs. If a provider has a schema issue, a bad default, or a flaky update path, Pulumi still has to ride that provider behavior. Drift will still happen when infrastructure changes outside Pulumi, too. The difference is that Pulumi gives you first-class tooling to detect and reconcile it, as covered in Detect and reconcile drift above — but the drift itself, and the discipline to act on it, do not disappear.

Pulumi does not eliminate preview-time unknowns either. Some values are not known until deployment, so the plan can still contain uncertainty. Bad project decomposition and side-effect-heavy deployment code remain risks too, which is why testing, clear stack boundaries, and disciplined component design still matter.

OpenTofu compatibility caveat

OpenTofu users face many of the same infrastructure-as-code concerns around state, providers, drift, secrets, lifecycle behavior, and migration planning. This post stays Terraform-focused because that is where most teams begin the Pulumi comparison, but the same Pulumi capabilities are relevant when evaluating OpenTofu alternatives or hybrid migration paths.

Pulumi can also work with Terraform provider ecosystems, including long-tail providers that may not have a native Pulumi package yet. Treat that as an interoperability path, not a promise that every Terraform or OpenTofu workflow maps one-for-one without design work.

Get started with Pulumi

If your team is evaluating infrastructure as code options, start with the workflow that creates the most leverage: write infrastructure in the language your team already uses, test shared components, protect critical resources, and migrate one stack at a time.

To go deeper, get started with Pulumi or read the Terraform migration guide.

Best AI Infrastructure Tools in 2026

Alex Leventer — Mon, 25 May 2026 00:00:00 +0000

“AI infrastructure tools” covers two distinct markets: infrastructure for AI (GPU clouds like CoreWeave, MLOps platforms like Weights & Biases) and AI for infrastructure (agentic platforms like Pulumi Neo that generate, deploy, and govern cloud resources for you). Most teams need tools from both categories, and picking the wrong one wastes budget and adoption goodwill.

The pressure to get this right is real. McKinsey research puts the productivity lift from generative AI in software development at 20–45%, which is great for application teams and a problem for platform teams trying to keep up with the resulting feature flow. Infrastructure investment is climbing on both fronts: more spend on the compute that trains and serves models, more spend on AI tools that manage everything else.

This guide covers both categories: the compute and MLOps stack in Part 1, and AI-powered infrastructure management in Part 2, where the more interesting product shift is happening.

AI infrastructure tools overview

Tools for building AI infrastructure

CoreWeave: GPU cloud built for AI workloads
Lambda Labs: straightforward GPU cloud for research and startups
Modal: serverless GPU compute
Weights & Biases: ML experiment tracking and model management
MLflow: open-source ML lifecycle platform
Hyperscaler AI platforms: AWS SageMaker, Google Vertex AI, Azure ML

AI-powered infrastructure management tools

Pulumi Neo: agentic AI with policy automation
Firefly AIaC: asset codification and IaC generation
env0 Cloud Compass: multi-IaC insights and analysis
Spacelift AI: run explanation and troubleshooting
Crossplane with Upbound: Kubernetes-native infrastructure
General-purpose code assistants: Copilot, Claude Code, Cursor, Gemini
AWS Application Composer: visual serverless builder

Quick picks

If you only have two minutes:

Enterprise compliance: Pulumi Neo. Executes changes (not only suggestions), ships with policy packs for CIS, HITRUST, NIST, and PCI DSS, and works with Terraform, CloudFormation, and resources created by hand.
Serious GPU compute: CoreWeave. Purpose-built for AI workloads, deep NVIDIA partnership, and prices that generally undercut the hyperscalers.
Best developer experience for ML: Modal. Decorate a Python function, get a GPU, pay by the second.
Open-source MLOps: MLflow. No vendor lock-in, runs anywhere, plays well with everything.

What is AI infrastructure?

The term covers two distinct categories that share almost no vendors.

Infrastructure for AI is the compute, storage, and orchestration that AI workloads run on. Training a large model is not a normal cloud workload: it wants thousands of GPUs talking to each other over fat, low-latency networks for weeks at a time. Inference is different again: lower latency, smarter batching, different hardware. General-purpose cloud was not designed for either case, which is why specialized GPU clouds and MLOps platforms exist.

AI-powered infrastructure management is the inverse: AI tools that manage cloud infrastructure. They generate infrastructure as code, run deployments, detect drift, and remediate policy violations. The pitch is that modern infrastructure (multi-cloud, containers, microservices, regulated workloads) has gotten too complex for humans to manage by hand and too varied for scripted automation to keep up with.

Most organizations end up needing both: somewhere to run their ML workloads, and something to keep the rest of the cloud sane.

Part 1: Tools for building AI infrastructure

These are the platforms you run AI and ML workloads on: GPU clouds for raw compute, MLOps platforms for the lifecycle around them.

CoreWeave

CoreWeave is the GPU cloud that broke out of the AI hype cycle into a real public company. They went public in 2025, signed a multi-billion-dollar capacity deal with OpenAI, and acquired Weights & Biases. Their thesis from day one was that AI workloads deserve infrastructure designed for AI workloads, not a GPU SKU bolted onto a general-purpose cloud.

License: Proprietary
Best for: Large-scale training and high-throughput inference; teams that need dedicated GPU capacity with first access to new NVIDIA hardware
Strengths: GPU infrastructure designed for AI; Kubernetes-native; direct NVIDIA partnership; handles distributed training at scale
Watch out for: Smaller global footprint than AWS/GCP/Azure; not a general-purpose cloud, so if you need RDS, S3, and a managed Kafka in the same provider, this isn’t it

Lambda Labs

Lambda has been the approachable GPU cloud for a long time. Environments come pre-configured with PyTorch and TensorFlow, and you can be running on an H100 in about as long as it takes to copy your SSH key.

License: Proprietary
Best for: Research teams, startups, and individual practitioners who want GPUs without a configuration tax
Strengths: Straightforward to start on; pre-configured deep learning environments; competitive on-demand pricing; strong learning resources
Watch out for: Smaller scale than CoreWeave or the hyperscalers; availability gets tight during demand spikes

Modal’s pitch is that you write a Python function, decorate it, and Modal handles the GPU. No capacity planning, no idle instances burning money overnight, no Dockerfile to maintain.

License: Proprietary
Best for: Variable ML workloads where reserved capacity would sit idle; data scientists who’d rather not learn Kubernetes
Strengths: Strong developer experience; serverless GPUs with automatic scaling; pay-per-second pricing; cold starts are fast for what they are
Watch out for: You give up infrastructure control. Not ideal for long training jobs that need reserved hardware or strict configuration requirements.

Weights & Biases

Weights & Biases is the de facto standard for ML experiment tracking and model management, integrated with essentially every framework and cloud you’d plausibly use. CoreWeave acquired the company in 2025, which has accelerated the joint roadmap but raised some neutrality questions for teams that prefer their tooling cloud-agnostic.

License: Proprietary with a free tier
Best for: ML teams that need shared experiment tracking, model versioning, and reporting
Strengths: Industry-leading experiment tracking and visualization; comprehensive model registry; strong team collaboration; broad integration surface
Watch out for: Costs scale quickly past the free tier; some teams self-host alternatives for data residency reasons

MLflow

MLflow is the leading open-source MLOps platform: experiment tracking, packaging, registry, and serving, with no lock-in. Originally built at Databricks, it’s now a broad open-source ecosystem with managed offerings from multiple vendors (including Databricks and the major clouds).

License: Apache 2.0
Best for: Teams that want MLOps without a vendor; or want the option to start managed and self-host later
Strengths: Open source; covers the full ML lifecycle; runs locally, on-prem, or managed; broad framework support
Watch out for: Self-hosting carries the usual operational tax; commercial alternatives have stronger collaboration UX out of the box

Hyperscaler AI platforms

The major clouds all sell end-to-end ML platforms. Each leads on the dimensions that line up with its parent cloud (Vertex for Google’s models and TPUs, SageMaker for AWS-native data pipelines, Azure ML for Microsoft-stack integration), but the wider integration with the rest of the cloud is the deciding factor.

AWS SageMaker: end-to-end ML on AWS, deeply integrated with S3 and Glue, with first-class connections to Lambda for serverless inference and to the rest of the AWS data stack. The default pick if your data already lives in AWS.
Google Vertex AI: Google’s ML stack, including TPUs for workloads that need them, plus access to Google’s foundation models. Strongest when paired with BigQuery.
Azure Machine Learning: the natural choice when the rest of your stack is Microsoft; first-party MLOps integrations across GitHub Actions, Azure DevOps, and Microsoft Fabric for downstream reporting. The right choice if you’re already an Azure shop with Microsoft compliance requirements.

The shared tradeoff: hyperscaler GPU compute typically runs 2–3x the per-hour price of specialized providers, and the platforms work best when you commit to them top to bottom. For organizations already inside one cloud, the unified billing and single support contract usually justifies the premium. For a new ML team starting from scratch, it rarely does.

Part 2: AI-powered infrastructure management tools

This is where the more interesting product shift is happening. Instead of running AI on infrastructure, these tools point AI at your infrastructure and let it do work. They’re a newer, AI-native layer on top of the broader infrastructure as code tooling landscape.

From code generation to agentic execution

Before the tool list, one distinction matters more than any feature comparison: whether the tool generates code or executes changes.

Code generation tools like GitHub Copilot suggest infrastructure code based on context. You review it, maybe edit it, run it yourself. The AI helps, but you’re still the one doing the work.

Agentic platforms generate the code and run it, with the guardrails you define. They understand your environment, handle multi-step workflows, and enforce policies on the way through. You describe the outcome; the platform makes it happen.

Capability	Code generation	Agentic execution
Generates infrastructure code	Yes	Yes
Understands infrastructure context	Limited	Deep
Executes changes	No	Yes
Handles multi-step workflows	No	Yes
Enforces policies automatically	No	Yes
Remediates drift and violations	No	Yes

Where you want to land on this spectrum is mostly a governance question, not a productivity one.

Pulumi Neo

Pulumi Neo is Pulumi’s agentic AI for infrastructure. The distinguishing claim is execution: Neo doesn’t only suggest a Terraform snippet, it figures out the right resources, generates the code, and runs the deployment inside whatever guardrails you’ve set.

License: Proprietary (Pulumi Cloud)
Best for: Platform engineering teams that want AI automation with real policy controls, especially in regulated industries

A few things that set it apart in practice:

Policy automation and compliance. Neo is integrated with Pulumi Insights and Governance, which ships pre-built policy packs for CIS benchmarks, HITRUST CSF, NIST SP 800-53, and PCI DSS. Detection and remediation run in the same loop: Neo finds a violation, generates a fix, and (subject to approvals) applies it. You can batch-remediate across stacks and accounts with prompts like “find and fix all unencrypted S3 buckets across our AWS accounts.”

Works with infrastructure you didn’t create with Pulumi. Neo’s governance applies to Pulumi-managed resources, Terraform state, CloudFormation stacks, and resources someone clicked together in the AWS console. That matters because the realistic adoption path is to point Neo at what you have, audit it, and gradually bring it under management, not to migrate everything first.

Progressive autonomy. Trust levels are configurable. Start with human approval for everything; loosen it for well-defined, low-risk operations as confidence builds; keep production and sensitive resources behind strict approvals. This is the part that tends to determine whether enterprises actually deploy agentic AI in anger, versus letting it sit as a sandbox toy.

IDE and CI/CD integration. The Pulumi MCP Server brings Neo into Cursor, Claude Code, Claude Desktop, Windsurf, and any other MCP-compatible client. The Pulumi Cloud UI is the home base for approvals, history, and remediation status. Neo also slots into CI/CD pipelines for pre-merge policy remediation.

Case studies:

Werner Enterprises reduced infrastructure provisioning time from 3 days to 4 hours using Pulumi.
Spear AI cut their Authority to Operate (ATO) timeline from an expected 1.5 years to roughly 3 months by using policy-as-code to evidence compliance controls for auditors.

Tradeoff to be honest about: Neo gets more valuable the deeper you are in the Pulumi ecosystem. If you’re running IaC, ESC, and policy packs already, Neo has a lot of context to draw on. If you’re kicking the tires, it’s still useful, but the differentiating capability (context-aware, policy-respecting agentic execution) is harder to feel.

Firefly AIaC

Firefly is an asset management platform with AI features bolted on top of a strong core. The core capability is asset codification: it discovers cloud resources you already have and generates the IaC for them.

License: Proprietary
Best for: Teams that need to codify existing cloud footprints or generate IaC from natural language

Strengths: solid asset discovery, multi-cloud coverage, natural-language IaC generation, drift detection with remediation hooks. Caveat: AI features here are supplementary to the asset management product, not the main event, and Firefly is less focused on agentic execution than on inventory and policy.

env0 Cloud Compass

env0’s Cloud Compass adds AI to env0’s IaC automation platform, focusing on analysis rather than autonomous execution.

License: Proprietary
Best for: Multi-IaC shops that want AI-generated PR summaries, drift explanations, and cost insights

Strengths: multi-tool support across Terraform, OpenTofu, Pulumi, and Terragrunt; AI-generated PR summaries; drift cause analysis; cost estimation. Caveat: this is analysis and explanation, not action: Cloud Compass complements an agentic tool rather than replacing one.

Spacelift AI

Spacelift’s AI work is focused on the post-run experience: explaining what happened in a deployment and helping troubleshoot failures.

License: Proprietary
Best for: GitOps shops that want AI assistance reading complex runs and diagnosing failed deployments

Strengths: AI-powered run explanation; troubleshooting guidance for failures; broad IaC tool support; mature CI/CD integration. Caveat: like Spacelift as a whole, this is observation and explanation, not generation or execution. Pair with something that writes the code.

Crossplane with Upbound

Crossplane brings Kubernetes-style declarative management to cloud resources. Upbound is the company that commercializes it, and is layering AI-native control-plane capabilities into the 2.0 generation.

License: Apache 2.0 (Crossplane); proprietary (Upbound)
Best for: Teams already deep in Kubernetes that want to manage cloud resources the same way

Strengths: Kubernetes-native model; native GitOps fit; very active OSS community; AI control-plane work emerging from Upbound. Caveat: the learning curve is real if you’re not already living in Kubernetes; the commercial AI features are still maturing.

General-purpose code assistants

General-purpose AI coding assistants are the tools your developers already have open: GitHub Copilot, Claude Code, Cursor, and Google’s Gemini and Antigravity. They write Terraform HCL, Pulumi programs, and CloudFormation templates competently, about as well as they write anything else.

License: Proprietary (subscription), varies by tool
Best for: Developers who want broad code assistance, including infrastructure code, inside their existing editor

Strengths: excellent line-by-line code completion; broad language support; first-class editor integration; trained on huge corpora. Caveat: no infrastructure context. They don’t know what’s in your account, what your policies are, or which subnet you should pick. Treat their IaC suggestions as first-pass scaffolding, not production output.

AWS Application Composer

Application Composer is AWS’s visual builder for serverless applications. Drag services onto a canvas, get a CloudFormation template out, with AI suggestions for service configuration along the way.

License: Proprietary (AWS, included)
Best for: Teams building AWS serverless apps who prefer a visual workflow

Strengths: visual development for serverless; direct AWS integration; AI suggestions for service configuration; emits CloudFormation. Caveat: AWS-only, CloudFormation-only, and best suited to serverless rather than general infrastructure.

Comparison tables

Infrastructure for AI

Tool	Category	Key strength	Limitation	Pricing	Best for
CoreWeave	GPU cloud	Purpose-built GPU infra, NVIDIA partnership	Not a general-purpose cloud	Per-GPU-hour	Large-scale AI training
Lambda Labs	GPU cloud	Approachable, pre-configured environments	Smaller scale	Per-GPU-hour	Research teams, startups
Modal	Serverless GPU	Developer experience, pay-per-second	Less infrastructure control	Pay-per-use	Variable ML workloads
Weights & Biases	MLOps	Industry-standard experiment tracking	Costs scale quickly	Free tier + paid	ML team collaboration
MLflow	MLOps	Open source, no lock-in	Self-hosting overhead	Free (self-hosted)	Flexible ML lifecycle
AWS SageMaker	Hyperscaler	AWS ecosystem integration	Higher cost, lock-in	Per-use	AWS-native orgs
Google Vertex AI	Hyperscaler	Google models, TPU access	Lock-in	Per-use	Google Cloud users
Azure ML	Hyperscaler	Microsoft integration, enterprise features	Lock-in	Per-use	Microsoft ecosystem

AI-powered infrastructure management

Tool	Approach	Key strength	Limitation	Pricing	Best for
Pulumi Neo	Agentic AI	Execution + policy automation	Best within Pulumi ecosystem	Pulumi Cloud tiers	Enterprise platform teams
Firefly AIaC	Asset management	Asset codification, IaC generation	AI is supplementary	Proprietary	Codifying existing infra
env0 Cloud Compass	Multi-IaC platform	Multi-tool support, PR analysis	Analysis, not execution	Proprietary	Multi-IaC environments
Spacelift AI	CI/CD platform	Run explanation, troubleshooting	Observation, not action	Proprietary	GitOps workflows
Crossplane / Upbound	Kubernetes-native	K8s patterns for infra	Requires K8s expertise	Open source + commercial	Kubernetes-native teams
Code assistants	Code assistant	Broad language support, IDE	No infrastructure context	Subscription	General code assistance
AWS Composer	Visual builder	Visual serverless development	AWS- and CFN-only	Included with AWS	AWS serverless apps

How to choose

There’s no universal best tool. Five questions sort the field quickly:

Cloud strategy. Multi-cloud means tools like Pulumi Neo, Firefly, env0, or Crossplane. Single-cloud commitment means hyperscaler-native tools may integrate more deeply (AWS Composer, SageMaker, and so on).
Team expertise. Programmers gravitate to tools that use real languages (Pulumi Neo, Pulumi IaC). Kubernetes teams find Crossplane natural; everyone else finds it steep. Teams that prefer visual workflows should look at AWS Composer or env0’s UI.
Compliance. Regulated industries (healthcare, finance, government) get the most value from tools with pre-built compliance packs and audit trails. Pulumi Neo’s CIS/HITRUST/NIST/PCI packs are the most direct fit. If preventative policy enforcement matters, prefer tools that block non-compliant deployments rather than flag them after the fact.
Existing footprint. Greenfield projects can use anything. Brownfield is where it gets interesting: Pulumi Neo works against Terraform, CloudFormation, and manually-created resources, which lets you adopt incrementally instead of migrating first. Mixed-IaC shops should also look at env0.
Budget. Open source first: MLflow for MLOps, Crossplane for Kubernetes-native infra. Open source is not free, though: self-hosting carries a real total cost of ownership in hosting, maintenance, and the expertise to operate it. Commercial tools (Pulumi Cloud, env0, Spacelift) fold that operational cost into the price, on top of support, SLAs, and the enterprise-tier features open source can lack.

Before adopting anything, get visibility into what you have today, pilot on staging where mistakes are cheap, and define success metrics up front: time to provision, policy violation rates, mean time to remediate. The best AI infrastructure tool is the one your team will actually use, which means meeting developers where they already work.

Key trends and outlook

From copilots to agents. “AI suggests code” and “AI runs the deploy” are different products with different governance implications. The teams getting value from agentic tools have figured out which tasks to delegate fully, which to keep human-in-the-loop, and which to leave alone.

Progressive autonomy. Enterprise adoption follows a predictable shape: visibility → recommendations → human-approved execution → autonomous execution for well-understood scenarios. Tools that support that graduation will see stronger enterprise traction than tools that force an all-or-nothing choice.

Policy as the control plane. As AI takes on more infrastructure tasks, policy frameworks become the primary control plane. Done well, policy becomes an enabler (guardrails that let you safely expand automation) rather than a brake on velocity.

MCP standardization. The Model Context Protocol is becoming the integration standard between AI assistants and infrastructure tools. The practical upshot is that the IDE is increasingly a viable surface for managing infrastructure, with AI mediating between natural language and the underlying APIs.

Consolidation. CoreWeave acquiring Weights & Biases and NVIDIA acquiring Run:ai both point toward integrated platforms across the AI infrastructure stack. For tool selection today, that’s an argument for picking vendors with clear strategic direction over point solutions likely to be acquired or out-competed.

Frequently asked questions

What is the best AI agent for cloud infrastructure management?

For enterprise governance plus true agentic capability, Pulumi Neo is currently the most complete offering: it executes changes (not just suggests them), integrates with pre-built compliance frameworks, and works with infrastructure regardless of how it was provisioned. For Kubernetes-native shops, Crossplane with Upbound’s emerging AI features is worth tracking.

How can I use generative AI to manage cloud infrastructure?

Start by identifying the repetitive, time-consuming infrastructure work in your team. The highest-value early use cases tend to be:

Code generation: write IaC from natural-language descriptions, then review.
Documentation: explain unfamiliar configurations and reduce onboarding time.
Troubleshooting: analyze logs, errors, and configs to suggest likely causes.
Security and compliance: scan for violations and generate fixes.
Full automation: for shops that want it, agentic platforms like Pulumi Neo execute provisioning workflows end-to-end with governance controls intact.

What is agentic AI for infrastructure?

Agentic AI for infrastructure means AI systems that autonomously execute infrastructure tasks, not just generate code suggestions. The difference from a code assistant is action: an agent understands your environment, respects your policies, and performs multi-step work (provisioning, configuration, security controls) within the boundaries you’ve defined.

How do AI agents improve DevOps workflows?

By automating the repetitive parts (provisioning, drift remediation, policy enforcement), reducing context-switching, and catching issues earlier. Teams that have rolled out agentic tools well report faster provisioning, fewer policy violations slipping into production, and quicker compliance remediation. The compounding effect (engineers freed for higher-value work as the agent absorbs the routine) is the actual point.

What’s the difference between AI code generation and agentic execution?

Code generation suggests IaC for a human to review and run. Agentic execution generates the code and runs it, with policy and governance enforced along the way. It’s the difference between a knowledgeable colleague who suggests an approach and a knowledgeable colleague who also ships the change with appropriate oversight.

Can AI generate Terraform or Pulumi programs?

Yes. Most general-purpose AI assistants (Copilot, Claude, Gemini, ChatGPT, Cursor) can produce Terraform HCL, Pulumi programs in TypeScript / Python / Go, and CloudFormation. Quality varies. Generic assistants lack environment context and will happily emit syntactically correct but operationally wrong code. Infrastructure-specific tools like Pulumi Neo generate code that’s aware of your existing resources, policies, and provider constraints.

Can AI help with infrastructure compliance and policy automation?

Yes, and this is one of the highest-leverage uses of AI in infrastructure. Tools like Pulumi Neo detect policy violations across your footprint (including resources created outside IaC), generate compliant remediation, and apply it with the approvals you require. Pre-built frameworks for CIS, HITRUST, NIST, and PCI DSS shorten what would otherwise be a long manual compliance project.

Are AI infrastructure tools secure for enterprise use?

Enterprise-grade ones are. Look for RBAC, full audit logging of AI actions, preventative policy enforcement (not just detection), and human-in-the-loop approvals for sensitive operations. SOC 2, data residency options, and configurable autonomy levels are table stakes. The risk to avoid is wiring a consumer AI assistant directly into a production cloud account without those controls.

How do I choose between different AI infrastructure tools?

Match the tool to your context: existing clouds and IaC, team skills, compliance requirements, budget. Enterprise platform teams with governance needs should evaluate Pulumi Neo first. MLOps-focused teams should look at Weights & Biases or MLflow. For general code assistance inside the editor, a general-purpose assistant like Copilot, Cursor, or Gemini is the default. Most organizations end up with more than one: a code assistant for daily development and an agentic platform for production infrastructure.

What are the best tools for machine learning infrastructure?

For GPU compute, CoreWeave leads at scale, Modal wins for variable workloads and developer experience, and the hyperscalers are the default pick if you’re already inside one of them. For experiment tracking and model management, Weights & Biases is the leading commercial platform; MLflow is the leading open-source one. Most teams pick on the deploy model and pricing fit rather than capability gap. For the cloud infrastructure underneath the ML workloads, the same infrastructure management story applies: Pulumi Neo can provision and govern ML infrastructure the same way it handles everything else.

Conclusion

Two categories, two problems. GPU clouds and MLOps platforms (CoreWeave, Lambda, Modal, hyperscaler trio, W&B, MLflow) solve the compute and lifecycle problem for running AI workloads. AI-powered infrastructure tools (Neo, Firefly, env0, Spacelift, Crossplane, code assistants, Composer) solve the management problem for everything else.

For GPU workloads, the choice mostly comes down to scale and where you already are. For infrastructure management, the real question is how much you actually want AI to do. Code assistants help you write IaC faster, but you’re still running it. Agentic platforms like Pulumi Neo execute changes and enforce policy on the way through, with the guardrails you control.

The pattern from teams getting real value: treat AI as a force multiplier on routine work (provisioning, drift, compliance) and keep human judgment in the loop for the architecture and the edge cases.

If you want to see agentic infrastructure management running against real resources, start with Pulumi Neo.

Self-Verifying AI Agents: Vercel's Agent-Browser in the Ralph Wiggum Loop

Engin Diri — Tue, 20 Jan 2026 00:00:00 +0000

In my previous post about the Ralph Wiggum technique, Claude Code built a complete serverless URL shortener on AWS. The setup included Playwright MCP for end-to-end testing. It worked. But I kept wondering if there was something better for AI-driven browser automation. Then Vercel released agent-browser, and I had to try it.

Why browser automation matters for AI coding

When an AI coding agent builds a frontend, someone has to verify it works. Without browser automation, that someone is you. The AI finishes and says “done,” but you can’t trust that claim until you open a browser and click around yourself.

Browser automation changes this. The AI verifies its own work. It builds a component, launches a browser, tests the interaction, confirms behavior matches expectations. If something breaks, it fixes the code and tests again. The validation loop runs without you.

This matters more as AI agents take on larger tasks. A quick component fix might not need automated testing. But when an agent builds an entire dashboard from scratch, you need proof that the deployed application actually works.

The context problem with browser automation

Playwright MCP gives you powerful browser control, but it comes with overhead. Every screenshot, every DOM snapshot, every accessibility tree adds tokens to your context window. GitHub issue #889 documents a 6x token increase between versions 0.0.30 and 0.0.32. Users report single screenshots consuming over 15,000 tokens. Some exhausted their entire five-hour token allocation in just a few automation steps.

The problem is verbose output. Full accessibility trees contain every element on the page with all their properties. Console message logging adds more. Each piece of information might be useful for debugging, but together they overwhelm the context window.

This creates a frustrating tradeoff. You want rich browser interaction for thorough testing, but that richness costs tokens. Fewer tokens means fewer iterations before hitting limits.

Vercel’s “less is more” philosophy

Vercel ran into something similar with their D0 text-to-SQL agent. Their research documents what happened when they reduced tool complexity.

The original architecture used 17 specialized tools. Each tool handled one specific operation: create tables, insert rows, run queries, validate schemas. The approach seemed logical. Specialized tools should produce better results than general ones.

The numbers told a different story. With 17 tools, they got 80% success (4 out of 5 queries), averaging 274.8 seconds and ~102,000 tokens. The worst case took 724 seconds, burned 145,463 tokens, and still failed.

Then they rebuilt with just two tools: ExecuteCommand and ExecuteSQL. Success jumped to 100%. Average execution dropped to 77.4 seconds (3.5x faster). Token usage fell to ~61,000 (37% reduction). The worst case took 141 seconds, used 67,483 tokens, and succeeded.

Vercel’s takeaway: “We were constraining reasoning because we didn’t trust the model to reason.” Fewer tools meant the model could think more freely about how to accomplish tasks. The simplicity reduced confusion and context waste.

Applying “less is more” to browser automation

agent-browser takes the same approach. Instead of separate tools for clicking, typing, scrolling, and navigating, it has a unified CLI with one clever idea: the snapshot + refs system.

When you request a page snapshot, agent-browser returns something like this:

- button "Sign In" [ref=e1]
- textbox "Email" [ref=e2]
- textbox "Password" [ref=e3]
- link "Documentation" [ref=e4]

Those @e1, @e2 references are stable element identifiers. To click the sign-in button, you run click @e1. No CSS selectors. No XPath expressions. No waiting for the DOM to stabilize. The reference points to that exact element.

This cuts out the verbosity of full accessibility trees. You get just enough information to understand the page structure and interact with elements. The AI can reason about what it sees without drowning in metadata.

Installing agent-browser

Setup is simple:

npm install -g agent-browser && agent-browser install

This installs the CLI and downloads a bundled browser. You don’t need to install any additional browsers.

For Claude Code integration, install the official skill from the agent-browser package. You can either copy it from node_modules:

cp -r node_modules/agent-browser/skills/agent-browser .claude/skills/

Or download it directly:

mkdir -p .claude/skills/agent-browser
curl -o .claude/skills/agent-browser/SKILL.md \
 https://raw.githubusercontent.com/vercel-labs/agent-browser/main/skills/agent-browser/SKILL.md

The skill gives Claude Code better context than just running agent-browser --help.

Unlike Playwright MCP, there’s no server configuration. Agent-browser runs as a standalone CLI that Claude Code invokes directly through bash.

The experiment: adding analytics

I wanted a realistic test scenario, so I added an analytics dashboard to the url-shortener-saas project from my previous post. The feature tracks click events with metadata (browser, device, country, referrer) and displays them through interactive charts.

This follows the same “Ralph Wiggum” workflow from my previous post: write a feature-prompt.md that describes what you want, then let Claude Code implement, deploy with Pulumi, and verify with browser automation. Here’s a snippet from the feature prompt:

## Backend Requirements

### New DynamoDB Table: Analytics Events

Create a new DynamoDB table `url-shortener-analytics-{stack}` with:
- Partition Key: shortCode (String)
- Sort Key: timestamp (String, ISO 8601 format)
- Attributes: browser, deviceType, country, referrer, etc.

### New Lambda: analytics.ts

GET /api/analytics/{shortCode}
- Returns timeline, browsers, devices, countries, referrers
- Query params: from, to, granularity

## Success Criteria

1. `pulumi up` deploys successfully without errors
2. All existing E2E tests still pass
3. New analytics E2E tests pass
4. Charts render with real data after generating test clicks

Claude Code reads this, writes the Lambda handlers, updates the Pulumi infrastructure code, and deploys. The infrastructure changes are straightforward:

// Analytics events table
const analyticsTable = new aws.dynamodb.Table("analytics-table", {
 name: `${projectName}-analytics-${stack}`,
 billingMode: "PAY_PER_REQUEST",
 hashKey: "shortCode",
 rangeKey: "timestamp",
 attributes: [
 { name: "shortCode", type: "S" },
 { name: "timestamp", type: "S" },
 ],
 globalSecondaryIndexes: [{
 name: "by-date",
 hashKey: "shortCode",
 rangeKey: "timestamp",
 projectionType: "ALL",
 }],
});

After pulumi up succeeds, the agent needs to verify the deployed feature works. That’s where browser automation comes in. The feature prompt specifies verification requirements:

## End-to-End Verification

After deployment, use the `/agent-browser` skill to verify:
1. Analytics link appears in navigation
2. Analytics page loads without errors
3. Charts render (timeline, browser, device, geographic)
4. URL-specific analytics work from dashboard
5. Click data appears after generating test clicks

The test suite covered six scenarios: homepage load, URL shortening, dashboard view, analytics navigation, analytics overview, and date filter functionality. Nothing fancy, just the basics you’d want to verify after deploying.

I ran the exact same tests with both Playwright MCP and agent-browser to see how much context each consumed.

Agent-browser workflow in practice

Here’s what the CLI interaction looked like during my test run.

Navigate to the deployed application:

$ agent-browser open https://d1232drths1aav.cloudfront.net
✓ Snip.ly - Modern URL Shortener
 https://d1232drths1aav.cloudfront.net/

Snapshot to see available elements (the -i flag filters to interactive elements only):

$ agent-browser snapshot -i
- link "S Snip.ly" [ref=e1]
- link "Home" [ref=e2]
- link "Dashboard" [ref=e3]
- link "Analytics" [ref=e4]
- link "Docs" [ref=e5]
- button "Switch to dark mode" [ref=e6]
- link "Get Started" [ref=e7]
- textbox "Paste your long URL here..." [ref=e8]
- button "Shorten URL" [ref=e9]

That entire homepage snapshot is 280 characters. Playwright MCP returned 8,247 characters for the same page.

Fill the URL input and click the shorten button:

$ agent-browser fill @e8 "https://example.com/agent-browser-e2e-test"
✓ Done

$ agent-browser click @e9
✓ Done

Each action confirmation is 6 characters. Playwright MCP returns the full page state after every click - 12,891 characters when I clicked the shorten button.

Navigate to analytics:

$ agent-browser click @e4
✓ Done

$ agent-browser wait --load networkidle && agent-browser snapshot -i
✓ Done
- link "S Snip.ly" [ref=e1]
- link "Home" [ref=e2]
- link "Dashboard" [ref=e3]
- link "Analytics" [ref=e4]
- button "Last 7 days" [ref=e8]
- button "Last 30 days" [ref=e9]
- button "Last 90 days" [ref=e10]
- link "1 analytics-e2e-test https://example.com/analytics-test-verification 5" [ref=e11]
- link "2 test-url https://www.example.com/this-is-a-very-long-url... 4" [ref=e12]

The analytics snapshot shows date filter buttons and top URLs with click counts. 385 characters versus Playwright MCP’s 4,127.

Test the date filter:

$ agent-browser click @e9
✓ Done

$ agent-browser screenshot analytics-30-day-filter.png
✓ Screenshot saved to analytics-30-day-filter.png

The ref-based workflow is deterministic. Each command operates on a specific element from the snapshot. No guessing about selectors.

The numbers: 82.5% context reduction

Same six tests, both tools:

Metric	Playwright MCP	Agent-Browser	Reduction
Total response characters	31,117	5,455	82.5%
Largest single response	12,891	2,847	77.9%
Average response size	3,112	328	89.5%
Homepage snapshot	8,247	280	96.6%
Dashboard snapshot	12,891	2,847	77.9%

The difference is what each tool returns after every action.

Playwright MCP returns the full accessibility tree after every click:

### Page state
- Page URL: https://d1232drths1aav.cloudfront.net/dashboard
- Page Title: Snip.ly - Modern URL Shortener
- Page Snapshot:
- generic [ref=e2]:
 - banner [ref=e3]:
 - generic [ref=e4]:
 - link "S Snip.ly" [ref=e5] [cursor=pointer]:
 - /url: /
 - generic [ref=e6]: S
 - generic [ref=e7]: Snip.ly
 - navigation [ref=e8]:
 - link "Home" [ref=e9] [cursor=pointer]:
 - /url: /
 - text: Home
 ...
[12,891 characters continues...]

Agent-browser returns:

✓ Done

6 characters versus 12,891 for the same button click.

Six tests consumed ~31K characters with Playwright MCP versus ~5.5K with agent-browser. At roughly 4 characters per token, that’s ~7,800 tokens versus ~1,400. An AI agent could run 5.7x more tests in the same context budget.

What I noticed

Past the numbers, working with agent-browser felt different in ways that are hard to quantify.

The compact snapshots changed the rhythm of iteration. A typical page fit in a few hundred tokens instead of thousands, so Claude Code could run more test cycles before hitting limits. I spent less time worrying about context and more time actually testing.

Element refs removed a frustration I’d had with Playwright. CSS selectors break when someone changes a class name or restructures the DOM. With agent-browser, a button is just @e9. It doesn’t care about styling. That predictability was a relief.

What worked well:

Snapshots stay small enough that you don’t think about them
Refs mean no selector debugging
The CLI just works with Claude Code’s bash tool
No MCP server to configure

Agent-browser is early. Documentation is thin, and I read the source more than once to figure out edge cases.

Where I hit friction:

Modals that appear after API calls needed manual wait logic
Playwright’s waiting mechanisms are more mature
Hidden or dynamically loaded elements sometimes didn’t show up without explicit waits

For my URL shortener tests, agent-browser used fewer tokens per cycle, and the ref-based approach was more predictable than selector-driven automation.

Playwright MCP still wins on depth. Network interception, multi-tab handling, PDF generation, better waiting logic—if you need those, you need Playwright. For complex browser automation, it’s the more capable tool.

When to use each

Agent-browser fits long autonomous sessions where context budget matters, basic navigation and verification tasks, and setups where you want to skip MCP configuration. CLI-based skills also avoid the schema overhead—tool definitions for multi-tool MCPs eat tokens even when idle.

Playwright MCP fits when you need the advanced stuff: network interception, PDF generation, multi-tab workflows, or sophisticated synchronization. It’s also the right choice if you have existing Playwright test suites. If the full MCP schema feels heavy, Playwright skills offer a lighter wrapper.

Start with agent-browser for AI validation loops. Move to Playwright when you outgrow it.

Future of the Cloud: 10 Trends Shaping 2026 and Beyond

Sara Huddleston — Thu, 04 Dec 2025 07:56:40 +0000

In 2026, several trends will dominate cloud computing, driving innovation, efficiency, and scalability. From Infrastructure as Code (IaC) to AI/ML, platform engineering to multi-cloud and hybrid strategies, and security practices, let’s explore the 10 biggest emerging trends.

On This Article

1. Cloud Will Become a Business Necessity by 2028
2. Hyperscalers Accelerate AI-Driven Cloud Expansion
3. Hybrid and Multi-Cloud to Drive Innovation
4. Enterprises Rebuild Their Cloud Foundations to Operationalize AI
5. IaC Drives Scalable Cloud, Multi-Cloud, and AI Operations
6. DevSecOps Evolves Into AI-Integrated Security
7. Platform Engineering and Internal Developer Platforms
8. AIOps Matures Into a Cloud Operations Standard
9. Kubernetes Dominance and Increased Complexity
10. AI Code Assistants in the Enterprise
The Future of Cloud: Reinvented for an AI-First Decade

1. Cloud Will Become a Business Necessity by 2028

According to Gartner, by 2028 the cloud will be the key driver for business innovation, and estimates that over 95% of new digital workloads will be deployed on cloud-native platforms.

The future of cloud computing. Credit: Gartner

According to McKinsey & Company’s “In search of cloud value” report:

Cloud value is driven by innovation, worth 5x more than cost savings.
EBITDA uplift of 20–30% by 2030 for high-performing organizations.
Asia leads in projected cloud value, followed by the US and Europe.
High-ROI organizations excel by aligning cloud strategy with business priorities, building strong cloud foundations, and using modern operating models.

Teams succeeding in this transition increasingly use Infrastructure as Code, automation, and unified governance frameworks like Pulumi Insights + Policies to operationalize this value.

2. Hyperscalers Accelerate AI-Driven Cloud Expansion

Hyperscalers are making the largest infrastructure investments in cloud history — nearly all centered on AI workloads, inference, and high-performance compute.

AWS has integrated Anthropic’s Claude 3 and Claude 4 models into Amazon Bedrock for enterprise LLM workflows. “Claude Opus 4 and Claude Sonnet 4 are available today in Amazon Bedrock, enabling customers to build agents with stronger reasoning, memory, and tool use.” — AWS, May 2025
Microsoft Azure revenue rose 33% year-over-year in Q3 (ended March 31), outperforming estimates of ~29.7%. AI contributed 16 percentage points to this growth, up from 13 points in the prior quarter. “Microsoft is on track to invest approximately $80 billion to build out AI-enabled datacenters to train AI models and deploy AI and cloud-based applications around the world,” said Brad Smith, the Microsoft Vice Chair and President.
Google Cloud is committing $25 billion over two years for data center and AI infrastructure expansion across the PJM grid, with total capital expenditure for 2025 ranging from $75–85 billion. “As our CEO has said, in these early days of a very transformative technology, the risks of under-investing are dramatically higher than the risks of over-investing,” said Eunice Huang, Head of AI and Emerging Tech Policy.
Oracle anticipates 15–20% cloud revenue growth in FY 2026–2027 attributable to AI infrastructure demand, tied to its partnership in the Stargate initiative.

As hyperscalers integrate AI deeper into their service layers, engineering teams must adapt with IaC-driven automation, reusable patterns, and policy controls to deploy cloud and AI infrastructure consistently. See how organizations deploy AWS infrastructure at the speed of AI with Pulumi and Pulumi Policies.

3. Hybrid and Multi-Cloud to Drive Innovation

Hybrid and multi-cloud strategies are now mainstream:

Hybrid cloud will grow from $130B to $310–330B by 2030 (ResearchAndMarkets).
87% of enterprises run workloads across multiple clouds (Mordor Intelligence).
Gartner predicts that 40% of enterprises will adopt hybrid compute architectures in mission-critical workflows by 2028 (up from 8%).

Credit: Cloud Worldwide Service, Forbes

As AI and regulatory requirements grow, organizations must deploy workloads across AWS, Azure, Google Cloud, on-prem, and edge — while maintaining consistent security, compliance, and configuration.

Modern cloud teams use:

Infrastructure as Code for consistent multi-cloud provisioning and environment standardization, forming the backbone of AI infrastructure orchestration
Reusable components and internal platforms to define scalable architecture patterns and accelerate delivery across Kubernetes, AI/ML pipelines, and hybrid environments
Policy-driven guardrails to maintain cost, security, and compliance across environments, supporting cloud governance automation and modern cloud cost governance

Pulumi enables all three through its multi-cloud IaC model, Pulumi Policies, and internal developer platform capabilities.

4. Enterprises Rebuild Their Cloud Foundations to Operationalize AI

While hyperscalers are transforming the global cloud platform, enterprises face a different challenge: adapting their own cloud foundations to support AI at scale. Organizations are moving beyond prototypes and integrating AI into core products, internal workflows, and customer-facing systems, requiring new levels of automation, governance, and AI infrastructure orchestration.

According to Gartner, global AI infrastructure spending is expected to surpass $2 trillion in 2026. IDC predicts that by 2027, more than 50% of enterprises will use AI agents to drive core workflows, which requires scalable, secure, and automated cloud architectures to support model execution and orchestration.

To enable this transition, enterprises are investing in:

GPU provisioning and orchestration, data pipelines, vector databases, feature stores, and LLM infrastructure needed for real-time AI workloads.
Data pipelines, vector databases, and feature stores needed for real-time AI workloads
Model-serving infrastructure, including gateways, inference routers, and autoscaling layers
Strong identity, secrets, and access controls as AI systems increase security exposure
Automation through Infrastructure as Code to ensure reproducibility and reduce drift
Policy-driven governance to secure cost, compliance, and architectural consistency

As AI becomes deeply embedded across engineering organizations, teams are increasingly using software engineering approaches such as Infrastructure as Code, reusable components, platform engineering, and policy automation to standardize how AI infrastructure is deployed, scaled, and secured across clouds.

To support this shift, Pulumi’s perspective on Superintelligence Infrastructure explains why AI workloads, from pre-training to inference at massive scale, require dynamic infrastructure orchestration rather than static configuration.

Pulumi users increasingly rely on:

Pulumi IaC for standardized AI infrastructure
Pulumi ESC to manage all secrets and configuration at scale
Pulumi Insights for visibility and misconfiguration analysis
Pulumi Policies for AI-specific guardrails in code, cost detection, and to provide automated compliance protections

5. IaC Drives Scalable Cloud, Multi-Cloud, and AI Operations

As cloud environments expand and AI workloads demand highly dynamic infrastructure, Infrastructure as Code (IaC) is becoming the foundation for scaling reliably across all environments. Organizations are increasingly adopting IaC in general-purpose languages to unify development and infrastructure workflows, reduce configuration drift, and deliver cloud resources at speed.

Modern Infrastructure as Code is advancing far beyond simple provisioning:

Standardizing multi-cloud and hybrid patterns so teams can deploy consistently across AWS, Azure, Google Cloud, on-prem, and edge environments.
Integrating seamlessly with cloud providers and third-party services, including data platforms and messaging systems like CockroachDB, Confluent Cloud, and Kafka.
Providing deeper validation and type-safety, ensuring parameters, dependencies, and security controls are correct before deployment.
Improving cloud resource efficiency and visibility with tools like Pulumi Insights Discovery.
Embedding security and compliance through Policy as Code, enforcing guardrails, cost controls, and regulatory requirements automatically, enabling truly policy-driven cloud management.
Enabling intelligent automation, from unit and integration tests to auto-remediation policies and policy-driven approvals.
Incorporating AI-driven optimization and insights, helping teams detect misconfigurations, analyze usage patterns, and generate infrastructure updates with tools like Pulumi Neo and Pulumi Policies.

As organizations scale both traditional cloud workloads and AI-driven systems, IaC has become critical for achieving secure, repeatable, and high-velocity operations across every environment.

6. DevSecOps Evolves Into AI-Integrated Security

As AI becomes embedded across cloud-native systems, DevSecOps is entering a new era. Gartner predicts that by 2028, over 50% of enterprises will use AI security platforms to protect their AI investments. Below are the 3 key predictions for the future of DevSecOps:

AI-driven security automation: Teams will increasingly rely on AI to detect threats, enforce policies, and generate secure infrastructure patches. See Pulumi’s capabilities in AI-powered remediation.
More focus on secrets management: With AI systems accessing more sensitive data, secure secret storage will be essential. Pulumi ESC helps teams centralize and govern credentials, keys, and tokens safely.
Greater cross-team collaboration: Dev, Sec, and Ops workflows will converge under shared frameworks: IaC, policy automation, runtime scanning, and GitOps.

As organizations increase their use of AI across cloud-native systems, the need for tightly aligned security, governance, and cloud governance automation becomes even more urgent. At the Gartner Data & Analytics Summit in Sydney, Carlie Idoine, VP Analyst at Gartner, emphasized this growing dependency:

"[AI]… it doesn’t deliver value on its own – AI needs to be tightly aligned with data, analytics, and governance to enable intelligent, adaptive decisions and actions across the organization."

This perspective mirrors what we’re seeing across modern DevSecOps practices: AI can amplify security, but only when paired with strong foundations in secrets management, governance, and cross-team collaboration.

7. Platform Engineering & Internal Developer Platforms (IDPs)

According to Gartner, by 2026, 80% of large software engineering organizations will establish platform engineering teams as internal providers of reusable services, components, and tools for application delivery. Platform engineering will ultimately solve the central problem of cooperation between software developers and operators.

Mid-size to large companies will begin or continue to invest in implementing platform engineering practices, with large tech companies as first adopters. They will provide Internal Developer Platforms (IDP) to elevate the Developer Experience (DX, sometimes referred to as DE or DevEx), helping them work faster, like abstracting the complexities of configuring, testing, and validation, deploying infrastructure, and scanning their code for security.

Internal developer platform-in-a-box. Credit: Pulumi

IDPs are reshaping how developers interact with cloud infrastructure, bringing together platform engineering, automation, and emerging AI platform engineering practices.

8. AIOps Matures into a Cloud Operations Standard

AIOps is becoming mainstream, helping teams predict failures, auto-scale infrastructure, and resolve incidents with minimal manual effort. As AI and automation continue to evolve, the fusion of these technologies will enable organizations to achieve unprecedented levels of efficiency and scalability.

Proactive Operations: AI-powered tools will assist teams in foreseeing issues with greater accuracy, minimizing downtime, and reducing the firefighting nature of incident management. These tools will automatically detect anomalies, optimize performance, and trigger remediation actions.
Intelligent Automation: Routine operational tasks like patching, monitoring, and resource scaling will be fully automated. AI-driven decision-making will allow for smarter resource allocation and optimization, dynamically adjusting infrastructure and workloads in response to real-time demands and predictions.
Data-Driven Insights: AIOps will analyze vast amounts of operational data and provide actionable insights, enabling teams to focus on high-impact tasks such as improving system architecture and user experience. The AI-powered insights will also inform better strategic decisions, helping teams to continuously evolve their DevOps practices.
Collaboration Across Teams: AIOps will bridge the gap between DevOps, SecOps, and IT operations by bridging monitoring and automation. Cross-team collaboration will improve as AI systems consolidate and interpret data from various departments, allowing for a more cohesive approach to system management.

AIOps features include observability, automation, and real-time analytics to bridge DevOps, SRE, and IT operations.

9. Kubernetes Dominance and Increased Complexity

Kubernetes will continue its ascent in 2026. According to Research & Markets, the global Kubernetes market was valued at USD 2.3 billion in 2024 and is projected to reach USD 8.2 billion by 2030, with a CAGR of 23.8% over the forecast period.

The CNCF Annual Survey shows AI/ML workloads rapidly moving onto Kubernetes — including batch pipelines, model experimentation, real-time inference, and data preprocessing — even as only 41% of ML/AI developers are cloud-native today. This shift is accelerating as teams need flexible GPU scheduling, distributed pipelines, and portable execution environments.

Kubernetes is also evolving in response to AI demands. Inference workloads, powered by LLMs and GPUs, now require low-latency execution closer to the user. This shift is pushing organizations to build intelligent orchestration layers that schedule AI pipelines across edge and core clusters, often leveraging Kubernetes as the common control plane for AI cluster orchestration.

As we move into 2026, three patterns are becoming clear:

Kubernetes is evolving to support AI through GPU-aware scheduling, Kubernetes GPU scheduling optimizations, and more advanced workload orchestration.
Governance and consistency matter more than ever, as teams struggle to secure and manage multi-cluster, multi-cloud environments.
Platform engineering is essential, providing curated patterns and automation rather than raw YAML to reduce cognitive load.

Kubernetes will remain a strategic foundation — but operating it effectively now depends on robust automation, strong security controls, and standardized delivery models that scale across clouds, clusters, and AI pipelines.

10. AI Code Assistants in the Enterprise

AI-powered coding assistants like GitHub Copilot, Claude Code, Cursor, and others are rapidly becoming part of modern software development.

By 2027, the use of AI assistants will dramatically increase developer velocity to meet functional business requirements for 70% of new digital solutions in production (source: IDC).

The value of AI code assistants. Credit: Gartner

According to Gartner, by 2028, 75% of enterprise software engineers will use dedicated AI code assistants, and 63% of organizations are currently piloting, deploying or beginning to use AI code assistants.

As enterprise adoption of AI assistants increases, expectations are rising: they must not only generate code but also understand the state of infrastructure, configurations, and security posture. That means being able to answer questions about environments, surface misconfigurations, or act directly on infrastructure.

One of the newest developments is the release of Pulumi Agent Skills, a collection of infrastructure expertise packaged for use in AI coding assistants. These skills teach tools such as Claude Code, Cursor, or Gemini CLI to reason about Pulumi projects, reducing hallucination and improving outputs based on real infrastructure conventions and practices.

Combined with infrastructure access via tools like Pulumi’s Remote MCP Server, teams can build secure, AI-driven workflows where assistants provide insights and Pulumi Neo safely executes actions with previews, policies, and orchestration.

AI code assistants are no longer experimental; they’re fast becoming a competitive advantage in cloud software development.

The Future of Cloud: Reinvented for an AI-First Decade

Cloud infrastructure is entering its most transformative era since the rise of Kubernetes. The trends shaping 2026 reveal a clear pattern: AI is no longer a workload — it’s becoming the organizing principle of cloud strategy.

AI-native cloud architectures that require elastic compute, GPU orchestration, fast data access, and governance built into every layer
Infrastructure as Code as the operational backbone, standardizing deployments across AI, cloud, and hybrid environments
Platform engineering and IDPs to enable self-service, gold-standard patterns, and automated guardrails
Security integrated into every pipeline, with AI-assisted threat detection, strong secrets management, and policy-driven compliance
AIOps and intelligent automation are becoming standard for scaling modern cloud systems
Kubernetes evolving for AI, driving new orchestration patterns across edge, core, and inference clusters
Multi-cloud and hybrid ecosystems accelerating to support interoperability, resilience, and global workload placement

Taken together, these shifts point to a new model of cloud operations that is intelligent, automated, policy-aware, and built on software engineering principles rather than manual configuration.

Organizations that invest now in modern IaC, unified governance, reusable components, and policy frameworks — all core capabilities of the Pulumi Cloud platform — will be positioned to lead in an AI-first world. The gap between teams that modernize and those that do not will widen rapidly in 2026 and beyond.

Try Pulumi for Free

Beyond YAML in Kubernetes: The 2026 Automation Era

Sara Huddleston — Wed, 12 Nov 2025 07:09:46 +0000

Kubernetes continues to evolve, powering not only applications but entire AI and ML systems across clouds, edges, and enterprises. By 2026, DevOps engineers, SREs, cloud engineers, and platform teams face growing pressure to deliver faster, smarter, and more secure infrastructure at scale.

Kubernetes automation is entering a new era where infrastructure as code, policy enforcement, and AI-driven orchestration work together to manage cloud environments intelligently.

Pulumi’s 2025 advancements, including Pulumi Kubernetes Operator 2.0 GA, new Kubernetes best practices playbooks, Pulumi Neo for AI assisted infrastructure management, and Policy Automation, set the foundation for a new era of Kubernetes automation that extends across every role involved in managing modern infrastructure.

In this Kubernetes article:

Why Kubernetes Needs to Go Beyond YAML

The article Kubernetes Best Practices I Wish I Had Known Before highlights a key challenge: relying solely on YAML as the source of truth for Kubernetes is no longer sustainable. Clusters are dynamic, environments multiply, and static YAML files cannot keep up with the complexity of modern infrastructure.

Teams across disciplines face similar challenges:

Multi-cluster and hybrid-cloud sprawl
Inefficient manual configuration and drift
Lack of policy enforcement and governance at scale
Secrets scattered across systems

Pulumi addresses these challenges by introducing general-purpose programming languages such as TypeScript, Python, Go, C#, and Java into Kubernetes management. This approach enables teams to define, test, and share reusable infrastructure code, bridging the gap between declarative manifests and modern software engineering practices.

Learn more: Pulumi Kubernetes documentation

The 2026 Convergence of AI, Platforms, and Policy in Kubernetes

The CNCF State of Cloud Native Development Q3 2025 report shows that more than half of DevOps professionals and nearly a third of all developers now identify as cloud native. Adoption of hybrid and multi-cloud architectures continues to grow, while AI and ML workloads are becoming first-class citizens in Kubernetes environments. The report notes that 41% of professional ML and AI developers are cloud native, confirming that Kubernetes has become a foundational technology for building intelligent, scalable systems.

This trend highlights how the next generation of Kubernetes operations is evolving. Teams need unified platforms that simplify AI-driven workloads, automatically enforce governance, and reduce operational complexity across environments. Pulumi already delivers this through an integrated platform that brings automation, security, and developer productivity together in one place.

Pulumi’s platform provides a complete foundation for intelligent infrastructure management that extends from development to production.

Pulumi Neo adds AI-assisted infrastructure management that turns natural language into production-ready Kubernetes and cloud code.
Pulumi IDP enables engineering and platform teams to build self-service environments that abstract complexity for developers while maintaining consistency and control.
Pulumi Policies brings continuous compliance and policy enforcement directly into the delivery workflow.
Pulumi ESC secures credentials, API keys, and sensitive configurations across Kubernetes and cloud environments.

Together, these capabilities form a unified automation and governance layer for Kubernetes and cloud native systems.

The result is a model where infrastructure, policy, and developer experience work together to power secure, scalable, and AI-ready platforms that meet the needs of engineering teams of every size and discipline, from application development to security and cloud operations.

The 2026 Shift: AI-Assisted Kubernetes Operations

The next phase of Kubernetes management will be AI-driven, context-aware, and self-healing. Infrastructure will not only follow instructions but also understand intent. This is the vision behind Pulumi Neo, an AI Infrastructure Agent designed to help teams automate complex systems.

Pulumi Neo can interpret natural-language requests such as “deploy a GPU-backed EKS cluster with three node groups,” generate infrastructure code that adheres to organizational policies, and continuously refine that code as environments change.

AI-powered observability and decision-making. According to the CNCF Annual Survey, 93% of organizations already use or plan to adopt AI-driven monitoring and predictive analysis for Kubernetes environments. The goal is to identify performance and reliability issues before they affect users. Pulumi Policies assists to get clean and stay clean, while Neo extends this capability by acting on those insights, transforming detected issues into actionable infrastructure updates that teams can validate or deploy.
ML and GPU workloads on Kubernetes. As organizations expand AI and ML pipelines across clusters, automation and cost efficiency become critical (FinOps Foundation). Pulumi Insights is an intelligent infrastructure management service that helps you discover, understand, manage, and improve your infrastructure. Insights improves security, compliance, and efficiency through AI-powered asset and compliance management.
Unifying DevOps, SRE, and MLOps workflows. The convergence of software and model delivery continues to accelerate (TechRadar). Pulumi’s code-based approach, combined with Neo’s agentic reasoning, creates a unified workflow for infrastructure, applications, and AI systems.

Additional insights and demonstrations:

Kubernetes and Pulumi Neo together represent a future of autonomous infrastructure management, where AI assists teams in deploying, maintaining, and improving their environments intelligently and securely.

Operator-First: Kubernetes Deploys Your Cloud

The Pulumi Kubernetes Operator 2.0 GA introduced a Kubernetes-native approach to infrastructure management. Each Pulumi stack becomes a Kubernetes Custom Resource, allowing Kubernetes itself to execute Pulumi programs written in any supported language. This enables:

Management of AWS, Azure, and GCP infrastructure from within the cluster
Integration with GitOps systems such as Argo CD and Flux
Continuous reconciliation and drift detection through Pulumi’s state and policy engine

With the new Pulumi Kubernetes Operator 2.3, the operator gets even more production-ready features:

Faster and more resilient stack updates through improved workspace lifecycle management
Support for multi-namespace and multi-tenant deployments
Better visibility with enhanced events, status reporting, and error surfacing
Performance improvements for large-scale environments and parallel stack operations

Documentation: Using the Pulumi Kubernetes Operator

Intelligent Infrastructure Across Every Cloud

Kubernetes has become the control plane for everything from application deployments to AI and ML workloads across clouds and environments. Engineering teams are running clusters on Amazon EKS, Microsoft AKS, and Google GKE while also managing edge, hybrid, and on-premises environments. Pulumi extends Kubernetes automation across all of them, unifying clusters, workloads, and cloud resources under a consistent model of infrastructure as code.

With Pulumi, teams can use familiar programming languages to define Kubernetes resources, cloud infrastructure, and policies together. This approach provides a single workflow for managing compute, networking, storage, and identity across multiple clouds without relying on brittle YAML templates. It enables consistent provisioning, policy enforcement, and automation across every cluster and environment.

By treating Kubernetes as the universal control plane for cloud infrastructure, Pulumi gives teams a scalable foundation that adapts to any workload and environment. The result is an intelligent, multi-cloud Kubernetes infrastructure that combines the flexibility of cloud providers with the reliability of modern automation.

Bring Your YAML and Helm, Then Evolve

Teams do not need to start from scratch. Pulumi supports importing existing YAML manifests and Helm charts to help organizations adopt a code-first approach incrementally. Many teams begin by wrapping existing manifests in Pulumi code, then refactor them into reusable components that enforce best practices and compliance policies.

This hybrid approach enables modernization without disrupting existing CI/CD pipelines or team workflows.

Begin Your Kubernetes Automation Journey

For teams preparing for the next phase of Kubernetes management in 2026:

Get Started with Kubernetes to create your first Pulumi program.
Add the Pulumi Kubernetes Operator to enable infrastructure deployments from within your clusters.
Integrate GitOps workflows with Argo CD, Flux, or Jenkins X.
Apply policy guardrails to enforce security and compliance automatically.
Refactor infrastructure into reusable components for consistent, scalable operations.

Agentic Workflows for Production-ready Kubernetes

Experience Kubernetes automation in practice. See how agentic workflows power production-ready Kubernetes by automating GitOps operations, managing environments, and reducing manual effort in this on-demand workshop.

Watch Agentic Workflows for Production-ready Kubernetes to learn how to:

Provision and manage clusters across clouds using general-purpose programming languages
Multi-cloud Kubernetes infrastructure management
Fleet management with GitOps (Argo CD)
Reduce YAML complexity while maintaining reliability and speed

Watch On Demand.

Final Thoughts

Kubernetes in 2026 and beyond is not just for platform engineers. It is for DevOps professionals, SREs, and cloud teams, big and small, responsible for maintaining infrastructure security, reliability, and performance. Pulumi unifies infrastructure as code, secrets management, policy governance, and AI automation into a single platform, enabling every team to adopt an intelligent, code-driven approach to Kubernetes that scales across workloads, clouds, and the AI-driven future.

Try Pulumi for Free

Why Azure Teams Are Moving from ARM Templates to .NET

Sara Huddleston — Fri, 22 Aug 2025 01:41:10 +0000

Azure Resource Manager (ARM) templates are powerful, but painful. If you’ve ever tried to provision cloud infrastructure using ARM, you know the challenges:

Templates that started simple… and now span thousands of lines
Manual configuration stitched together with bespoke deployment logic
Lack of support for key services like Databricks
Slow, error-prone deployments that require multiple manual steps
No reuse, no testing, and no relief

ARM wasn’t built for the complexity of modern Azure workloads. If you’re already familiar with general-purpose languages, there’s a better path: Pulumi.

Top Pain Points of ARM Templates

Pain Point	ARM Templates	Pulumi (C#)
Language	JSON	C#, Python, TypeScript, or Go
Code Reuse	None—copy/paste only	Classes, functions, modules
Logic	Complex condition syntax	if / switch / for loops
IDE Support	Very limited	Full IntelliSense and refactoring
Testing	None	Unit tests with xUnit/NUnit
Debugging	Post-deploy troubleshooting	Step-through debugging in IDE
Refactoring	Manual edits	Standard IDE workflows

Pulumi: The Obvious Upgrade for .NET and Azure

Pulumi solves these problems at their root. It lets you define your Azure infrastructure using C#, the same language you’re already using to build your applications. With Pulumi, you get:

✅ Familiar programming languages ✅ Type safety and compile-time validation ✅ Full IDE support (IntelliSense, refactoring, debugging) ✅ Built-in support for Databricks, Kubernetes, and more ✅ Automated config and secrets management ✅ Easy testing, reuse, and CI/CD integration

From Static Templates to Software Engineering

Here’s an example of how different it is to build a storage account:

⛔ ARM Template (JSON)

{
 "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
 "contentVersion": "1.0.0.0",
 "parameters": {
 "storageAccountName": {
 "type": "string",
 "metadata": { "description": "Globally unique, 3–24 lowercase letters and numbers." }
 }
 },
 "resources": [
 {
 "type": "Microsoft.Storage/storageAccounts",
 "apiVersion": "2021-09-01",
 "name": "[parameters('storageAccountName')]",
 "location": "[resourceGroup().location]",
 "sku": { "name": "Standard_LRS" },
 "kind": "StorageV2",
 "properties": {}
 }
 ],
 "outputs": {
 "storageAccountId": {
 "type": "string",
 "value": "[resourceId('Microsoft.Storage/storageAccounts', parameters('storageAccountName'))]"
 }
 }
}

✅ Azure with Pulumi in C#

using Pulumi;
using Pulumi.AzureNative.Storage;

class MyStack : Stack
{
 public MyStack()
 {
 var storageAccount = new StorageAccount("mystorage", new StorageAccountArgs
 {
 ResourceGroupName = "my-rg",
 Sku = new SkuArgs { Name = SkuName.Standard_LRS },
 Kind = Kind.StorageV2
 });
 }
}

It’s clean. It’s familiar. And it works seamlessly with your .NET tooling. Pulumi is open source, and your Pulumi Cloud account is free for individuals and small teams, with advanced editions for large enterprises. Try Pulumi Cloud for FREE->

Why It Just Works for .NET Teams

If your organization is built on Azure and .NET:

Use C# across both infrastructure and application layers
Share libraries and logic between services
Test infrastructure the same way you test code
Integrate with Azure DevOps and GitHub Actions
Manage secrets, environments, and policies as code

Pulumi supports all the Azure services ARM does (and more), while giving you flexibility and control ARM never could.

Summary

ARM templatesweren’t designed to scale with the complexity of today’s cloud environments. They’re static, verbose, hard to test, and increasingly brittle.

Pulumi gives you the tools to manage Azure the way you manage software: modular, testable, scalable, and secure.

If you’re already building with C# and .NET, you’re 90% of the way there. Why suffer through another slow, error-prone ARM deployment?

Backstage vs Pulumi IDP: Why Infrastructure-First Wins!

Engin Diri — Wed, 13 Aug 2025 00:00:00 +0000

Developers are losing days every month to infrastructure bottlenecks, compliance hurdles, and inconsistent environments. Platform engineering promised to fix that, yet too many platforms fail before they deliver real impact.

In this comparison of Backstage vs Pulumi IDP, we’ll explore why choosing the right architectural approach matters more than the tool itself.

Quick comparison: Backstage vs Pulumi IDP

Backstage is an open-source developer portal framework from Spotify that focuses on service catalogs and documentation. It requires significant setup time (12-18 months) and ongoing maintenance (3-5 FTEs).

Pulumi IDP is an infrastructure-first internal developer platform that embeds governance, cost control, and security from day one. It can be deployed in hours with minimal ongoing maintenance.

The problem isn’t whether you choose Backstage or Pulumi IDP. The real question is: Will your platform treat infrastructure as a first-class concern, or as an afterthought?

According to Gartner, 80% of large enterprises will deploy internal developer platforms within the next two years. But without a strong infrastructure foundation, those platforms risk becoming expensive, hard-to-maintain bottlenecks instead of accelerators.

Why platform engineering efforts fail: Common mistakes

Platform teams consistently make four critical mistakes:

Neglecting Infrastructure Foundations
Over-focusing on the developer portal experience while letting infrastructure governance and scalability lag behind.
Ignoring Cost Efficiency
Prioritizing productivity at the expense of cloud cost management.
Example: One company considered giving every developer their own cluster, a scaling nightmare both technically and financially.
Treating Security & Governance as Add-Ons
Bolting on compliance after launch leads to constant firefighting and security debt.
Building for Yesterday’s Architecture
Designing general-purpose platforms that can’t keep up with Kubernetes-native workloads.

Portal-first vs infrastructure-first platform engineering

There are two dominant approaches:

Portal-First typified by Backstage, which starts with developer experience and service catalogs.
Infrastructure-First exemplified by Pulumi IDP, which builds the platform foundation around scalable, policy-driven infrastructure.

Platform Engineering Feature	Backstage (Portal-First)	Pulumi IDP (Infrastructure-First)
Primary Focus	Developer portal & catalog	Scalable, policy-driven infrastructure
Setup Time	12-18 months	Hours
Maintenance	3-5 FTE ongoing	Minimal ongoing overhead
Infra Provisioning	Requires separate tooling	Built-in
Cost Awareness	Depends on infra layer	Native
Security & Governance	Add-on	Built-in from day one

Backstage: The portal-first platform engineering approach

Backstage is an open-source framework for building developer portals. Originally built by Spotify, it excels at unifying tools, services, and documentation.

Strengths

Mature Ecosystem with over 1,200 integrations and a large community.
Excellent Service Catalog providing centralized metadata, ownership, and discovery.
Docs-as-Code that keeps documentation close to the codebase.
Self-Service Templates that standardize scaffolding for new projects.

Challenges

High Maintenance Overhead requiring 3-5 FTEs just to keep it running in large orgs.
Complex Setup with Yarn version headaches, TypeScript complexity, plugin upkeep.
Infra as an Afterthought that lacks built-in provisioning, often pushing infra concerns down the road.
Hidden Costs resulting in multi-million dollar TCO over three years for a 300-dev team when factoring in staffing and infra complexity.

Pulumi IDP: the infrastructure-first platform engineering approach

Pulumi IDP brings Infrastructure Platform Engineering (IPE) to the forefront by embedding scalable, secure, cost-aware infrastructure into the platform from day one.

Strengths

Infrastructure as a First-Class Concern with built-in multitenancy, isolation, and governance.
Efficiency & Cost Awareness through golden paths and reusable components optimized from the start.
Policy-Driven by Design that enforces security, compliance, and cost policies automatically.
Cloud-Native Ready ideal for ephemeral workloads, Kubernetes, and multi-cloud.

Considerations

Newer Platform with a smaller plugin ecosystem than Backstage’s.
Infra-Heavy Focus that’s best fit for infra-intensive orgs; overpowered if you only need a catalog and docs.

Real-world platform engineering outcomes: Backstage vs Pulumi IDP

Pulumi IDP Adoption: CLEAR leveraged Pulumi IDP’s prebuilt capabilities instead of building infra automation from scratch, speeding up delivery while keeping governance tight.

Backstage vs Pulumi IDP decision guide

When to choose Backstage

Choose Backstage for platform engineering if you:

Have a dedicated platform team with strong React/TypeScript skills
Primarily need service cataloging and documentation
Already have robust infrastructure provisioning and governance tools
Have 18+ months and budget for ongoing maintenance (3-5 FTEs)

When to choose Pulumi IDP

Choose Pulumi IDP for platform engineering if you:

Need infrastructure governance from day one
Want cost management and policy automation built in
Must scale efficiently across Kubernetes and multi-cloud
Prefer to avoid building everything from scratch
Need to deploy quickly (hours vs months)

The shift to infrastructure platform engineering (IPE)

Platform engineering isn’t failing because the idea is flawed. It’s failing because too many efforts start with the portal and leave infrastructure for later.

Infrastructure Platform Engineering flips that model, ensuring the platform’s foundation is:

Hybrid approaches are also possible. Pulumi offers a Backstage plugin so teams can pair Backstage’s portal features with Pulumi IDP’s infrastructure power.

Bottom line: infrastructure-first wins for platform engineering

If your platform is slow, costly, or hard to govern, it’s not a developer problem. It’s an infrastructure problem. Treating infrastructure as a first-class concern from day one isn’t optional. It’s the difference between a platform that scales and one that stalls.

Frequently asked questions

What is the main difference between Backstage and Pulumi IDP?

Backstage is a portal-first developer platform that focuses on service catalogs and documentation, requiring separate tools for infrastructure provisioning. Pulumi IDP is an infrastructure-first platform that embeds governance, cost control, and infrastructure automation from the start.

How long does it take to implement Backstage vs Pulumi IDP?

Backstage typically requires 12-18 months for full implementation with ongoing maintenance by 3-5 FTEs. Pulumi IDP can be deployed in hours with minimal ongoing maintenance overhead.

Can I use Backstage and Pulumi IDP together?

Yes, Pulumi offers a Backstage plugin that allows teams to combine Backstage’s portal features with Pulumi IDP’s infrastructure capabilities for a hybrid approach.

What are the costs of running Backstage vs Pulumi IDP?

Backstage’s TCO for a 300-developer team can reach multiple millions over three years when factoring in staffing and infrastructure complexity. Pulumi IDP has lower operational costs due to built-in automation and minimal maintenance requirements.

Which platform is better for Kubernetes environments?

Pulumi IDP is purpose-built for cloud-native and Kubernetes environments with built-in support for ephemeral workloads and multi-cloud deployments. Backstage requires additional tooling for Kubernetes infrastructure management.

Learn more about Pulumi IDP and how infrastructure-first platform engineering avoids common failure patterns.

Secrets Management Tools: The Complete 2025 Guide

Asaf Ashirov — Thu, 24 Jul 2025 00:00:00 +0000

Every modern application depends on secrets to function: database passwords, API keys, certificates, and configuration values that enable secure communication between services. But here’s the challenge: as your infrastructure grows, managing these secrets becomes exponentially more complex.

The numbers tell a stark story. According to the Akeyless State of Secrets Management Report, 96% of organizations struggle with secrets sprawl such as credentials scattered across code repositories, configuration files, and deployment scripts. The consequences are severe: Verizon’s 2025 Data Breach Investigations Report found that 88% of data breaches involved compromised credentials, with IBM’s research showing the average breach now costs organizations $4.88 million.

The path forward requires more than just storing secrets securely, it demands intelligent orchestration across your entire infrastructure. But with dozens of solutions available, from traditional enterprise vaults to modern orchestration platforms, finding the right approach can feel overwhelming.

This guide cuts through the complexity. We’ll examine the leading secrets management tools across multiple categories, helping you understand not just what they do, but when and why to use them. Whether you’re architecting your startup’s first production environment or modernizing enterprise legacy systems, you’ll find actionable insights to make the right choice for your specific needs.

Secrets Management Tools Overview

The Evolution Beyond Simple Secret Storage

What started as simple password vaults has evolved into something far more sophisticated. Traditional secret storage addressed only part of the challenge: keeping credentials secure. But modern infrastructure demands orchestration across complex, distributed environments where applications need dozens of different secrets available across multiple cloud providers and deployment stages.

The fundamental shift happened when teams realized that managing secrets effectively requires treating them as infrastructure components, not just security artifacts. Your applications don’t just need database passwords stored securely—they need those credentials dynamically generated, automatically rotated, and consistently available across development, staging, and production environments without manual intervention.

Today’s leading platforms function as intelligent orchestrators rather than simple storage systems. They aggregate secrets from multiple existing sources, provide configuration-as-code capabilities that enable version control and reproducible deployments, and generate dynamic credentials with automatic expiration. This orchestration approach means you can work with your existing secret stores while gaining centralized management and modern capabilities like hierarchical organization that reduces duplication across environments.

The best solutions recognize that secrets management is fundamentally an infrastructure orchestration problem. They provide unified access patterns that work seamlessly across multi-cloud environments, comprehensive audit logging for compliance requirements, and fine-grained access controls that adapt to your organizational structure all while maintaining compatibility with the tools and workflows your teams already use.

Most Popular Secrets Management Tools

Secrets Orchestration Platforms

This represents the newest evolution in secrets management: platforms that connect and coordinate multiple secret sources rather than forcing you to abandon your existing infrastructure. Instead of requiring wholesale migration to yet another secret store, these intelligent brokers provide unified interfaces that work with your current tools while adding modern capabilities like dynamic credential generation and configuration-as-code workflows.

Pulumi ESC (Environments, Secrets, and Configuration)

Pulumi ESC takes a fundamentally different approach to secrets management. Rather than forcing you to migrate from your existing secret stores, it orchestrates them connecting HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, Google Secret Manager, and over 20 other providers through a unified interface. This means you can modernize your secrets workflow without abandoning your current infrastructure investments.

The platform’s strength lies in its configuration-as-code approach. You define hierarchical YAML environments that cascade from base configurations through development, staging, and production. This eliminates the manual configuration copying that leads to secrets sprawl: define common settings once, inherit them everywhere they’re needed, while maintaining appropriate security boundaries between environments.

Enterprise-Grade Security and Compliance: ESC provides comprehensive audit logging with detailed access trails, including user identity, timestamp, access method, and resource details. The platform’s audit capabilities support compliance requirements for frameworks like SOC 2, GDPR, and industry-specific regulations by providing immutable audit logs and real-time monitoring of secret access patterns.

Performance and Scalability: ESC delivers enterprise-scale performance with low-latency secret retrieval, high availability across multiple regions, and the ability to handle thousands of concurrent requests. The architecture is designed to scale automatically with organizational growth while maintaining consistent sub-second response times for secret operations.

Dynamic credential generation sets Pulumi ESC apart from traditional storage-focused tools. Instead of storing long-lived AWS access keys or Azure service principal secrets, it automatically provisions short-lived OIDC tokens on-demand. This dynamic approach eliminates entire categories of security risk by ensuring credentials expire automatically and can’t be misused over extended periods.

Advanced Key Management: ESC provides advanced key management capabilities with support for industry-standard encryption algorithms, automated key rotation, and secure key derivation. The platform offers envelope encryption and fine-grained access controls that ensure encryption keys are managed securely and in accordance with regulatory requirements.

The platform maintains a zero vendor lock-in philosophy through its open-source engine and comprehensive multi-language SDK support for TypeScript, Python, Go, and .NET. Teams can integrate ESC into existing workflows through familiar CLI tooling while maintaining full visibility into orchestration logic through transparent, auditable code.

Cost-Effective Enterprise Solution: Pulumi ESC offers significant cost advantages through its unified platform approach, reducing the need for multiple point solutions and simplifying operational overhead. ESC’s integration with existing infrastructure workflows eliminates the need for separate tools and reduces training costs, while its automated rotation and compliance features reduce manual administrative tasks and associated labor costs. For organizations with strict data residency requirements, Pulumi Service offers self-hosting options that provide additional cost predictability and security control.

Pulumi ESC offers a generous free tier with unlimited environments, making it accessible for teams to experiment with configuration-as-code principles. Usage-based pricing for advanced features scales naturally with organizational growth, making it particularly attractive for multi-cloud environments and teams prioritizing systematic approaches to eliminating secrets sprawl.

Doppler

Doppler focuses on developer experience with an intuitive interface and extensive integrations for modern development workflows. The platform provides branch-based environment management and real-time secret synchronization across connected services, with plans starting at $3 per user per month.

Infisical

Infisical combines open-source transparency with modern secrets management, offering both self-hosted and cloud options. The platform includes built-in secrets scanning capabilities and comprehensive SDK support, with cloud service starting at $8 per user per month.

Enterprise Secrets Vaults

Traditional enterprise vaults focus on maximum security and compliance, offering comprehensive secret storage with advanced features designed for large organizations with sophisticated security requirements.

HashiCorp Vault

HashiCorp Vault remains the established standard for enterprise secrets management, offering unmatched flexibility and a comprehensive feature set for complex environments. The platform provides dynamic secrets generation with automatic expiration for over 50 different systems, enabling organizations to move away from static, long-lived credentials toward more secure, just-in-time access patterns.

Vault’s architecture supports over 100 authentication methods and secret engines, providing flexibility to integrate with virtually any existing infrastructure or identity system. Multi-region clustering with strong consistency guarantees ensures high availability and data integrity across geographically distributed deployments. Extensive audit logging and compliance reporting capabilities help organizations meet regulatory requirements while maintaining operational visibility.

The platform’s cloud-agnostic deployment options support both Kubernetes and traditional VM-based infrastructure, making it suitable for organizations with diverse technical environments. Vault’s open-source core provides transparency and community-driven development, while commercial enterprise features starting at $2 per node per hour add advanced management, replication, and support capabilities.

HashiCorp Vault excels in organizations requiring maximum flexibility and customization, complex multi-cloud environments, and teams with strong DevOps expertise capable of managing sophisticated infrastructure platforms.

CyberArk Conjur

CyberArk Conjur focuses on enterprise security with advanced compliance features and integration with broader privileged access management systems. The platform provides enterprise-grade role-based access control with comprehensive audit capabilities, enabling organizations to implement fine-grained security policies across their entire infrastructure.

Modern versions of Conjur incorporate AI-powered anomaly detection and threat analysis, helping security teams identify unusual access patterns that may indicate compromise or policy violations. Automated compliance reporting supports SOC 2, PCI-DSS, and other regulatory frameworks, reducing the operational overhead of maintaining compliance documentation.

Conjur’s integration with CyberArk’s broader privileged access management suite provides a comprehensive approach to credential security that extends beyond simple secret storage to include session monitoring, just-in-time access provisioning, and threat detection. The platform’s advanced policy engine enables fine-grained access controls that can adapt to changing organizational and regulatory requirements.

With enterprise licensing based on scale and deployment requirements, CyberArk Conjur targets regulated industries, enterprises with strict compliance requirements, and organizations prioritizing maximum security over operational simplicity.

Akeyless

Akeyless offers a modern, cloud-native approach to enterprise secrets management without the operational complexity of traditional self-hosted solutions. The platform’s SaaS-first architecture eliminates infrastructure management overhead while providing enterprise-grade capabilities including just-in-time access and automated credential rotation.

The platform implements zero-knowledge encryption with client-side key management, ensuring that even Akeyless cannot access customer secrets. This approach addresses concerns about cloud-based secret storage while maintaining the operational benefits of a managed service. A comprehensive API and integration ecosystem enables connection with existing tools and workflows.

Akeyless provides a generous free tier supporting up to 5 clients, with usage-based pricing that scales naturally with organizational growth. This pricing model, combined with the elimination of operational overhead, makes Akeyless attractive for organizations seeking enterprise features without the complexity of self-managed infrastructure, particularly cloud-first teams prioritizing rapid deployment and scaling.

Cloud-Native Secrets Managers

Cloud-native solutions provide tight integration with specific cloud platforms, offering optimized experiences for organizations committed to particular cloud ecosystems. These platforms leverage native cloud services and identity systems to provide seamless integration with existing infrastructure.

AWS Secrets Manager

Amazon’s native secrets management service provides deep integration with the AWS ecosystem and automatic rotation capabilities specifically designed for AWS services. The platform offers native integration with over 50 AWS services including RDS, Lambda, ECS, and EKS, enabling seamless credential management across the entire AWS service portfolio.

Automatic rotation capabilities for supported databases and AWS services eliminate the operational overhead of manual credential management while improving security through regular rotation cycles. Cross-region replication with automatic failover ensures high availability for critical secrets, while fine-grained IAM permissions with resource-based policies provide precise access control aligned with AWS security best practices.

VPC endpoint support enables private network access without internet routing, addressing security requirements for air-gapped or highly secure environments. The service’s pricing model of $0.40 per secret per month plus $0.05 per 10,000 API calls provides predictable costs that scale with usage.

AWS Secrets Manager excels for AWS-native organizations, applications requiring automatic credential rotation, and teams leveraging extensive AWS service portfolios where tight integration provides operational efficiency and security benefits.

Azure Key Vault

Microsoft’s comprehensive platform manages secrets, keys, and certificates within the Azure ecosystem while providing strong compliance features particularly valued by government and enterprise customers. The platform integrates seamlessly with Azure services and Active Directory authentication, leveraging existing identity infrastructure to provide consistent access control across the Azure ecosystem.

FIPS 140-2 Level 2 validated Hardware Security Modules provide the highest levels of cryptographic security, making Azure Key Vault suitable for government contractors and organizations with stringent security requirements. Managed HSM support extends these capabilities for scenarios requiring maximum security control and audit capabilities.

Certificate lifecycle management with automatic renewal reduces operational overhead while ensuring consistent security posture across web applications and services. Virtual network integration and private endpoint support enable secure access patterns that align with enterprise network security architectures.

Azure Key Vault’s standard tier pricing of $0.03 per 10,000 operations provides cost-effective secret management for Azure-centric organizations, government contractors requiring FIPS compliance, and enterprises with Microsoft-heavy infrastructure environments.

Google Secret Manager

Google Cloud’s scalable secrets management service is optimized for high-volume, global deployments with strong integration across GCP services. The platform provides automatic global replication across all GCP regions, ensuring low-latency access to secrets regardless of geographic distribution.

IAM integration supports fine-grained, condition-based permissions that can adapt to complex organizational structures and security requirements. Secret versioning with automatic rollback capabilities provides operational safety for configuration changes, while integration with Cloud Build, GKE, Cloud Run, and App Engine enables seamless secret management across Google Cloud’s entire service portfolio.

The platform’s high-performance API with global edge caching minimizes latency for high-frequency secret retrieval operations, making it suitable for applications with demanding performance requirements. Pricing of $0.06 per secret version per month plus $0.03 per 10,000 API calls provides cost-effective scaling for high-volume usage patterns.

Google Secret Manager serves Google Cloud-native organizations, applications requiring massive scale, and global deployments where low latency and high availability are critical operational requirements.

Developer-Focused Tools

These tools prioritize user experience and ease of adoption, often serving as excellent entry points for teams beginning their secrets management journey. They emphasize intuitive interfaces and efficient workflows that reduce barriers to adoption.

1Password Secrets Automation

1Password has successfully expanded beyond personal password management to offer comprehensive business secrets management while maintaining their renowned user experience. The platform implements zero-knowledge architecture with client-side encryption, ensuring that even 1Password cannot access customer secrets while providing the usability that made their consumer products successful.

The intuitive interface remains accessible to both technical and non-technical users, addressing the common challenge of secrets management tools that require specialized expertise. Comprehensive SDK and CLI support enables developer workflows while maintaining the simplicity that drives organization-wide adoption. Integration with popular CI/CD platforms and development tools provides the automation capabilities modern development teams require.

Advanced sharing capabilities include granular, time-limited permissions that enable secure collaboration while maintaining audit trails and access control. This combination of security and usability makes 1Password particularly effective in mixed environments where both technical and business users need access to secrets.

At $8 per user per month with volume discounts available, 1Password Secrets Automation targets teams prioritizing usability over advanced features, mixed technical/non-technical environments, and organizations already invested in the 1Password ecosystem.

Bitwarden Secrets Manager

Bitwarden leverages their password management expertise to provide cost-effective secrets management specifically designed for development teams. The platform includes machine account support for automated CI/CD workflows, addressing the common requirement for non-human access to secrets in modern development processes.

CLI and SDK integration covers major programming languages while maintaining the straightforward approach that characterizes Bitwarden’s products. Comprehensive event logging and audit trails provide the visibility required for security and compliance, while two-person integrity controls add an extra layer of protection for sensitive operations.

The platform’s competitive per-user pricing of $3 per month with transparent costs makes it particularly attractive for small to medium teams, organizations seeking simple and cost-effective solutions, and existing Bitwarden users looking to extend their investment into development workflows.

Application Security & Scanning

These tools focus on preventing secrets leakage by detecting credentials in code repositories, CI/CD pipelines, and other development artifacts. Rather than managing secrets after they’re created, these platforms prevent security incidents by identifying and remediating credential exposure.

GitGuardian

GitGuardian provides comprehensive secrets detection and remediation across the entire software development lifecycle with high accuracy and low false positives. The platform offers real-time scanning of commits, pull requests, and issues across all major Git platforms, ensuring that credential exposure is identified and addressed before code reaches production environments.

Advanced machine learning algorithms detect over 350 secret types while minimizing false positives that can lead to alert fatigue. Developer-friendly remediation workflows provide guided resolution steps that help development teams address issues quickly without disrupting their normal workflows. Historical repository scanning capabilities enable comprehensive security assessment of existing codebases.

Integration with GitHub, GitLab, Bitbucket, and Azure DevOps ensures coverage across diverse development environments. The platform’s free tier supports small teams, while enterprise plans starting at $18 per developer per month provide advanced features and support for larger organizations.

GitGuardian excels in organizations with large codebases, teams implementing DevSecOps practices, and compliance-focused environments where preventing credential exposure is critical to maintaining security posture.

TruffleHog

TruffleHog offers powerful open-source secrets detection with both community and enterprise versions for comprehensive credential scanning. The platform uses high-performance scanning algorithms that combine advanced entropy analysis with pattern matching to identify credentials across diverse file types and encoding formats.

Support for over 700 credential types includes custom patterns that can adapt to organization-specific secret formats. CI/CD integration with GitHub Actions, GitLab CI, and Jenkins enables automated scanning as part of existing development workflows. Historical git repository scanning provides commit-level analysis that can identify when and how credentials entered the codebase.

The active open-source community ensures regular updates and improvements while providing transparency into detection algorithms. Enterprise features and support options are available for organizations requiring commercial backing and advanced capabilities.

TruffleHog serves open-source advocates, security-conscious development teams, and organizations with strong technical security expertise capable of implementing and maintaining open-source security tools.

Specialized & Integration Tools

These tools address specific use cases or provide bridge functionality between secrets managers and deployment platforms, filling gaps in comprehensive secrets management architectures.

External Secrets Operator

The External Secrets Operator provides Kubernetes-native integration with external secrets management systems, enabling GitOps workflows with secure secret handling. The platform uses Kubernetes Custom Resource Definitions to provide native resource management that integrates seamlessly with existing Kubernetes operational patterns.

Multi-provider support includes Vault, AWS, Azure, GCP, and numerous other secret sources, enabling organizations to maintain consistent Kubernetes secret management regardless of their underlying secret storage choices. Automatic secret synchronization with configurable refresh intervals ensures that Kubernetes secrets remain current with external sources while minimizing API load.

Template-based secret transformation and formatting capabilities enable adaptation of external secret formats to Kubernetes requirements. As an active CNCF community project with growing enterprise adoption, the External Secrets Operator benefits from diverse contributions and broad compatibility testing.

This free and open-source tool excels in Kubernetes-heavy environments, teams adopting GitOps practices, and organizations requiring cloud-agnostic secret synchronization across diverse infrastructure platforms.

Berglas

Google’s Berglas provides optimized secrets injection for serverless and container environments, particularly Google Cloud Run and similar platforms. The platform’s serverless-optimized secret injection minimizes cold start impact, addressing one of the key performance challenges in serverless architectures.

Deep integration with Google Cloud services and IAM leverages existing cloud infrastructure to provide secure, efficient secret access. Container-native deployment patterns use init container approaches that work seamlessly with existing containerized application architectures. Minimal runtime overhead and memory footprint ensure that secret management doesn’t impact application performance.

As an open-source project backed by Google’s engineering team, Berglas benefits from direct integration with Google Cloud services and ongoing development aligned with Google Cloud platform evolution. The free and open-source nature makes it accessible for teams of all sizes.

Berglas serves Google Cloud serverless deployments, container-native applications, and teams prioritizing minimal overhead in performance-sensitive environments.

Confidant

Lyft’s open-source Confidant offers a production-proven approach to secrets management with focus on developer experience and AWS optimization. Battle-tested at Lyft’s scale with millions of requests daily, Confidant provides real-world validation of its architecture and performance characteristics.

AWS-optimized architecture leverages KMS and DynamoDB to provide secure, scalable secret storage using proven AWS services. Developer-centric design emphasizes simple API and CLI interfaces that reduce friction in day-to-day development workflows. The blind credentials feature provides enhanced security by ensuring that even system administrators cannot access certain types of sensitive information.

IAM integration with fine-grained permissions leverages AWS’s native access control systems to provide consistent security policies across the entire infrastructure. As a free and open-source solution, Confidant enables organizations to implement enterprise-grade secret management without licensing costs.

Confidant excels in AWS-heavy environments, teams with strong technical capabilities, and organizations seeking proven open-source solutions with demonstrated scale and reliability.

Chamber

Segment’s Chamber provides elegant secrets management using AWS Parameter Store, optimizing for simplicity and cost-effectiveness. The platform leverages existing AWS infrastructure to minimize complexity while providing essential secret management capabilities.

Cost-effective operations use Parameter Store’s generous free tier to provide secret storage without additional infrastructure or licensing costs. Simple deployment requires minimal operational overhead, making it suitable for teams with limited DevOps resources. Version control integration supports infrastructure as code practices by enabling secret management through familiar development workflows.

Namespace organization with hierarchical parameter structure provides logical organization that scales with application complexity while maintaining simplicity of operation. As a free and open-source tool with only AWS Parameter Store costs, Chamber provides extremely cost-effective secret management.

Chamber serves AWS-native deployments seeking simplicity, teams with cost constraints, and organizations preferring minimal tooling complexity over advanced feature sets.

Top Features to Look for in Secrets Management Tools

Secrets Orchestration and Multi-Source Integration

The most advanced secrets management platforms function as intelligent orchestrators, connecting multiple secret sources and providing unified access patterns. This capability is crucial for organizations with heterogeneous environments where secrets are distributed across multiple systems. Rather than forcing migration to a single secret store, orchestration platforms work with existing infrastructure investments while providing centralized management and consistent access patterns.

Effective orchestration platforms can aggregate secrets from existing enterprise vaults like HashiCorp Vault and CyberArk, cloud-native services including AWS Secrets Manager, Azure Key Vault, and Google Secret Manager, legacy systems with database configuration and file-based secrets, and third-party services like 1Password, Bitwarden, and specialized tools. Pulumi ESC exemplifies this orchestration approach, providing a unified interface across over 20 secret sources while maintaining compatibility with existing infrastructure investments.

This orchestration capability reduces migration risk and preserves existing investments while enabling gradual adoption of modern secret management practices. Organizations can maintain their current secret stores while gaining the benefits of centralized management, consistent access patterns, and advanced features like dynamic credential generation.

Configuration as Code and Environment Management

Modern secrets management extends beyond simple credential storage to comprehensive configuration management. The best platforms support configuration-as-code principles that bring software engineering discipline to environment management and secret distribution.

Version control integration with full change tracking and rollback capabilities ensures that configuration changes undergo the same scrutiny as application code. Hierarchical organization reduces duplication through inheritance and composition, enabling teams to define common configurations once and apply them consistently across multiple environments. Reproducible deployments ensure consistency across environments while code review processes apply software engineering practices to configuration changes. Automated testing capabilities validate configuration changes before deployment, preventing configuration errors that could lead to security vulnerabilities or application failures.

This approach transforms secrets from scattered, manual processes into systematic, auditable infrastructure that follows established software engineering best practices. Teams can apply familiar development workflows to secret management, improving both security and operational efficiency.

Dynamic Credential Generation

Static secrets pose inherent security risks due to their long-lived nature and potential for unauthorized sharing. Dynamic credential generation addresses these challenges by creating credentials on-demand with automatic expiration, significantly reducing the attack surface associated with credential compromise.

Effective dynamic credential systems provide short-lived tokens with automatic expiration and renewal, eliminating the need for manual rotation while ensuring credentials cannot be misused over extended periods. Just-in-time access generates credentials only when needed, reducing the window of opportunity for credential misuse. OIDC integration leverages identity providers for cloud access, enabling seamless authentication without storing long-lived cloud credentials.

Database credentials with automatic rotation for major database systems ensure that application access remains current while removing the operational burden of manual credential management. API keys with configurable lifespans and scope limitations provide fine-grained control over third-party service access. This dynamic approach significantly improves security posture while reducing operational overhead.

Multi-Platform Integration and SDK Support

Your secrets management platform should integrate seamlessly with your existing development and deployment infrastructure, providing native support for the tools and workflows your teams already use. Effective integration reduces friction in adoption while ensuring that secret management becomes a natural part of existing processes rather than an additional burden.

Development integration should include CI/CD platforms like GitHub Actions, GitLab CI, Jenkins, and Azure DevOps, enabling automated secret management as part of deployment workflows. Container orchestration platforms including Kubernetes, Docker Swarm, and Nomad should provide native secret injection capabilities. Infrastructure as Code tools like Terraform, Pulumi, and CloudFormation should support secret management through familiar provisioning workflows. Local development integration should include environment synchronization and IDE integration to provide consistent experiences across development and production environments.

Runtime integration capabilities should extend to application frameworks like Spring Boot, Django, and Express.js, enabling developers to access secrets through familiar programming patterns. Cloud platforms including AWS Lambda, Azure Functions, and Google Cloud Run should provide optimized secret injection with minimal performance impact. Monitoring tools, service meshes, and other infrastructure components should integrate seamlessly to provide comprehensive observability and management capabilities.

Comprehensive Audit and Compliance Capabilities

Security and compliance requirements demand detailed visibility into secret access and management activities. Effective audit capabilities provide the transparency required for security monitoring, compliance reporting, and incident investigation while enabling organizations to demonstrate adherence to regulatory requirements.

Complete audit trails with detailed attribution, timestamps, and context enable security teams to understand exactly who accessed which secrets when and from where. Change tracking for all secret modifications, rotations, and access grants provides visibility into the complete lifecycle of credential management. Compliance reporting supporting SOC 2, ISO 27001, PCI-DSS, and other regulatory frameworks automates the documentation required for compliance audits.

Anomaly detection capabilities identify unusual access patterns that may indicate compromise or policy violations, enabling proactive security response. Integration with SIEM systems provides centralized security monitoring and alerting, ensuring that secret management activities are included in overall security operations. These capabilities transform secret management from a potential compliance liability into a security asset that enhances overall organizational security posture.

Performance and Scalability

Consider both current requirements and future growth when evaluating secrets management platforms. API performance with low latency for high-frequency secret retrieval ensures that secret management doesn’t become a bottleneck in application performance. Geographic distribution supporting global deployments with regional access provides consistent performance regardless of deployment location.

High availability with automatic failover and disaster recovery ensures that secret management doesn’t become a single point of failure in critical applications. Horizontal scaling capabilities handle increased load without performance degradation as organizations grow. Intelligent caching strategies optimize performance while maintaining security, reducing API load while ensuring secrets remain current.

Effective performance and scalability ensure that secret management enhances rather than hinders application performance, enabling organizations to scale their security practices alongside their infrastructure growth.

Key Considerations for Choosing Secrets Management Tools

Orchestration vs. Replacement Strategy

The fundamental choice between orchestration and replacement approaches significantly impacts both implementation complexity and long-term flexibility. Orchestration platforms like Pulumi ESC work with existing infrastructure, providing unified interfaces without requiring complete migration. This approach offers reduced migration risk with gradual adoption, preserved investments in existing secret stores and processes, flexibility to use best-of-breed solutions for different use cases, and simplified operations through centralized management of distributed secrets.

Replacement approaches require migration of all secrets to a single platform. While potentially simpler architecturally, this approach involves higher migration costs and extended transition periods, vendor lock-in that makes future changes more difficult, all-or-nothing adoption requiring complete workflow changes, and potential loss of functionality from specialized existing systems.

Organizations with heterogeneous environments, multiple cloud providers, or significant existing investments in secret management infrastructure typically benefit from orchestration approaches that preserve flexibility while providing centralized management capabilities.

Cloud Strategy Alignment

Your choice of secrets management platform should align with your overall cloud strategy and deployment patterns. Organizations with multi-cloud or hybrid strategies benefit from cloud-agnostic solutions that provide consistent experiences across platforms. Pulumi ESC, HashiCorp Vault, and other orchestration platforms excel in these environments by providing unified interfaces regardless of underlying infrastructure.

Organizations committed to specific cloud platforms can leverage native services like AWS Secrets Manager, Azure Key Vault, and Google Secret Manager for optimal integration and cost efficiency within their chosen ecosystem. These platforms provide deep integration with cloud-native services while optimizing costs through native billing and resource management.

Migration flexibility becomes important as organizational requirements evolve. Orchestration platforms provide natural migration paths between different underlying secret stores as requirements change, while cloud-native solutions may require more significant changes if cloud strategy evolves. Consider solutions that maintain flexibility for future changes while meeting current operational requirements.

Team Structure and Expertise

The technical complexity and operational requirements of different secrets management platforms vary significantly, making team structure and expertise critical factors in platform selection. High-complexity tools like HashiCorp Vault and CyberArk Conjur suit organizations with dedicated security or platform teams capable of managing sophisticated infrastructure. These platforms offer maximum flexibility and features but require significant expertise to implement and operate effectively.

Medium-complexity tools like Pulumi ESC and Doppler balance advanced features with operational simplicity, making them suitable for organizations with strong technical teams that prefer managed services or simplified operations. These platforms provide enterprise-grade capabilities without the operational overhead of self-managed infrastructure.

Low-complexity tools like 1Password and Bitwarden prioritize ease of use over advanced capabilities, making them suitable for organizations with limited technical resources or mixed teams where non-technical users require access to secrets. These platforms excel in environments where adoption and usability take priority over advanced features.

Organizational structure also influences platform choice. Centralized teams can manage sophisticated platforms and enforce consistent policies across the organization, while distributed teams benefit from self-service capabilities and intuitive interfaces that enable independent operation. Mixed environments require tools accessible to both technical and non-technical users, emphasizing usability and clear documentation.

Security and Compliance Requirements

Regulatory and security requirements significantly influence platform selection, with different industries and use cases demanding specific capabilities and certifications. Government and defense organizations may require FIPS 140-2 Level 2 validation provided by platforms like Azure Key Vault and CyberArk, while financial services often need comprehensive audit trails and segregation of duties capabilities.

Healthcare organizations require HIPAA-compliant secret handling and access controls, while European operations must consider GDPR implications for secret storage and processing. Understanding these requirements early in the selection process helps narrow platform choices and avoid costly compliance gaps.

Security model preferences also vary significantly between organizations. Zero-knowledge encryption models where service providers cannot access secrets appeal to security-conscious organizations, while Hardware Security Module support provides the highest levels of cryptographic security for sensitive applications. Network isolation capabilities become important for air-gapped or highly secure environments, while multi-factor authentication integration with existing identity systems ensures consistent security policies.

Cost Optimization

Understanding the total cost of ownership for different secrets management approaches requires consideration of both direct and indirect costs. Per-user pricing models suit teams with predictable user counts but can become expensive as organizations scale. Usage-based pricing scales naturally with actual consumption but requires careful monitoring to avoid unexpected costs. Per-secret pricing works well for applications with many users but few secrets, while enterprise licensing may provide cost-effective solutions for large deployments.

Total cost of ownership extends beyond licensing to include operational overhead for self-hosted versus managed solutions, training and certification requirements for specialized platforms, integration costs including development time and ongoing maintenance, and migration expenses from existing solutions. Managed services may appear more expensive initially but often provide better total cost of ownership when operational overhead is considered.

Consider both current costs and future scaling requirements when evaluating pricing models. Platforms that provide cost-effective entry points while supporting growth can provide better long-term value than solutions optimized only for current requirements.

The Future of Secrets Management: Orchestration and Configuration as Code

The secrets management landscape is undergoing a fundamental shift from simple storage systems to sophisticated orchestration platforms. This evolution reflects the reality of modern infrastructure—applications span multiple clouds, integrate with dozens of services, and require dynamic adaptation to changing requirements.

From Storage to Orchestration

Traditional secret management models rely on centralized vaults where all secrets are stored in a single system, requiring applications to understand specific retrieval mechanisms and access patterns. This approach often creates vendor lock-in and forces organizations to migrate from existing secret stores, disrupting established workflows and creating migration risk.

The emerging orchestration model uses intelligent brokers that aggregate secrets from multiple sources—existing vaults, cloud services, legacy systems—presenting them through unified, consistent interfaces. This orchestration approach provides investment protection by working with existing secret stores, gradual migration without disruptive all-or-nothing transitions, best-of-breed integration leveraging specialized solutions where appropriate, and operational simplification through centralized management of distributed secrets.

Orchestration platforms enable organizations to maintain their current infrastructure investments while gaining the benefits of centralized management, consistent access patterns, and modern capabilities like dynamic credential generation. This approach reduces both risk and cost while providing a clear path toward modern secret management practices.

Configuration as Code Revolution

The convergence of secrets and configuration management represents the next major evolution in infrastructure management. Modern applications require more than isolated credentials—they need comprehensive environment configuration including secrets, feature flags, service endpoints, and deployment parameters. Managing these elements separately creates complexity and increases the risk of configuration drift between environments.

Configuration-as-code principles bring software engineering discipline to environment management by providing version control with complete change history and rollback capabilities, code review processes that ensure changes undergo appropriate scrutiny, automated testing that validates configuration changes before deployment, and reproducible environments that eliminate configuration drift between stages.

Pulumi ESC pioneered this approach, demonstrating how configuration-as-code can systematically address secrets sprawl while improving security, reliability, and developer productivity. This convergence transforms environment management from manual, error-prone processes into systematic, auditable infrastructure that follows established software engineering best practices.

Dynamic Credentials and Zero-Trust Architecture

The shift toward dynamic, short-lived credentials aligns with zero-trust security principles that assume compromise and limit blast radius through minimal access grants. Rather than managing long-lived secrets that require careful rotation and access control, modern platforms generate credentials on-demand with automatic expiration.

This approach provides reduced attack surface through minimal credential lifetime, simplified rotation with automatic credential lifecycle management, enhanced audit trails with precise attribution and timing, and improved compliance through automated policy enforcement. Dynamic credentials eliminate many of the operational challenges associated with traditional secret management while significantly improving security posture.

Organizations adopting zero-trust architectures benefit from secret management platforms that support dynamic credential generation, fine-grained access controls, and comprehensive audit capabilities. These platforms become integral components of zero-trust implementations rather than separate security tools.

AI and Machine Learning Integration

Advanced platforms are incorporating AI and machine learning capabilities to enhance security and operational efficiency. Anomaly detection algorithms identify unusual access patterns that may indicate compromise or policy violations, enabling proactive security response before incidents escalate. Intelligent rotation systems optimize credential lifecycles based on usage patterns and risk assessment, balancing security requirements with operational efficiency.

Automated compliance capabilities ensure policies are consistently applied across all environments while predictive security features identify potential vulnerabilities before they’re exploited. These AI-powered capabilities transform secret management from reactive operations into proactive security systems that enhance overall organizational security posture.

Choosing the Right Path Forward

The secrets management landscape has fundamentally shifted from simple storage to intelligent orchestration. Your choice today will determine not just your current security posture, but your ability to scale and adapt as your infrastructure grows more complex.

The decision framework is clearer than you might expect. If you’re managing multi-cloud environments or have significant existing secret store investments, orchestration platforms like Pulumi ESC provide the most strategic value. They let you modernize your approach without disrupting current workflows, while adding configuration-as-code capabilities and hierarchical environment management that systematically address secrets sprawl.

Organizations committed to maximum flexibility and customization will find HashiCorp Vault’s extensibility unmatched, though it requires substantial technical expertise to operate effectively. Cloud-native teams can leverage AWS Secrets Manager, Azure Key Vault, or Google Secret Manager for seamless integration within their chosen ecosystem, optimizing both cost and operational complexity.

Teams prioritizing rapid adoption and developer experience should consider Doppler, Infisical, or 1Password Secrets Automation. These platforms excel at driving organization-wide adoption through intuitive interfaces while providing essential capabilities without overwhelming complexity.

Here’s the critical insight: secrets management isn’t just a security decision—it directly impacts your development velocity and operational efficiency. Platforms that embrace orchestration, configuration-as-code, and dynamic credentials enable faster development cycles while reducing the operational overhead that comes from managing scattered, manual processes.

The cost of maintaining ad-hoc secrets management extends far beyond security incidents. Developer productivity losses from hunting down credentials, operational complexity from manual rotation processes, and the constant risk of configuration drift between environments create technical debt that compounds over time. The investment in systematic solutions pays dividends immediately through reduced operational overhead and improved security posture.

The industry’s evolution toward zero-trust architectures and configuration-as-code practices isn’t slowing down. Organizations that adopt systematic approaches today position themselves to handle tomorrow’s infrastructure complexity with confidence, while those that delay face increasingly difficult migration challenges as their systems grow more distributed and interdependent.

Ready to revolutionize your secrets and configuration management? Explore Pulumi ESC and discover how secrets orchestration can transform your development workflows while eliminating sprawl across your entire infrastructure.

Most Effective Infrastructure as Code (IaC) Tools

Asaf Ashirov — Thu, 26 Jun 2025 00:00:00 +0000

Infrastructure as Code (IaC) has evolved beyond simple automation into a fundamental shift toward applying software engineering practices to infrastructure management. In 2025, leading organizations aren’t just provisioning infrastructure—they’re treating it as software, complete with testing, version control, code reviews, and continuous integration.

As infrastructure complexity grows, teams increasingly seek approaches that provide the same developer productivity tools they use for application development. While template-based and domain-specific language approaches serve many use cases effectively, teams with complex requirements or programming backgrounds often find that general-purpose programming languages offer advantages in testing, abstraction, and collaboration.

This comprehensive guide examines the most effective infrastructure as code tools available today, providing detailed analysis of core IaC platforms, complementary tools, and related technologies through the lens of software engineering best practices. Whether you’re starting fresh with IaC or evaluating alternatives to overcome limitations in your current toolchain, we’ll help you navigate this complex landscape and choose solutions that truly bring software engineering to infrastructure.

What is Infrastructure as Code?

Infrastructure as Code (IaC) is an approach to automating the provisioning and management of infrastructure using software engineering principles, approaches, and tools. Rather than manually configuring servers, networks, and cloud resources through user interfaces or command-line tools, IaC enables you to define your entire infrastructure declaratively through code.

This approach brings the same benefits that have revolutionized software development—version control, automated testing, code reviews, and CI/CD pipelines—to infrastructure management.

What Are Infrastructure as Code Tools?

Infrastructure as Code tools are platforms and frameworks that enable you to define, provision, and manage infrastructure resources through code rather than manual processes. These tools translate your infrastructure definitions into API calls that create, modify, or destroy cloud resources across various providers.

The most effective IaC tools share several key characteristics:

Goal-state focus: Define your desired infrastructure outcome, whether through declarative syntax (like YAML/JSON templates) or imperative languages that express declarative intent
Multi-cloud support: Work across different cloud providers and services
State management: Track the current state of your infrastructure
Preview capabilities: Show what changes will be made before applying them
Idempotency: Safe to run multiple times with consistent results

Why Infrastructure as Code Tools Are Essential

The shift to IaC tools addresses fundamental challenges that manual infrastructure management cannot solve at scale:

Accelerates Deployment Velocity: Teams can provision complex multi-cloud architectures in minutes instead of weeks. This speed enables faster time-to-market and more frequent, reliable deployments.

Enables True Collaboration: Infrastructure becomes code that teams can review, test, and approve together. This collaborative approach reduces errors and ensures knowledge sharing across the organization.

Eliminates Configuration Drift: Manual changes lead to inconsistencies between environments. IaC ensures your production, staging, and development environments remain identical, eliminating the notorious “works on my machine” syndrome for infrastructure.

Provides Cost Control: Automated provisioning and deprovisioning prevents resource sprawl. Teams can easily track infrastructure costs, set budget alerts, and optimize resource usage across environments.

Ensures Compliance and Security: Codified security policies and compliance requirements are automatically enforced across all deployments. Audit trails become automatic, and policy violations are caught before deployment.

Guarantees Business Continuity: Complete infrastructure definitions stored in version control enable rapid disaster recovery. Organizations can reconstruct entire environments from code, minimizing downtime and data loss.

Infrastructure as Code Tools Overview

This guide covers the following infrastructure as code tools and platforms:

10 Most Used IaC Tools in 2025

Pulumi IaC - Modern IaC with general-purpose programming languages
Terraform - BSL-licensed IaC from HashiCorp that uses the HCL domain-specific language
AWS CDK - Cloud Development Kit for AWS
AWS CloudFormation - Native AWS integration
Azure Resource Manager (ARM) - Native Azure JSON templates
Azure Bicep - Azure-native domain-specific language that compiles to ARM
Google Cloud Infrastructure Manager - Terraform-based solution for Google Cloud
Kubernetes YAML - Native Kubernetes resource definitions
Crossplane - Kubernetes as universal control plane
OpenTofu - Open-source Terraform alternative

Configuration Management Tools

Chef - Configuration management and compliance automation
Puppet - Configuration management and compliance automation
Salt - Configuration management and remote execution

Application and Platform Management Tools

Kubernetes - Container orchestration platform

Security and Compliance Tools

Pulumi ESC - Configuration and secrets management platform
Pulumi Insights - Cloud resource search, analytics, and compliance platform
Snyk - Developer security platform with IaC scanning
Wiz - Comprehensive cloud security platform
HashiCorp Sentinel - Policy-as-code framework for Terraform
Checkov - Static analysis for IaC security
TFLint - Terraform linting and validation

Infrastructure Automation and Management Platforms

Pulumi Cloud - Managed service for Pulumi IaC with enterprise features
HashiCorp Cloud Platform - Enterprise SaaS platform for Terraform management and automation
Spacelift - Automation platform for IaC workflows (not an IaC tool itself)
Env0 - Governance and automation platform for existing IaC tools

Core Infrastructure as Code Tools

1. Pulumi

License: Apache 2.0
Best For: Teams who want flexible, language-agnostic IaC for infrastructure and operations

Pulumi IaC represents a modern approach to infrastructure as code, fundamentally changing how teams approach infrastructure by enabling the use of general-purpose programming languages like Python, TypeScript, Go, C#, and Java, plus YAML for simpler configurations. Unlike tools that force teams to learn proprietary domain-specific languages (DSLs), Pulumi leverages familiar languages and software engineering practices, providing unprecedented flexibility, powerful abstractions, and seamless integration with existing development workflows.

Pulumi’s approach combines the best of both imperative and declarative paradigms: you use imperative programming languages to define your desired infrastructure state, but the Pulumi engine processes this declaratively to determine what changes are needed to achieve your intended outcome.

Key Features:

Universal language support: Use Python, TypeScript, Go, C#, Java, or YAML configurations—no new DSL to learn
Any cloud, any architecture: Deploy to AWS, Azure, Google Cloud, Kubernetes, and 100+ other providers
Real programming constructs: Leverage loops, conditionals, functions, classes, packages, and third-party libraries
Superior developer experience: Full IDE support with IntelliSense, debugging, and refactoring
Built-in testing: Unit and integration testing for infrastructure code
Policy as Code: Enforce compliance and security policies with CrossGuard
Component ecosystem: Rich library of reusable infrastructure components

Universal Language Code Examples:

import * as pulumi from "@pulumi/pulumi";
import * as aws from "@pulumi/aws";
import * as awsx from "@pulumi/awsx";

// Create a VPC with automatic subnets
const vpc = new awsx.ec2.Vpc("main-vpc", {
 cidrBlock: "10.0.0.0/16",
 numberOfAvailabilityZones: 2,
});

// Create an ECS cluster
const cluster = new aws.ecs.Cluster("app-cluster");

// Create an Application Load Balancer
const alb = new awsx.elasticloadbalancingv2.ApplicationLoadBalancer("app-alb", {
 vpcId: vpc.vpcId,
 subnetIds: vpc.publicSubnetIds,
});

// Deploy a containerized application
const service = new awsx.ecs.FargateService("app-service", {
 cluster: cluster.arn,
 taskDefinitionArgs: {
 container: {
 image: "nginx:latest",
 memory: 128,
 ports: [{
 containerPort: 80,
 targetGroup: alb.defaultTargetGroup,
 }],
 },
 },
});

export const vpcId = vpc.vpcId;
export const serviceUrl = alb.loadBalancer.dnsName;

import pulumi
import pulumi_aws as aws
import pulumi_awsx as awsx

# Create a VPC with automatic subnets
vpc = awsx.ec2.Vpc("main-vpc",
 cidr_block="10.0.0.0/16",
 number_of_availability_zones=2)

# Create an ECS cluster
cluster = aws.ecs.Cluster("app-cluster")

# Create an Application Load Balancer
alb = awsx.elasticloadbalancingv2.ApplicationLoadBalancer("app-alb",
 vpc_id=vpc.vpc_id,
 subnet_ids=vpc.public_subnet_ids)

# Deploy a containerized application
service = awsx.ecs.FargateService("app-service",
 cluster=cluster.arn,
 task_definition_args=awsx.ecs.FargateServiceTaskDefinitionArgs(
 container=awsx.ecs.TaskDefinitionContainerDefinitionArgs(
 image="nginx:latest",
 memory=128,
 ports=[awsx.ecs.TaskDefinitionPortMappingArgs(
 container_port=80,
 target_group=alb.default_target_group
 )]
 )
 ))

pulumi.export("vpc_id", vpc.vpc_id)
pulumi.export("service_url", alb.load_balancer.dns_name)

package main

import (
 "github.com/pulumi/pulumi-aws/sdk/v6/go/aws/ecs"
 "github.com/pulumi/pulumi-awsx/sdk/v2/go/awsx/ec2"
 "github.com/pulumi/pulumi-awsx/sdk/v2/go/awsx/elasticloadbalancingv2"
 awsxecs "github.com/pulumi/pulumi-awsx/sdk/v2/go/awsx/ecs"
 "github.com/pulumi/pulumi/sdk/v3/go/pulumi"
)

func main() {
 pulumi.Run(func(ctx *pulumi.Context) error {
 // Create a VPC with automatic subnets
 vpc, err := ec2.NewVpc(ctx, "main-vpc", &ec2.VpcArgs{
 CidrBlock: pulumi.String("10.0.0.0/16"),
 NumberOfAvailabilityZones: pulumi.Int(2),
 })
 if err != nil {
 return err
 }

 // Create an ECS cluster
 cluster, err := ecs.NewCluster(ctx, "app-cluster", nil)
 if err != nil {
 return err
 }

 // Create an Application Load Balancer
 alb, err := elasticloadbalancingv2.NewApplicationLoadBalancer(ctx, "app-alb", &elasticloadbalancingv2.ApplicationLoadBalancerArgs{
 VpcId: vpc.VpcId,
 SubnetIds: vpc.PublicSubnetIds,
 })
 if err != nil {
 return err
 }

 // Deploy a containerized application
 _, err = awsxecs.NewFargateService(ctx, "app-service", &awsxecs.FargateServiceArgs{
 Cluster: cluster.Arn,
 TaskDefinitionArgs: &awsxecs.FargateServiceTaskDefinitionArgs{
 Container: &awsxecs.TaskDefinitionContainerDefinitionArgs{
 Image: pulumi.String("nginx:latest"),
 Memory: pulumi.Int(128),
 Ports: awsxecs.TaskDefinitionPortMappingArray{
 &awsxecs.TaskDefinitionPortMappingArgs{
 ContainerPort: pulumi.Int(80),
 TargetGroup: alb.DefaultTargetGroup,
 },
 },
 },
 },
 })
 if err != nil {
 return err
 }

 ctx.Export("vpcId", vpc.VpcId)
 ctx.Export("serviceUrl", alb.LoadBalancer.DnsName())
 return nil
 })
}

using System.Collections.Generic;
using Pulumi;
using Aws = Pulumi.Aws;
using Awsx = Pulumi.Awsx;

return await Deployment.RunAsync(() =>
{
 // Create a VPC with automatic subnets
 var vpc = new Awsx.Ec2.Vpc("main-vpc", new()
 {
 CidrBlock = "10.0.0.0/16",
 NumberOfAvailabilityZones = 2,
 });

 // Create an ECS cluster
 var cluster = new Aws.Ecs.Cluster("app-cluster");

 // Create an Application Load Balancer
 var alb = new Awsx.ElasticLoadBalancingV2.ApplicationLoadBalancer("app-alb", new()
 {
 VpcId = vpc.VpcId,
 SubnetIds = vpc.PublicSubnetIds,
 });

 // Deploy a containerized application
 var service = new Awsx.Ecs.FargateService("app-service", new()
 {
 Cluster = cluster.Arn,
 TaskDefinitionArgs = new Awsx.Ecs.Inputs.FargateServiceTaskDefinitionArgs
 {
 Container = new Awsx.Ecs.Inputs.TaskDefinitionContainerDefinitionArgs
 {
 Image = "nginx:latest",
 Memory = 128,
 Ports = new[]
 {
 new Awsx.Ecs.Inputs.TaskDefinitionPortMappingArgs
 {
 ContainerPort = 80,
 TargetGroup = alb.DefaultTargetGroup,
 },
 },
 },
 },
 });

 return new Dictionary<string, object?>
 {
 ["vpcId"] = vpc.VpcId,
 ["serviceUrl"] = alb.LoadBalancer.Apply(lb => lb.DnsName),
 };
});

name: aws-ecs-example
runtime: yaml
description: An example that deploys an ECS Fargate service with load balancer

resources:
 # Create a VPC with automatic subnets
 main-vpc:
 type: awsx:ec2:Vpc
 properties:
 cidrBlock: "10.0.0.0/16"
 numberOfAvailabilityZones: 2

 # Create an ECS cluster
 app-cluster:
 type: aws:ecs:Cluster

 # Create an Application Load Balancer
 app-alb:
 type: awsx:elasticloadbalancingv2:ApplicationLoadBalancer
 properties:
 vpcId: ${main-vpc.vpcId}
 subnetIds: ${main-vpc.publicSubnetIds}

 # Deploy a containerized application
 app-service:
 type: awsx:ecs:FargateService
 properties:
 cluster: ${app-cluster.arn}
 taskDefinitionArgs:
 container:
 image: "nginx:latest"
 memory: 128
 ports:
 - containerPort: 80
 targetGroup: ${app-alb.defaultTargetGroup}

outputs:
 vpcId: ${main-vpc.vpcId}
 serviceUrl: ${app-alb.loadBalancer.dnsName}

Key Features:

General-purpose language support: Use Python, TypeScript, Go, C#, Java, or YAML without learning new DSLs
Software engineering practices: Full IDE support, comprehensive testing frameworks, debugging capabilities
Multi-cloud flexibility: Native cloud provider SDKs with same-day feature access across 150+ providers
Incremental adoption: Migration tools and state integration for gradual transitions
Open source licensing: Apache 2.0 ensures long-term freedom and flexibility

Considerations:

Learning curve: Teams new to programming may prefer template-based approaches initially
Ecosystem maturity: Smaller community compared to more established tools like Terraform
Tool complexity: Advanced features may require more setup than simpler template systems

Organizations like Unity, Snowflake, and Starburst have reported significant productivity improvements (80-90% deployment time reductions) when adopting programming language-based approaches. These improvements typically occur when transitioning from manual processes or basic template systems to automated approaches with comprehensive testing, IDE integration, and code reusability. Results vary based on starting point, team expertise, infrastructure complexity, and specific use cases.

Ready to get started? Experience Pulumi’s programming language approach and see how familiar languages can transform your infrastructure management with comprehensive testing, powerful abstractions, and seamless multi-cloud support.

2. Terraform

License: Business Source License (BSL) 1.1 (Not Open Source)
Best For: Teams with existing Terraform expertise and established workflows

Terraform uses HashiCorp Configuration Language (HCL) to define infrastructure across multiple cloud providers. However, its 2023 licensing change to BSL (no longer open source) and inherent limitations with domain-specific languages create challenges for teams requiring advanced software engineering practices.

Key Features:

Extensive provider ecosystem: Largest collection of community-maintained providers covering virtually every cloud service
Established workflows: Mature plan-and-apply process with extensive tooling and CI/CD integrations
Community and resources: Vast ecosystem of modules, extensive documentation, training materials, and community support
Enterprise adoption: Widely adopted in enterprises with established processes and expertise
Module ecosystem: Rich collection of reusable Terraform modules for common patterns

When Terraform Works Well:

Teams with existing HCL expertise and Terraform investments
Infrastructure patterns that fit well within HCL’s declarative model
Teams comfortable with template-based approaches

Considerations for Complex Scenarios:

Language constraints: HCL’s domain-specific nature can require workarounds for complex logic compared to general-purpose programming languages
Testing approach: Primarily supports integration testing; teams needing comprehensive unit testing may require additional tooling
IDE experience: While improving, HCL tooling provides less comprehensive support than mature programming language ecosystems
State management: Requires manual backend configuration and locking setup for team collaboration

Code Example:

data "aws_availability_zones" "available" {}

resource "aws_vpc" "main" {
 cidr_block = "10.0.0.0/16"

 tags = {
 Name = "main-vpc"
 }
}

resource "aws_subnet" "public" {
 count = 2
 vpc_id = aws_vpc.main.id
 cidr_block = "10.0.${count.index + 1}.0/24"
 availability_zone = data.aws_availability_zones.available.names[count.index]

 tags = {
 Name = "public-subnet-${count.index + 1}"
 }
}

3. AWS Cloud Development Kit (CDK)

License: Apache 2.0
Best For: AWS-focused teams who prefer programming languages over templates

AWS CDK allows you to define AWS infrastructure using familiar programming languages, synthesizing CloudFormation templates for deployment while providing higher-level abstractions. CDK addresses many limitations of traditional template-based approaches by enabling general-purpose programming languages.

Key Features:

General-purpose programming languages: TypeScript, Python, Java, C#, JavaScript support with full IDE integration (Go available in Developer Preview)
AWS-optimized constructs: High-level components encapsulating AWS best practices
Type safety: Compile-time checking and IntelliSense support
CloudFormation reliability: Built on AWS’s proven deployment engine

Notable Limitations:

AWS-only ecosystem: Locked into single cloud provider, limiting multi-cloud strategies
CloudFormation constraints: Inherits template size limits and deployment restrictions
Vendor lock-in: Deep AWS integration makes migration to other clouds challenging
Limited cross-cloud consistency: Teams need different tools and approaches for multi-cloud deployments

CDK represents a significant improvement over CloudFormation templates but constrains organizations to AWS-only infrastructure strategies.

Code Example:

import * as cdk from 'aws-cdk-lib';
import * as ec2 from 'aws-cdk-lib/aws-ec2';
import * as ecs from 'aws-cdk-lib/aws-ecs';
import { Construct } from 'constructs';

export class MyStack extends cdk.Stack {
 constructor(scope: Construct, id: string, props?: cdk.StackProps) {
 super(scope, id, props);

 const vpc = new ec2.Vpc(this, 'MyVpc', {
 maxAzs: 2
 });

 const cluster = new ecs.Cluster(this, 'MyCluster', {
 vpc: vpc
 });

 const taskDefinition = new ecs.FargateTaskDefinition(this, 'TaskDef', {
 memoryLimitMiB: 512,
 cpu: 256
 });

 taskDefinition.addContainer('web', {
 image: ecs.ContainerImage.fromRegistry('nginx:latest'),
 portMappings: [{ containerPort: 80 }]
 });

 new ecs.FargateService(this, 'MyService', {
 cluster: cluster,
 taskDefinition: taskDefinition
 });
 }
}

4. AWS CloudFormation

License: Proprietary (AWS Service)
Best For: AWS-only deployments requiring deep service integration

AWS CloudFormation provides the foundation for infrastructure as code on AWS, offering native integration with all AWS services and deep platform-specific features.

Pulumi Integration: Pulumi provides native AWS providers that offer the same comprehensive AWS service coverage as CloudFormation, with the added benefit of using general-purpose programming languages. You can also import existing CloudFormation stacks into Pulumi for gradual migration or hybrid management approaches.

Key Features:

AWS-native: First-party support for all AWS services
JSON/YAML templates: Declarative resource definitions
Stack management: Organized resource grouping and lifecycle management
Change sets: Preview infrastructure changes before deployment
Service integration: Deep integration with other AWS services

Code Example:

AWSTemplateFormatVersion: '2010-09-09'
Resources:
 MyVPC:
 Type: AWS::EC2::VPC
 Properties:
 CidrBlock: 10.0.0.0/16
 EnableDnsHostnames: true
 Tags:
 - Key: Name
 Value: MyVPC

 MySubnet:
 Type: AWS::EC2::Subnet
 Properties:
 VpcId: !Ref MyVPC
 CidrBlock: 10.0.1.0/24
 AvailabilityZone: !Select [0, !GetAZs '']

5. Azure Resource Manager (ARM)

License: Proprietary (Microsoft Service)
Best For: Azure-native deployments requiring comprehensive platform integration

Azure Resource Manager provides the foundational infrastructure as code solution for Microsoft Azure, offering complete support for Azure services through JSON-based ARM templates. As Azure’s native IaC solution, ARM templates provide the most comprehensive coverage of Azure services and features.

Pulumi Integration: Pulumi’s native Azure providers offer equivalent comprehensive Azure service coverage with general-purpose programming languages. ARM templates can be imported into Pulumi, and you can reference ARM deployments from Pulumi programs for hybrid scenarios.

Key Features:

Azure-native: Complete Azure service coverage with first-party support
JSON templates: Declarative resource definitions in JSON format
Resource groups: Logical organization of related resources
Deployment modes: Complete or incremental deployment options
Comprehensive integration: Deep integration with Azure services and features

Code Example:

{
 "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
 "contentVersion": "1.0.0.0",
 "resources": [
 {
 "type": "Microsoft.Storage/storageAccounts",
 "apiVersion": "2023-01-01",
 "name": "mystorageaccount",
 "location": "[resourceGroup().location]",
 "sku": {
 "name": "Standard_LRS"
 },
 "kind": "StorageV2"
 }
 ]
}

6. Azure Bicep

License: MIT
Best For: Azure deployments requiring improved readability and developer experience

Azure Bicep is a domain-specific language (DSL) that simplifies Azure Resource Manager template authoring. Bicep files compile transparently to ARM templates, providing all the capabilities of ARM with significantly improved syntax and developer experience.

Key Features:

Simplified syntax: Clean, readable syntax compared to JSON ARM templates
ARM compilation: Compiles to ARM templates for deployment, ensuring full compatibility
Type safety: Strong typing and IntelliSense support in development environments
Modular design: Support for modules and code reuse across projects
Azure-native: Complete Azure service coverage through ARM template compilation

Code Example:

@description('Storage Account type')
@allowed([
 'Standard_LRS'
 'Standard_GRS'
 'Standard_ZRS'
 'Premium_LRS'
])
param storageAccountType string = 'Standard_LRS'

@description('Location for the storage account.')
param location string = resourceGroup().location

resource storageAccount 'Microsoft.Storage/storageAccounts@2023-01-01' = {
 name: 'mystorageaccount'
 location: location
 sku: {
 name: storageAccountType
 }
 kind: 'StorageV2'
 properties: {}
}

7. Google Cloud Infrastructure Manager

License: Proprietary (Google Service)
Best For: Google Cloud Platform deployments using Terraform

Google Cloud Infrastructure Manager automates the deployment and management of Google Cloud infrastructure resources using Terraform configurations, representing Google’s modern approach to infrastructure as code. Infrastructure Manager replaces Google Cloud Deployment Manager, which will reach end of support on December 31, 2025.

Key Features:

Terraform-based: Uses standard Terraform configurations declaratively
Automated workflows: Handles Terraform init, validate, and apply operations
Version control integration: Supports Git repositories and Cloud Storage
Deployment tracking: Comprehensive metadata storage and logging
Multiple Terraform versions: Flexibility in Terraform version selection
Cloud Build integration: Leverages Google Cloud Build for execution environment
Migration path: Provides upgrade path from legacy Cloud Deployment Manager

Code Example:

# main.tf - Terraform configuration for Infrastructure Manager
resource "google_compute_instance" "vm_instance" {
 name = "my-vm"
 machine_type = "e2-medium"
 zone = "us-central1-a"

 boot_disk {
 initialize_params {
 image = "debian-cloud/debian-11"
 }
 }

 network_interface {
 network = "default"
 access_config {
 // Ephemeral public IP
 }
 }

 metadata = {
 startup-script = "echo Hello from Infrastructure Manager!"
 }
}

output "instance_ip" {
 value = google_compute_instance.vm_instance.network_interface[0].access_config[0].nat_ip
}

8. Kubernetes YAML

License: Apache 2.0
Best For: Teams managing container-native applications and cloud-native infrastructure

Kubernetes YAML manifests represent one of the most widely adopted forms of infrastructure as code, enabling teams to define, version, and manage containerized applications and their supporting infrastructure through declarative configuration files.

Key Features:

Declarative configuration: Define desired state through human-readable YAML files
Native Kubernetes integration: Direct integration with Kubernetes API without additional tools
GitOps compatibility: Version control YAML files for automated deployment workflows
Resource relationships: Define dependencies and relationships between Kubernetes resources
Extensive ecosystem: Rich ecosystem of operators and custom resources extending functionality

Code Example:

apiVersion: apps/v1
kind: Deployment
metadata:
 name: web-app
 labels:
 app: web-app
spec:
 replicas: 3
 selector:
 matchLabels:
 app: web-app
 template:
 metadata:
 labels:
 app: web-app
 spec:
 containers:
 - name: web-app
 image: nginx:1.21
 ports:
 - containerPort: 80
 resources:
 requests:
 memory: "64Mi"
 cpu: "250m"
 limits:
 memory: "128Mi"
 cpu: "500m"
---
apiVersion: v1
kind: Service
metadata:
 name: web-app-service
spec:
 selector:
 app: web-app
 ports:
 - port: 80
 targetPort: 80
 type: LoadBalancer

9. Crossplane

License: Apache 2.0
Best For: Kubernetes-first organizations managing multi-cloud infrastructure

Crossplane is a Cloud-Native Framework for Platform Engineering that extends Kubernetes to help organizations build custom infrastructure management platforms, allowing teams to provision and manage cloud resources using Kubernetes APIs and patterns.

Pulumi Integration: Pulumi offers the Pulumi Kubernetes Operator (PKO) that provides similar Kubernetes-native infrastructure management capabilities, plus support for YAML-based definitions. Teams can also use Pulumi programs to provision the underlying infrastructure that Crossplane manages, creating layered infrastructure management approaches.

Key Features:

Kubernetes-native: Uses CRDs and standard Kubernetes patterns
Composite resources: Create higher-level infrastructure abstractions
GitOps compatibility: Seamless integration with GitOps workflows
Multi-cloud support: Provision resources across cloud providers
Policy integration: Leverage Kubernetes RBAC and admission controllers

Code Example:

apiVersion: ec2.aws.crossplane.io/v1alpha1
kind: VPC
metadata:
 name: sample-vpc
spec:
 cidrBlock: 10.0.0.0/16
 region: us-east-1
 tags:
 Name: sample-vpc
 providerConfigRef:
 name: aws-provider-config

10. OpenTofu

License: Mozilla Public License 2.0
Best For: Teams seeking an open-source Terraform alternative with community governance

OpenTofu emerged as a fork of Terraform v1.5.x following HashiCorp’s license change, maintained by the Linux Foundation. It provides full compatibility with Terraform while ensuring long-term open-source availability under MPL 2.0 licensing.

Key Features:

True open source: MPL 2.0 license with community governance via Linux Foundation ensuring long-term accessibility
Terraform compatibility: Drop-in replacement maintaining existing workflows, modules, and provider ecosystem
Community-driven development: Transparent roadmap, open contribution process, and vendor-neutral governance
License certainty: Removes concerns about future licensing restrictions for commercial use

When OpenTofu Makes Sense:

Organizations requiring guaranteed open-source licensing for compliance or philosophical reasons
Teams with significant Terraform investments wanting to avoid vendor lock-in
Environments where community governance and transparency are priorities
Projects needing long-term license stability

Architectural Considerations: As a Terraform fork, OpenTofu inherits the same architectural approach, which means teams evaluating it should consider whether HCL-based infrastructure definition meets their long-term needs for testing, IDE integration, and developer productivity, or whether a programming language-based approach might better serve complex scenarios.

Code Example:

resource "aws_instance" "web" {
 ami = "ami-0c55b159cbfafe1d0"
 instance_type = "t3.micro"

 tags = {
 Name = "HelloWorld"
 }
}

output "instance_ip" {
 value = aws_instance.web.public_ip
}

Ansible

License: GPL v3
Best For: Configuration management with some infrastructure provisioning capabilities

Ansible is primarily a configuration management tool, not a pure Infrastructure as Code tool. While Ansible can provision some cloud resources, its core strength lies in configuring and managing software on existing systems rather than comprehensive infrastructure provisioning.

Ansible provides configuration management and limited infrastructure provisioning through its agentless architecture and simple YAML-based playbooks.

Pulumi Integration: Rather than competing with Ansible, Pulumi complements it perfectly. Use Pulumi for infrastructure provisioning and Ansible for configuration management. Pulumi’s Command provider can execute Ansible playbooks as part of your infrastructure deployment, and many Pulumi customers use both tools together for comprehensive infrastructure automation. See example: Deploy WordPress to AWS using Pulumi and Ansible.

Key Features:

Agentless architecture: No software installation required on target systems
YAML playbooks: Human-readable automation definitions
Idempotent operations: Safe to run multiple times
Large module library: Extensive built-in functionality for various systems
Push-based execution: Centralized control and execution

Code Example:

---
- name: Provision AWS infrastructure
 hosts: localhost
 tasks:
 - name: Create VPC
 amazon.aws.ec2_vpc_net:
 name: ansible-vpc
 cidr_block: 10.0.0.0/16
 region: us-east-1
 tags:
 Environment: production
 register: vpc

 - name: Create subnet
 amazon.aws.ec2_vpc_subnet:
 vpc_id: "{{ vpc.vpc.id }}"
 cidr: 10.0.1.0/24
 region: us-east-1
 tags:
 Name: ansible-subnet

Chef

License: Apache 2.0
Best For: Complex configuration management scenarios requiring programmable logic

Chef is a configuration management tool, not an Infrastructure as Code tool. Chef focuses on configuring and maintaining software, services, and system settings on existing infrastructure rather than provisioning cloud resources.

Chef provides configuration management and system automation using Ruby-based recipes and cookbooks, offering powerful programmability for complex configuration scenarios.

Key Features:

Ruby DSL: Full programming language for configuration logic
Agent-based architecture: Continuous compliance and drift detection
Cookbook ecosystem: Reusable configuration patterns and community recipes
Test Kitchen: Infrastructure testing and validation framework
Enterprise features: Advanced reporting and compliance capabilities

Code Example:

# cookbook/recipes/default.rb
package 'nginx' do
 action :install
end

service 'nginx' do
 action [:enable, :start]
end

template '/etc/nginx/sites-available/default' do
 source 'default.erb'
 owner 'root'
 group 'root'
 mode '0644'
 notifies :restart, 'service[nginx]'
end

Puppet

License: Apache 2.0
Best For: Enterprise environments requiring strong governance and compliance

Puppet is a configuration management tool, not an Infrastructure as Code tool. Puppet specializes in maintaining desired configuration state on existing systems and ensuring compliance, rather than provisioning cloud infrastructure.

Puppet offers enterprise-grade configuration management with a focus on compliance, governance, and declarative system state management.

Key Features:

Declarative language: Puppet DSL for describing desired system state
Compliance reporting: Built-in governance and audit capabilities
Forge marketplace: Community modules and enterprise content
Enterprise support: Professional services and enterprise features
Continuous enforcement: Ongoing configuration compliance monitoring

Code Example:

# manifests/webserver.pp
class webserver {
 package { 'nginx':
 ensure => installed,
 }

 service { 'nginx':
 ensure => running,
 enable => true,
 require => Package['nginx'],
 }

 file { '/var/www/html/index.html':
 ensure => file,
 content => '<h1>Hello from Puppet!</h1>',
 owner => 'www-data',
 group => 'www-data',
 mode => '0644',
 }
}

Salt

License: Apache 2.0
Best For: Python-oriented teams requiring high-performance configuration management

Salt is primarily a configuration management and remote execution tool, not a pure Infrastructure as Code tool. While Salt can manage some infrastructure components, its primary focus is on configuring systems and executing commands across large infrastructures.

Salt provides fast, scalable configuration management and remote execution using Python, designed for high-performance system automation at scale.

Key Features:

Python-based: Leverage the Python ecosystem and libraries
High performance: Fast execution across large infrastructures
Event-driven automation: Reactive automation and orchestration
Pillar data system: Secure, hierarchical data management
Flexible communication: Support for various communication patterns

Code Example:

# /srv/salt/webserver.sls
nginx:
 pkg.installed: []
 service.running:
 - enable: True
 - require:
 - pkg: nginx

/var/www/html/index.html:
 file.managed:
 - source: salt://files/index.html
 - user: www-data
 - group: www-data
 - mode: 644

Infrastructure as Code Tools

Kubernetes - Container Orchestration Platform

License: Apache 2.0
Best For: Container-native infrastructure and application management

While primarily a container orchestration platform, Kubernetes itself serves as an infrastructure as code tool through its declarative YAML manifests and API-driven resource management.

Key Features:

Declarative configuration: YAML-based resource definitions
API-driven: RESTful API for all resource operations
Self-healing: Automatic recovery and reconciliation
Extensible: Custom resources and controllers
GitOps compatible: Works seamlessly with Git-based workflows

Code Example:

apiVersion: apps/v1
kind: Deployment
metadata:
 name: nginx-deployment
spec:
 replicas: 3
 selector:
 matchLabels:
 app: nginx
 template:
 metadata:
 labels:
 app: nginx
 spec:
 containers:
 - name: nginx
 image: nginx:1.21
 ports:
 - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
 name: nginx-service
spec:
 selector:
 app: nginx
 ports:
 - port: 80
 targetPort: 80
 type: LoadBalancer

Infrastructure as Code Security and Compliance Tools

While the tools above focus on provisioning and managing infrastructure, a complete IaC ecosystem includes security scanning and compliance tools. These tools complement your primary IaC tool by providing security analysis, policy enforcement, and compliance checking:

Security Scanning Tools

Snyk - License: Proprietary
Leading developer security platform that includes comprehensive infrastructure as code scanning alongside container and application security. Provides real-time vulnerability detection, compliance checking, and automated remediation guidance. Integrates with popular development tools and CI/CD pipelines with extensive enterprise adoption.

Wiz - License: Proprietary
Comprehensive cloud security platform that includes infrastructure as code scanning capabilities. Provides vulnerability management, compliance monitoring, and security posture assessment across cloud environments. Offers integration with development workflows and supports multiple IaC formats with strong enterprise presence.

Checkov - License: Apache 2.0
Popular open-source static analysis tool for infrastructure as code that scans cloud infrastructure configurations for security and compliance issues. Supports Terraform, CloudFormation, Kubernetes, Helm, ARM templates, and more. Integrates with CI/CD pipelines and provides over 1000+ built-in policies covering CIS benchmarks, PCI DSS, and GDPR compliance.

Linting and Validation Tools

TFLint - License: MPL 2.0
Terraform linter focused on possible errors, best practices, and security issues in Terraform configurations. Provides pluggable rule sets for cloud providers (AWS, Azure, GCP) and helps enforce coding standards, detect deprecated syntax, and prevent common configuration errors.

These security tools integrate into CI/CD pipelines alongside your chosen IaC tool to provide comprehensive security coverage throughout the infrastructure lifecycle.

Pulumi ESC

License: Apache 2.0 (Open Source) / Proprietary (SaaS)
Best For: Teams needing centralized configuration and secrets management across environments and tools

Pulumi ESC (Environments, Secrets, and Configuration) is a comprehensive platform for managing configuration data, secrets, and environment variables across your entire infrastructure and application stack. ESC provides a single source of truth for configuration that works with any infrastructure tool, not just Pulumi.

Key Features:

Universal configuration management: Works with any infrastructure tool, CI/CD system, or application
Hierarchical environments: Compose configuration from multiple sources with inheritance and overrides
Dynamic secrets: Integration with cloud providers for short-lived credentials and just-in-time access
Policy-based access control: Fine-grained permissions and audit logging for configuration access
Multiple consumption methods: CLI, REST API, SDK integration, and direct cloud provider integration
GitOps workflows: Version control integration with pull request-based configuration management

Code Example:

# Production environment configuration
values:
 app:
 name: myapp
 version: ${fn.fromJSON(aws.ecr.getAuthorizationToken).password}
 database:
 connectionString: ${pulumi.database.connectionString}
imports:
 - shared/common
 - aws/production

Pulumi Insights

License: Proprietary (SaaS)
Best For: Organizations needing comprehensive cloud resource visibility, search, and compliance monitoring

Pulumi Insights provides cloud resource search, analytics, and compliance capabilities across your entire multi-cloud infrastructure, regardless of how resources were provisioned. It offers a unified view of your cloud resources with powerful search, cost analysis, and policy enforcement.

Key Features:

Universal cloud inventory: Discover and catalog resources across AWS, Azure, Google Cloud, and Kubernetes
Advanced search and analytics: Query resources by tags, properties, relationships, and compliance status
Cost optimization insights: Resource cost analysis, trends, and optimization recommendations
Compliance monitoring: Continuous policy evaluation and drift detection across all cloud resources
Resource relationships: Understand dependencies and relationships between cloud resources
Integration with any IaC tool: Works with resources created by Pulumi, Terraform, CloudFormation, or manually

Use Cases:

Cloud governance: Ensure compliance with organizational policies and industry standards
Cost management: Identify unused resources and optimization opportunities
Security auditing: Track resource configurations and detect security misconfigurations
Multi-cloud visibility: Single pane of glass for resources across different cloud providers

Infrastructure Automation and Management Platforms

While the above tools focus on defining and provisioning infrastructure, several platforms provide automation, orchestration, and management capabilities that work with Infrastructure as Code tools. Important: These are not IaC tools themselves, but rather automation platforms that rely on underlying IaC tools.

IaC Automation Platforms

Pulumi Cloud Best For: Teams using Pulumi IaC who need enterprise-grade collaboration, security, and governance

Pulumi Cloud is the smartest and easiest way to automate, secure, and manage everything you run in the cloud. It serves as the managed service companion to Pulumi’s open-source infrastructure as code tool, providing enterprise capabilities that extend beyond basic IaC functionality.

The relationship between Pulumi IaC and Pulumi Cloud follows a Git/GitHub model: Pulumi IaC is like Git (fully open source and functional on its own), while Pulumi Cloud is like GitHub (a managed service that makes the open-source tool much easier to use securely at scale with teams).

Key Features:

Managed state backend: Secure, scalable state management with transactional protocols
Team collaboration: Full audit logs, RBAC, and identity provider integration
Centralized secrets management: Pulumi ESC for configuration and secrets across environments
Cloud inventory and insights: Pulumi Insights for search, compliance, and drift detection
Remote deployments: CI/CD integrations and automated workflows
Policy enforcement: Built-in security and compliance policy as code
Multi-product platform: Integrated IaC, secrets management, and cloud insights

Pulumi IaC works with or without Pulumi Cloud - you can use DIY backends (S3, Azure Blob, etc.) or the managed service. However, Pulumi Cloud becomes the default experience when you install the Pulumi CLI, providing instant collaboration capabilities without the overhead of building and maintaining your own infrastructure management platform.

HashiCorp Cloud Platform (HCP) - License: Proprietary (SaaS)
Best For: Organizations standardizing on HashiCorp tools across infrastructure and security lifecycle management

HashiCorp Cloud Platform (HCP) is an enterprise-grade SaaS platform that provides unified lifecycle management for infrastructure and security operations. HCP Terraform (formerly Terraform Cloud) serves as the managed service for Terraform/OpenTofu workflows, while the broader platform integrates multiple HashiCorp tools.

Key Features:

HCP Terraform management: Workspace organization, remote execution, and state management for Terraform
Infrastructure lifecycle automation: Continuous validation, drift detection, and module lifecycle management
Private VCS access: Secure integration with private version control repositories
Policy enforcement: Sentinel policy-as-code framework for compliance and governance
Integrated security services: HCP Vault for secrets management, HCP Consul for service networking
Enterprise access controls: RBAC, SAML SSO integration, and fine-grained permissions
Module and image management: HCP Packer for automated machine/container image creation

HCP focuses specifically on HashiCorp tool integration and provides a comprehensive platform for organizations that have standardized on the HashiCorp ecosystem for infrastructure and security operations.

Spacelift - Spacelift is not an Infrastructure as Code tool—it’s an automation and workflow platform that relies on other IaC tools like Terraform, OpenTofu, Pulumi, CloudFormation, and Kubernetes. Spacelift provides CI/CD pipelines, policy enforcement, and collaboration features for teams using these underlying IaC tools.

Env0 - Env0 is not an Infrastructure as Code tool—it’s an automation platform that provides workflow management, governance, and collaboration features for existing IaC tools like Terraform, OpenTofu, and Terragrunt. It adds CI/CD pipelines, cost management, and policy enforcement on top of these tools.

Atlantis - An open-source tool that provides GitOps-style workflows for Terraform and OpenTofu by automatically running terraform plan and apply operations via pull request automation.

Development Environment Tools

Vagrant - Vagrant is not an Infrastructure as Code tool—it’s a development environment management tool that creates and configures lightweight, reproducible virtual development environments. While it can provision VMs, its focus is on local development environments rather than cloud infrastructure provisioning.

Docker Compose - While not an IaC tool, Docker Compose defines multi-container applications and can be used alongside IaC tools for application deployment after infrastructure provisioning.

These platforms and tools serve important roles in the infrastructure automation ecosystem but should not be confused with Infrastructure as Code tools themselves. They enhance and orchestrate the work of actual IaC tools rather than replacing them.

The Future of Infrastructure as Code

The infrastructure as code landscape is rapidly evolving toward software engineering maturity, with several transformative trends reshaping how organizations approach infrastructure:

Software Engineering Convergence: The most significant trend is the convergence of infrastructure and software engineering practices. Organizations are moving away from limited DSLs toward full programming languages that enable testing, debugging, refactoring, and other software engineering best practices. This shift enables infrastructure teams to leverage the same tools, skills, and methodologies that have proven successful in application development.

Real-Time Cloud Integration: Native cloud provider SDK integration is becoming the standard, replacing community-maintained providers that lag behind new cloud features. Organizations expect same-day access to new cloud services without waiting weeks or months for provider updates.

Comprehensive Testing Paradigms: Infrastructure testing is evolving beyond basic integration tests to include unit testing, property-based testing, and continuous validation. Teams are applying test-driven development principles to infrastructure, catching issues before deployment rather than discovering them in production.

Internal Developer Platform Evolution: Organizations are building sophisticated Internal Developer Platforms that provide self-service infrastructure capabilities while maintaining governance and compliance. These platforms leverage infrastructure as code tools to create standardized, reusable components that accelerate development velocity.

AI-Enhanced Development: Integration of AI tools to help generate, optimize, and troubleshoot infrastructure code, with particular strength in environments that use familiar programming languages where AI assistance is most mature. Emerging technologies like Model Context Protocol (MCP) and AI prompt templates are beginning to enable more sophisticated AI-infrastructure interactions.

These trends favor tools that embrace software engineering principles from the ground up, rather than attempting to retrofit programming capabilities onto template-based or DSL-limited approaches.

Migration and Adoption Strategies

Organizations don’t need to choose between maintaining existing infrastructure and adopting modern IaC approaches. Proven migration strategies enable gradual adoption while preserving operational stability.

Incremental Adoption Approaches

Team-by-Team Migration: Start with new projects or specific teams, allowing gradual skill development and process refinement. Teams can maintain existing infrastructure while building new capabilities with modern tools.

Project-by-Project Transition: Migrate individual applications or services incrementally, enabling teams to learn and optimize approaches before expanding scope.

Hybrid Operations: Use state integration and import tools to reference existing infrastructure while building new components with modern IaC tools.

Proven Migration Timelines

Real-world migrations demonstrate that adoption can be remarkably fast with proper tooling:

Atlassian Bitbucket: Complete Terraform to Pulumi migration in 2 days using automated conversion tools. This rapid migration was enabled by existing Python expertise on the team, well-structured Terraform code, and straightforward infrastructure patterns that converted cleanly.
Enterprise migrations: Typical team migrations complete in weeks, not months, depending on infrastructure complexity and team preparation
Learning curve: Teams with programming experience adapt to language-based IaC approaches within days, while those new to programming may require additional training time

Migration Tools and Resources

Automated Conversion: Tools like tf2pulumi and pulumi convert automatically translate existing infrastructure definitions, preserving logic and structure while upgrading to modern approaches.

State Integration: Import existing cloud resources and reference Terraform state during transition periods, enabling zero-downtime migrations.

Training and Support: Comprehensive documentation, tutorials, and community resources accelerate team onboarding and reduce migration risks.

Best Practices for Successful Adoption

Start with pilot projects to build confidence and establish patterns
Leverage automated migration tools to reduce manual conversion effort
Maintain state integration during transition periods for operational continuity
Invest in team training to maximize productivity gains from modern approaches
Establish testing practices early to realize reliability and quality benefits

The key insight: migration to modern IaC approaches is a technical upgrade, not a complete rebuild. Organizations can preserve existing investments while gaining access to superior tooling and practices.

Frequently Asked Questions

Which IaC tool should I choose for AWS?

For teams wanting programming languages: Pulumi IaC and AWS CDK both offer excellent developer experiences with general-purpose programming languages. Pulumi provides multi-cloud flexibility, while CDK offers deep AWS-native integration.

For AWS-only deployments: CloudFormation provides the deepest native AWS service support and direct integration with AWS services.

For Terraform ecosystem users: OpenTofu provides open-source licensing with Terraform compatibility, while Terraform offers extensive community resources and established workflows.

Is Terraform still worth learning in 2025?

Terraform remains a valuable skill and viable choice for many scenarios, though teams should consider their specific needs and long-term goals:

When Terraform Makes Sense:

Teams building on existing Terraform infrastructure and expertise
Organizations with successful Terraform workflows and established processes
Projects that benefit from Terraform’s extensive module ecosystem
Teams comfortable with HCL and template-based approaches

When to Consider Alternatives:

Teams wanting comprehensive testing capabilities (unit, property, integration testing)
Organizations requiring full IDE support with debugging and refactoring
Projects needing complex programmatic logic or extensive code reuse
Teams with strong programming backgrounds who prefer familiar languages

Key Considerations:

Licensing: Terraform’s Business Source License may create restrictions for some commercial scenarios
Ecosystem: Terraform has the largest provider ecosystem and community resources
Learning investment: Consider whether learning HCL aligns with your team’s skill development goals
Migration options: Tools exist for migrating between different IaC platforms when needs change

The choice often depends on team background, infrastructure complexity, and development workflow preferences rather than one approach being universally superior.

How do I get started with infrastructure as code?

Choose Based on Your Team Profile:

Programming-oriented teams: Consider Pulumi IaC for familiar languages with full IDE support, testing frameworks, and multi-cloud flexibility
Template-oriented teams: OpenTofu or Terraform offer extensive community resources, established workflows, and broad ecosystem support
Cloud-specific teams: Native tools (AWS CDK/CloudFormation, Azure ARM/Bicep, Google Cloud Infrastructure Manager) provide deep platform integration
Kubernetes-focused teams: Consider Crossplane or Pulumi Kubernetes Operator for container-native approaches

Getting Started Steps:

Start small: Begin with simple projects like deploying a single application or basic infrastructure
Use examples: Leverage existing templates, tutorials, and community examples to accelerate learning
Plan for growth: Consider how your tool choice will scale with team size and infrastructure complexity
Experiment: Most tools offer free tiers or trials - try multiple approaches with simple projects to find what fits your team best

What’s the difference between configuration management and infrastructure provisioning?

Infrastructure provisioning (Pulumi IaC, Terraform, CloudFormation) creates and manages cloud resources like VMs, networks, and databases
Configuration management (Ansible, Chef, Puppet) configures and maintains software on existing systems
Many modern tools do both, with Pulumi IaC and Ansible offering comprehensive capabilities across both domains

Can I use multiple IaC tools together?

Absolutely! Many organizations use complementary tools for different aspects of infrastructure management:

Pulumi + Configuration Management:

Pulumi + Ansible: Infrastructure provisioning + server configuration (example)
Pulumi + Chef/Puppet: Cloud resources + complex configuration management

Pulumi + Native Cloud Tools:

Reference existing CloudFormation/ARM deployments from Pulumi programs
Import CloudFormation/ARM resources into Pulumi for gradual migration
Use Pulumi alongside CDK for different parts of AWS infrastructure

Pulumi + Kubernetes:

Pulumi Kubernetes Operator (PKO) for GitOps workflows
Pulumi + Crossplane for layered infrastructure management
Pulumi + security scanners like Checkov or Terrascan for compliance

Terraform + Pulumi Coexistence:

Use Terraform for base infrastructure and Pulumi for Internal Developer Platforms (IDPs)
Reference existing Terraform state from Pulumi programs during gradual migration
Manage different infrastructure layers with different tools based on team expertise

Pulumi IaC is designed for heterogeneous environments where multiple tools may be in use. For example, you can manage existing Terraform or CloudFormation resources with Pulumi, either using both tools in tandem or for temporary management while migrating to native Pulumi IaC code. Other Pulumi tools, like Pulumi IDP, also enable you to manage IaC self-service workflows like other tools on this list. See what’s possible when migrating to Pulumi.

Which tool has the best learning resources?

Pulumi: Excellent documentation with examples in multiple languages, comprehensive tutorials
Terraform/OpenTofu: Extensive community content, many courses and books available
AWS CDK: Outstanding official documentation with workshops and examples
Kubernetes: Vast ecosystem but steeper learning curve

How important is open-source licensing for IaC tools?

Very important for long-term strategy:

Apache 2.0 (Pulumi, CDK) offers maximum flexibility
MPL 2.0 (OpenTofu) ensures open-source availability
BSL (Terraform) restricts commercial competitors
Proprietary (CloudFormation, ARM) ties you to specific vendors

Choose open-source tools like Pulumi or OpenTofu to avoid vendor lock-in.

What about security and compliance?

All major IaC tools support security best practices:

Built-in policy engines: Pulumi CrossGuard, AWS Config, Azure Policy
Third-party scanners: Checkov, KICS, Terrascan work with all tools
Compliance frameworks: Most tools support SOC 2, PCI DSS, CIS benchmarks
Secret management: Integration with Vault, AWS Secrets Manager, Azure Key Vault

Pulumi offers the most comprehensive built-in security features with CrossGuard policy as code.

Can I migrate from one IaC tool to another?

Yes, and many organizations are successfully migrating to overcome limitations in their current tools. Migration tools and proven approaches exist:

Proven Migration Success Stories:

Atlassian Bitbucket: Completed migration from Terraform to Pulumi’s Python-based IaC in just 2 days using migration tools
Starburst: Achieved 112x faster deployments after incrementally migrating from Terraform
Multiple organizations: Report 80-90% deployment time reductions after moving to programming language-based approaches

Available Migration Tools:

Pulumi: Offers pulumi convert for importing from Terraform, ARM, and CloudFormation with state integration
Terraformer: Can import existing cloud resources into Terraform/OpenTofu
CDK Migrate: Helps move from CloudFormation to CDK
Manual migration: Always possible by recreating resources in the new tool

Migration Strategies:

Incremental adoption: Migrate team-by-team or project-by-project without disruption
State integration: Reference existing infrastructure during transition periods
Zero downtime: Tools like Pulumi enable seamless migration without service interruption

The key is choosing tools that provide comprehensive migration support and incremental adoption paths rather than requiring “rip and replace” approaches.

Conclusion: The Evolution of Infrastructure as Code

The infrastructure as code landscape in 2025 reflects a maturing field where different approaches serve different organizational needs and team preferences. The evolution from manual processes to automated infrastructure has branched into multiple viable paths, each with distinct advantages.

The Spectrum of Approaches:

Template-based tools like Terraform and OpenTofu continue to serve teams effectively, particularly those comfortable with declarative configuration and established HCL workflows. Cloud-native solutions provide deep platform integration for single-cloud strategies. Programming language-based approaches offer familiar development experiences for teams seeking comprehensive testing, IDE integration, and code reusability.

Evidence of Success Across Approaches:

Organizations achieve significant improvements regardless of their chosen path—the key is selecting tools that align with team expertise and infrastructure requirements. Understanding what DevOps is and platform engineering concepts helps inform these decisions. Success stories span the entire ecosystem, from Terraform’s widespread enterprise adoption to programming language approaches enabling dramatic productivity gains at companies like Unity, Snowflake, and Starburst.

Choosing Your Path:

The most successful organizations focus on key decision criteria:

Team background: Match tools to existing skills and preferred development approaches
Infrastructure complexity: Consider testing, abstraction, and maintainability needs
Organizational constraints: Factor in licensing, governance, and compliance requirements
Growth trajectory: Plan for how needs may evolve with scale and team expansion
Integration requirements: Ensure compatibility with existing workflows and toolchains

The Future of Infrastructure:

The industry continues evolving toward treating infrastructure as software, but this transformation takes many forms. Organizations exploring serverless architectures and container strategies particularly benefit from programmable infrastructure approaches. Whether through enhanced DSLs, visual design tools, programming languages, or hybrid approaches, the goal remains consistent: enabling teams to manage infrastructure with the same reliability, collaboration, and velocity they expect from modern software development.

For teams ready to embrace programming language-based infrastructure as code, Get started with Pulumi to experience how familiar languages and software engineering practices can transform infrastructure management with comprehensive testing, powerful abstractions, and seamless multi-cloud support.

Maximize Business Outcomes In Your Multi-Cloud Environment

Marlowe Fenne — Fri, 16 May 2025 00:00:00 +0000

Overcoming the cost and complexity of multi-cloud environments and managing infrastructure more effectively is a perpetual challenge. For thousands of companies growing Platform Engineering skills, the solution to these challenges may be closer than you think.

Hundreds of thousands of developers across the globe already rely on Pulumi to drive more scalable, repeatable deployments in large self-managed production environments. By combining the power of Infrastructure as Code (IaC) with automation, compliance, and robust security within a Pulumi-hosted environment, you can achieve new levels of performance, visibility and security while reducing risk. Here are a few examples:

Speed - Streamlined Operations

Pulumi Cloud accelerates time to market. It automates deployments, manages state, and centralizes secrets, eliminating the complexities of DIY IaC backends. Its transactional state management prevents issues like outages caused by mismanaged state files, offering a secure, reliable platform for scaling operations.

Materialize reduced costs and accelerated time to market by making developer onboarding 75% faster.

Scale - Improved Developer Productivity

By supporting modern programming languages like Python, TypeScript, and Go, Pulumi Cloud allows developers to define infrastructure using familiar tools, speeding up onboarding and simplifying workflows. Predefined policy packs and dynamic secrets further reduce operational overhead.

BMW Group used Pulumi to build a scalable and resilient hybrid cloud implementation that could handle more than eleven thousand developers.

Security - Enhanced Security and Compliance

With features like Pulumi CrossGuard for policy enforcement and Pulumi ESC for centralized secrets management, Pulumi Cloud ensures adherence to security standards like SOC2 and HIPAA. This eliminates the risks associated with improperly stored credentials or manually enforced policies.

Tetrate uses Pulumi ESC to stop secrets sprawl and attain compliance more efficiently.

Savings - Cost Efficiency

Pulumi Cloud’s AI-driven insights identify stale infrastructure and optimize resource use, reducing waste and cutting costs. Its managed service eliminates the need for dedicated backend engineers, freeing resources for core business innovation.

Unity Technologies reduced deployment times by 80%, from weeks to hours, significantly improving their time to market.

By choosing Pulumi Cloud, IT leaders can focus on driving innovation, securing infrastructure, and achieving scalability without the hidden costs and risks of managing IaC backends manually. It’s a comprehensive solution for modern cloud management.

“Pulumi lets us manage multi-cluster Kubernetes infrastructure efficiently, all in one stack. It has hugely benefited productivity and our service’s reliability. Without Pulumi, we know that scaling and maintaining Materialize would be much harder for the team.”

– Paul Hemberger, Engineering Manager for Materialize’s cloud team

Is your team ready to move from a self-managed environment to Pulumi cloud? Explore your options with these resources, and enroll in our workshop series that’s customizable for your cloud and business environment.

AI/ML on Kubernetes: Deploying Models with Pulumi on Google Cloud

Sara Huddleston — Mon, 24 Mar 2025 07:32:19 +0000

Kubernetes has transformed cloud infrastructure by enabling scalable, containerized applications. While it initially gained traction for managing web applications and microservices, its capabilities now extend to AI/ML workloads, making it the go-to platform for data scientists and machine learning engineers.

Running AI/ML workloads on Kubernetes presents unique challenges, including:

Specialized hardware requirements (e.g., GPUs, TPUs)
Scalability for model training and inference
Complex data pipelines that integrate various cloud services
Infrastructure automation for seamless deployment

Google Cloud Kubernetes (GKE) provides a robust foundation for AI/ML workloads, but managing infrastructure manually can be cumbersome. This is where Pulumi comes in—enabling Infrastructure as Code (IaC) to automate and simplify AI/ML infrastructure on Kubernetes.

Pulumi: Automating AI/ML Infrastructure on Google Cloud

Pulumi is a modern Infrastructure as Code (IaC) tool that allows teams to define and manage cloud infrastructure using general-purpose programming languages like Python, TypeScript, and Go. This approach is particularly beneficial for AI/ML teams, as Python is already the dominant language in data science and machine learning.

With Pulumi, you can:

Provision and scale Kubernetes clusters on Google Cloud automatically.
Define AI/ML environments as code, making deployments repeatable and version-controlled.
Integrate infrastructure with machine learning pipelines, reducing operational overhead.

Deploying AI/ML Workloads on Kubernetes

Below, we explore two use cases for running AI/ML workloads on Google Kubernetes Engine (GKE) using Pulumi.

Use Case 1: Deploying a Large Language Model (LLM) with Retrieval Augmented Generation (RAG)

Large Language Models (LLMs) like GPT-3, Whisper, and DALL-E require significant infrastructure for training and inference. Retrieval Augmented Generation (RAG) enhances LLMs by integrating external knowledge sources, improving accuracy and relevance.

Using Pulumi, you can automate the deployment of an open-source LLM with RAG on Kubernetes.

Step 1: Set Up a Kubernetes Cluster on Google Cloud

import pulumi
import pulumi_gcp as gcp

# Create a GKE cluster for AI/ML workloads
cluster = gcp.container.Cluster("ml-cluster",
 location="us-central1",
 initial_node_count=3,
 node_version="1.23",
 min_master_version="1.23")

# Create a node pool optimized for ML workloads
node_pool = gcp.container.NodePool("ml-node-pool",
 cluster=cluster.name,
 node_config=gcp.container.NodePoolNodeConfigArgs(
 machine_type="n1-standard-4",
 oauth_scopes=[
 "https://www.googleapis.com/auth/devstorage.read_only",
 "https://www.googleapis.com/auth/logging.write",
 ],
 labels={"team": "ml"},
 shielded_instance_config=gcp.container.NodePoolNodeConfigShieldedInstanceConfigArgs(
 enable_secure_boot=True,
 enable_integrity_monitoring=True,
 ),
 ),
 initial_node_count=2,
 location="us-central1",
 version="1.23")
...

This Pulumi script:

Provisions a Kubernetes cluster on Google Cloud.
Creates a dedicated node pool optimized for AI/ML workloads.
Ensures security best practices for machine learning environments.

Step 2: Deploy the LLM with RAG Model

Once the cluster is set up, we can deploy the LLM with RAG model using Pulumi’s Kubernetes provider:

Define Kubernetes Deployments for the LLM and RAG model.
Package models as Docker containers and deploy them to the cluster.
Configure Kubernetes Services to expose APIs for model inference.
Use ConfigMaps and Secrets to manage parameters and credentials.

By defining these resources in Pulumi, deployments become fully automated, repeatable, and scalable.

Use Case 2: Training and Serving Custom Machine Learning Models

Beyond pre-trained LLMs, Kubernetes is ideal for training and serving custom AI/ML models. Pulumi can help automate every stage of the ML lifecycle.

Step 1: Set Up the Model Training Environment

Using Pulumi, we define a training environment with:

A Kubernetes Deployment for training jobs (GPU-enabled).
Persistent Volume Claims (PVCs) for storing training data and model artifacts.
Monitoring tools for tracking performance.

Step 2: Deploy and Serve the Trained Model

Once the model is trained, Pulumi can be used to:

Deploy the trained model as a Kubernetes Deployment.
Expose the model via a Kubernetes Service (REST API or gRPC).
Add autoscaling rules for dynamic inference scaling.

Pulumi allows teams to manage the entire AI/ML pipeline in a structured and automated way.

Try Jay’s demo code on Creating an AI Training Platform on GKE with Pulumi.

Why Use Pulumi for AI/ML on Kubernetes?

Pulumi provides several advantages for AI/ML teams running workloads on Kubernetes:

1. Use General-Purpose Languages for Infrastructure as Code

Most AI/ML engineers already work with Python or Go, and Pulumi lets them manage infrastructure using the same language.
No need to learn YAML or Kubernetes manifests—define everything programmatically.

2. Automate AI/ML Workflows

Define infrastructure, training jobs, and model serving in one unified IaC framework.
Ensure consistency across development, staging, and production environments.

3. Improve Scalability and Cost Efficiency

Pulumi integrates with Google Cloud AI services for optimized compute resources.
Automate autoscaling and resource allocation for AI/ML workloads.

4. Increase Security and Compliance

Manage credentials and secrets securely with Pulumi ESC (Secrets Management).
Apply policy-as-code to enforce security best practices.

Get Started with AI/ML on Kubernetes with Pulumi

Pulumi makes it easy to deploy, scale, and manage AI/ML workloads on Kubernetes, leveraging Google Cloud’s AI infrastructure. Whether you’re serving LLMs, training custom models, or automating ML pipelines, Pulumi provides a developer-friendly, scalable, and secure solution.

By combining Kubernetes, Google Cloud, and Pulumi, you can accelerate AI/ML innovation while reducing infrastructure complexity.

Why Choose Pulumi Cloud Over DIY Backends?

Aaron Kao — Wed, 19 Mar 2025 09:00:00 -0700

Note: This post discusses Pulumi Copilot, which Pulumi Neo has replaced. Learn about Neo →

Pulumi Cloud empowers engineers to automate, secure, and manage modern infrastructure platforms.

Many companies are building internal developer platforms or modern infrastructure platforms to provide developer self-service while maintaining security and compliance. Companies adopt Pulumi IaC so they can apply software engineering practices to their infrastructure scaling problems and because it is fully open source with a strong community and public roadmap.

At Pulumi, we’re committed to open source—always have been; always will be. Pulumi IaC is entirely open source (Apache 2.0 license), meaning you can adopt and extend it however you like. If you’re new to Pulumi, the open source edition is an excellent way to start modernizing your infrastructure. But as your organization grows and the complexity of your environment increases, you may find yourself devoting significant time to rolling your own enterprise IaC backend features.

That’s why we built Pulumi Cloud—to help you avoid building and maintaining these capabilities from scratch while ensuring you can automate, secure, and manage your infrastructure at scale. Pulumi Cloud provides enterprise capabilities that make it easier to build modern infrastructure platforms. Companies receive increasing value from Pulumi Cloud as their organization and their infrastructure platforms grow in size and complexity.

As companies expand or platform engineering mandates become more expansive, challenges arise around collaboration, security, governance, and scaling. Some questions that need answering include:

How do teams collaborate?
How do you securely manage infrastructure state?
How do you enable self-service infrastructure?
How do you adhere to IT security standards?
How do you enforce governance policies?
How do you protect sensitive data?
How do you enforce least privileged access across the organization?
How do you maintain uptime or get support for your architecture?
How do you manage the cost and complexity of multi-cloud environments?

If some of these questions apply to you or your team, learn more about Pulumi Cloud below to understand when it makes sense to transition to a paid Pulumi offering.

What drives the most value in Pulumi Cloud?

The most frequent business values that our existing customers experience with Pulumi Cloud relate to speed, scale, security, and savings.

Speed

There are speed benefits that customers typically experience across three areas: the infrastructure platform, developer productivity, and operations. Pulumi Cloud simplifies building and running complex infrastructure automation workflows through the Automation API. It also makes it easy to componentize best practices that can be easily shared and distributed through a centralized repository.

Pulumi Cloud streamlines the software delivery pipeline with Pulumi Deployments and a wide range of 3rd party CI/CD integrations.

Pulumi Cloud provides Pulumi Insights, offering search, analytics, and AI-driven insights over your infrastructure. With Insights, you can instantly search for critical information - such as finding MySQL databases on end-of-life versions across all your cloud assets, reducing the operational time it takes to find needles in haystacks.

Scale

Part of building an infrastructure platform is so your organization can scale and make it easy to onboard new developers. Pulumi Cloud integrates seamlessly with various identity providers like Azure ActiveDirectory, Okta, G Suite, or any SAML/SSO provider, offering deep support for role-based access control (RBAC) and SCIM for automatic synchronization and revocation of access based on identity provider groups. Audit logs keep track of developer activity within an organization, recording what actions were taken, when, and by whom.

Pulumi Cloud also makes it easy to build developer portals for developer self-service. Organization Templates can provide a centralized repository for cloud components, best practices and configurations. The New Project Wizard also provides a gallery interface to pick a template and easily walk through configuration and deployment of the infrastructure.

Security

Another reason your organization is investing in an infrastructure platform is so that security and compliance can be automated as infrastructure is self-serviced. Your platform must prevent infrastructure deployments that violate security, reliability, cost, or compliance policies. Pulumi Cloud, through Pulumi CrossGuard, provides out-of-the-box support for common security and compliance policies, ensuring PCIDSS, ISO27001, SOC2, and CIS compliance for cloud applications and infrastructure.

For applications being built across the organization, securing sensitive information like database passwords, cloud credentials, and API keys is paramount. Secrets can inadvertently end up in insecurely stored state files, leading to potential breaches. Pulumi Cloud, however, encrypts all data in transit and at rest, utilizing hardware security module (HSM) based encryption. Read the Pulumi Cloud Security Whitepaper for more information.

Pulumi Cloud further enhances security with Pulumi ESC, a centralized secrets management and orchestration service. This service pulls and syncs secrets from various stores like HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, GCP Secret Manager, and 1Password, making it easy to adopt dynamic, short-lived secrets on demand. Secrets can be accessed via CLI, API, Kubernetes operator, the Pulumi Cloud UI, and in-code with TypeScript/JavaScript, Python, and Go SDKs. Pulumi ESC leverages the same identity, RBAC, Teams, SAML/SCIM, OIDC, and scoped access tokens used by Pulumi IaC, ensuring that secrets management complies with enterprise security policies.

Savings

Building a platform and managing cloud infrastructure demands considerable time and energy. As discussed above, Pulumi Insights X-Rays your entire cloud footprint, so you can observe, plan, and drive changes across your infrastructure. With this total visibility, Pulumi Insights helps you reduce waste by showing you usage information and identifying potentially stale infrastructure, which can lead to substantial cost savings.

You can also have a conversation with Pulumi Copilot about your infrastructure in natural language and get answers to operational questions that would take hours to piece together from other sources.

Why not build your own enterprise features on top of Pulumi IaC open source?

Build vs buy is a question of opportunity cost. Should you and your team build and operate your own enterprise backend service that engineers at Pulumi have already built to handle the needs and scale of the world’s biggest companies? Or is their time better spent focused on building a modern infrastructure platform that will increase development velocity across the company and drive business growth?

Maintenance costs

When you build and operate your own enterprise backend, you’ll need to dedicate one full-time engineer for every team of ten - that’s nearly 10% of your engineering expense. Running a backend requires maintenance, updates, and troubleshooting. Outages and incidents can lead to significant financial losses. Pulumi Cloud, as a fully managed service, frees up your team’s time from the operational and maintenance burdens of managing an IaC backend.

Operational reliability and availability

One of the primary functions of the enterprise backend is managing state. State management involves managing concurrency controls, preventing state corruption, ensuring backup and recovery, maintaining high availability of the state service, and providing consistent visibility across all managed resources; this is easy to get wrong. Manual human intervention is frequently required to recover and repair state files, a process that is time-consuming, can create or prolong outages, and carries significant risk.

Security and compliance

Building your own enterprise backend also requires you to design and manage the service to adhere to numerous IT security standards, including SOC 1/SSAE 16/ISAE 3402, SOC 2, SOC 3, FISMA, FedRAMP, DOD SRG Levels 2 and 4, PCI DSS Level 1, EU Model Clauses, ISO 9001 / ISO 27001 / ISO 27017 / ISO 27018, ITAR, IRAP, FIPS 140-2, MLPS Level 3, and MTCS. This involves a manual assessment and validation process for each standard, which can be time-consuming and complex.

Customer support

You will also be giving up 12x5 or 24x7 customer support, which helps ensure your organization receives immediate assistance with any architectural, cloud-related, or Pulumi best-practices issues. Pulumi also has an experienced group of Solutions Architects and Customer Success Architects that have experience scaling infrastructure as code and building modern infrastructure platforms.

Conclusion

Pulumi Cloud is an enterprise-ready solution that comes with less risk and less maintenance costs than the DIY approach. With Pulumi Cloud, you get a fully managed service that automates deployments, ensures compliance, and offers comprehensive security features out-of-the-box. You’ll get a clear understanding of the product roadmap as well as talented engineers supporting your architecture and use cases.

Pulumi Cloud gives you the platform to automate, secure, and manage your modern infrastructure platform so your company can choose to focus on innovation and growth.

Try Pulumi Cloud for free and see how it can accelerate your infrastructure automation. Sign up today and start building with Pulumi Cloud.

Why Every Cloud Engineer Needs Pulumi ESC for Secrets Management

Sara Huddleston — Mon, 17 Mar 2025 07:28:56 +0000

Managing secrets is one of the most critical responsibilities in cloud engineering. Secrets like API keys, database credentials, and encryption tokens are the backbone of secure and seamless cloud operations. Yet they are so often an afterthought. They get replicated across cloud-specific secrets managers and stuffed in GitHub secrets, compromising security for the sake of simplicity. ¿Por que no los dos? Why can’t secrets management be secure and simple?

Enter Pulumi ESC (Environments, Secrets, and Configuration)—a breakthrough in taming secrets sprawl and streamlining configuration management across infrastructure. Let’s explore why Pulumi ESC is a necessity for cloud engineers, helping make secrets management secure while keeping it simple.

The Challenge of Secrets Management in Modern Cloud Environments

Secrets management has changed significantly over the past decade. Gone are the days when secrets could be hardcoded, manually maintained in static configuration files, or left floating around in plaintext on dev machines. Nowadays, cloud environments demand a higher level of sophistication:

Distributed Systems: Even in multi-cloud and hybrid setups, secrets must be accessible across varied platforms without exposing vulnerabilities.
Dynamic Infrastructure: Kubernetes, serverless architectures, and ephemeral environments must have secrets that adapt dynamically.
Security Risks: Hardcoded or poorly managed secrets can lead to catastrophic breaches, costing companies millions in data recovery and compliance penalties.
Operational Burdens: Manual secrets management is error-prone, inefficient, unscalable, and needs to align with DevOps and DevSecOps best practices.

Pulumi ESC addresses these issues head-on, redefining how cloud engineers manage secrets efficiently, securely, and at scale.

Jk Jensen, Team Lead at Mysten Labs, said:

“Pulumi ESC has been a lifesaver for us. It’s nice to throw everything behind an ESC environment and eliminate one-off granting/IAM permissions and other issues related to static credentials. It gives us peace of mind knowing that we can grant permissions quickly and revoke easily limiting blast radius for any access.”

What is Pulumi ESC?

Pulumi ESC simplifies how organizations manage secrets and configurations. It is designed to secure sensitive configurations across modern cloud environments and supports seamless integration, enabling engineers to:

Access, share, and manage secrets, passwords, API keys, and configuration settings like network and deployment options.
Synchronize secrets and configuration from any secrets manager to any app, tool, or CI/CD platform.
Access secrets securely through CLI, API, Kubernetes operator, the Pulumi Cloud UI, and in-code with Typescript/Javascript, Python, and Go SDKs.
Connect to cloud providers and secrets stores via OIDC to generate dynamic, short-lived, auto-expiring credentials.
Set role-based access controls (RBAC), making securing secrets and configurations easy by assigning permissions to users based on their roles.

Whether integrated with Pulumi’s Infrastructure as Code (IaC) platform or used as a standalone service, Pulumi ESC enables cloud engineers to streamline secrets management with centralized control.

Key Features of Pulumi ESC

1. Seamless Integration with External Platforms

Pulumi ESC integrates with popular secrets providers, including AWS Secrets Manager, Azure Key Vault, GCP Secret Manager, 1Password, and HashiCorp Vault, making it adaptable for multi-cloud and hybrid cloud architectures.

2. Dynamic Secrets Synchronization with ESO

Partnering with the External Secrets Operator, Pulumi ESC synchronizes secrets securely into Kubernetes clusters. This eliminates hardcoding secrets into manifests or relying on unsecured manual processes.

3. Safely Roll Back to a Previous Version

Pulumi ESC Versioning gives you unprecedented control over your secrets and configuration. Every change is captured in an immutable revision history, allowing you to audit modifications, compare versions, and safely roll back.

4. Secure by Design

Pulumi ESC follows a “secure by default” model, employing encryption, access control, and detailed audit trails. Engineers can meet compliance regulations effortlessly while gaining full visibility into secret access patterns.

5. Automated Rotation and Expiry

Pulumi ESC minimizes security risks by automating the rotation of secrets. This feature aligns secrets management with CI/CD processes for cloud engineers focused on DevOps, ensuring credentials remain valid only when needed.

6. Configuration-as-Code, Automation, and Integration Everywhere

Pulumi ESC embraces an “as-code” approach, enabling configuration and secrets management using TypeScript, JavaScript, Go, Python, or YAML. The ’esc’ CLI and API support automation in CI/CD environments, reducing credential duplication and ensuring a single source of truth.

7. Dev Tools Integrations

Pulumi ESC’s metadata and support for popular configuration formats enable seamless integration with tools like Direnv, Docker, and GitHub, allowing easy management of environment variables, secrets, and configurations.

8. Infrastructure Tools Integrations

Pulumi ESC extends its capabilities beyond Pulumi IaC by integrating with other infrastructure tools such as Cloudflare, Terraform, and OpenTofu. These integrations enable seamless provisioning of cloud credentials and input variables directly from ESC environments.

Why Cloud Engineers Need Pulumi ESC

Enhanced Security and Compliance

Cloud engineers often have to balance security and operations. Pulumi ESC centralizes secrets in a secure vault, ensuring encrypted storage, access control, and audit visibility. It also complies with industry standards like SOC 2, PCI-DSS, and MTCS.

Streamlined Multi-Cloud Management

Managing secrets across AWS, Azure, and GCP can quickly become chaotic. Pulumi ESC’s cross-platform integration simplifies this process, ensuring engineers can manage and sync secrets from a single interface.

Simplified Kubernetes Secrets

Kubernetes’ default secrets offer limited security and scalability. Pulumi ESC with ESO and Secrets Store CSI Driver overcomes these limitations by securely synchronizing and managing secrets within Kubernetes clusters. This prevents unauthorized access and provides automated updates.

Zero Downtime Through Automation

Manual secrets management often leads to errors such as expired credentials or outdated tokens. Pulumi ESC automates the entire lifecycle of secrets—creation, rotation, replication, and expiry—guaranteeing uninterrupted services.

Developer-Friendly Workflows

Tools should make engineers’ lives easier, not harder. Pulumi ESC’s CLI, SDKs, and API provide intuitive ways to integrate into existing workflows. For cloud engineers leveraging Infrastructure as Code with Pulumi, managing secrets alongside the stack becomes effortless.

Thomas Meckel, Senior Cloud Architect at Ophios GmbH, explains:

“Pulumi’s built-in encryption of secrets sets it apart as a leader in secure infrastructure management. Unlike other tools that leave sensitive data exposed or require complex configurations, Pulumi ensures secrets are encrypted by default, leveraging flexible options like Azure Key Vault or AWS KMS. This eliminates the risk of plaintext exposure and simplifies secure deployments. For any organization serious about cloud security, Pulumi’s approach to secrets management is a critical differentiator, combining ease of use with robust protection against breaches.”

Kubernetes Secrets Management

For secrets management in Kubernetes environments, Pulumi ESC becomes even more powerful when paired with External Secrets Operator (ESO) or the Secrets Store CSI Driver. Here’s how it works:

Using Pulumi ESC with External Secrets Operator

External Secrets Operator is an open-source Kubernetes operator that syncs secrets from external providers (like Pulumi ESC) into Kubernetes as native secrets.

Centralized Storage: Store secrets securely in Pulumi ESC and synchronize them with Kubernetes across multiple clusters.
Dynamic Updates: Whenever a secret is updated in ESC, ESO automatically replicates the changes into Kubernetes, eliminating manual intervention.
Granular Management: Define which secrets are synchronized and to which namespaces, ensuring tight access controls and minimizing risk.
Automated Secret Rotation: By leveraging ESC’s rotation capabilities, ESO ensures Kubernetes receives refreshed credentials without requiring downtime.

Learn how to manage Kubernetes secrets with Pulumi ESC and External Secrets Operator: The Perfect Solution for Today’s Cloud-Native Secret Management.

Using Pulumi ESC with Secrets Store CSI Driver

The Secret Store CSI Driver mounts secrets, certificates, and keys from external stores into Kubernetes pods as volumes.

Automated Secrets Injection: Secrets Store CSI Driver enables Pulumi ESC to automatically inject secrets into Kubernetes pods as mounted volumes or environment variables. This reduces the manual overhead of managing secrets directly in Kubernetes.
Secure and Dynamic Secret Access: By leveraging Pulumi ESC, Kubernetes applications can securely fetch secrets from external providers, ensuring dynamic access without exposing credentials in pod specifications.
Streamlined Operations: This integration simplifies the process of synchronizing secrets from Pulumi ESC with Kubernetes-native constructs. The automation reduces errors and boosts efficiency.

Learn how to Master Kubernetes Secrets with Pulumi ESC + Secrets Store CSI Driver.

The Future of Secrets Management with Pulumi ESC

Pulumi ESC is more than just a secrets management tool — it’s the foundation of secure, scalable, and agile cloud operations. For cloud engineers grappling with multi-cloud complexity, Kubernetes deployments, and compliance concerns, it provides a streamlined, automated approach that enhances efficiency and security.

With rising cyber threats and stricter data regulations, adopting tools like Pulumi ESC is no longer optional. It’s a competitive advantage for cloud engineers and organizations aiming to lead in today’s cloud-native world.

Next Steps to Secure Your Secrets

Secrets management doesn’t have to be a headache! With Pulumi ESC, you can safeguard your infrastructure, ensure compliance, and eliminate manual errors—all while enhancing security and agility.

Get started with Pulumi ESC today and experience the future of secrets management. Take control of your cloud environment—securely and effortlessly.

Top 15 Python Tools for DevOps

Adam Gordon Bell — Mon, 06 Jan 2025 00:23:24 -0500

Have you ever had one of those moments: Elasticsearch is crashing, logs are filling up too fast, or a deployment needs data from three different APIs. The big enterprise solutions aren’t quite right, and your team estimates six months to build something proper. But you know that with Python and a few choice libraries, you could hack something together by tomorrow.

Let's build a little web dashboard in Python.

That’s where Python really shines. It lets you be the scrappy problem-solver who can travel up and down the stack. But Python isn’t just for quick fixes. The same language that helps you hack tomorrow’s solution can also build your company’s long-term infrastructure.

This guide covers both ends of that spectrum. I’ll show you python packages for “we need it yesterday” moments, and then move into solutions that can grow with your team. And along the way I’ll build a little example service monitor and package capturer to demonstrate the python packages I’m covering. I’ll wrap it in a CLI, in a web dashboard and deploy it to AWS, all while staying in Python.

So here’s my list of Python libraries for DevOps work, starting from #15 to the most important last at number #1.

Dashboards / monitoring

Let’s start with building web dashboards. Long-term, it’s usually better if there’s an off-the-shelf tool for that specific dashboard you need. But if you can create a quick visual on a Django endpoint, you can move on to the next issue.

15 and 14. Django and Flask: (Django, Flask) While tools like Grafana excel at metrics visualization, sometimes you need custom dashboards that integrate with internal systems. These frameworks let you build dashboards to track and visualize various aspects of your systems. I find Django a great fit here.
13. Prometheus: (prometheus-client) This library is a versatile tool for metrics. Want to expose custom metrics to Prometheus? Use the client to create counters, gauges, or histograms. Need to pull data from a weird API and expose it as metrics? Write a quick exporter that fetches from your API every few minutes and translates the responses into Prometheus metrics.

from flask import Flask, render_template_string
import requests

app = Flask(__name__)

@app.route("/")
def index():
 try:
 response = requests.get("https://www.githubstatus.com/api/v2/status.json", timeout=5)
 if response.status_code == 200:
 data = response.json()
 status = data["status"]["indicator"]
 description = data["status"]["description"]
 else:
 status = "critical"
 description = "Unable to reach GitHub API"
 except Exception as e:
 status = "critical"
 description = f"Error: {e}"

 color = {
 "none": "bg-green-500",
 "minor": "bg-yellow-500",
 "major": "bg-red-500",
 "critical": "bg-red-700",
 }.get(status, "bg-gray-500")

 return render_template_string(
 """
 ...
 """,
 color=color,
 description=description,
 )

Code for a simple Dashboard

You might also like:

Task scheduling and orchestration

Sometimes you need to run things on a schedule. And while I love cron, sometimes you need more. Maybe you need to coordinate multiple tasks, handle retries, or manage complex job dependencies. Here’s where Python can help:

12. Schedule: (schedule) When cron is too heavy but you need more than a bash script. I use it for quick automation tasks like “check this API every hour and alert if something’s wrong.” It runs in your Python process - no system configuration needed.
11. RQ (Redis Queue): (rq) Perfect for local development queues. Need to prototype a GitHub webhook handler that’ll eventually use SQS? With Redis in Docker and RQ, you can have a working queue in minutes. No AWS needed until production.
10. Airflow: (airflow) The big gun of scheduling. Yes, it’s complex, but sometimes you need that power. I’ve seen teams replace entire ETL systems with a few Airflow DAGs. When you need to coordinate multiple steps, handle failures gracefully, and have everything visible in a nice UI, it delivers.

def schedule_url_checks():
 for url in urls.values():
 schedule.every(30).seconds.do(lambda url=url: check_url_status(url))

def run_scheduler():
 while True:
 schedule.run_pending()
 time.sleep(1)

if __name__ == "__main__":
 schedule_url_checks()
 threading.Thread(target=run_scheduler, daemon=True).start()

Adding Schedule to our code, so we can request in the background.

Network analysis and security

When your network issues go beyond what tcpdump can tell you, or when you need to automate security checks, Python is here to help:

9. Scapy: (scapy) The Python alternative to Wireshark for programmatic network traffic analysis. Need to figure out why your microservices aren’t talking to each other? Want to check your load balancer? Use it to capture and analyze packets with a few lines of code.
8. Bandit: (bandit) Security scanning for your CI pipeline. Point it at your Python codebase and it’ll flag common issues like hardcoded credentials or unsafe deserialization.

def packet_callback(packet):
 global packet_stats
 packet_stats["total_packets"] += 1
 if packet.haslayer("HTTPRequest"):
 packet_stats["http_requests"] += 1

def start_packet_sniffer():
 sniff(prn=packet_callback, store=False, timeout=60) # Capture packets every 60 seconds

if __name__ == "__main__":
 threading.Thread(target=start_packet_sniffer, daemon=True).start()

Adding packet sniffing to our code, mainly just because we can.

Containerization and cloud interaction

Sometimes you need more control over your containers than Dockerfiles can provide. Maybe you need to dynamically build images based on environment variables, or automate container management:

7. Docker SDK for Python: (docker-py) When you need to automate Docker operations programmatically. I use it to clean up old containers and images, check container health, and build images dynamically from configuration files. More powerful than chaining Docker CLI commands.
6. Dagger: (dagger-io) Write container build logic in Python instead of Dockerfiles. Need to build multiple similar containers with slight variations? Want to pull in files from different sources based on environment? It lets you programmatically define container contents and build steps. (Bonus: this same code can later be used in CI/CD pipelines.)

import dagger

async def main():
 # Connect to the Dagger Engine
 async with dagger.Connection() as client:
 container = (
 client.container()
 .from_("python:3.11-slim")
 .with_exec(["python", "-c", "print('Hello from Dagger!')"])
 )

 # Execute the container and get the output
 output = await container.stdout()
 print(output)

if __name__ == "__main__":
 import asyncio
 asyncio.run(main())

Using Dagger makes it easy to stay in Python while building containers.

Building command-line tools

Let's build a CLI version of our service status dashboard in Python.

Every useful script eventually needs to become a proper tool. When your team starts asking “can I use that script too?” it’s time to enhance your CLI skills:

5/4. Click/Typer: (Click, Typer) Turn your quick scripts into proper CLI tools. Instead of remembering python cleanup.py --older-than 7 --dry-run, you get tab completion, help text, and proper argument handling. Typer is particularly nice if you’re using modern Python - it uses type hints to build the CLI interface.
3. Rich: (rich) Make your terminal output actually readable. Need to display tables of data? Want progress bars for long-running tasks? Rich makes it easy to build user-friendly CLIs. I use it to turn wall-of-text logs into colored, formatted output that helps spot problems quickly.

2. The essential toolkit

The foundation of any DevOps tooling consists of these essential libraries:

Requests (requests) - For making HTTP requests
Pytest (pytest) - For testing your code
logging (Python logging) - For structured logging
YAML/JSON/TOML parsers (PyYAML, json, toml) - For config file handling

While not flashy, these libraries form the backbone of every tool I build. And so I update my little tool to have some tests, some logging and store the api status urls in a toml file.

Now, #1 and it’s IaC time. I can get my dashboard onto AWS in a lambda using Pulumi.

# Build and push the Docker image to ECR
image = awsx.ecr.Image("app-server-image",
 repository_url=repository.repository_url,
 context="..",
 dockerfile="Dockerfile",
 platform="linux/amd64"
)

Push my Image to ECR

1. Pulumi

While most tools in this list excel at quick solutions, infrastructure demands a more robust approach. This is where Pulumi stands apart. It’s not just another scrappy tool—it’s an enterprise-grade Infrastructure as Code platform that happens to harness Python’s power and flexibility.

With support for real Python code instead of configuration languages, you can define, deploy, and manage your cloud resources using familiar programming concepts and practices.

With Pulumi, you get:

Complete programming language support for using loops, functions, and classes in your infrastructure code
Infrastructure testing capabilities to validate your deployments before they go live
Container deployment solutions for managing Docker images and Lambda functions
Rich AWS integration for comprehensive cloud resource management
Infrastructure automation to streamline your deployment workflows

# Create a Lambda function
lambda_function = aws.lambda_.Function("custom-lambda",
 name="custom-lambda",
 package_type="Image",
 image_uri=image.image_uri,
 role=lambda_role.arn,
 timeout=30,
 memory_size=512,
 environment={
 "variables": {
 "FLASK_ENV": "production"
 }
 }
)

Start it up in a Lambda

Bringing it all together

Dashboard is still pretty basic, but now it's on AWS with a little Python infrastructure code.

Here’s where Python excels - combining these tools to solve real problems. For example:

Need a dashboard for infrastructure costs? Combine Flask with the AWS SDK and Pulumi Insights.
Want to automate container cleanup? Mix Docker SDK with Schedule for regular maintenance.
Building a custom GitHub webhook processor? Use Flask to receive webhooks, RQ for asynchronous handling, and Rich for readable logs.

Start simple (maybe just a script with Requests and PyYAML), then gradually add more tools as needed. That’s the beauty of Python in DevOps - you can start small and grow your solution naturally.

The art of getting things done

The tools I’ve covered span the full spectrum of DevOps needs—from quick scripts to enterprise-grade solutions. Python’s versatility makes it uniquely suited for both ends of this spectrum:

For urgent needs, tools like Schedule, Rich, and Click let you rapidly prototype solutions.
For long-term infrastructure, Pulumi and Airflow provide the robustness needed for production systems.
For everything in between, Python’s extensive library ecosystem helps you gradually evolve quick fixes into mature tools.

The key is knowing when to use each tool.

Infrastructure as Code: The Hidden Cost of Doing It Yourself

Aaron Kao — Tue, 10 Dec 2024 09:00:00 -0800

Note: This post discusses Pulumi Copilot, which Pulumi Neo has replaced. Learn about Neo →

Infrastructure as Code (IaC) has revolutionized how cloud resources are managed, allowing for more efficient, scalable, and repeatable deployments. We designed Pulumi IaC to let you program cloud infrastructure using familiar programming languages like TypeScript, JavaScript, Python, Go, .NET, Java, and YAML. This approach not only simplifies the process but also integrates seamlessly with existing development tools and ecosystems (e.g., IDEs, standard unit test frameworks, integration test). You can define infrastructure with code, often in just one line, for serverless, Kubernetes, AI/ML, databases, and more. You can also preview changes before deploying unlike many other IaC solutions. Pulumi IaC is fully open source with a public roadmap. We value working with the community to shape the product through feedback and contributions.

What is Pulumi Cloud?

Infrastructure as Code tools like Pulumi require systems for coordinating deployments, which include concurrency control, state management, and security. For the purposes of this post, let’s refer to these systems as IaC backends. There are several options for managing these backends: you can either handle them yourself, which we’ll call DIY, or you can leverage Pulumi Cloud, available as a SaaS or self-hosted solution. With Pulumi Cloud, you gain access to a comprehensive infrastructure management platform designed to handle everything running in the cloud. This platform automates your IaC deployments, centralizes secrets management and orchestration to manage secrets sprawl effectively, and employs AI to oversee infrastructure assets and ensure compliance. On the other hand, with a DIY approach, you have the flexibility to build everything Pulumi Cloud offers or opt for a more minimalistic setup tailored to your organization’s specific needs. Both options are well-supported by Pulumi, but there are distinct advantages to choosing Pulumi Cloud over the DIY method, which we’ll explore further.

Costs and Complexities of DIY Backends

Building and maintaining your own Infrastructure as Code backend involves a significant engineering and operational commitment. On the engineering front, you face security and compliance challenges, as well as the need to develop features that ensure enterprise readiness. Operationally, the backend must be highly available and reliable, and it should facilitate easy onboarding for the rest of the organization when the time comes. Beyond these immediate concerns, there are also hidden personnel costs associated with running your own backend. Let’s break down some of those hidden costs.

Materialize reduced costs and accelerated time to market by making developer onboarding 75% faster.

–— Paul Hemberger, Engineering Manager for Materialize’s cloud team

Learn more

Operational Excellence

One of the primary functions of IaC backends is managing state. State management involves managing concurrency controls, preventing state corruption, ensuring backup and recovery, maintaining high availability of the state service, and providing consistent visibility across all managed resources; this is easy to get wrong. For instance, an incorrect Git merge of your state can result in outages, as evidenced by Spotify speaking publicly about accidentally deleting two-thirds of their production Kubernetes clusters due to a faulty state merge.

Pulumi Cloud offers total visibility into changes within your organization, allowing you to track who is deploying what, when, and where, down to the individual cloud infrastructure properties being changed and the source commits triggering them. If issues arise and you need to revert to a prior known state, Pulumi Cloud’s transactional state checkpointing protocol ensures automatic recovery from failures, and failures are common with transient cloud and networking issues. In contrast, DIY backends require manual human intervention to recover and repair state files, a process that is time-consuming, extends outages, and carries significant risk. Pulumi Cloud also automatically backs up and replicates your state checkpoints, facilitating easy recovery for audits or rollbacks, potentially preventing outages or meeting audit standards.

Managing your infrastructure with IaC demands considerable time and energy. Pulumi Cloud provides Pulumi Insights, offering search, analytics, and AI-driven insights over your infrastructure. If you’re using a DIY backend, you’ll need to build your own search clusters and grep systems. With Insights, you can instantly search for critical information - such as finding MySQL databases on end-of-life versions across all your cloud assets. You can also have a conversation with Pulumi Copilot about your infrastructure in plain English and get answers to operational questions that would take hours to piece together from other sources.

With this total visibility, Pulumi Insights helps you reduce waste by showing you usage information and identifying potentially stale infrastructure, which can lead to substantial cost savings.

When you build and operate your own IaC backend, you’ll need to dedicate one full-time engineer for every team of ten - that’s nearly 10% of your engineering expense. Pulumi Cloud, as a fully managed service, frees up your team’s time from the operational and maintenance burdens of managing an IaC backend.

Unity reduced deployment times by 80%, from weeks to hours, significantly improving their time to market.

“Terraform relies on HCL and lacks support for concepts like classes, objects and inheritance. An equivalent deployment would take more lines of code while yielding IaC that is less reusable.”

Learn more

Security and Compliance

IaC backends are mission-critical components that require robust security measures to protect the backend service, cloud assets, and applications running on the infrastructure.

At the backend service layer, you must design and manage the service to adhere to numerous IT security standards, including SOC 1/SSAE 16/ISAE 3402, SOC 2, SOC 3, FISMA, FedRAMP, DOD SRG Levels 2 and 4, PCI DSS Level 1, EU Model Clauses, ISO 9001 / ISO 27001 / ISO 27017 / ISO 27018, ITAR, IRAP, FIPS 140-2, MLPS Level 3, and MTCS. This involves a manual assessment and validation process for each standard, which can be time-consuming and complex.

Pulumi, as an Amazon Web Services Advanced Partner, undergoes a thorough review and certification of its security and compliance practices by the AWS team. Pulumi Cloud operates on AWS infrastructure, which is designed and managed in alignment with security best practices and all the aforementioned IT security standards. This infrastructure does not require or have access to personally identifiable information (PII), making it suitable for managing applications that require HIPAA and ISO 27018 compliance. Pulumi also conducts annual penetration testing of Pulumi Cloud and maintains active SOC 2 Type II compliance.

Access control at the backend service layer is crucial for enforcing least privilege access. Pulumi Cloud integrates seamlessly with various identity providers like Azure ActiveDirectory, Okta, G Suite, or any SAML/SSO provider, offering deep support for role-based access control (RBAC) and SCIM for automatic synchronization and revocation of access based on identity provider groups. This fine-grained control over state access is a significant advantage over DIY backends, where all access control mechanisms would need to be built from scratch. Audit logs play a vital role in tracking user activity within an organization, recording what actions were taken, when, and by whom. Pulumi’s audit logs are immutable, capturing the UNIX timestamp of events, the user who invoked the action, the event itself, and the source IP of the call. This level of auditing ensures that the activities of organization members are attributable, enhancing security and compliance.

At the cloud asset layer, you and your team need to prevent infrastructure deployments that violate policies related to security, reliability, cost, or compliance. Pulumi Cloud, through Pulumi CrossGuard, provides out-of-the-box support for common security and compliance policies, ensuring PCIDSS, ISO27001, SOC2, and CIS compliance for cloud applications and infrastructure. Such organization-wide enforcement and specific policy support are not readily available with DIY backends.

At the application layer, securing sensitive information like database passwords, cloud credentials, and API keys is paramount. Secrets can inadvertently end up in insecurely stored state files, leading to potential breaches, as highlighted by a Sysdig article where an attacker exploited a manually managed state file to gain control over an entire AWS account. Pulumi Cloud, however, encrypts all data in transit and at rest, utilizing hardware security module (HSM) based encryption. It also avoids capturing cloud credentials, instead relying on client-side authentication, as detailed in the Pulumi Cloud Security Whitepaper.

Pulumi Cloud further enhances security with Pulumi ESC, a centralized secrets management and orchestration service. This service allows for pulling and syncing secrets from various stores like HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, GCP Secret Manager, and 1Password, making it easy to adopt dynamic, short-lived secrets on demand. Pulumi ESC leverages the same identity, RBAC, Teams, SAML/SCIM, OIDC, and scoped access tokens used for Pulumi IaC, ensuring that secrets management complies with enterprise security policies. Every access or change to secrets or configuration values is logged for auditing, providing a secure and auditable environment for you and your team to access secrets via CLI, API, Kubernetes operator, the Pulumi Cloud UI, and in-code with TypeScript/JavaScript, Python, and Go SDKs. With a DIY backend, you have to manage integration and access controls with individual secrets stores, with potential secrets sprawl and operational overhead.

Tetrate uses Pulumi ESC to stop secrets sprawl and attain compliance more efficiently.

“With Pulumi ESC, our developers get dynamic AWS and Azure credentials on-demand. Onboarding new developers is quick and secure, with no more manually filling in .env templates.”

–— Liam White, Platform Lead

Learn more

Organizational Scaling

As your organization grows, you need an IaC backend that scales with the organization and makes it easy to onboard new teams. Pulumi IaC brings your development, infrastructure and security teams together. Your infrastructure teams can define and manage common infrastructure across the organization, collaborate with security teams to establish security and compliance guardrails, and enable easy self-service of infrastructure through custom developer platforms or shared infrastructure libraries. Teams that prefer not to program can use YAML, while those who do can leverage Python, TypeScript, Golang, or C# to define organization-wide components.

You might also like:

With Pulumi IaC, your teams can tackle the growing complexity of modern architectures using familiar software engineering principles. Programming languages offer loops, conditional logic, class inheritance, and object-oriented design, allowing your organization to craft more sophisticated infrastructure compared to legacy IaC tools.

When you’re scaling your organization, you’ll need an IaC backend that makes team onboarding efficient. DIY backends often involve ad-hoc onboarding with bespoke identity solutions, requiring custom documentation and training to troubleshoot unique problems. This can slow down onboarding and reduce end-user productivity. Additionally, DIY backends place the internal support burden on your team, requiring them to assist users in navigating the system.

In contrast, Pulumi Cloud offers standardized, well-documented capabilities and integrates seamlessly with identity systems, leading to efficient onboarding and increased productivity for new employees. Pulumi Cloud provides 12x5 or 24x7 support, ensuring your organization receives immediate assistance with any architectural, cloud-related, or Pulumi best-practices issues. Furthermore, Pulumi Cloud includes built-in RBAC, simplifying the onboarding and scaling of new users.

BMW Group used Pulumi to build a scalable and resilient hybrid cloud implementation that could handle more than eleven thousand developers.

“When we started to use Terraform to deploy our first cloud services with AWS, it didn’t scale quickly enough for our needs. With Pulumi we’re really speeding up development. We can use any language instead of some special language like HCL and by automating policies, we have compliant and secure systems from the beginning.”

–— Jan-Peter Alten, DevOps Engineer

Learn more

Conclusion

When you choose between managing your own backend and using Pulumi Cloud, you need to carefully consider all the costs. You’ll face substantial operational costs with DIY backends, requiring dedicated engineering resources for maintenance, updates, and troubleshooting. Outages and incidents can lead to significant financial losses, as demonstrated by real-world examples where improper state management resulted in major service disruptions. The cost of setup and maintenance for a DIY backend is not just financial but also involves the time and effort of your team, which could otherwise be focused on core business activities.

Moreover, the cost of an engineer dedicated to managing the backend can be nearly 10% of your engineering budget, a significant investment for any organization. Figuring it out on your own adds to the complexity and potential for errors, increasing the risk of costly mistakes. Invisible excess waste in terms of unused or underutilized infrastructure can also accumulate, leading to unnecessary expenses.

When it comes to scaling, the cost of onboarding new teams or users onto a DIY system can be high due to the need for custom documentation, training, and support. Security is another critical area where the costs can escalate, with the need to comply with numerous IT security standards, manage access control, and ensure robust secrets management.

We built Pulumi Cloud as a fully managed service to address these concerns by providing a platform that automates deployments, ensures compliance, and offers comprehensive security features out-of-the-box. You’ll reduce your operational burden, minimize your risk of outages, and make scaling and onboarding easier, ultimately leading to cost savings and increased productivity. By choosing Pulumi Cloud, your organization can focus on innovation and growth rather than the intricacies of IaC backend management. You get to optimize your infrastructure without the overhead of running your own DIY solution.

Next Steps

Each unique variable in your environment –— cloud providers, languages, team structure, business objective, etc. –— makes realizing the full benefits of Pulumi Cloud different for each organization.

Our newly launched program called Immersion Days, is a customizable, half-day event designed to expand Pulumi’s impact across your organization.

The program has 3 key components:

Strategic Leadership Engagement: Address key business challenges like security posture, cost optimization, and developer productivity.
Architectural Review: Evaluate and refine platform engineering projects to enhance efficiency and scalability.
Hands-On Workshops: Equip your engineering teams with practical Pulumi skills through interactive technical sessions.

This program will help strengthen executive buy-in for your infrastructure initiatives while showcasing Pulumi’s value to your peer engineering teams.

If this sounds valuable, let’s discuss tailoring the agenda to fit your organization’s priorities.

Meta image credit: ESO/L. Calçada

Pulumi for AWS: Automate, Secure, and Manage Your Cloud

Aaron Kao — Mon, 02 Dec 2024 09:00:00 +0000

Note: This post discusses Pulumi Copilot, which Pulumi Neo has replaced. Learn about Neo →

Pulumi is excited to be at AWS re:Invent this week, where we’re showcasing our broad and deep support for AWS across all our products. From automating infrastructure with Pulumi IaC to securing secrets with Pulumi ESC to managing cloud assets with Pulumi Insights, Pulumi makes AWS a competitive advantage. Whether you’re a developer, DevOps pro, or platform engineer, Pulumi delivers the tools you need to build and manage modern cloud applications with ease.

Stop by the Pulumi re:Invent booth #370 this week to chat with experts on the Pulumi team. If you can’t make it to re:Invent, join our workshop, Accelerating Platform Engineering with Pulumi on AWS, on December 11, 2024, to see how Pulumi can enhance your cloud operations on AWS.

Why Pulumi for AWS?

Pulumi empowers your organization to automate AWS cloud infrastructure through code, tame secrets sprawl through centralized secrets management, and manage cloud assets and compliance with the help of AI. Pulumi encourages infrastructure, platform, development, DevOps, and security teams to collaborate and accelerates time to market with greater control and minimized risk.

Pulumi will speed up your deployments and time to value, providing you with an approach to open source and community that gives stability and choice. It will also increase your productivity and velocity through better tooling. Lastly, Pulumi uses software engineering to tackle the scale of an infinite combination of cloud architectures. Read more about why engineers and developers switch to Pulumi.

Pulumi for AWS Over the Years

Pulumi was founded back in 2017 to tackle the mounting challenges of modern cloud applications, which have grown increasingly intricate, spanning multiple environments and relying on numerous cloud resources and SaaS services. This complexity creates significant challenges for managing infrastructure. Legacy tools are designed for “two virtual machines with a database” and not thousands or millions of resources across many clouds and accounts. Teams waste time wrestling with excessive YAML configurations, resorting to copy-paste solutions, or using limited domain-specific languages (DSLs) that fail to scale effectively.

The fragmentation between development, infrastructure, and security teams only compounds these challenges. Pulumi’s founding vision addresses these pain points by enabling teams to build and manage cloud infrastructure through infrastructure as code using familiar programming languages and tools. Pulumi Infrastructure as Code (IaC) was launched with strong support of the AWS cloud. We wanted to be the best way for you to manage and scale your AWS infrastructure through code. Over the years, we launched many AWS-specific features to simplify how to manage AWS infrastructure at scale.

Well-Architected AWS Best Practices as a Component

One of the first innovations made for AWS was Pulumi Crosswalk for AWS, a collection of libraries that automatically use well-architected best practices to make common infrastructure-as-code tasks in AWS easier and more secure. Released in 2019, Crosswalk for AWS supports “day one” tasks, such as creating your initial container-based workloads, using Amazon Elastic Container Service (ECS) – including Fargate or Kubernetes (EKS) – and creating serverless workloads using Amazon API Gateway and AWS Lambda. Secure and cost-conscious defaults are chosen so that simple programs automatically use best practices for the underlying infrastructure, enabling better productivity with confidence.

Crosswalk for AWS also supports “day two and beyond” tasks, such as scaling your workload, securing and integrating it with your existing infrastructure, and going to production in multiple complex environments. This includes Amazon Virtual Private Cloud (VPC) for network isolation, AWS Auto Scaling for dynamic scaling, and AWS Identity and Access Management (IAM) for securing your infrastructure.

Earlier this month at KubeCon 2024, we launched the Pulumi Elastic Kubernetes Service (EKS) Provider v3.0.0, which is one of the Crosswalk libraries that makes Kubernetes management on AWS even easier. This release simplifies multi-cluster deployments, improves resource handling, and offers enhanced compatibility with the latest AWS EKS features.

AWS Policies as Code

We released Pulumi CrossGuard to enforce your organization’s cloud governance — security, compliance, cost controls, and more. This enables Policy as Code within your organization so that you can define guardrails for your infrastructure, ensuring engineers are following best practices and putting security first. CrossGuard helps your organization prevent mistakes before they occur and respond rapidly to any incidents.

Building Controls Planes

Many AWS customers build internal developer platforms (IDP) for developers to self-service infrastructure. In 2020, Pulumi Automation API was created to help automate infrastructure for these IDP control planes. Automation API exposes the full power of infrastructure as code through a programmatic interface, instead of through CLI commands, and it lets you use the Pulumi engine as an SDK, enabling you to create software that can create, update, configure, and destroy infrastructure dynamically. This enables you to use Pulumi to build IDPs that are custom-tailored to your team, organization, or customers.

AWS CDK for Pulumi

In 2022, Pulumi brought the ability to use AWS Cloud Development Kit (CDK) constructs from within a Pulumi deployment. For users already using AWS CDK, this provides Pulumi as a new option for orchestrating deployments in place of CloudFormation, offering improved deployment speed and integration with the full set of features of the Pulumi Platform. Even better, you can also now combine AWS CDK and Pulumi resources in a single Pulumi infrastructure as code project - passing outputs from Pulumi resources into AWS CDK constructs, and outputs from AWS CDK constructs into Pulumi resources.

AWS Cloud Development Kit (CDK) on Pulumi is now generally available. This powerful integration includes full support for CDK features like assets, custom resources, aspects, and context values/methods. It provides access to the full ecosystem of over 1,200 CDK Construct libraries, and it also supports all 180+ Pulumi providers, allowing for CDK applications to include resources outside of AWS.

Cloud Control API

In 2021, AWS launched Cloud Control API as a standard set of APIs to Create, Read, Update, Delete, and List (CRUDL) resources across hundreds of AWS Services. Pulumi supported that launch with a native provider called the Pulumi Cloud Control Provider, formerly known as AWS Native. The provider is now generally available, enabling day 1 support for new AWS resources, seamless compatibility with Pulumi IaC projects that currently use the Pulumi AWS provider, and extended support for third-party resources.

Beyond Pulumi IaC

Over the last few years, our customers have shared a clear message: IaC alone is insufficient. The complexities of modern cloud environments demand more than just IaC to manage cloud resources, improve security, and ensure compliance. In response, Pulumi’s offerings have expanded into a comprehensive suite of tools that go beyond IaC.

Pulumi Insights: Intelligent Cloud Management

The complexities of modern cloud environments create significant challenges in making sense of the millions of resources and resource updates per month, across hundreds of clouds, regions, and accounts. Identifying cost saving opportunities is difficult amidst soaring cloud expenditures, and maintaining compliance and security is mission critical because errors can cause catastrophic damage.

Pulumi Insights empowers organizations to tackle cloud complexity by delivering visibility, actionable insights, and AI-assisted optimization for their infrastructure. With Pulumi Insights, companies can scan and sync their entire AWS resource inventory – including resources not managed with Pulumi IaC – ensuring a complete picture of their cloud assets. This Account Discovery capability is now in public preview.

Compliance checks can also be run against standards such as PCI DSS, ISO 27001, and CIS benchmarks, helping maintain regulatory compliance and mitigate risks. The AI-powered Pulumi Copilot provides an interactive assistant to gain visibility into a team’s activity, discover cost saving opportunities, get compliant, and debug cloud failures. Pulumi Insights enables companies to discover, understand, manage, and improve their cloud infrastructure on their journey towards intelligent infrastructure management.

Pulumi ESC: Centralized Secrets Management

Cloud complexity creates significant challenges in managing sensitive credentials, API keys, and configurations across development, testing, and production environments. As organizations scale, they often face issues of secrets and configuration sprawl, duplication of secrets, and too many long-lived static secrets. None of the existing secrets management solutions adequately address these challenges, exposing enterprises to errors that can lead to security breaches, unintended exposure of sensitive data, and unauthorized access to critical resources.

Pulumi ESC addresses these challenges by offering seamless two-way integration – both pull and sync – with AWS Secrets Manager and other popular secrets stores, as well as the capability to consume secrets securely across any application, tool, and CI/CD platform. Developers gain easy, secure access to secrets via CLI, API, Kubernetes operators, and SDKs – eliminating the need for .env files and reducing the security risks associated with them. Additionally, Pulumi ESC can issue dynamic, short-lived AWS authentication tokens on demand via OpenID Connect (OIDC), reducing the risks that come with long-lived access tokens, while RBAC, versioning, and a detailed audit log let you trust (and prove) your secrets are secure.

Try Pulumi Cloud Today

Check out the Pulumi roadmap for upcoming features, let us know your feature requests by creating an issue on GitHub, connect with the Pulumi community on Slack, and if you haven’t yet, sign-up for Pulumi Cloud to get access to our full suite of products – Pulumi IaC, Pulumi ESC, and Pulumi Insights – so you can automate, secure, and manage everything you run in the cloud.

Meta image credit: ESO/M. Zamani

YAML, Terraform, Pulumi: What’s the Smart Choice for Deployment Automation with Kubernetes?

Engin Diri — Mon, 18 Nov 2024 08:00:00 +0100

YAML and Kubernetes go together like peanut butter and jelly. While Kubernetes objects can be defined in JSON, YAML has emerged as the de facto standard.

It’s often the first tool developers encounter when diving into Kubernetes, and for good reason - its human-readable format makes it the preferred choice in most tutorials, documentation, and even production deployments.

But is it the best way to manage your Kubernetes resources? Let’s compare YAML, Terraform, and Pulumi and see which is best for managing your Kubernetes resources.

I also gave a talk before on No YAML! and what alternatives you have if you would only stick with the Go language:

Kubernetes Components and the Kubernetes API

Before we discuss the ways to manage Kubernetes objects, let’s look at the components of a typical Kubernetes cluster and their interactions.

Kubernetes Components. Credit: kubernetes.io

A Kubernetes cluster has two component categories: control plane and node. The control plane components manage the cluster. They consist of:

kube-apiserver - The API server is the front end for the Kubernetes control plane. It exposes the Kubernetes API.
etcd - A consistent, highly available key-value store. It is Kubernetes’ backing store for all API data.
kube-scheduler - Watches for newly created Pods with no assigned node and selects a node for them to run on.
kube-controller-manager - Runs a controller to implement the control loop.
cloud-controller-manager - Runs controllers that interact with the underlying cloud providers.

The node components run on every node in the cluster. They provide the runtime environment for the containers.

kubelet - An agent that runs on each node in the cluster. It ensures that pods are running.
kube-proxy - Maintains network rules on nodes.
Container Runtime - Is responsible for running containers.

The Kubernetes API is the central component in a Kubernetes cluster. It is the interface to the cluster and the only way to work with Kubernetes objects.

A Kubernetes object is a “record of intent”. It represents the desired state of the workload running on the cluster. The whole Kubernetes system will continuously work to ensure that the object exists.

YAML Manifests

If you are long enough exposed to Kubernetes, you will have seen a lot of YAML files. You can define many Kubernetes objects in a YAML file. These include Deployments, Services, ConfigMaps, Secrets, and more.

Let’s have a look at an example of a Deployment object in YAML for an Nginx web server:

Example

apiVersion: apps/v1
kind: Deployment
metadata:
 name: nginx-deployment
spec:
 replicas: 1
 selector:
 matchLabels:
 app: nginx
 template:
 metadata:
 labels:
 app: nginx
 spec:
 containers:
 - name: "nginx:latest"
 image: nginx

Pros and Cons of YAML

Pros

Simple: Kubernetes YAML files are easy to read and write.
The standard: YAML is the standard way to define Kubernetes objects. It is a first-class citizen in the kubectl command-line tool.

Cons

Multiple environments: If you have multiple environments, like development, staging, and production, you need to maintain multiple YAML files.
Too manual: You must create and update the YAML files by hand. Also, you must track changes across many files.
Not DRY: You cannot use the DRY principle (Don’t Repeat Yourself) in YAML files. If you have the same configuration in many files, you need to update all of them by hand.
No real abstraction: The advantage of a static configuration file is also its disadvantage. You cannot use dynamic values in the YAML files.
Need for tools from the ecosystem: You need to use tools like helm or kustomize to manage the complexity of many YAML files, environments, and templating.

To sum it up, YAML is a good choice for simple Kubernetes objects and small projects. But, if you have a complex project, and to be honest, most are, you need a better way to manage your Kubernetes resources.

Or to rephrase it: Friends don’t let friends manage Kubernetes resources with YAML.

Why should you avoid YAML? Credit: No YAML!

Terraform Kubernetes Provider

Terraform is an Infrastructure as Code tool. It lets you define and manage your infrastructure in a declarative way. It uses a high-level configuration language called HashiCorp Configuration Language (HCL). To manage Kubernetes objects with Terraform, use the Kubernetes provider. It allows you to define Kubernetes objects in Terraform HCL.

The Kubernetes provider allows you to define Kubernetes objects like kubernetes_deployment, kubernetes_service, kubernetes_config_map, kubernetes_secret, and more in code, leveraging the language features of Terraform. You can use, to a certain extent, loops, conditions, and variables in a way that is not possible with plain YAML files.

Let’s have a look at an example of a Deployment object in Terraform HCL for an Nginx web server:

Example

resource "kubernetes_deployment" "nginx" {
 metadata {
 name = "nginx-deployment"
 }

 spec {
 replicas = 1

 selector {
 match_labels = {
 app = "nginx"
 }
 }

 template {
 metadata {
 labels = {
 app = "nginx"
 }
 }

 spec {
 container {
 image = "nginx:latest"
 name = "nginx"
 }
 }
 }
 }
}

This is a very simple example of a Deployment object in Terraform HCL. Let’s add some complexity to the example by adding variables and loops:

Example with Variables and Loops

variable "namespace" {
 description = "The namespace to deploy the resources"
 type = string
 default = "default"
}

variable "nginx_image" {
 description = "The Nginx image to use"
 type = string
 default = "nginx:latest"
}

variable "replicas" {
 description = "The number of replicas to deploy"
 type = number
 default = 1
}

variable "number_of_deployments" {
 description = "The number of deployments to create"
 type = number
 default = 2
}

locals {
 nginx_image = var.nginx_image
 replicas = var.replicas
 namespace = var.namespace
 number_of_deployments = var.number_of_deployments
}

resource "kubernetes_deployment" "nginx" {
 for_each = {for i in range(local.number_of_deployments) : i => i}

 metadata {
 name = "nginx-deployment-${each.key}"
 namespace = local.namespace
 }

 spec {
 replicas = local.replicas
 selector {
 match_labels = {
 app = "nginx-${each.key}"
 }
 }

 template {
 metadata {
 labels = {
 app = "nginx-${each.key}"
 }
 }

 spec {
 container {
 image = local.nginx_image
 name = "nginx"
 }
 }
 }
 }
}

In this example, we can already see the advantage of Terraform over plain YAML files. We can use variables and loops to define multiple kubernetes_deployment objects in a more dynamic way.

Pros and Cons of Terraform

Pros

Dynamic: You can use variables, loops, and conditions in Terraform HCL. This lets you define your Kubernetes objects in a more dynamic way.
Abstraction: You can apply the DRY principle in Terraform HCL by defining and reusing modules across projects.
Environment management: By defining variables, you can manage multiple environments, like development, staging, and production. This is a more structured way to do it, without needing extra tools.

Cons

Complexity: Terraform is more complex than plain YAML files. You must learn Terraform’s HCL to define your Kubernetes objects.
DSL: Terraform is a Domain-Specific Language (DSL). You need to learn it to define your Kubernetes objects.
Testability: Testing Terraform code is harder. You need tools like Terratest and Kitchen-Terraform for it.
Helm Support: Terraform does not support Helm charts out of the box. You need to use the Helm provider to manage them with Terraform. This can add complexity to your Terraform code, and you need to keep track of the Helm provider dependency.
IDE Support: Terraform lacks the same IDE support as YAML files. You need plugins, like the Terraform Extension for Visual Studio Code, for syntax highlighting and autocompletion.

Terraform is a good choice for managing your Kubernetes resources if you have a complex project and you do not mind the complexity of the Terraform language. It gives you more flexibility and abstraction than plain YAML files, and you can manage multiple environments in a more structured way.

But is there a better way to manage your Kubernetes resources? Let’s have a look at Pulumi.

Pulumi and the Power of General Purpose Languages

Last but not least, let’s have a look at Pulumi. Pulumi is an Infrastructure as Code tool. It lets you define and manage your Kubernetes objects using general-purpose programming languages. Pulumi supports multiple languages like Python, Go, TypeScript, JavaScript, .NET, and JVM-based languages. This gives you all the benefits of a full programming language. It includes native IDE support, code completion, and debugging.

You need to install the Pulumi CLI. Then, create a new Pulumi project. Finally, add the Kubernetes library to it. It depends on the language you choose. You could use a package manager, like npm or pip.

Let’s have a look at an example of what a Deployment object would look like in all the supported languages.

import * as pulumi from "@pulumi/pulumi";
import * as k8s from "@pulumi/kubernetes";

const nginxDeployment = new k8s.apps.v1.Deployment("nginx-deployment", {
 metadata: {
 name: "nginx-deployment",
 },
 spec: {
 replicas: 1,
 selector: {
 matchLabels: {
 app: "nginx",
 },
 },
 template: {
 metadata: {
 labels: {
 app: "nginx",
 },
 },
 spec: {
 containers: [
 {
 name: "nginx",
 image: "nginx:latest",
 },
 ],
 },
 },
 },
});

import pulumi
import pulumi_kubernetes as k8s

nginx_deployment = k8s.apps.v1.Deployment(
 "nginx-deployment",
 metadata=k8s.meta.v1.ObjectMetaArgs(
 name="nginx-deployment",
 ),
 spec=k8s.apps.v1.DeploymentSpecArgs(
 replicas=1,
 selector=k8s.meta.v1.LabelSelectorArgs(
 match_labels={
 "app": "nginx",
 },
 ),
 template=k8s.core.v1.PodTemplateSpecArgs(
 metadata=k8s.meta.v1.ObjectMetaArgs(
 labels={
 "app": "nginx",
 },
 ),
 spec=k8s.core.v1.PodSpecArgs(
 containers=[
 k8s.core.v1.ContainerArgs(
 name="nginx",
 image="nginx:latest",
 ),
 ],
 ),
 ),
 ),
)

package main

import (
 "github.com/pulumi/pulumi-kubernetes/sdk/v4/go/kubernetes/apps/v1"
 corev1 "github.com/pulumi/pulumi-kubernetes/sdk/v4/go/kubernetes/core/v1"
 metav1 "github.com/pulumi/pulumi-kubernetes/sdk/v4/go/kubernetes/meta/v1"
 "github.com/pulumi/pulumi/sdk/v3/go/pulumi"
)

func main() {
 pulumi.Run(func(ctx *pulumi.Context) error {
 _, err := v1.NewDeployment(ctx, "nginxDeployment", &v1.DeploymentArgs{
 Metadata: &metav1.ObjectMetaArgs{
 Name: pulumi.String("nginx-deployment"),
 },
 Spec: &v1.DeploymentSpecArgs{
 Replicas: pulumi.Int(1),
 Selector: &metav1.LabelSelectorArgs{
 MatchLabels: pulumi.StringMap{
 "app": pulumi.String("nginx"),
 },
 },
 Template: &corev1.PodTemplateSpecArgs{
 Metadata: &metav1.ObjectMetaArgs{
 Labels: pulumi.StringMap{
 "app": pulumi.String("nginx"),
 },
 },
 Spec: &corev1.PodSpecArgs{
 Containers: corev1.ContainerArray{
 &corev1.ContainerArgs{
 Name: pulumi.String("nginx"),
 Image: pulumi.String("nginx:latest"),
 },
 },
 },
 },
 },
 })
 if err != nil {
 return err
 }
 return nil
 })
}

using Pulumi;
using Pulumi.Kubernetes.Types.Inputs.Core.V1;
using Pulumi.Kubernetes.Types.Inputs.Apps.V1;
using Pulumi.Kubernetes.Types.Inputs.Meta.V1;
using System.Threading.Tasks;
using Deployment = Pulumi.Deployment;

class MyStack : Stack
{
 public MyStack()
 {
 var nginxDeployment = new Pulumi.Kubernetes.Apps.V1.Deployment("nginxDeployment", new DeploymentArgs
 {
 Metadata = new ObjectMetaArgs
 {
 Name = "nginx-deployment",
 },
 Spec = new DeploymentSpecArgs
 {
 Replicas = 1,
 Selector = new LabelSelectorArgs
 {
 MatchLabels =
 {
 { "app", "nginx" }
 }
 },
 Template = new PodTemplateSpecArgs
 {
 Metadata = new ObjectMetaArgs
 {
 Labels =
 {
 { "app", "nginx" }
 }
 },
 Spec = new PodSpecArgs
 {
 Containers =
 {
 new ContainerArgs
 {
 Name = "nginx",
 Image = "nginx:latest",
 }
 }
 }
 }
 }
 });
 }
}

class Program
{
 static Task<int> Main() => Deployment.RunAsync<MyStack>();
}

package myproject;

import com.pulumi.Pulumi;
import com.pulumi.kubernetes.apps.v1.Deployment;
import com.pulumi.kubernetes.apps.v1.DeploymentArgs;
import com.pulumi.kubernetes.apps.v1.inputs.DeploymentSpecArgs;
import com.pulumi.kubernetes.core.v1.inputs.ContainerArgs;
import com.pulumi.kubernetes.core.v1.inputs.PodSpecArgs;
import com.pulumi.kubernetes.core.v1.inputs.PodTemplateSpecArgs;
import com.pulumi.kubernetes.meta.v1.inputs.LabelSelectorArgs;
import com.pulumi.kubernetes.meta.v1.inputs.ObjectMetaArgs;

import java.util.Map;

public class App {
 public static void main(String[] args) {
 Pulumi.run(ctx -> {
 var nginxDeployment = new Deployment("nginxDeployment", DeploymentArgs.builder()
 .metadata(ObjectMetaArgs.builder()
 .name("nginx-deployment")
 .build())
 .spec(DeploymentSpecArgs.builder()
 .replicas(1)
 .selector(LabelSelectorArgs.builder()
 .matchLabels(Map.of("app", "nginx"))
 .build())
 .template(PodTemplateSpecArgs.builder()
 .metadata(ObjectMetaArgs.builder()
 .labels(Map.of("app", "nginx"))
 .build())
 .spec(PodSpecArgs.builder()
 .containers(ContainerArgs.builder()
 .name("nginx")
 .image("nginx:latest")
 .build())
 .build())
 .build())
 .build())
 .build());
 });
 }

Now have a look into the more complex example with variables and loops in Pulumi. I am using TypeScript as an example, but you can of course use any of the Pulumi supported languages.

Example with Variables and Loops

import * as pulumi from "@pulumi/pulumi";
import * as k8s from "@pulumi/kubernetes";

let config = new pulumi.Config();

const namespace = config.get("namespace") || "namespace";
const nginxImage = config.get("nginxImage") || "nginx:latest";
const replicas = config.getNumber("replicas") || 1;
const numberOfDeployments = config.getNumber("numberOfDeployments") || 1;

for (let i = 0; i < numberOfDeployments; i++) {
 new k8s.apps.v1.Deployment(`nginxDeployment-${i}`, {
 metadata: {
 name: `nginx-deployment-${i}`,
 namespace: namespace,
 },
 spec: {
 replicas: replicas,
 selector: {
 matchLabels: {
 app: `nginx-${i}`,
 },
 },
 template: {
 metadata: {
 labels: {
 app: `nginx-${i}`,
 },
 },
 spec: {
 containers: [
 {
 name: "nginx",
 image: nginxImage,
 },
 ],
 },
 },
 },
 });
}

In this example, you can see how easy it is to define multiple Deployment objects with variables and loops syntax provided by TypeScript. This is a big advantage over plain YAML files and Terraform HCL. Blending the full power of a general-purpose programming language with the Kubernetes API is a natural process. Consider the possibilities of creating reusable functions, classes, and modules. You could share them across multiple projects and teams.

You might also like:

Pros and Cons of Pulumi

Pros

You can use general-purpose languages to define your Kubernetes objects. These include Python, Go, TypeScript, JavaScript, .NET, and JVM-based languages.

Full IDE support: You get full IDE support. It includes syntax highlighting, code completion, and debugging.
Testability: You can use the full power of your programming language to test your Pulumi code.
Abstraction: You can use the DRY principle in Pulumi. Define reusable functions, classes, and modules in your chosen programming language.
Environment management: You can manage multiple environments, like development, staging, and production, by defining config variables. This is a more structured way, without needing extra tools.
Kubernetes Helm Support: Pulumi supports Helm charts out of the box. You can manage Helm charts with Pulumi without needing extra tools or providers.
Programmatic execution of Pulumi: You can further blend Pulumi code into your projects using the Pulumi Automation API.

Cons

Runtime dependency: You must have the runtime of your chosen programming language installed on your machine, or use a containerised version of it in your CI/CD pipeline.
Follow best practices and compliance: Set up a code review process. It should ensure the Pulumi code follows the best practices of your chosen programming language and your organization’s additional best practices.
No possibility to convert one Pulumi language to another: If you start with one language, you can’t convert the Pulumi code to another language. You need to rewrite the Pulumi code in the new language.

YAML vs. Terraform vs. Pulumi - Results

Feature	YAML	Terraform	Pulumi
Readability	✅ Simple and human-readable	⚠️ Requires learning HCL	✅ Uses familiar programming languages
Environment Management	❌ Requires manual management of multiple files	✅ Structured management via variables	✅ Structured management via config variables
DRY Principle	❌ No reusability, requires manual updates	✅ Supports modules and reusable code	✅ Full support via functions, classes, modules
Dynamic Configuration	❌ Static configuration only	✅ Supports loops, conditions, variables	✅ Full programming language capabilities
IDE Support	✅ Good support	⚠️ Limited, requires plugins	✅ Full language-native IDE support
Testing	❌ Limited testing options	⚠️ Requires specialized tools (Terratest)	✅ Native language testing frameworks
Helm Support	✅ Native support	⚠️ Requires additional provider	✅ Built-in support
Learning Curve	✅ Low	⚠️ Medium (new DSL)	⚠️ Varies by language knowledge
Dependencies	✅ Minimal	⚠️ Terraform installation	❌ Language runtime required
Ecosystem Tools	❌ Requires additional tools (Helm, Kustomize)	✅ Integrated tooling	✅ Integrated tooling
Abstraction	❌ Limited	✅ Good	✅ Excellent

Legend:

✅ Good/Supported
⚠️ Partial/With limitations
❌ Poor/Not supported

Time to say Goodbye to YAML?

So, what’s the smart choice for deployment automation with Kubernetes? Is YAML still the best choice for Kubernetes? Or, is there a better way to manage your resources? I understand if you are a YAML fan. Despite complaints, it is still the most popular way to define Kubernetes objects. Many folks feel a sense of accomplishment when their YAML file works on the first try.

If you have a complex project, you will soon hit the limits of YAML. You want to manage your Kubernetes resources in a more structured, dynamic way while following best practices and compliance. Then, you keep adding more complexity to your YAML files. You do this by using tools like helm and kustomize to fix YAML’s flaws. Or, you adopt a hybrid approach with jsonnet, cuelang, or ytt. This makes it even more complex.

Giving up on YAML is not easy, but it does not mean that you have to give up on control. You can still have full control by using Terraform or Pulumi.

Conclusion

Now it’s time to make a decision. What’s the smart choice for deployment automation with Kubernetes? Is it YAML, Terraform, or Pulumi? For me, the smart choice is Pulumi. It gives you all the benefits of a general-purpose programming language. You gain full control, a more streamlined workflow, and the power to define all your infrastructure needs as code beyond Kubernetes. Especially on complex projects, use Pulumi. It’s better than dealing with many YAML files and the complexity of Terraform HCL.

Next time you start a new project, try Pulumi. See for yourself that it’s a smart choice. It’s an upgrade to your productivity and happiness.

But that’s my opinion. What’s your opinion? What’s your smart choice for deployment automation with Kubernetes?

If you want to try out Pulumi or play around to prove me wrong, you can start with:

Get Started with Pulumi

Use Pulumi's open-source SDK to create, deploy, and manage infrastructure on any cloud.

When to Use Cosmos DB

Adam Gordon Bell — Mon, 11 Nov 2024 17:39:54 -0500

When should you use Cosmos DB on Azure? It’s a hard question to answer.

Azure Cosmos DB tries to do it all - which makes it both powerful and, honestly, kind of confusing. The marketing doesn’t help either. Yeah, it’s a flexible database, but before you jump in, you need to understand how it actually works under the hood, what it’ll cost you, and what trade-offs you’re making by choosing it.

I’m going to break all that down. Here’s a roadmap:

TL;DR

The short version is: you should use it on Azure when you’d use DynamoDB on AWS. That’s to say, you should use it when you’re OK with being cloud-specific, when you want hands-off scalability, and when you know the query pattern and potential cost ramifications ahead of time.

But let’s start at the beginning.

What is Cosmos DB? Features & Architecture Explained

Cosmos DB is Microsoft high availability distributed database. First released as DocumentDB in 2014 and rebranded to Cosmos DB in 2017, its used internally at MS for Bing and Office 365 and available on Azure in all regions.

Types Of Databases

Different databases are good at different things. Relational databases focus on strong consistency and complex relationships. Key-value stores are optimized for speed and simplicity. Document databases trade schema rigidity for flexibility. NewSQL systems attempt to combine consistency and scale.

Type	Example	Best For
Relational	PostgreSQL	Traditional business applications with complex transactions
Key-Value	Redis	Caching and session management
Document	MongoDB	Applications with evolving data structures
NewSQL	Spanner, CockroachDB	Global applications requiring both scale and consistency
Dynamo-Inspired	DynamoDB, Cassandra	High write throughput, eventually consistent applications

Cosmos DB can look like each of those categories. This is because it’s a multi-model DB, with a number of APIs that correspond to each model type. Despite it having a SQL interface (often recognized as the most used and recommended interface), and despite it purporting to be multi-model, at its lowest layer, it is actually backed by a document-based storage layer. It is a powerful document database, one with tunable consistency, distribution by logical and physical partition, and more, but it’s helpful to know how the storage layer works to understand everything else. I’m going to show some examples, but first let’s clear up what Cosmos DB is not.

If you are going to use Cosmos DB, you should probably be using the Core API, also called the “API for NoSQL”. It’s the quickest to get new features. Confusingly, despite being called a NoSQL API, data is queried and added using SQL.

Cosmos DB Vs. SQL Server ( Azure SQL Database ) or Postgres

This is a personal opinion, but if you have a use case that is well served by a traditional relational database, you should choose that. Postgres and SQL Server are both great and both available on Azure ( Postgres as Azure Database for PostgreSQL ). They both have great query planners; they have great tooling for migration and backups, as well as schema management. The SQL API from Cosmos should not be considered an alternative to a relational database unless you have specific needs because it’s a different type of beast designed for different use cases. But let me show you.

If you grab our CosmoDB how to guide and pulumi up, you’ll see from that, the first hint of its document roots in that the pulumi namespace is Pulumi.AzureNative.DocumentDB, but it goes deeper because although I can insert and select with sql in Cosmos DB, there is no schema.

How to Insert & Query Data in Cosmos DB NoSQL

If I insert this customer:

CosmosDatabase database = await client.
 CreateDatabaseIfNotExistsAsync(databaseId);
CosmosContainer container = await database.
 CreateContainerIfNotExistsAsync(containerId, "/customerId");

// Insert a customer document
var customer = new Customer
{
 Id = Guid.NewGuid().ToString(),
 CustomerId = "12345", // Cosmos DB Partition key
 Name = "John Doe",
 Email = "john.doe@example.com"
};

await InsertCustomer(container, customer);

I can do selects against it like SELECT * FROM c WHERE c.customerId = '12345" but when I look in that container in Azure Data Explorer, I see something like this:

{
 "id": "1d4e26b3-7a02-4e97-8a9d-eccc0b2fd537",
 "customerId": "12345",
 "name": "John Doe",
 "email": "john.doe@example.com",
 "_rid": "<resource id>",
 "_self": "<document URI>",
 "_etag": "\"00000000-0000-0000-0000-000000000000\"",
 "_attachments": "attachments/",
 "_ts": 1609459200
}

As with any document database, rather than a schema, it’s just a JSON document. That’s all good, but because there is no schema, if I needed to do something like migrate name to fullname, how do I do it? Well, there are a bunch of strategies, but they all involve writing some application code to go record by record and move the value from name to full name.

So don’t be fooled by the SQL usage in the API. Cosmos DB is not a relational database; before you use a document database, you should be clear of the trade-offs.

Document Database / NoSQL Trade-Offs

Joins and Relationships: Cosmos DB lacks support for complex joins and foreign key constraints. Cosmos DB typically requires denormalization or application-level management of relationships.
ACID Transactions and Consistency: Cosmos DB supports ACID transactions but only within single partitions (more on partitions soon). Cross-partition operations in Cosmos DB may require manual consistency handling.
Schema Evolution and Migrations: Relational databases enforce a schema and support migration tools. Cosmos DB’s schemaless design offers flexibility but requires custom logic for data migrations, which can increase operational overhead with frequent schema changes.
Query Optimization and Indexing: Postgres, SQL Server, and any relational database will have a query optimization layer with a sophisticated planner and manual indexing control. Cosmos DB auto-indexes all fields, simplifying queries but potentially increasing costs. Custom indexing policies offer less control than you would see in SQL Server or Postgres.
Cost Structure: Relational database costs are tied to compute and storage resources. Scaling might be a challenge past some point, but costs are fixed. Cosmos DB uses Request Units (RUs) for billing and charging per read, write, and query. This can lead to unpredictable costs if not carefully tuned.
Operational Maturity: Relational databases are mature with mature solutions for backup, replication, and monitoring. Cosmos DB is fully managed but has fewer third-party tools. Postgres or another relational DB may be easier to integrate into existing workflows requiring mature operational support.

If your use case aligns well with relational databases, consider using PostgreSQL or SQL Server. You have multiple Azure options, including Azure Database for PostgreSQL and Azure SQL Database. There’s even Azure Cosmos DB for PostgreSQL, which confusingly uses native PostgreSQL combined with the Citus extension for distributed capabilities. It’s not based on Cosmos DB’s NoSQL DocumentDB storage layer and is a Postgres database.

Cosmos DB is best for other use cases, so on we go to ‘NoSQL’ document databases.

Azure offers various services under the “Cosmos DB” brand like Azure Cosmos DB for PostgreSQL, Azure Cosmos DB for MongoDB (VCore), and a managed instance for Cassandra. These are not based on the core Cosmos DB engine, they are not an API into Cosmos, they are a whole different things - hosted instances of specific database types.

Cosmos DB Vs MongoDB

So, let’s talk MongoDB then. Cosmos DB is multi-model in a specific way. It has a single storage layer, the DocumentDB, and then various APIs. One of these is a MongoDB interface. This Mongo interface, on top of Cosmos DB, might be a great choice if you are used to Mongo, because you can often just change your query string on your existing mongodb code and start using cosmos.

using MongoDB.Driver;
using MongoDB.Bson;

// Connect to Cosmos DB using MongoDB API
var client = new MongoClient("mongodb://<account>:<key>@<account>.mongo.cosmos.azure.com:10255/?ssl=true");
var db = client.GetDatabase("customersdb");
var collection = db.GetCollection<BsonDocument>("customers");

var docs = await collection.Find(
 new BsonDocument("customerId", "12345")
).ToListAsync();

That will totally work. You can query using MQL, assuming you avoid Mongo’s advanced features. Still, you will quickly need to understand Cosmos-specific things, like RUs and partitions, or else you might end up with unexpected performance or costs.

Reddit Azure users report some challenges with using the Mongo API, and Microsoft also recommends using the SQL-based “API for NoSQL” if you can. So Mongo fans may want to consider not choosing Cosmos’ Mongo API.

However, the big advantage of Cosmos over Mongo is distribution and scaling up. But to understand that, we need to explain partitions.

With MongoDB, you’re setting up shards, configuring keys, and managing replica sets. Sure, you get control, but you’re also the one staying up late managing infrastructure as your data grows.

In Cosmos DB, scaling and partitioning are more hands-off – you just have to enable ‘automatic scaling’ – but you need the correct partition key from the start. So you need to understand your access patterns and be aware that ‘automatic scaling’ does what it says, but costs will increase as you scale.

How Cosmos DB Partitions & Scales Data Efficiently

In MongoDB, a shard is a collection of data stored on a specific server, used to distribute data across multiple servers for horizontal scaling. Partitioning is really an improvement on this idea. Cosmos separates partitions into logical and physical partitions. You choose the logical partitions only and leave the DB to decide the best way to group these onto specific physical servers. The physical groupings are physical partitions, and the system manages scaling by handling data distribution across physical partitions without user intervention.

Cosmos DB Partitioning

Logical Partitions: Like MongoDB’s shards, logical partitions group documents with the same partition key. However, each logical partition can store up to 20 GB of data and is automatically managed by Cosmos DB.
Physical Partitions: Cosmos DB hides the complexity of managing the physical servers. Physical partitions store and serve one or more logical partitions, and Cosmos DB handles how data is distributed across physical partitions for you. This allows Cosmos DB to automatically scale and balance the load as needed.

Comparison To MongoDB

Feature	MongoDB Sharding	Cosmos DB Partitioning
Data Distribution	Manual sharding with shard key and replica sets	Automatic partitioning with partition key
Scaling	Manual scaling (add shards)	Automatic scaling (Azure-managed)
Operational Complexity	Requires manual setup and maintenance	Minimal operational overhead
Global Distribution	Requires manual setup of replica sets	Built-in global distribution
Consistency Models	Eventual (with strong for replica sets)	5 consistency models, including strong
Query Performance	Requires index management, can result in scatter-gather queries	Auto-indexing, but cross-partition queries can be costly
Cost Model	Based on instance, storage, and IO usage	Request Units (RUs) per operation, with potential for high costs

MongoDB Vs. Cosmos DB Cost Comparison

Your exact numbers may vary, but by my back-of-the-napkin math, Cosmos DB is cheaper more than MongoDB Atlas for similar workloads. It also has SLAs on read speed and scaling is much easier.

Service	Cost (500 reads/sec, 50 writes/sec, 10 KB document)	Pricing Model
MongoDB Atlas	~$387.62/month	Based on instance size (M30), fixed pricing
Cosmos DB	~$227.28/month	Request Units (RUs) based, scales with document size and operations

Cosmos DB Vs Cassandra

After learning about partitioning and seeing the Cassandra API, you might think Cosmos DB is basically managed by Cassandra. And there are some key similarities. In many ways, Cosmos DB is Cassandra-inspired, but there are key differences.

You might also like:

How Cosmos DB and Cassandra Relate

Partitioning: Both use logical partition keys for scalability to distribute data across nodes. Cassandra requires manual management, while Cosmos DB automates partitioning and scaling, reducing operational burdens, though at the cost of flexibility.
Tunable Consistency: Like Cassandra, Cosmos DB offers tunable consistency but expands on it with five levels: Strong, Bounded Staleness, Session, Consistent Prefix, and Eventual—allowing finer control over consistency vs. performance.

Key Differences

Cassandra API: Though Cosmos DB offers a Cassandra API, it’s not running Cassandra under the hood. So, while the API is familiar, the system behaves differently, especially in terms of performance.
Operational Complexity: Cassandra gives complete control over nodes and replication but requires hands-on management. Cosmos DB automates these tasks, offering hands-off operations while maintaining high availability, making it easier to manage at scale.

API for Apache Cassandra

If you have existing Apache Cassandra usage, in theory, the API for Apache Cassandra lets you use CosmosDB equivalently by just changing the query string. As with the Mongo API above, if possible you are probably better to use Core NoSQL API, but that will required rewriting dataaccess code.

Cosmos DB CQL Querying

using Cassandra;

// Connect to Cosmos DB's Cassandra API
var cluster = Cluster.Builder()
 .WithCredentials("<username>", "<password>") // From Azure Portal
 .WithPort(10350)
 .AddContactPoint("<account>.cassandra.cosmos.azure.com")
 .WithSSL()
 .Build();

var session = await cluster.ConnectAsync();

var cql = "SELECT * FROM customersdb.customers WHERE customer_id = ?";
var results = await session.ExecuteAsync(cql, "12345");

foreach (var row in results)
{
 Console.WriteLine($"Customer: {row["name"]}");
}

When to Use Cassandra Vs Cosmos DB

Cassandra: Use when you need control and can manage partitioning and scaling manually.
Cosmos DB: Use when you want hands-off scalability and a fully managed service with the option to use Cassandra-like APIs.

So use Cassandra when you need complete control over partitioning and scaling and are prepared to manage infrastructure manually. Opt for Cosmos DB when you want a hands-off managed service that handles the operational complexity for you, even if you’re using the familiar Cassandra API.

Dynamo DB Vs Cosmos DB

After comparing Cosmos DB to Cassandra, it’s natural to think of DynamoDB next. Like Cosmos DB, DynamoDB is fully managed and Dynamo-inspired, but being part of AWS, it operates differently from both Cassandra and Cosmos DB, especially in terms of operational simplicity and pricing.

Managed Operations

DynamoDB and Cosmos DB remove the ops overhead you’d get with Cassandra. If Cassandra gives you full control over nodes and partitioning, DynamoDB and Cosmos DB automate much of the complexity behind the scenes. With DynamoDB, you don’t have to manually manage shards or replication—AWS handles that for you, just like Cosmos DB on Azure.

Both databases also rely heavily on partition keys for data distribution. In DynamoDB, choosing the right partition key is critical to avoid hot spots, just like you need a well-thought-out partition key in Cosmos DB to balance the load across physical partitions. But where DynamoDB allows you to toggle between on-demand and provisioned capacity to manage scaling, Cosmos DB simply auto-scales as your traffic grows, offering a more seamless experience if you’re willing to pay for it.

Cosmos DB Consistency Levels

While Cassandra offers tunable consistency, DynamoDB simplifies this down to just two options: eventual consistency (default) or strong consistency. It’s enough for many use cases, but Cosmos DB follows Cassandra in covering many levels of consistency ranging from strong to eventual. One level, Session level consistency, seems both unique to Cosmos and valuable. It ensures you are always able to read your writes in the same session without impacting performance as much as higher consistency levels can. This makes Cosmos DB pretty unique if you to fine-tune consistency for globally distributed applications.

Cosmos DB vs Dynamo DB Costs

Again, using some back-of-the-napkin math, DynamoDB in provisioned Mode is more cost-effective than Cosmos DB for the same workload with 10 kb document sizes, but the numbers could swing the other way based on your use case. This is with estimating 500 reads / second ( 400 point reads or get-time, 100 more complex queries) and 50 writes.

Service	Workload (500 reads/sec, 50 writes/sec)	3 KB Document Size	10 KB Document Size	Key Difference
DynamoDB	500 reads/sec, 50 writes/sec	$137.67/month	$54.84/month
Cosmos DB	500 reads/sec, 50 writes/sec	$227.28/month	$212.92/month

Tangent: Azure Table Storage vs. Cosmos DB

Cosmos DB also has a Azure Table API and marketing material saying it’s a better choice than Azure Table Storage. My take is Azure Table and Cosmos DB’s Table API both provide key-value storage with distinct trade-offs. Azure Table Storage is cost-effective and ideal for simpler, predictable workloads, requiring minimal complexity. Cosmos DB’s Table API adds flexibility, optional global distribution, and tunable consistency, but also brings more complexity and cost.

While both offer similar functionality, Cosmos DB’s advanced features will cost you. If you know you aren’t going to need scale read and writes or need multi-region writes or other features, Azure Table Storage’s simpler, predictable pricing is the way to go.

When Cosmos DB Makes Sense

OK, I think all these comparisons give us a solid grounding to talk about trade-offs. So, with all this in mind, when should you use Cosmos DB?

Document Database with Global Distribution: Cosmos DB is a strong choice if you need a document database that supports global distribution with multiple consistency models. Its automatic scaling and geo-replication mean you can reach a global audience and a high level of throughput with minimal operational overhead.
Hands-Off Scalability: This came up again and again. When you want to focus more on development and less on database administration, Cosmos DB offers hands-off scalability. It automatically handles partitioning, indexing, and replication, which is great for teams that prefer highly managed services.
Schema Flexibility: When your data structure is not fixed and might evolve over time, Cosmos DB’s schema-less nature is an advantage. This flexibility is helpful in cases where your application data needs to adapt frequently without the constraints of a rigid schema. Also, there is a taste aspect to this. While I like schemas and structure, some teams have extensive experience working with document-based NoSQL solutions, and they will find CosmosDB a great fit.

When to Avoid Cosmos DB

Cost Sensitivity: Cosmos DB can be expensive, when you start working multi-region or start writing a lot of data per partition. If cost is a primary concern, especially for smaller projects, it might be better to consider alternatives.
Complex Joins and Transactions: If your application requires complex joins, foreign key relationships, or cross-partition transactions, Cosmos DB might not be the best fit. A relational database like PostgreSQL or SQL Server would serve these requirements more effectively.
Predictable Workloads with Lower Complexity: For applications that have predictable workloads and do not need the complexity of multi-region consistency or scaling to varying demand levels, a simpler solution like a traditional relational database might be more cost-effective and easier to manage.
Need for Strong Schema Enforcement: Long-term, there is a lot to be said for having a scheme and an easy way to evolve your data. If your application benefits from strict schema enforcement to ensure data integrity and reduce developer errors, a relational database like PostgreSQL or SQL Server will be a better choice than Cosmos DB. Cosmos DB’s schema-less nature can introduce challenges if your data model needs strict consistency and structure.
Avoiding Vendor Lock-In: If you want to maintain portability and avoid vendor lock-in, Cosmos DB might not be ideal for you. A highly managed database service, whether CosmosDB, Dynamo, or Spanner, will be hard to replace on another cloud vendor. A more portable database like PostgreSQL or Cassandra might be preferable for multi-cloud or cloud-agnostic strategies.

More Reasons for Cosmos DB ( Update )

Since this article came out, I’ve had a chance to talk to several Cosmos DB users inside and outside Microsoft. I spoke with Mark Brown on the Cosmos DB team, and he highlighted two additional reasons why teams choose Cosmos DB, that I had originally under emphasized:

High Availability: Cosmos DB is designed for mission-critical applications requiring always-on availability. It’s the only Azure database with five 9s availability and active-active multi-region writes. This high availability is why services like Azure Active Directory and Teams use it.
Guaranteed Low Latency: Cosmos DB offers SLAs on read and write latency (<10ms P99), a guarantee few other databases can match. This speed is achieved by co-locating compute and storage on the same cluster, minimizing data access times.

Managing Database Infrastructure with Pulumi

Whether you choose Cosmos DB, PostgreSQL, or Azure Table Storage Pulumi simplifies the process of provisioning and managing database infrastructure on Azure. With infrastructure as code in your favorite programming languages, you can define, deploy, and maintain your entire database infrastructure using familiar development practices. Pulumi’s Azure Native provider helps you implement the right database solution for your specific needs.

With Pulumi, you get:

Rich Azure database provisioning capabilities for Cosmos DB, PostgreSQL, and Azure SQL
Automated configuration management to handle connection strings and secrets securely
Infrastructure testing capabilities to validate your database configuration before deployment
Stack references for managing multiple database environments
Custom components for creating reusable database infrastructure patterns

Ready to streamline your database infrastructure management?

Try Pulumi for Free

Summary

If you need something that is document-based, scales globally, and handles different consistency levels well, Cosmos DB could be a great choice - especially if you’re already using Azure. Azure takes it seriously - it’s in every data center they have, and they treat it as mission-critical. But here’s the thing - while it’s easier to manage than the alternatives we looked at, you’ll pay more for that convenience.

Many times, that cost is not the variable being optimized for. Data is paramount, and Cosmos DB works well for many. James Thurley, Co-founder of Canopy Simulations, found it a perfect fit for their needs:

We’ve been using Cosmos DB as a document database since it was called DocumentDB, and it’s been fast, reliable, and straightforward for our needs. We store large, arbitrarily structured JSON documents, and Cosmos DB’s full indexing has handled that effortlessly. For us, the simplicity works—we don’t need to scale to millions of users, and with auto-scaling, each customer’s database runs smoothly without any partitioning.

For help provisioning Cosmos DB, check out our Azure Cosmos DB How to guide and if you decide to go with Azure Tables instead, our Azure Native provider is there to help you all the same.

And if you have a Cosmos DB experience to share ( or I got something wrong ): reach out. And, if you haven’t already, give Pulumi IaC a try:

Get Started with Pulumi

Use Pulumi's open-source SDK to create, deploy, and manage infrastructure on any cloud.

How Secrets Sprawl is Slowing You Down—And What to Do About It.

Engin Diri — Mon, 28 Oct 2024 12:40:10 +0200

Only a few things are certain in the lives of developers and DevOps engineers: taxes, yearly performance reviews, and secret sprawl. While the first two are inevitable, the last one is something that can be managed.

As we keep adding new cloud resources and releasing new applications, the number of secrets we need to manage keeps growing: passwords, API keys, certificates, and more. And as if this isn’t enough, we need to manage secrets across different systems and environments with different teams that need to access them; we end up with duplicates.

Let’s have a look at a typical environment and see what teams use: Everything container-related may use Docker secrets or Kubernetes secrets. There is also a high chance that they might use cloud-specific secrets managers like Azure Key Vault, AWS Secrets Manager, or Google Secret Manager. In addition to these, there is a high chance that they might use HashiCorp Vault or some enterprise-grade secrets manager like CyberArk.

There are still a lot of organizations that store their secrets (like the API key for a cloud service) in environment variables to configure their applications on virtual machines, containers, or serverless functions. And as if that weren’t risky enough, some developers still hardcode sensitive information in their application code. Or use plain unencrypted text files such as .env files and share them inside the team. To be fair, this is not something that is done on purpose, and most teams realize the risks of these practices. But the problem is that they have not found a better way to manage their secrets that won’t slow them down and impact their productivity.

As the IT infrastructure grows, it becomes increasingly challenging for organizations to secure, organize, and distribute their secrets. This is where secrets sprawl comes into play. Secrets sprawl is the uncontrolled and unmanaged distribution of secrets across different systems and environments.

Modern architectures are adding to the problem of secret sprawl as modern applications are more distributed and consist of smaller building blocks with a growing number of different technologies.

While teams are ensuring that each of their applications has everything it needs to run, it’s also easy for them to lose track of the secrets they are using. Everything can be fine until they need to rotate a secret or revoke a compromised one. Then they need to go through all the systems and environments to find and update the secret. Tracking down all the places where a secret is used can be a time-consuming and error-prone process with a high risk of missing some places.

So what are some of the pain points of secret sprawl, and how can we overcome them to regain our productivity?

Pain Points of Secrets Sprawl

With secrets sprawled all across our teams (development and operations) and infrastructure, we face several points:

It is challenging to keep track of all the secrets and where they are used. When we need, for example, to find a specific secret, we need to go through different secret managers, code, and, in the worst case, the local files of one of the developers.

Do we need to rotate a secret? Now we need to go through all the systems and environments to find and update every duplicated secret.
Security risk is another pain point to mention. When a secret is spread throughout the organization, it’s hard to manage access control and enforce specific access policies.

Security best practices also recommend that secrets should be rotated regularly. But with secrets sprawled all over the place, it makes it a lot of work to rotate them. Time we could spend on more important tasks like developing new features.
Secrets sprawl makes it extremely challenging to distribute secrets. Having a secret, for example, in a cloud provider’s secret manager is cool and great, but what if we need to use it in a Kubernetes cluster? What is the process for that?

Also, having secrets in multiple places means there are different owners for them. These secrets are now some kind of gatekeeping by the team that owns them. This makes it hard for other teams to access them when they need them. And even if they get access, they will then be mostly shared in plain text as the other team does not have access to the secret manager itself.

As we can see, secret sprawl is a real problem that can slow down our teams and impact our productivity. But it also affects how fast an organization can scale its development and operations teams.

With an “organic” way of managing secrets and no real transparency, it’s hard to keep up with the pace of the business, and secret sprawl becomes a major bottleneck. Additionally, that growth means a whole bunch of new secrets that need to be managed.

Rinse and repeat.

But behold, there is a solution to this problem. And it’s called centralized secrets management.

Centralized Secrets Management against Secrets Sprawl

The cure for secrets sprawl is centralized secrets management. When you centralize your secrets in one place, you know where they are and who has access to them.

This makes it easier to manage access control and enforce specific access policies. It also makes it easier to rotate secrets as you only need to do it in one place.

Have a look at an example scaling of an organization or team:

When the company is small, the team decides to use Kubernetes to deploy their applications, and they store their secrets in Kubernetes secrets. This first step is already a centralization of secrets as it tightens access to the secrets and makes it easier to audit them. Maintaining an encrypted secrets store and centralizing the secrets in one place is a good start and ensures the organization is following a consistent threat protection policy.

As the company grows, one DevOps engineer is responsible for multiple Kubernetes clusters. In these cases, individual users can’t enforce their own application-wide policies, meaning secrets are better managed and controlled.

But what if the company grows even more and the team decides to use multiple cloud providers? There are many reasons for this, like costs, different service offerings, and better disaster recovery when using multiple cloud providers.

Sticking to the built-in secrets managers of the cloud providers is not a good idea as it will lead to secrets sprawl.

You might also like:

Why Pulumi ESC is the right choice for centralized multi-cloud secrets management

Pulumi ESC is the right choice for centralized multi-cloud capable secrets management as it reduces secrets sprawl by centralizing secrets storage with a lot of integrations for a wide range of platforms.

Pulumi ESC delivers a seamless integration so you can still use your existing secrets managers like Azure Key Vault, AWS Secrets Manager, Google Secret Manager, or HashiCorp Vault. Secrets are automatically synced to Pulumi ESC, saving developers a lot of time so they can focus on their main tasks like developing and building new products and features.

Pulumi ESC is a completely managed service that again saves time and resources for the organization as they don’t need to worry about the infrastructure, maintenance, and support of their self-hosted secrets manager.

Wrapping Up

Every organization faces the risk of secrets sprawl as they grow and add more cloud resources and applications, which they may not even be aware of.

Multi-cloud scenarios make it even more challenging to manage secrets across different systems and environments.

As teams have to juggle between delivering and building new products and features, managing secrets in a secure and efficient way becomes a major bottleneck on productivity and a major security risk. A ticking time bomb that can explode at any time.

Secrets managers can help you reduce secrets sprawl by centralizing secrets storage and providing a seamless way to use, change, and distribute secrets across different systems and environments. Independent of the size of your organization, a startup or a large enterprise, it’s never too late to start managing your secrets in a secure and efficient way.

Pulumi ESC is on the way to becoming the best choice to solve the problem of secrets sprawl. Making both developers and security teams happy by providing a secure and efficient way to manage secrets across different systems and environments.

Start using Pulumi ESC and ESO today by creating an account on the Pulumi Cloud Console and begin managing your secrets in a secure and efficient way.

Create an Account

Accelerate, Scale and Secure AI Innovation with Pulumi Platform Engineering

Marlowe Fenne — Tue, 01 Oct 2024 00:00:00 +0000

Note: This post discusses Pulumi Copilot, which Pulumi Neo has replaced. Learn about Neo →

As leadership teams continue to bet big on AI, the tradeoffs between how much to invest and when to expect a reasonable return are ever-present. While exploring scenarios for accelerating this return on investment, organizations are discovering some unique ways to accelerate their AI payback with Platform Engineering.

As innovation and ROI pressures mount, how are savvy tech organizations using Platform Engineering to get more competitive advantage - and perhaps a quantum leap - from their AI investments?

Changing the Rules of the AI Game

Platform Engineering is transforming how organizations automate, secure and manage their resources - particularly in AI environments that require substantial compute, memory and cloud infrastructure.

Save Money on Resources

AI’s wide array of disparate technology resources make it an ideal use case for Platform Engineering. Cloud innovators are unifying AI layers, including web frameworks, LLMs, containers, databases, secrets, policies, and configurations, into streamlined Python libraries. Then they leverage these libraries to efficiently manage infrastructure stacks through code.

For example, platform teams can now manage Google Dialogflow, LangChain Llama and other stacks using one platform, and then repurpose these unified resources across projects. Plus, they can author infrastructure as code, using programming languages they know and love, and write statements to define infrastructure using their own IDE’s, with autocomplete, type checking, and documentation. These teams deliver higher quality projects with fewer errors (and better testing), and are frequently happier, more productive, and more innovative.

With this “work smarter, not harder” approach, there’s also less work, as there’s a lot less code required to run infrastructure. In many cases, code can be consolidated by 50% or more, and it can be leveraged across entire organizations without tedious, error-prone copying and pasting.

All these efficiencies combine to reduce cloud, compute and storage costs, so you can re-invest the savings into more AI innovation and/or more scale across your organization.

Accelerate Time to Market

While speed is a byproduct of these efficiencies, it’s also a key reason to leverage platform engineering for AI. The most recognizable names in the AI industry have many attributes in common, including innovation and speed to market. Many of these leaders leverage Pulumi to achieve this decisive advantage.

Snowflake is a great example of this approach. “There’s no question that, if we had gone down the traditional infrastructure automation route, it would have taken us a week or a week and a half to do one deployment of the cluster, end to end,” said Raman Hariharan, Director of Cloud Platform Engineering. “Plus, that deployment wouldn’t be repeatable, testable or scalable. It would have been a mad scramble to meet our deadline. When we demonstrated to people that what used to take a week and a half now, with [platform engineering], took under a day, they were shocked.” Read the full Snowflake case study here.

Pulumi customers regularly rave about their results with platform engineering - many citing 5 to 10X faster time to market. See more case studies here.

Another benefit: more freedom to innovate with more resources

This speed and efficiency also frees up valuable time for engineering staff to work on the creative new projects that drive innovation and new revenue generating applications. By combining generative AI with Pulumi’s insights and knowledge of your entire cloud infrastructure, users are solving a wide array of next-generation cloud development challenges.

Joren McReynolds, VP of Engineering at Panther Labs said, “We are now in the best position to deliver new innovative solutions to our customers and to do so quickly, which is huge for a startup such as ours that needs to accelerate our efforts and to do so efficiently and seamlessly.”

To make this process even more efficient, a new AI-driven conversational chat interface called Pulumi Copilot is now integrated throughout Pulumi Cloud, enabling users to quickly accomplish a variety of cloud infrastructure management tasks by leveraging the power of large language models plus the rich capabilities of Pulumi Cloud.

“At Unity Aura we manage hundreds of infrastructure updates per day,” said Eilon Ashkenazi, DevOps Engineer at Unity Aura. “With Pulumi Copilot we can improve the development process for the team by delivering working reference examples faster and discovery of resources to identify and update infrastructure in production.”

Dramatically Improve AI Security

Whether it’s cloud settings, API keys, database credentials or VM passwords, AI environments hold a wide variety of secrets, increasing risk, outages, errors and operational friction. Now you can centralize and secure your secrets management using platform engineering best practices within Pulumi. Easily access, share, and manage environments, secrets, and configurations securely on any cloud using your favorite programming languages. Pull and sync with any secrets store, and consume in any application, tool, or CI/CD platform.

Many industry-leading AI technology providers such as Snowflake have already based some of their competitive differentiation on Pulumi’s unique value. More waves of large organizations are following this example as they navigate their journeys to AI time to market and return on investment.

Learn more about how Pulumi and Platform Engineering can help your organization in the same way it helped Snowflake speed up its deployment by 10x. Or take a look at how Aptos Labs achieved 10x faster development cycles.

If you are ready to talk to an expert about how platform engineering can help your organization, click here. For practitioners on your team, here are some events and learning assets to get up to speed quickly on platform engineering and infrastructure as code.

Accelerate Revenue Growth and Time to Market with Platform Engineering

Marlowe Fenne — Wed, 04 Sep 2024 00:00:00 +0000

With 62% of large organizations already using multi-cloud (Cloud Computing News), business leaders are looking for their next competitive advantage. Finding these next-gen business edges can be a real challenge, but some innovative organizations are discovering that time to market can be a big competitive lever. They are accelerating their development cycles by up to 70% and seizing opportunities to build new markets, establish new brands and capture market share. This Time To Market (TTM) advantage can apply to entire markets as well as any aspect of your product or service connected to the cloud.

Gaining these big advantages means solving some big challenges. In most cases, development cycles are expanding as software gets more complex. “It’s a study in entropy, and it is not getting any more simple,” said “DevOps for Dummies” author Emily Freeman (SiliconAngle). Factor in multi-cloud infrastructure factors such as different programming languages (C#, Python, Java, .NET, GO, YAML), policies and authentication, and the magnitude of these challenges becomes very real.

Underpinning these challenges are how organizations approach their software development lifecycle (SDLC), multi-cloud infrastructure, security policies and more. Collectively, these factors dramatically affect time to market and how companies handle all of the preceding laundry list of challenges around the complexity of cloud deployments. When organizations evolve their processes and business models toward faster, smarter, more streamlined release cycles, they gain TTM advantage and that profound business edge over competitors.

So, how are these organizations getting there?

More speed and scale with Platform Engineering

Platform Engineering is becoming a business essential for cloud-first companies: “The Platform engineering team typically sits between operations and more IT-centric folks and developers, and their goals are to be a center of excellence, establish best practices, put in place the systems that enable the organization to scale, and ultimately empower the rest of the organization to ship faster with confidence, compliance, cost control - all the things necessary for a modern enterprise to go to the cloud,” said Joe Duffy, CEO and Founder of Pulumi.

Good platform engineering is a method of handling all platform deployments, rollbacks, load balancing and operations in a consistent, centralized manner that is programmatic and can be controlled and directed by the engineering organization. A robust platform engineering solution helps the organization to solve its complex cloud issues, including those around deployment, testing, policy and security. Great platform engineering becomes a secret weapon that some cloud-first organizations are using to outmaneuver and disrupt their competitors.

When DevOps, infrastructure and product delivery teams are working together in one seamless platform - using their favorite languages across all their stacks, they’re faster, happier, and more productive, which means faster development cycles and faster TTM. They deliver new features, new services and new products more quickly than competitors, and adjust and make needed changes faster, adapting to market changes and conditions more quickly.

Aptos Labs is a blockchain and Web3 technology leader that’s leveraged this approach very well. “Switching to Pulumi for our IaC needs helped us massively accelerate development velocity, while upgrading the security, compliance, and cost control policies,” said Christian Thielemann, Software Engineer.

As more organizations recognize its business transformation value, platform engineering is becoming a strategic differentiator. For example 4IR, a technology provider for manufacturing and IOT industries, said, “[platform engineering] has emerged as a key element in our strategy, creating tangible value for us by reducing infrastructure deployment time, up-skilling our team, and accelerating our time to market.”

How Platform Engineering delivers business value

Platform engineering allows organizations to improve productivity by removing bottlenecks around configuring cloud architectures, provisioning, testing and deployment. It improves security and compliance by setting up guardrails to enforce policy and security, preventing costly issues that can significantly delay or stop product deployment. By automating these necessary parts of cloud deployment, and enabling control and the ability to deliver consistency and repeatability, platform engineering makes your platform team and development teams faster, more efficient and improves their ability to work together.

Platform engineering tools deliver the ability for your platform team to program and control all aspects of the platform on which your software will run. You can manage deployment, scaling, provisioning, testing and more using code that you control and can manage and improve. That means predictability and the ability to fine control all of your platforms. The better platform engineering tools work with a range of cloud platforms and can be integrated into your existing toolset very easily.

All of these specific advantages mean that platform engineering delivers profound improvements in deployment times, testing times and provisioning leading to reductions of 70% or more in time to market. Snowflake, one of the largest cloud data warehouses, used by a large percentage of the Fortune 500, saw an improvement in deployment time from one and a half weeks to less than a day.

Effectively, platform engineering does the following things to deliver faster time to market and faster revenue growth:

Solves a whole set of TTM issues and problems
Simultaneous benefits to DevOps, engineering and the business
Faster development cycles
Reduces cloud complexity and cost and inefficiency
Better adherence to policy and security

Platform engineering results also vary widely by company due to multiple factors. While 75% of participants in a recent Gartner survey said their organizations had adopted platform engineering, only 44% had formalized their approach. Plus, some solutions are more agile and flexible than others. “When we did it with Terraform, it took two weeks to do [infrastructure deployments]. Now we do it in about three hours a day. So that’s how much of an improvement Pulumi gave us on our deployment time,” said Matt Stephenson, Senior Principal Software Engineer at Starburst Data.

To find out more about how platform engineering can help you, take a look at these case studies:

Aptos Labs uses Pulumi to transform development, increasing velocity by up to 10x while improving security, compliance, and cost control.
4IR uses Pulumi to reduce infrastructure deployment times, up-skill its team, and accelerate time to market.
Starburst Data uses Pulumi to reduce infrastructure deployments from 2 weeks to just 3 hours.

If you are ready to talk to an expert about how platform engineering can help your organization, click here.

Why Switch to Pulumi for Infrastructure as Code?

Aaron Kao — Tue, 23 Jul 2024 19:47:50 -0700

Note: This post discusses Pulumi Copilot, which Pulumi Neo has replaced. Learn about Neo →

The cloud promised to revolutionize your business.

Faster innovation. Lower costs. Unlimited scalability.

But for many companies, that promise remains frustratingly out of reach. Instead of accelerating product development, infrastructure has become a bottleneck. You and your team (DevOps, platform, or infrastructure engineering teams) are bogged down by:

Clunky tools and manual processes
Provisioning a simple test environment takes days
Rolling out updates across regions takes weeks
The combinations of modern cloud architectures seems infinite

You know there has to be a better way. A way to truly harness the power of the cloud and turn it into your competitive advantage.

But how?

Enter Pulumi – the open source infrastructure as code (IaC) platform that gives 10x better scale, productivity, and time to value for thousands of companies worldwide.

So why should you switch to Pulumi? How is it different from other infrastructure as code tools? This post should answer all those questions.

What is Pulumi?

Pulumi is an infrastructure as code platform that allows you to manage and scale infrastructure, configurations, policies, and secrets with programming languages. Pulumi facilitates clear collaboration across your infrastructure, development, and security teams.

Pulumi’s approach is better.

10x Better. Pulumi takes a unique and 10x better approach to infrastructure as code by empowering you with the familiar languages and tools you love for application development. While modern programming languages have evolved to provide powerful features like AI copilots, Intellisense, linting tools, testing frameworks, and CICD pipelines, infrastructure management has lagged behind, relying on rigid scripting languages and error-prone manual processes. Pulumi bridges this gap by allowing you to use industry-standard programming languages to manage infrastructure with the same level of sophistication and tooling you enjoy for application development. Pulumi embraces the change and direction the industry is going, so you never fall behind with your IaC tooling.

Powering the Next Wave. Pulumi is at the forefront of the industry. It helps you embrace the latest practices (e.g., Platform Engineering, GitOps) and builds the latest technologies (e.g., AI Copilots) into the core user experience. It also helps you build and manage new technology paradigms (e.g., AI workloads, LLMs, internal developer platforms).

Powerful Automations. Another unique approach is that Pulumi makes it easy to automate and scale modern cloud architectures. In the last decade, the industry has moved from monolithic to microservices architectures, which operate as distributed systems over shared infrastructure platforms, to achieve greater resilience, team agility, flexible scaling, and modular codebases. The cloud's programmability, infinite elasticity, and on-demand nature made it easy to spin up micro-sized services tailored to business demands, facilitated by technologies like containers, Kubernetes, and serverless. Pulumi empowers you to apply software engineering to manage infrastructure of this modern and immense scale.

AI-Powered. Pulumi builds AI into the core infrastructure management experience. Pulumi combines the power of large language models with semantic understanding of the cloud to unlock greater insights and controls over managing cloud infrastructure. Pulumi leverages the familiar GPT experience you know, love, and use daily, so you can find and take action on any resource in your cloud environments.

Ok, but why does this matter enough for me to switch?

Only you can answer that question, but there are some compelling reasons to adopt the platform trusted by hundreds of thousands of developers.

Faster Time to Value. Your company moved to the cloud to increase innovation and reduce costs. However, getting infrastructure to developers is a frequent bottleneck for you which can slow down prototyping new products or shipping new features. Spinning up new development or testing environments takes days and rolling out production updates across many regions can take weeks. The existing tools don’t allow you to set security and compliance guardrails and enable easy self-service of infrastructure.

Pulumi will speed up your deployments and time to value.

Open Platform Commitment. Some platforms, such as Terraform, have altered their licensing and introduced uncertainty. They are no longer true open source, and they tie their previously open source software to their commercial services. The lack of an open source approach fragments the community and introduces proprietary constraints to cloud infrastructure.

Pulumi provides you with an approach to open source and community that provides stability and choice.

Increased Productivity. You expect your tools and workflows to keep up with the industry: AI copilots, Intellisense, linting tools, testing frameworks, and CICD pipelines. But most of these innovations are just for building applications and services and not for infrastructure, configurations, policies, and secrets. Existing infrastructure tools are fraught with bad UX, rigid scripting languages, and error prone manual processes.

Pulumi will increase your productivity and velocity through better tooling.

Infinite Scale. Modern cloud architectures are distributed systems that are microservices that are dynamic and ephemeral in nature. The number of infrastructure resource types and the configurable input properties is staggering. You face the daunting task of how to combine these resources to solve their unique problems. Without software engineering, managing these modern distributed systems is fruitlessly manual.

Pulumi uses software engineering to tackle the scale of infinite combinations.

Customers of Pulumi frequently experience 100% productivity increases, 99% time saved, and 10x acceleration when using Pulumi compared to what they were using before.

Frequently Asked Questions - Why Pulumi?

Here are some frequently asked questions about why you should choose Pulumi based on the following use cases and alternatives:

Why Pulumi, by use case?
- Why Pulumi for Internal Developer Platforms?
- Why Pulumi for AI Workloads?
Why is Pulumi better than the alternatives?
How can I switch to Pulumi?

Why Pulumi, by use case?

There are many different use cases for why you might use Pulumi: infrastructure CICD, modern applications, internal developer platforms, AI/ML workloads, and infrastructure modernization. Below are more details on two popular use cases.

Why Pulumi for Internal Developer Platforms?

You and your team may build internal developer platforms (IDPs) to maximize the use of the cloud at scale across the company while being secure and compliant, so your development teams can ship faster. There are a number of components/layers that are considered basic requirements when building an internal developer platform. The layers are as follows:

Developer Control Plane. Curated experiences that empower developers by meeting them at their level of expertise, whether it's an abstracted developer portal, custom CLI, or shared IaC templates.
Integration & Delivery. Automations to version control, test, trace, and deploy all infrastructure from resources, configurations, environments, and secrets as well as orchestration automations to manage provisioning workflows.
Monitoring & Logging. Components to log, monitor, and observe all infrastructure for greater operational control as well as optimize against unnecessary costs.
Security & Identity. Security and compliance guardrails that regulate every piece of infrastructure from policies to fine-grained access controls to secrets.
Resources. Providers that support modern cloud architectures such as Kubernetes, containers, serverless, generative AI, machine learning, data lakes, hybrid cloud/on-premises, and more.

This diagram illustrates the different layers of an internal developer platform:

Most solutions struggle to keep up with the requirements of each layer. Many of the alternative solutions can’t handle the scale of resources you need to manage, find it difficult to tie infrastructure automation directly into your core business, have leaky secrets, and enforce compliance and security incompletely.

Pulumi is a platform engineering solution that enables you to build a bridge to your developers and empower them to leverage the cloud with security, scalability, repeatability, and consistency. It provides the building blocks for each of the five layers.

Developer Control Plane. Pulumi is the simplest and most intuitive way to manage cloud infrastructure because of its ability to use standard programming languages, including YAML. This removes the friction to the basic requirements of managing cloud infrastructure well. Pulumi Automation API makes it simple to code any user interface for a developer portal / CLI. Pulumi also provides private templates that integrate with developer portals like AWS Proton and Backstage.
Integration & Delivery. Pulumi Automation API can embed IaC programs directly in applications, resulting in 10x greater management of resources per engineer. Pulumi can take advantage of all existing testing frameworks supported by the selected programming language.
Monitoring & Logging. Pulumi Insights adds advanced search, analytics, and AI to any cloud infrastructure, giving unique insights into cloud usage and cost optimizations. Pulumi partners with leading observability solutions making it easy to manage monitoring and logging resources through IaC.
Security & Identity. Pulumi CrossGuard provides policy as code with auto-remediation. Pulumi ESC makes it easy to manage secrets and configurations for every environment. Access to each cloud resource and secret can be granularly controlled and audited.
Resources. Pulumi supports modern cloud architectures such as Kubernetes, containers, serverless, generative AI, machine learning, data lakes, hybrid cloud/on-premises, and more. Pulumi makes it simple to create components that abstract away the complexity of managing thousands of resources across hundreds of distinct clouds.

Pulumi is purpose built to make all aspects of platform engineering vastly simpler.

Why Pulumi for AI Workloads?

Your company may be using AI to increase innovation and reduce costs. AI gives them the ability to design richer and more intuitive interfaces for their products and/or services to connect better with their customers. The hardest part of AI is at times not the AI pieces but the cloud infrastructure parts: how to provision and manage the infrastructure that AI workloads run on (e.g., compute and networking) and depend on (e.g., databases and storage).

There are many layers to building and managing AI applications: model training, data pipelines, backend services, frontend applications.

Pulumi provides an abstraction across all the different layers of the AI stack (web framework, LLM, containers, databases, secrets, policies, configurations, etc) as a simple Python library. Through this abstraction you can manage stacks of AI infrastructure as code.

Pulumi makes it trivial to take local AI development to production in the cloud.

Why is Pulumi better than the alternatives?

There are many different tools you can use to manage infrastructure. However, Pulumi provides you with a more productive authoring experience and more powerful automations that will allow you to ship faster and manage the infinite scale of cloud infrastructure. Read on for how Pulumi compares to specific options: clickops, Terraform, CDK, and IDP services.

Why Pulumi vs. clickops?

Manually provisioning and managing infrastructure for production via the cloud console (i.e., clickops) is a bad idea. There isn’t repeatability or consistency which leads to errors, and that can lead to downtime or worse, security breaches. That is why infrastructure as code was invented as a way to have a single source of truth for all infrastructure with changes 100% automated.

If you don’t believe this, just ask any cloud or devops subreddit, Slack group, or Discord server.

Why Pulumi vs. Terraform?

Pulumi and Terraform are both infrastructure as code (IaC) platforms, however they have fundamental differences in how they approach your needs of infrastructure management. First, here are the similarities.

Both Pulumi and Terraform include the ability to create, deploy, and manage infrastructure as code on any cloud. Both Terraform and Pulumi follow a desired state infrastructure as code model, where the IaC code represents the desired state of the infrastructure. The deployment engine compares this desired state with the current state of the stack and determines the necessary actions, such as creating, updating, or deleting resources. Both Terraform and Pulumi support many cloud providers, including AWS, Azure, and Google Cloud, plus other services like CloudFlare, Digital Ocean, and more.

However, beyond the basics of infrastructure as code there are significant differences that affect productivity, scalability, and collaboration.

Increased Productivity. As discussed at the beginning, Pulumi’s promise is to build in all the latest advancements in both the developer and operations experience. When you write Pulumi code, you now have AI copilots that can pair program with you, IDEs that have autocompletion and Intellisense squiggles, powerful libraries of low level and abstract functions, testing frameworks, code review tools, automated release controls via CICD pipelines, and great software packaging tools. When it comes to managing infrastructure with Pulumi, you also have Pulumi Copilot which combines the best generative AI models available in the industry today with access to your data and actions within Pulumi Cloud. Pulumi Copilot incorporates the context of where you are in the Pulumi Cloud console to easily answer questions about “this stack” or “the latest update” as well as automating cloud tasks. Terraform, on the other hand, has built a proprietary ecosystem that doesn’t tap into the latest advancements of how code is written or how infrastructure is managed.
Greater Scalability. Pulumi embraces software engineering as a way to solve and manage the exponentially increasing complexity of modern architectures. Programming languages with their loops, conditional logic, class inheritance, object orientedness allows engineers to design more complex and sophisticated infrastructure compared to using HCL. Pulumi also allows you to build custom workflows atop infrastructure programs, giving rise to event-driven automations or internal developer portals that provide self-service.
Better Collaboration. Pulumi makes it easy to prototype new products and quickly ship them into production because it is easier for the platform, development, and security teams to collaborate. You (platform engineering and devops teams) can define and manage common infrastructure across the company, work with the security teams to set security and compliance guardrails, and enable easy self-service of infrastructure whether through custom developer platforms or shared infrastructure libraries. To define common company-wide components, if you don’t want to program can use use YAML; if you do, you can use Python, TypeScript, Golang, C#, etc. These components can be consumed by the development team in their own IaC program in any programming language with the development tools they already know. It's easy to start with YAML and move to other languages when more power is desired. With Terraform, you must understand and use HCL. It is difficult to build self-service infrastructure platforms because it lacks the programmability and ability to apply software engineering. It's just harder to bring together platform, development, and security teams and empower them with tools that work. Whereas Pulumi unblocks infrastructure as the bottleneck for software delivery.

Why Pulumi vs. AWS Cloud Development Kit (CDK)?

Pulumi and CDK are similar in that both allow you to use programming languages to write infrastructure as code. However, there are some key differences:

No Vendor Lock-In. CDK supports only AWS, whereas Pulumi supports over 150 cloud and SaaS providers, with more being added all the time. CDK depends on CloudFormation as the deployment engine; it shares many of the same benefits and limitations as CloudFormation (see Pulumi vs. CloudFormation)
Execution > Translation. Pulumi and CDK support similar programming languages but differ fundamentally in their deployment approaches. Pulumi's engine directly understands these languages and communicates with cloud providers. In contrast, CDK transpiles code into AWS Cloud Assembly, an intermediate format consisting of CloudFormation templates and other assets, before deployment via CloudFormation. This difference impacts your development speed and correctness. CDK's approach can lead to slower deployments and delayed error discovery, potentially hours into the process since the errors aren’t caught during compile time. Additionally, you need expertise in both CloudFormation and CDK for effective debugging and successful deployments, whereas Pulumi's direct approach simplifies this process.
Versatility. CDK and Pulumi both support automated testing, but Pulumi offers more versatile options. While both allow unit testing, Pulumi's deep integration between language and runtime enables fast, offline tests (in-memory) with mocked cloud provider calls. In contrast, CDK only permits assertions against synthesized CloudFormation templates and lacks offline testing capabilities. This makes Pulumi's testing approach more comprehensive and flexible than CDK's.

Why Pulumi vs. 3rd party internal developer portal providers?

There are many third party providers of internal developer portals (think Port, Cortex, Backstage). Some are services and others are open source software. These providers are similar in that they offer simple developer portals that are a single part of a greater infrastructure management platform.

As discussed earlier, internal developer platforms have five layers: developer control plane, integration & delivery, monitoring & logging, resources management, and security & identity. Most of these providers offer easy to use GUI consoles, simple CICD integrations, comprehensive suite of monitoring & logging, and some form of role-based access controls. However, they lack the infrastructure as code fundamentals and automation capabilities that Pulumi has, which enable you to build powerful customizations through software engineering. Many of these solutions also lack strong secrets management and policy enforcement capabilities that are critical for production and enterprise deployments.

That said, if you need an off the shelf solution, then one of these services or software might be a good choice for you. Some of these solutions can integrate with Pulumi, and if your needs become more complex, you can always switch to Pulumi later.

Have a particular Pulumi vs X comparison that you need thoughts on? Feel free to join the Pulumi Community Slack if you have quick technical questions, or talk to a Solutions Architect if you need more detailed consultation about your specific architecture.

How can I switch to Pulumi?

Switching to Pulumi doesn’t have to be intimidating. We’ve done this with thousands of customers before, and we can guide you through it.

We provide self-service conversion tools that allow you to Import infrastructure no matter how it was provisioned, click-ops included. You can also use tools to convert your HashiCorp Terraform, AWS CloudFormation, Azure Resource Manager (ARM) templates, or Kubernetes YAML.

Self-service Tool Guide

If you need help, we have a team of cloud experts who can answer your questions, give you a demo, or roll up their sleeves to get your migration done.

Contact Expert Services

We have done lots of migrations from all types of infrastructure as code tools, and we are happy to help you think through how to make switching to Pulumi as easy as possible.

Switch to Pulumi

Meta image credit: ESO/M. Kornmesser

Pulumi vs HCL: Understanding the Language Differences in Infrastructure as Code

Engin Diri — Tue, 09 Jul 2024 00:00:00 +0000

The Java Language Architect at Oracle, Brian Goetz, author of Java Concurrency in Practice, has commented how declarative languages can be a double-edged sword:

HashiCorp’s infrastructure as code solution, Terraform, uses a domain-specific language (DSL) to declare cloud resources. Pulumi’s infrastructure as code solution, on the other hand, lets you choose from any number of modern languages – C#, Java, JavaScript, Go, Python, or TypeScript – or the industry-standard markup language YAML, to declare cloud resources. Although both Terraform and Pulumi are declarative infrastructure as code engines at their core, this fundamentally different approach to expression languages has significant consequences.

Real-World Consequences

We’ve worked with 1,000s of companies and 100,000+ developers and infrastructure experts alike to adopt infrastructure as code using Pulumi and modern languages, and we see several significant recurring themes as they migrate away from Terraform and HCL.

Tapping Into Millions of Developers

Pulumi allows developers to use widely-adopted general-purpose languages for infrastructure as code. This approach taps into vast existing developer communities, with JavaScript boasting over 17 million developers, Python 15 million, and Go 3 million worldwide. By utilizing these languages, Pulumi enables teams to leverage their current programming expertise and access extensive resources, libraries, and tools. Meanwhile, HCL maintains a dedicated user base of several hundred thousand developers who appreciate its specialized syntax for infrastructure description.

Pulumi Leverages Rich Ecosystems of General-Purpose Languages

Pulumi harnesses the extensive ecosystems surrounding popular programming languages for infrastructure as code. While domain-specific languages like HCL have their strengths, Pulumi’s approach offers developers access to:

Comprehensive IDE support, including features like autocompletion, syntax highlighting, and real-time error detection, which may be more advanced than those available for specialized IaC languages
Wide array of established linting tools to enforce coding standards and catch potential issues early in the development process
Robust testing frameworks that allow for thorough verification and validation of infrastructure configurations, often more mature than those specific to IaC languages
Extensive libraries and packages that can be seamlessly integrated into infrastructure code, expanding possibilities beyond traditional IaC toolsets

This approach allows teams to utilize familiar tools and workflows, potentially increasing productivity and code quality. Developers can leverage their existing programming expertise and the vast resources available in these language communities when working on infrastructure projects, which may require less additional learning compared to adopting a specialized syntax

Pulumi Embraces Open-Source Languages and Principles

Languages like Python, JavaScript, and Go are developed and maintained by diverse global communities, ensuring transparency and collective innovation. These languages have remained open-source throughout their history, with their core components freely available for use, modification, and distribution.

In contrast, some domain-specific IaC languages have different ownership and licensing models. For example, HCL has always been under the control of a single company. Recently, there have been changes in its licensing, with parts of its execution engine moving to a “source available” license that is no longer considered fully open-source.

By using mainstream open-source languages, Pulumi offers teams the benefits of well-established ecosystems, community-driven development, and the assurance of continued open availability. This approach can provide additional confidence for organizations concerned about long-term access and evolution of their IaC tooling.

Here’s a list of languages Pulumi commonly uses, along with their licenses:

Language	License
C#	MIT (.NET Core)
Java	GNU v2.0 (OpenJDK)
JavaScript	MIT (ECMAScript), BSD-style 3-Clause (V8)
Go	BSD-style 3-Clause
Python	BSD-style Python Software Foundation
TypeScript	Apache 2.0
YAML	Creative Commons Attribution

Developers Onboard Quicker with Pulumi

While HCL serves its purpose in infrastructure as code, many developers find Pulumi’s approach more appealing. Pulumi allows engineers to use familiar programming languages, making it easier to leverage existing skills and tools.

This familiarity often leads to faster onboarding and more efficient debugging processes. Pulumi’s flexibility enables developers to create custom solutions with ease, tapping into the full power of general-purpose languages. Additionally,

Pulumi’s open architecture provides developers with the freedom to integrate various tools and services, fostering a diverse and adaptable ecosystem for infrastructure management.

Enhancing Team Collaboration With Pulumi

Pulumi offers several advantages for fostering better collaboration across teams compared to HCL. While HCL is a powerful tool primarily utilized by operations and DevOps teams, its specialized nature for infrastructure tasks might limit broader engagement with development teams who use other programming languages.

Pulumi, on the other hand, supports multiple languages, allowing development teams to use familiar tools and languages which can enhance collaboration and streamline processes. Additionally, Pulumi’s flexibility in integrating with a variety of tools can help bridge gaps between different teams, ensuring smoother communication and more effective teamwork.

This inclusive approach not only accelerates progress but also democratizes access to infrastructure management, avoiding bottlenecks and enhancing overall team efficiency.

Reducing Redundancy and Copy-Paste Challenges

HCL often encounters a significant challenge with “copy-pasta,” where developers frequently copy and paste code. This practice can lead to redundant configurations across environments, bloating the codebase and complicating management.

Additionally, this increases the risk of errors as small mistakes can propagate across multiple instances, and each one must be manually updated when changes are needed, heightening the chance for inconsistencies. As projects evolve, maintaining a codebase with extensive copy-pasta becomes burdensome, slowing development and elevating the likelihood of bugs.

In contrast, Pulumi reduces the need for such redundancies by enabling more dynamic code reuse and better resource management, streamlining updates and fostering more robust and error-resistant infrastructure development.

Reduce Need for Custom Tooling

As projects expand, managing HCL configurations becomes increasingly complex, often necessitating custom tools for efficient large-scale management. While HCL is adept at defining infrastructure as code, it lacks built-in features to orchestrate, validate, and deploy configurations across extensive networks smoothly. Teams usually need to develop bespoke tools or integrate external solutions like Terragrunt, Atlantis, and Sentinel to automate tasks, ensure consistency, and facilitate integration with other systems. This process can demand significant resources and expertise.

In contrast, Pulumi is designed to scale seamlessly with projects, reducing the need for external tools or extensive custom solutions. Pulumi provides robust capabilities for managing large-scale projects efficiently, streamlining the deployment process, and ensuring consistency across various environments without the overhead of additional tooling. This makes Pulumi a more straightforward and resource-efficient choice for teams looking to manage their infrastructure effectively as they grow.

Future-Proofing Your Infrastructure

HCL, while robust, lacks the future-proof qualities of Pulumi SDKs due to its fixed syntax and usage constraints. In contrast, Pulumi’s support for multiple programming languages like Python, TypeScript, and Go, coupled with the potential to adopt new languages over time, offers unparalleled flexibility and adaptability.

This allows developers to write infrastructure as code in familiar languages, facilitating easier integration with existing projects and workflows. As technology progresses, the capacity to embrace new programming languages and paradigms becomes essential. Pulumi’s adaptable model supports this continuous evolution, ensuring that infrastructure as code practices can keep pace with the dynamic nature of development environments and preferences, thereby offering a more sustainable and scalable solution for long-term projects.

Making Infrastructure Code Simpler

As HCL continues to evolve, its fixed syntax and structured approach are likely to lead to greater complexity. This evolution could make the language increasingly specialized and challenging for newcomers, particularly those already proficient in more widely-used programming languages. As HCL adapts more bespoke features to meet specific needs, it may become less intuitive and harder to handle effectively, potentially resulting in a language that is cumbersome to use and maintain, especially in long-term projects.

In contrast, Pulumi offers a more streamlined and adaptable alternative. Supporting multiple mainstream programming languages like Python, TypeScript, and Go, Pulumi enables developers to work with tools and languages they are already familiar with, greatly reducing the learning curve and enhancing productivity. This flexibility allows Pulumi to integrate seamlessly into existing projects and workflows, making it a more sustainable and scalable choice for modern infrastructure needs.

HCL in the Wild: Practical Comparisons With Pulumi

In this section, we’ll explore real-life examples to compare and contrast HCL with Pulumi programs. By examining how each approach handles similar infrastructure tasks, you’ll quickly appreciate the advantages of leveraging a familiar programming language through Pulumi.

This comparison aims to highlight the practical benefits and increased efficiency that Pulumi offers over traditional HCL configurations.

`for_each` Loop With Conditional Expression

First, let’s look at an HCL example featuring a for_each loop with a conditional statement. At first glance, it may seem straightforward, but we can immediately see the unique way a loop must be defined in HCL.

Initially, you must decide whether to use count or for_each. Following this, you must adhere to the strict format for implementing conditional statements.

This contrasts starkly with how you would use these constructs in a generic programming language.

variable "storage_account_names" {
 type = list(string)
 default = ["mickey", "donald", "goofy"]
}

resource "azurerm_resource_group" "example" {
 name = "storage-rg"
 location = "West Europe"
}

resource "azurerm_storage_account" "my_storage" {
 for_each = {
 for name in var.storage_account_names :
 name => name
 if name != "goofy"
 }
 name = each.value
 resource_group_name = azurerm_resource_group.example.name
 location = azurerm_resource_group.example.location
 account_tier = "Standard"
 account_replication_type = "GRS"
}

Now let’s look at how we can approach the same example using Pulumi.

const storageAccountNames: string[] = [
 "mickey",
 "donald",
 "goofy",
];
const example = new azure.core.ResourceGroup("example", {
 name: "storage-rg",
 location: "West Europe",
});

storageAccountNames.filter((name: string) => name !== "goofy").forEach((name: string) => {
 new azure.storage.Account(`my_storage-${name}`, {
 name: name,
 resourceGroupName: example.name,
 location: example.location,
 accountTier: "Standard",
 accountReplicationType: "GRS",
 });
});

import pulumi
import pulumi_azure as azure

storage_account_names = ["mickey", "donald", "goofy"]

example = azure.core.ResourceGroup(
 "example",
 name="storage-rg",
 location="West Europe"
)

for name in filter(lambda n: n != "goofy", storage_account_names):
 azure.storage.Account(
 f"my_storage-{name}",
 name=name,
 resource_group_name=example.name,
 location=example.location,
 account_tier="Standard",
 account_replication_type="GRS"
 )

package main

import (
 "github.com/pulumi/pulumi-azure/sdk/v5/go/azure/core"
 "github.com/pulumi/pulumi-azure/sdk/v5/go/azure/storage"
 "github.com/pulumi/pulumi/sdk/v3/go/pulumi"
)

func main() {
 pulumi.Run(func(ctx *pulumi.Context) error {
 storageAccountNames := []string{"mickey", "donald", "goofy"}

 example, err := core.NewResourceGroup(ctx, "example", &core.ResourceGroupArgs{
 Name: pulumi.String("storage-rg"),
 Location: pulumi.String("West Europe"),
 })
 if err != nil {
 return err
 }

 for _, name := range storageAccountNames {
 if name != "goofy" {
 _, err := storage.NewAccount(ctx, "my_storage-"+name, &storage.AccountArgs{
 Name: pulumi.String(name),
 ResourceGroupName: example.Name,
 Location: example.Location,
 AccountTier: pulumi.String("Standard"),
 AccountReplicationType: pulumi.String("GRS"),
 })
 if err != nil {
 return err
 }
 }
 }

 return nil
 })
}

using Pulumi;
using Pulumi.Azure.Core;
using Pulumi.Azure.Storage;
using System.Collections.Generic;

class Program
{
 static Task<int> Main() => Deployment.RunAsync<MyStack>();
}

class MyStack : Stack
{
 public MyStack()
 {
 var storageAccountNames = new List<string> { "mickey", "donald", "goofy" };

 var resourceGroup = new ResourceGroup("example", new ResourceGroupArgs
 {
 Name = "storage-rg",
 Location = "West Europe",
 });

 foreach (var name in storageAccountNames)
 {
 if (name != "goofy")
 {
 var storageAccount = new Account($"my_storage-{name}", new AccountArgs
 {
 Name = name,
 ResourceGroupName = resourceGroup.Name,
 Location = resourceGroup.Location,
 AccountTier = "Standard",
 AccountReplicationType = "GRS",
 });
 }
 }
 }
}

import com.pulumi.Context;
import com.pulumi.Pulumi;
import com.pulumi.azurenative.core.ResourceGroup;
import com.pulumi.azurenative.core.ResourceGroupArgs;
import com.pulumi.azurenative.storage.Account;
import com.pulumi.azurenative.storage.AccountArgs;

import java.util.List;

public class Main {
 public static void main(String[] args) {
 Pulumi.run(Main::stack);
 }

 public static void stack(Context ctx) {
 var storageAccountNames = List.of("mickey", "donald", "goofy");

 var resourceGroup = new ResourceGroup("example", ResourceGroupArgs.builder()
 .name("storage-rg")
 .location("West Europe")
 .build());

 for (var name : storageAccountNames) {
 if (!name.equals("goofy")) {
 var storageAccount = new Account("my_storage-" + name, AccountArgs.builder()
 .name(name)
 .resourceGroupName(resourceGroup.name())
 .location(resourceGroup.location())
 .kind("StorageV2")
 .sku(AccountSkuArgs.builder()
 .name("Standard_GRS")
 .tier("Standard")
 .build())
 .build());
 }
 }
 }
}

We can see that we leverage the full potential that the generic programming language offers, using filter to streamline our array without the need for conditional statements, and then iterating through the reduced array with forEach. This approach is less error-prone, faster, and easier to debug.

However, implementing a for_each in HCL can become even more complicated.

`for_each` Loop With Multi-Level Nested Dynamic Blocks

To give you an idea of how HCL handles cascading nested dynamic providers, consider this: dynamic providers are intended to dynamically construct repeatable nested blocks. However, this complexity can make the code difficult to read and maintain. We will examine a specific resource from this GitHub repository to provide a clearer illustration:

variable "enable_auto_scaling" {
 type = bool
 default = false
 description = "Enable node pool autoscaling"
}

variable "agents_pool_kubelet_configs" {
 type = list(object({
 cpu_manager_policy = optional(string)
 cpu_cfs_quota_enabled = optional(bool, true)
 cpu_cfs_quota_period = optional(string)
 image_gc_high_threshold = optional(number)
 image_gc_low_threshold = optional(number)
 topology_manager_policy = optional(string)
 allowed_unsafe_sysctls = optional(set(string))
 container_log_max_size_mb = optional(number)
 container_log_max_line = optional(number)
 pod_max_pid = optional(number)
 }))
 default = [
 {
 cpu_manager_policy = "none"
 cpu_cfs_quota_enabled = true
 cpu_cfs_quota_period = "100ms"
 image_gc_high_threshold = 85
 image_gc_low_threshold = 65
 topology_manager_policy = "none"
 allowed_unsafe_sysctls = ["net.*", "kernel.*"]
 container_log_max_size_mb = 10
 container_log_max_line = 10
 pod_max_pid = 100
 }
 ]
 nullable = false
}

resource "azurerm_resource_group" "example" {
 name = "storage-rg"
 location = "West Europe"
}

resource "azurerm_kubernetes_cluster" "main" {
 name = "example-aks"
 location = azurerm_resource_group.example.location
 resource_group_name = azurerm_resource_group.example.name
 dns_prefix = "exampleaks"

 dynamic "default_node_pool" {
 for_each = var.enable_auto_scaling == true ? [] : ["default_node_pool_manually_scaled"]
 content {
 name = "default"
 vm_size = "Standard_DS2_v2"
 zones = [1, 2, 3]
 enable_auto_scaling = true
 min_count = 1
 max_count = 3
 dynamic "kubelet_config" {
 for_each = var.agents_pool_kubelet_configs
 content {
 allowed_unsafe_sysctls = kubelet_config.value.allowed_unsafe_sysctls
 }
 }
 }
 }
 identity {
 type = "SystemAssigned"
 }
}

As we can see, incorporating even one nested dynamic provider block can make the code difficult to read. We recommend using dynamic blocks sparingly to maintain readability and ease of maintenance, particularly when creating an abstraction with the help of a module. Overuse of these blocks, especially when defining a resource’s arguments and nested blocks directly from input variables, might not provide a useful abstraction.

Have look how this would look like when using Pulumi:

const config = new pulumi.Config();
const enableAutoScaling = config.getBoolean("enableAutoScaling") || false;

const agentsPoolKubeletConfigs = config.getObject("agentsPoolKubeletConfigs") || {
 allowedUnsafeSysctls: [
 "kernel.*",
 "net.*",
 ],
 containerLogMaxLine: 10,
 containerLogMaxSizeMb: 10,
 cpuCfsQuotaEnabled: true,
 cpuCfsQuotaPeriod: "100ms",
 cpuManagerPolicy: "none",
 imageGcHighThreshold: 85,
 imageGcLowThreshold: 65,
 podMaxPid: 100,
 topologyManagerPolicy: "none",
};
const example = new azure.core.ResourceGroup("example", {
 name: "storage-rg",
 location: "West Europe",
});

let kubeletConfigs: azure.types.input.containerservice.KubernetesClusterDefaultNodePoolKubeletConfig = agentsPoolKubeletConfigs;

let defaultNodePool: azure.types.input.containerservice.KubernetesClusterDefaultNodePool = {
 name: "default",
 vmSize: "Standard_DS2_v2",
 zones: [
 "1",
 "2",
 "3",
 ],
 enableAutoScaling: enableAutoScaling,
 minCount: 1,
 maxCount: 3,
 kubeletConfig: kubeletConfigs,
};

import pulumi
import pulumi_azure as azure

config = pulumi.Config()
enable_auto_scaling = config.get_bool("enableAutoScaling") or False

agents_pool_kubelet_configs = config.get_object("agentsPoolKubeletConfigs") or {
 "allowedUnsafeSysctls": [
 "kernel.*",
 "net.*",
 ],
 "containerLogMaxLine": 10,
 "containerLogMaxSizeMb": 10,
 "cpuCfsQuotaEnabled": True,
 "cpuCfsQuotaPeriod": "100ms",
 "cpuManagerPolicy": "none",
 "imageGcHighThreshold": 85,
 "imageGcLowThreshold": 65,
 "podMaxPid": 100,
 "topologyManagerPolicy": "none",
}

example = azure.core.ResourceGroup("example",
 name="storage-rg",
 location="West Europe")

kubelet_configs = azure.containerservice.KubernetesClusterDefaultNodePoolKubeletConfigArgs(
 **agents_pool_kubelet_configs
)

default_node_pool = azure.containerservice.KubernetesClusterDefaultNodePoolArgs(
 name="default",
 vm_size="Standard_DS2_v2",
 zones=["1", "2", "3"],
 enable_auto_scaling=enable_auto_scaling,
 min_count=1,
 max_count=3,
 kubelet_config=kubelet_configs,
)

package main

import (
 "github.com/pulumi/pulumi-azure/sdk/v5/go/azure/core"
 "github.com/pulumi/pulumi-azure/sdk/v5/go/azure/containerservice"
 "github.com/pulumi/pulumi/sdk/v3/go/pulumi"
)

func main() {
 pulumi.Run(func(ctx *pulumi.Context) error {
 enableAutoScaling := false

 agentsPoolKubeletConfigs := map[string]interface{}{
 "allowedUnsafeSysctls": []string{
 "kernel.*",
 "net.*",
 },
 "containerLogMaxLine": 10,
 "containerLogMaxSizeMb": 10,
 "cpuCfsQuotaEnabled": true,
 "cpuCfsQuotaPeriod": "100ms",
 "cpuManagerPolicy": "none",
 "imageGcHighThreshold": 85,
 "imageGcLowThreshold": 65,
 "podMaxPid": 100,
 "topologyManagerPolicy": "none",
 }

 example, err := core.NewResourceGroup(ctx, "example", &core.ResourceGroupArgs{
 Name: pulumi.String("storage-rg"),
 Location: pulumi.String("West Europe"),
 })
 if err != nil {
 return err
 }

 kubeletConfigs := &containerservice.KubernetesClusterDefaultNodePoolKubeletConfigArgs{
 AllowedUnsafeSysctls: pulumi.StringArray{
 pulumi.String("kernel.*"),
 pulumi.String("net.*"),
 },
 ContainerLogMaxLine: pulumi.Int(agentsPoolKubeletConfigs["containerLogMaxLine"].(int)),
 ContainerLogMaxSizeMb: pulumi.Int(agentsPoolKubeletConfigs["containerLogMaxSizeMb"].(int)),
 CpuCfsQuotaEnabled: pulumi.Bool(agentsPoolKubeletConfigs["cpuCfsQuotaEnabled"].(bool)),
 CpuCfsQuotaPeriod: pulumi.String(agentsPoolKubeletConfigs["cpuCfsQuotaPeriod"].(string)),
 CpuManagerPolicy: pulumi.String(agentsPoolKubeletConfigs["cpuManagerPolicy"].(string)),
 ImageGcHighThreshold: pulumi.Int(agentsPoolKubeletConfigs["imageGcHighThreshold"].(int)),
 ImageGcLowThreshold: pulumi.Int(agentsPoolKubeletConfigs["imageGcLowThreshold"].(int)),
 PodMaxPid: pulumi.Int(agentsPoolKubeletConfigs["podMaxPid"].(int)),
 TopologyManagerPolicy: pulumi.String(agentsPoolKubeletConfigs["topologyManagerPolicy"].(string)),
 }

 _, err = containerservice.NewKubernetesClusterDefaultNodePool(ctx, "defaultNodePool", &containerservice.KubernetesClusterDefaultNodePoolArgs{
 Name: pulumi.String("default"),
 VmSize: pulumi.String("Standard_DS2_v2"),
 Zones: pulumi.StringArray{pulumi.String("1"), pulumi.String("2"), pulumi.String("3")},
 EnableAutoScaling: pulumi.Bool(enableAutoScaling),
 MinCount: pulumi.Int(1),
 MaxCount: pulumi.Int(3),
 KubeletConfig: kubeletConfigs,
 }, pulumi.Parent(example))
 if err != nil {
 return err
 }

 return nil
 })
}

using Pulumi;
using Pulumi.AzureNative.Resources;
using Pulumi.AzureNative.ContainerService;
using System.Collections.Generic;

class MyStack : Stack
{
 public MyStack()
 {
 var enableAutoScaling = false;

 var agentsPoolKubeletConfigs = new Dictionary<string, object>
 {
 { "allowedUnsafeSysctls", new string[] { "kernel.*", "net.*" } },
 { "containerLogMaxLine", 10 },
 { "containerLogMaxSizeMb", 10 },
 { "cpuCfsQuotaEnabled", true },
 { "cpuCfsQuotaPeriod", "100ms" },
 { "cpuManagerPolicy", "none" },
 { "imageGcHighThreshold", 85 },
 { "imageGcLowThreshold", 65 },
 { "podMaxPid", 100 },
 { "topologyManagerPolicy", "none" }
 };

 var resourceGroup = new ResourceGroup("example", new ResourceGroupArgs
 {
 Name = "storage-rg",
 Location = "West Europe"
 });

 var kubeletConfigArgs = new KubernetesClusterDefaultNodePoolKubeletConfigArgs
 {
 AllowedUnsafeSysctls = agentsPoolKubeletConfigs["allowedUnsafeSysctls"] as string[],
 ContainerLogMaxLine = agentsPoolKubeletConfigs["containerLogMaxLine"] as int?,
 ContainerLogMaxSizeMb = agentsPoolKubeletConfigs["containerLogMaxSizeMb"] as int?,
 CpuCfsQuotaEnabled = agentsPoolKubeletConfigs["cpuCfsQuotaEnabled"] as bool?,
 CpuCfsQuotaPeriod = agentsPoolKubeletConfigs["cpuCfsQuotaPeriod"] as string,
 CpuManagerPolicy = agentsPoolKubeletConfigs["cpuManagerPolicy"] as string,
 ImageGcHighThreshold = agentsPoolKubeletConfigs["imageGcHighThreshold"] as int?,
 ImageGcLowThreshold = agentsPoolKubeletConfigs["imageGcLowThreshold"] as int?,
 PodMaxPid = agentsPoolKubeletConfigs["podMaxPid"] as int?,
 TopologyManagerPolicy = agentsPoolKubeletConfigs["topologyManagerPolicy"] as string
 };

 var defaultNodePool = new KubernetesClusterDefaultNodePool("defaultNodePool", new KubernetesClusterDefaultNodePoolArgs
 {
 Name = "default",
 VmSize = "Standard_DS2_v2",
 Zones = new[] { "1", "2", "3" },
 EnableAutoScaling = enableAutoScaling,
 MinCount = 1,
 MaxCount = 3,
 KubeletConfig = kubeletConfigArgs
 }, new CustomResourceOptions { Parent = resourceGroup });
 }
}

class Program
{
 static Task<int> Main() => Deployment.RunAsync<MyStack>();
}

import com.pulumi.Context;
import com.pulumi.Pulumi;
import com.pulumi.azure.core.ResourceGroup;
import com.pulumi.azure.core.inputs.ResourceGroupArgs;
import com.pulumi.azure.containerservice.KubernetesClusterDefaultNodePool;
import com.pulumi.azure.containerservice.inputs.KubernetesClusterDefaultNodePoolArgs;
import com.pulumi.azure.containerservice.inputs.KubernetesClusterDefaultNodePoolKubeletConfigArgs;

import java.util.Map;
import java.util.HashMap;

public class MyStack {
 public static void main(String[] args) {
 Pulumi.run(ctx -> {
 boolean enableAutoScaling = false;

 Map<String, Object> agentsPoolKubeletConfigs = new HashMap<>();
 agentsPoolKubeletConfigs.put("allowedUnsafeSysctls", new String[]{"kernel.*", "net.*"});
 agentsPoolKubeletConfigs.put("containerLogMaxLine", 10);
 agentsPoolKubeletConfigs.put("containerLogMaxSizeMb", 10);
 agentsPoolKubeletConfigs.put("cpuCfsQuotaEnabled", true);
 agentsPoolKubeletConfigs.put("cpuCfsQuotaPeriod", "100ms");
 agentsPoolKubeletConfigs.put("cpuManagerPolicy", "none");
 agentsPoolKubeletConfigs.put("imageGcHighThreshold", 85);
 agentsPoolKubeletConfigs.put("imageGcLowThreshold", 65);
 agentsPoolKubeletConfigs.put("podMaxPid", 100);
 agentsPoolKubeletConfigs.put("topologyManagerPolicy", "none");

 var resourceGroup = new ResourceGroup("example", ResourceGroupArgs.builder()
 .name("storage-rg")
 .location("West Europe")
 .build());

 var kubeletConfigArgs = KubernetesClusterDefaultNodePoolKubeletConfigArgs.builder()
 .allowedUnsafeSysctls((String[]) agentsPoolKubeletConfigs.get("allowedUnsafeSysctls"))
 .containerLogMaxLine((Integer) agentsPoolKubeletConfigs.get("containerLogMaxLine"))
 .containerLogMaxSizeMb((Integer) agentsPoolKubeletConfigs.get("containerLogMaxSizeMb"))
 .cpuCfsQuotaEnabled((Boolean) agentsPoolKubeletConfigs.get("cpuCfsQuotaEnabled"))
 .cpuCfsQuotaPeriod((String) agentsPoolKubeletConfigs.get("cpuCfsQuotaPeriod"))
 .cpuManagerPolicy((String) agentsPoolKubeletConfigs.get("cpuManagerPolicy"))
 .imageGcHighThreshold((Integer) agentsPoolKubeletConfigs.get("imageGcHighThreshold"))
 .imageGcLowThreshold((Integer) agentsPoolKubeletConfigs.get("imageGcLowThreshold"))
 .podMaxPid((Integer) agentsPoolKubeletConfigs.get("podMaxPid"))
 .topologyManagerPolicy((String) agentsPoolKubeletConfigs.get("topologyManagerPolicy"))
 .build();

 var defaultNodePool = new KubernetesClusterDefaultNodePool("defaultNodePool", KubernetesClusterDefaultNodePoolArgs.builder()
 .name("default")
 .vmSize("Standard_DS2_v2")
 .zones(new String[]{"1", "2", "3"})
 .enableAutoScaling(enableAutoScaling)
 .minCount(1)
 .maxCount(3)
 .kubeletConfig(kubeletConfigArgs)
 .build(), new CustomResourceOptions().parent(resourceGroup));
 });
 }
}

In Pulumi, using TypeScript as an example, we can easily create new objects of a specific type and populate them with values from our configuration. If we need to add conditions, we can include our usual if statements. This approach greatly simplifies the code, making it easy to read and maintain for any future changes.

Execute Programming Code With `null_resource`, `local_file` and `provisioners`

There are sometimes situations where there is a strong need to execute a script written in a programming language. Most prominent use case is packaging up the source code for an AWS lambda function. Let’s have a look into an example from the Terraform AWS Lambda module

locals {
 python = (substr(pathexpand("~"), 0, 1) == "/") ? "python3" : "python.exe"
}

# Generates a filename for the zip archive based on the content of the files
# in source_path. The filename will change when the source code changes.
data "external" "archive_prepare" {
 count = var.create && var.create_package ? 1 : 0
 program = [local.python, "${path.module}/package.py", "prepare"]
 query = {
 paths = jsonencode({
 module = path.module
 root = path.root
 cwd = path.cwd
 })
 docker = var.build_in_docker ? jsonencode({
 docker_pip_cache = var.docker_pip_cache
 docker_build_root = var.docker_build_root
 docker_file = var.docker_file
 docker_image = var.docker_image
 with_ssh_agent = var.docker_with_ssh_agent
 docker_additional_options = var.docker_additional_options
 docker_entrypoint = var.docker_entrypoint
 }) : null
 artifacts_dir = var.artifacts_dir
 runtime = var.runtime
 source_path = jsonencode(var.source_path)
 hash_extra = var.hash_extra
 hash_extra_paths = jsonencode(
 [
 # Temporary fix when building from multiple locations
 # We should take into account content of package.py when counting hash
 # Related issue: https://github.com/terraform-aws-modules/terraform-aws-lambda/issues/63
 # "${path.module}/package.py"
 ]
 )
 recreate_missing_package = var.recreate_missing_package
 }
}

# This transitive resource used as a bridge between a state stored
# in a Terraform plan and a call of a build command on the apply stage
# to transfer a noticeable amount of data
resource "local_file" "archive_plan" {
 count = var.create && var.create_package ? 1 : 0
 content = data.external.archive_prepare[0].result.build_plan
 filename = data.external.archive_prepare[0].result.build_plan_filename
 directory_permission = "0755"
 file_permission = "0644"
}

# Build the zip archive whenever the filename changes.
resource "null_resource" "archive" {
 count = var.create && var.create_package ? 1 : 0
 triggers = {
 filename = data.external.archive_prepare[0].result.filename
 timestamp = var.trigger_on_package_timestamp ? data.external.archive_prepare[0].result.timestamp : null
 }
 provisioner "local-exec" {
 interpreter = [
 local.python, "${path.module}/package.py", "build",
 "--timestamp", data.external.archive_prepare[0].result.timestamp
 ]
 command = data.external.archive_prepare[0].result.build_plan_filename
 }
 depends_on = [local_file.archive_plan]
}

We see a confusing mix of different providers (local and null_resource) and even the use of provisioner here. This setup is overly complex to read and maintain, leading to a split-brain situation where some logic is in the code and the rest in HCL. It also becomes very challenging to debug, especially if the team lacks experience with the Python code.

In Pulumi, simplicity is key: simply write your Python code and seamlessly integrate it with Pulumi SDK calls. No additional steps are necessary, and there’s no need to run the Python binary separately to execute the file. It’s all about streamlining the process to make your life easier. For instance, consider this example where we read the name of an Azure Resource Group from a JSON file (config.json, illustrating how effortlessly Python can blend with Pulumi’s infrastructure management capabilities.

import json
import pulumi
import pulumi_azure_native as azure_native

# Load the JSON file
with open('config.json') as json_file:
 config = json.load(json_file)

# Extract values from the JSON file
resource_group_name = config['resourceGroupName']
location = config['location']

# Create an Azure Resource Group
resource_group = azure_native.resources.ResourceGroup(
 "resourceGroup",
 resource_group_name=resource_group_name,
 location=location
)

# Export the name of the resource group
pulumi.export('resourceGroupName', resource_group.name)

If Statements Constructed With `count`

variable "mode" {
 default = "not-spoke"
}

variable "restricted_net_hub_project_id" {
 default = "xxx"
}

data "google_compute_network" "vpc_restricted_net_hub" {
 count = var.mode == "spoke" ? 1 : 0
 name = "vpc-c-shared-restricted-hub"
 project = var.restricted_net_hub_project_id
}

In this HCL example, we see the count parameter being used in a way that stretches its original intent—essentially using it to conditionally create or skip resources based on the value of var.mode. This method, while functional, can make the code more difficult to understand and maintain, as it repurposes Terraform constructs in unintended ways.

Contrast this with Pulumi, which allows you to use native if statements from the programming language, such as TypeScript or Python. This native approach enhances readability and maintainability because it aligns with standard programming practices, making it easier for developers to follow and debug. Pulumi’s use of familiar programming constructs means you can write more intuitive and straightforward infrastructure code without bending the tool to fit unusual patterns.

import * as pulumi from "@pulumi/pulumi";
import * as gcp from "@pulumi/gcp";

const config = new pulumi.Config();
const mode = config.get("mode") || "";
const restrictedNetHubProjectId = config.get("restrictedNetHubProjectId") || "";
if (mode == "spoke") {
 const vpcSharedSpoke = gcp.compute.getNetworkOutput({
 name: "vpc-c-shared-spoke",
 project: restrictedNetHubProjectId,
 });
}

import pulumi
import pulumi_gcp as gcp

config = pulumi.Config()
mode = config.get("mode") or ""
restricted_net_hub_project_id = config.get("restrictedNetHubProjectId") or ""

if mode == "spoke":
 vpc_shared_spoke = gcp.compute.get_network_output(
 name="vpc-c-shared-spoke",
 project=restricted_net_hub_project_id,
 )

package main

import (
 "github.com/pulumi/pulumi-gcp/sdk/v7/go/gcp/compute"
 "github.com/pulumi/pulumi/sdk/v3/go/pulumi"
)

func main() {
 pulumi.Run(func(ctx *pulumi.Context) error {
 mode := ""

 if mode == "spoke" {
 _, err := compute.LookupNetwork(ctx, &compute.LookupNetworkArgs{
 Name: "vpc-c-shared-spoke",
 Project: "your-restrictedNetHubProjectId",
 })

 if err != nil {
 return err
 }
 }

 return nil
 })
}

using Pulumi;
using Pulumi.Gcp.Compute;

class Program
{
 static Task<int> Main() => Deployment.RunAsync<ComputeStack>();

 class ComputeStack : Stack
 {
 public ComputeStack()
 {
 var mode = "";

 if (mode == "spoke")
 {
 var network = Output.Tuple(Output.Create("vpc-c-shared-spoke"), Output.Create("your-restrictedNetHubProjectId"))
 .Apply(tuple => GetNetwork.InvokeAsync(new GetNetworkArgs
 {
 Name = tuple.Item1,
 Project = tuple.Item2
 }));

 // Handle potential errors if necessary
 network.Apply(n =>
 {
 if (n == null)
 {
 throw new Exception("Network not found");
 }
 });
 }
 }
 }
}

import com.pulumi.Pulumi;
import com.pulumi.core.Output;
import com.pulumi.gcp.compute.ComputeFunctions;
import com.pulumi.gcp.compute.inputs.GetNetworkArgs;

public class Main {
 public static void main(String[] args) {
 Pulumi.run(ctx -> {
 String mode = "";

 if ("spoke".equals(mode)) {
 Output<Tuple<String, String>> networkData = Output.tuple(Output.of("vpc-c-shared-spoke"), Output.of("your-restrictedNetHubProjectId"));

 Output<ComputedNetwork> network = networkData.applyValue(tuple ->
 ComputeFunctions.getNetwork(GetNetworkArgs.builder()
 .name(tuple.t1)
 .project(tuple.t2)
 .build()
 )
 );

 network.applyValue(n -> {
 if (n == null) {
 throw new RuntimeException("Network not found");
 }
 return null;
 });
 }
 });
 }
}

HCL Function Frenzy

Another source of extreme confusion and constant re-learning is the heavy usage of built-in functions within HCL expressions. At first glance, while it seems helpful for performing complex operations quickly, it can lead to overly complex expressions.

Here is an example of very complex expressions involving extensive function usage from the Google Network module:

locals {
 local_network_name = element(reverse(split("/", var.local_network)), 0)
 peer_network_name = element(reverse(split("/", var.peer_network)), 0)

 local_network_peering = "${var.prefix}-${local.local_network_name}-${local.peer_network_name}"
 local_network_peering_name = length(local.local_network_peering) < 63 ? local.local_network_peering :
 "${substr(local.local_network_peering, 0, min(58, length(local.local_network_peering)))}-${random_string.network_peering_suffix.result}"
 peer_network_peering = "${var.prefix}-${local.peer_network_name}-${local.local_network_name}"
 peer_network_peering_name = length(local.peer_network_peering) < 63 ? local.peer_network_peering :
 "${substr(local.peer_network_peering, 0, min(58, length(local.peer_network_peering)))}-${random_string.network_peering_suffix.result}"
}

In Pulumi, we can use the same functions from the programming language we pick for our infrastructure. This makes things easier because we don’t need to learn new, special functions like in HCL. We can also use extra libraries if we need them. Compared to HCL, where you have to learn unique functions, Pulumi lets you work with tools you might already know, making the whole process simpler and more flexible.

import * as pulumi from "@pulumi/pulumi";

const config = new pulumi.Config();
const localNetwork = config.require("localNetwork");
const peerNetwork = config.require("peerNetwork");
const prefix = config.require("prefix");

const localNetworkName = localNetwork.split("/").reverse()[0];
const peerNetworkName = peerNetwork.split("/").reverse()[0];

const localNetworkPeering = `${prefix}-${localNetworkName}-${peerNetworkName}`;
const peerNetworkPeering = `${prefix}-${peerNetworkName}-${localNetworkName}`;
const networkPeeringSuffix = "peering";
const localNetworkPeeringName = localNetworkPeering.length < 63
 ? localNetworkPeering
 : `${localNetworkPeering.substring(0, Math.min(58, localNetworkPeering.length))}-${networkPeeringSuffix}`;

const peerNetworkPeeringName = peerNetworkPeering.length < 63
 ? peerNetworkPeering
 : `${peerNetworkPeering.substring(0, Math.min(58, peerNetworkPeering.length))}-${networkPeeringSuffix}`;

export const outputs = {
 localNetworkName,
 peerNetworkName,
 localNetworkPeeringName,
 peerNetworkPeeringName,
};

import pulumi

config = pulumi.Config()
local_network = config.require("localNetwork")
peer_network = config.require("peerNetwork")
prefix = config.require("prefix")

local_network_name = local_network.split("/")[::-1][0]
peer_network_name = peer_network.split("/")[::-1][0]

local_network_peering = f"{prefix}-{local_network_name}-{peer_network_name}"
peer_network_peering = f"{prefix}-{peer_network_name}-{local_network_name}"
network_peering_suffix = "peering"

local_network_peering_name = (
 local_network_peering if len(local_network_peering) < 63
 else f"{local_network_peering[:min(58, len(local_network_peering))]}-{network_peering_suffix}"
)

peer_network_peering_name = (
 peer_network_peering if len(peer_network_peering) < 63
 else f"{peer_network_peering[:min(58, len(peer_network_peering))]}-{network_peering_suffix}"
)

pulumi.export("localNetworkName", local_network_name)
pulumi.export("peerNetworkName", peer_network_name)
pulumi.export("localNetworkPeeringName", local_network_peering_name)
pulumi.export("peerNetworkPeeringName", peer_network_peering_name)

package main

import (
 "github.com/pulumi/pulumi/sdk/v3/go/pulumi"
)

func main() {
 pulumi.Run(func(ctx *pulumi.Context) error {
 localNetwork := "your-local-network"
 peerNetwork := "your-peer-network"
 prefix := "your-prefix"

 localNetworkName := reverseString(getNetworkName(localNetwork))
 peerNetworkName := reverseString(getNetworkName(peerNetwork))

 localNetworkPeering := prefix + "-" + localNetworkName + "-" + peerNetworkName
 peerNetworkPeering := prefix + "-" + peerNetworkName + "-" + localNetworkName
 networkPeeringSuffix := "peering"

 localNetworkPeeringName := condenseName(localNetworkPeering, networkPeeringSuffix)
 peerNetworkPeeringName := condenseName(peerNetworkPeering, networkPeeringSuffix)

 ctx.Export("localNetworkName", pulumi.String(localNetworkName))
 ctx.Export("peerNetworkName", pulumi.String(peerNetworkName))
 ctx.Export("localNetworkPeeringName", pulumi.String(localNetworkPeeringName))
 ctx.Export("peerNetworkPeeringName", pulumi.String(peerNetworkPeeringName))

 return nil
 })
}

func getNetworkName(network string) string {
 parts := strings.Split(network, "/")
 return parts[len(parts)-1]
}

func reverseString(s string) string {
 runes := []rune(s)
 for i, j := 0, len(runes)-1; i < j; i, j = i+1, j-1 {
 runes[i], runes[j] = runes[j], runes[i]
 }
 return string(runes)
}

func condenseName(name string, suffix string) string {
 if len(name) < 63 {
 return name
 }
 return name[:min(58, len(name))] + "-" + suffix
}

func min(a, b int) int {
 if a < b {
 return a
 }
 return b
}

using System;
using System.Linq;
using Pulumi;

class Program
{
 static Task<int> Main() => Deployment.RunAsync<MyStack>();

 class MyStack : Stack
 {
 public MyStack()
 {
 var localNetwork = "your-local-network";
 var peerNetwork = "your-peer-network";
 var prefix = "your-prefix";

 var localNetworkName = ReverseString(GetNetworkName(localNetwork));
 var peerNetworkName = ReverseString(GetNetworkName(peerNetwork));

 var localNetworkPeering = $"{prefix}-{localNetworkName}-{peerNetworkName}";
 var peerNetworkPeering = $"{prefix}-{peerNetworkName}-{localNetworkName}";
 var networkPeeringSuffix = "peering";

 var localNetworkPeeringName = CondenseName(localNetworkPeering, networkPeeringSuffix);
 var peerNetworkPeeringName = CondenseName(peerNetworkPeering, networkPeeringSuffix);

 this.Export("localNetworkName", localNetworkName);
 this.Export("peerNetworkName", peerNetworkName);
 this.Export("localNetworkPeeringName", localNetworkPeeringName);
 this.Export("peerNetworkPeeringName", peerNetworkPeeringName);
 }

 private string GetNetworkName(string network)
 {
 var parts = network.Split('/');
 return parts[parts.Length - 1];
 }

 private string ReverseString(string s)
 {
 var chars = s.ToCharArray();
 Array.Reverse(chars);
 return new string(chars);
 }

 private string CondenseName(string name, string suffix)
 {
 if (name.Length < 63) return name;
 return name.Substring(0, Math.Min(58, name.Length)) + "-" + suffix;
 }
 }
}

import com.pulumi.Context;
import com.pulumi.Pulumi;
import com.pulumi.core.Output;
import com.pulumi.resources.Stack;

import java.util.Arrays;

public class Program {
 public static void main(String[] args) {
 Pulumi.run(Program::stack);
 }

 public static void stack(Context ctx) {
 var localNetwork = "your-local-network";
 var peerNetwork = "your-peer-network";
 var prefix = "your-prefix";

 var localNetworkName = reverseString(getNetworkName(localNetwork));
 var peerNetworkName = reverseString(getNetworkName(peerNetwork));

 var localNetworkPeering = String.format("%s-%s-%s", prefix, localNetworkName, peerNetworkName);
 var peerNetworkPeering = String.format("%s-%s-%s", prefix, peerNetworkName, localNetworkName);
 var networkPeeringSuffix = "peering";

 var localNetworkPeeringName = condenseName(localNetworkPeering, networkPeeringSuffix);
 var peerNetworkPeeringName = condenseName(peerNetworkPeering, networkPeeringSuffix);

 ctx.export("localNetworkName", Output.of(localNetworkName));
 ctx.export("peerNetworkName", Output.of(peerNetworkName));
 ctx.export("localNetworkPeeringName", Output.of(localNetworkPeeringName));
 ctx.export("peerNetworkPeeringName", Output.of(peerNetworkPeeringName));
 }

 private static String getNetworkName(String network) {
 var parts = network.split("/");
 return parts[parts.length - 1];
 }

 private static String reverseString(String s) {
 var chars = s.toCharArray();
 for (int i = 0, j = chars.length - 1; i < j; i++, j--) {
 char temp = chars[i];
 chars[i] = chars[j];
 chars[j] = temp;
 }
 return new String(chars);
 }

 private static String condenseName(String name, String suffix) {
 if (name.length() < 63) return name;
 return name.substring(0, Math.min(58, name.length())) + "-" + suffix;
 }
}

Pitfalls of HCL’s `try` Function

HCL’s try function can be problematic because it evaluates each argument until one does not produce an error. While it seems useful for navigating complex data structures, it often masks underlying issues by ignoring errors rather than addressing them.

This behavior can make debugging difficult because it can hide the real reasons behind failures, leaving configurations brittle and error-prone. Here is an example of the overuse of the try function

platform = try(each.value.platform, var.eks_managed_node_group_defaults.platform, "linux")
cluster_endpoint = try(time_sleep.this[0].triggers["cluster_endpoint"], "")
cluster_auth_base64 = try(time_sleep.this[0].triggers["cluster_certificate_authority_data"], "")
cluster_service_ipv4_cidr = var.cluster_service_ipv4_cidr
cluster_ip_family = var.cluster_ip_family
cluster_service_cidr = try(time_sleep.this[0].triggers["cluster_service_cidr"], "")
enable_bootstrap_user_data = try(each.value.enable_bootstrap_user_data, var.eks_managed_node_group_defaults.enable_bootstrap_user_data, false)
pre_bootstrap_user_data = try(each.value.pre_bootstrap_user_data, var.eks_managed_node_group_defaults.pre_bootstrap_user_data, "")
post_bootstrap_user_data = try(each.value.post_bootstrap_user_data, var.eks_managed_node_group_defaults.post_bootstrap_user_data, "")
bootstrap_extra_args = try(each.value.bootstrap_extra_args, var.eks_managed_node_group_defaults.bootstrap_extra_args, "")
user_data_template_path = try(each.value.user_data_template_path, var.eks_managed_node_group_defaults.user_data_template_path, "")
cloudinit_pre_nodeadm = try(each.value.cloudinit_pre_nodeadm, var.eks_managed_node_group_defaults.cloudinit_pre_nodeadm, [])
cloudinit_post_nodeadm = try(each.value.cloudinit_post_nodeadm, var.eks_managed_node_group_defaults.cloudinit_post_nodeadm, [])

Switching to Pulumi provides a clearer, more maintainable approach:

import * as pulumi from "@pulumi/pulumi";

// Example configuration using TypeScript for better error handling
const config = new pulumi.Config();
const platform = config.get("platform") || "linux"; // Default to "linux" if undefined

// Output using straightforward TypeScript logic
pulumi.output({ platform });

import pulumi

# Example configuration using Python
config = pulumi.Config()
platform = config.get("platform") or "linux" # Default to "linux" if undefined

# Output using straightforward Python logic
pulumi.export("platform", platform)

package main

import (
 "github.com/pulumi/pulumi/sdk/v3/go/pulumi"
)

func main() {
 pulumi.Run(func(ctx *pulumi.Context) error {
 platform, ok := ctx.GetConfig("platform")
 if !ok {
 platform = "linux" // Default to "linux" if undefined
 }

 ctx.Export("platform", pulumi.String(platform))
 return nil
 })
}

using Pulumi;

class Program
{
 static Task<int> Main() => Pulumi.Deployment.RunAsync(() =>
 {
 var config = new Config();
 var platform = config.Get("platform") ?? "linux"; // Default to "linux" if undefined

 return new Dictionary<string, object?>
 {
 { "platform", platform }
 };
 });
}

import com.pulumi.Config;
import com.pulumi.Pulumi;

import java.util.HashMap;
import java.util.Map;

public class Main {
 public static void main(String[] args) {
 Pulumi.run(ctx -> {
 Config config = Config.auto();
 String platform = config.get("platform").orElse("linux"); // Default to "linux" if undefined

 Map<String, Object> result = new HashMap<>();
 result.put("platform", platform);

 ctx.export("result", result);
 });
 }
}

This Pulumi example shows how to handle configuration values in a more straightforward way, avoiding the need for complex try functions which potentially sweep errors under the rug. By using standard programming constructs, you can improve the readability and maintainability of your infrastructure code.

In Conclusion

In conclusion, Pulumi’s approach to infrastructure as code offers significant advantages over HCL, positioning it as a more developer-friendly and future-proof solution. By leveraging general-purpose programming languages, Pulumi addresses many of the limitations and complexities inherent in HCL.

Pulumi’s use of languages like TypeScript, Python, and Go brings several key benefits:

Larger ecosystem and community support, providing better tooling, debugging capabilities, and resources.
Familiar syntax and constructs for developers, reducing the learning curve and improving code readability.
Greater flexibility and expressiveness, allowing for more elegant solutions to complex infrastructure challenges.
Better integration with existing development workflows and practices.
Improved collaboration between development and operations teams, helping to break down silos.

The examples provided throughout this comparison demonstrate how Pulumi’s approach leads to cleaner, more intuitive code. Complex operations that require convoluted HCL expressions or multiple custom resources can often be accomplished with straightforward programming constructs in Pulumi.

Moreover, Pulumi’s model is inherently more adaptable to future changes in cloud technologies and programming paradigms. As new languages or cloud services emerge, Pulumi can easily incorporate them, ensuring that your infrastructure-as-code practices remain current and effective.

For organizations looking to modernize their infrastructure management, streamline their DevOps processes, and empower their development teams, Pulumi presents the only alternative to HCL. Its ability to unify application and infrastructure code under a single programming model offers a path to more efficient, maintainable, and scalable cloud engineering practices.

By choosing Pulumi, teams can enjoy the benefits of true programming languages for infrastructure, leading to more robust, flexible, and developer-friendly cloud deployments.

As always, we welcome your feedback and contributions in the Pulumi Community Slack, GitHub repository, and Pulumi Community Discussions.

New to Pulumi? Signing up is easy and free. Get started today!

Interested in migrating? Our cloud experts can help. Learn more about Pulumi’s Migration Services.

Why Developer Experience (DevEx) is Business Critical

Sara Huddleston — Tue, 20 Feb 2024 20:47:44 +0000

“Developer experience is hard to sell,” said Cleve Littlefield, Engineering Manager at Pulumi, during a casual meeting. With experience as both an end-user developer and a lead in self-service platform implementation, Cleve’s observation stuck with me.

Though I have expertise in leading implementations and upgrades for internal platforms, none were specifically for developers. However, experience remains vital across departments, addressing tools, processes, systems, and best practices, aiming to reduce cognitive load, increase productivity, enhance collaboration, boost communication and much more.

Intriguingly, engineering teams may perceive its value differently. Therefore, we will dive into the concept of developer experience, aka DevEx, which, in truth, should translate into a competitive advantage.

In this DevEx article

What is developer experience?

Developer experience (DevEx), also referred to as DevX or DX, encompasses systems, technology, processes, and culture that collectively impact the effectiveness of software development. It looks at all components of a developer’s ecosystem—from environment to workflows to tools—and evaluates how they contribute to developer productivity, satisfaction, and operational impact.

Developer experience revolves around the ease or difficulty of executing essential tasks. A positive developer experience means those tasks are relatively easy to perform, translating into higher performance.

The quality of the experience is equally vital for developers building and managing internal software as it is for those involved in developing customer-facing software products.

Is developer experience important?

It is not just important. It’s business critical. If your company is in the business of creating and selling software or relies on critical internal software, developers are vital internal stakeholders to your business foundation.

Greg Mondello, director of product at GitHub, said, “In most contexts, software development capacity is the limiting factor for innovation. Therefore, improvements to the effectiveness of software development are inherently valuable […] companies with better DevEx outperform their competitors, regardless of vertical.”

Platform Engineering Forrester Opportunity Snapshot - DevEx impacts overall business performance. Credit: Humanitec

As per McKinsey’s report, an enhanced developer experience (DevEx) can yield significant advantages for organizations, including enhanced talent hiring and retention, improved security, and increased developer productivity- this makes DevEx important for all companies, not just tech.

A positive developer experience can yield numerous business advantages, which can include:

Improvement in collaboration across departments
Higher attraction and retention top talent
Increase developer productivity and developer velocity
Reduction in operational costs
Accelerate time-to-market
Support innovation
Elevate customer attraction and retention
Increase bottom line through revenue growth

To this end, let’s look into what goes into developer experience and how to achieve it.

The GitHub developer experience (DevEx) formula

GitHub’s DevEx formula takes into consideration the following:

Productivity: The speed and simplicity of implementing changes to a codebase
Impact: The seamless transition from idea to production without obstacles
Satisfaction: The environment, workflows, and tools influence developer happiness

Optimizing DevEx involves fostering a collaborative environment where developers can be most productive, impactful, and satisfied.

DevEx formula. Credit: GitHub

Noah Gift, the founder of Pragmatic AI Labs and a professor at Duke University specializing in machine learning, MLOps, AI, data science, and cloud architecture, noted that with the right platform, there could be:

A 75% increase in productivity
A sustained 22% productivity increase three years later
An 80% reduction in onboarding time

Merely having skilled developers is insufficient. Developers also require the appropriate tools and processes to excel in their work. Top-tier developers anticipate the availability of such resources, influencing the hiring and retention of talent.

What does a great developer experience look like?

Engineering teams that have good developer experiences are more productive and efficient. Great DevEx is often enabled by a platform where the end-users are the developers.

Developer-first readily available internal developer platform, infrastructure, and development tooling, with well-organized and explicit documentation, including tutorials, demo environments, and curated learning paths.
A unified hub for all developer requirements eliminates the need for developers to navigate through numerous tools, saving valuable time.
Simplified workflows emerge when developers can swiftly select app patterns, such as API microservices or front-end journeys, and deploy them within minutes. This includes all-encompassing elements like environments, pre-integrated DevSecOps pipelines, monitoring, and fully automated change and release procedures.
Centralized tracking of software, API, and infrastructure status and versions promotes asset transparency. A real-time view supports adherence to architectural standards, security controls, and patching status, with bots offering automatic suggestions for code enhancements related to issues.
Integrated analytics and KPIs such as developer velocity, tech debt, error rate, mean time to recovery, and infrastructure cost can be automatically pulled by standard organizational tools, including backlog, pipeline, and monitoring tools.

Survey by GitHub on a typical experience for developers. Credit: GitHub

Without the proper tools, progress may slow down the development process and hinder developer productivity. It becomes crucial to implement appropriate measures to avoid disruptions that could impact everyone involved, including the developers themselves. Although not often mentioned, DevOps and Platform Engineering also aim to enhance the developer experience and achieve the associated benefits.

How does DevEx intersect with DevOps?

DevOps is about developers and operations working together and sharing values, assumptions, and responsibility for the software they build and maintain.

According to Vilas Veeraraghavan, VP of Engineering at Truckstop, “Developer Experience (DevEx) is the investment you make to enable solid DevOps practices, reduce developer burnout, and improve retention. The need for this investment is more pronounced as companies grow and the tech stack gets more diverse.”

Watch Jowanza Joseph, Head of Engineering at StreamFT, below as he discusses how the right tool empowered developers, improved DevEx, reduced bottlenecks, increased productivity, and helped DevOps be a culture, a practice, not a person.

Let’s address a strong indicator of success or failure - culture.

Culture is not something you are—it’s something you do. Software companies often focus on DevOps practices and culture, but all would benefit from adopting a DevOpsAll since the entire company should strive for the same thing. The diversity of perspectives, ideas, and insights can spark creativity and innovation and even ensure product-market alignment.

Organizational culture is a predictor of outcome success

Why it matters? Organizational culture encompasses everyone, from the development team and operations to product management teams, sales, marketing, and more.

According to George Spafford, Senior Director Analyst at Gartner, “Infrastructure & Operations leaders embarking on DevOps initiatives and struggling to address organizational change and the value they will provide to the larger enterprise […] people-related factors tend to be the greatest challenges — not technology.”

According to a Harvard study encompassing 200 companies over 11 years, companies that focused on shaping their culture outperformed their competitors:

Revenue growth was 4.1 times higher
The stock price was 12.2 times higher
Net income was 756% vs. 1%
Return on investment (ROI) was 15 times higher

The driving force behind this exceptional financial performance is that engaged employees are prone to increased productivity, fostering superior innovation and more effective problem-solving.

Slide from Mark’s New York Atlassian Community Group presentation. Credit: Mark Cruth, principal modern work coach/advocate at Atlassian

Based on decades of research on employee engagement, Gallup has established that engaged employees consistently yield superior business outcomes compared to their counterparts. This holds true across various industries, company sizes, and nationalities and remains consistent in prosperous and challenging economic conditions.

If it is not yet clear, then I will spell it out. Developer experience impacts employee engagement. A better developer experience can boost the engagement of the engineers and developers in the organization, and more engaged people are more likely to go the extra mile.

How developer experience supports better business outcomes. Credit: Swarmia

If organizations invest in cultural values centered on human-first factors, then even the choices made in tools, processes, and systems will also be with the end-user in mind.

How do you implement a great developer experience?

There isn’t a bulletproof checklist, but there are several aspects to consider, and you can see the outline below. First, you need to view the developers as customers.

You will need to understand how developers work, the developer workflow, what the onboarding process looks like for a new developer, the developer teams’ pain points, what developers love and hate about their day-to-day work, where they are spending most of their time, where they wish they spent most of their time, and so much more, that boils down to communication, and asking the right questions, and deep diving into analytics.

Cultivate a DevOps culture

Shared responsibility: Encourage a culture of shared responsibility where developers, operations, and other stakeholders work collaboratively
Continuous learning: Promote a culture of continuous learning and improvement to adapt to evolving technologies and methodologies
Open communication: Foster open communication channels to enhance collaboration and transparency among team members
Company-wide collaboration tools: It’s essential to encourage communication among developers and cross-functional teams to stimulate creativity, spark innovation, and enhance productivity and the speed of decision-making. Cross-functional collaboration contributes to successful business outcomes

Define clear objectives

Alignment with business goals: Ensure DevEx objectives align with business goals to drive meaningful outcomes
User-centric approach: Prioritize user needs and feedback, shaping the DevEx strategy around the actual experiences of developers

Leverage developer-first tools

Internal developer portals (IDPs): IDPs enable developers to quickly provision approved infrastructure, boosting productivity with pre-configured architectures, automated testing, and deployment adhering to organizational standards
CI pipelines: usually, pipelines can be made faster and more unified. If they have a microservice architecture, they are likely duplicating pipeline code for every service
Software development kits (SDKs): SDKs are integral components of a positive DevEx and provide developers with tools that facilitate crafting applications tailored to specific platforms or frameworks. Offering easy-to-access, well-designed, functional SDKs can make a meaningful difference in helping engineers quickly prototype ideas and refine their creations
Infrastructure as code (IaC): Developers like to write code, particularly in their preferred programming language, provision infrastructure, ensuring consistency and reproducibility
Monitoring and observability: Implement effective monitoring and observability tools (e.g., Prometheus, New Relic, Grafana) to gain insights into application performance and proactively address issues
Collaborative documentation platforms: Use collaborative documentation platforms to document code, processes, and best practices, ensuring knowledge sharing and reducing onboarding friction

Platform Engineering Forrester Opportunity Snapshot - Which of the following steps organizations are taking to improve DevEx? Credit: Humanitec

Prioritize developer-friendly workflows

Fast feedback loops: Minimize feedback loops by integrating quick feedback mechanisms, allowing developers to identify and resolve issues early in the development cycle
Self-service environments: Provide developers with self-service environments to facilitate experimentation, testing, and debugging without unnecessary dependencies on other teams
Version control best practices: Enforce version control best practices to maintain a clean and organized codebase, allowing for easier collaboration and tracking of changes

Continuous integration of feedback

Developer surveys: Conduct regular surveys to gather feedback on the DevEx, ensuring continuous improvement based on real user experiences
Rapid iteration: Encourage a culture of rapid iteration, where feedback is quickly incorporated into the development process to enhance the overall developer experience

Measure and optimize

Key performance indicators (KPIs): Define and track key metrics such as deployment frequency, lead time, and mean time to recovery to measure the effectiveness of the DevEx strategy
Iterative optimization: Continuously iterate and optimize DevEx based on performance metrics and user feedback

Implementing a Developer Experience requires a holistic approach that blends cultural aspects with powerful DevOps and platform engineering tools. Watch Daniel Tao, Head of Engineering at Atlassian, and Sven Peters, developer evangelist, discuss how to build a great developer experience through culture and an integrated approach to developer tools.

What DevEx is not

Now that DevEx has been defined, let’s address some common misconceptions about developer experience.

DevEx is not the same as User Experience (UX)

Developer experience may sound similar to user experience (for developers), but it’s different, although user experience is a component. For example, a platform engineer building an internal developer platform must view the developers as their customers and create a good user experience by making it intuitive and easy to use.

DevEx is not about enabling lazy developers

Part of the DevEx strategy is to retain talent. Companies that invest in DevEx don’t do it to pamper developers. The true reason behind it is that they want their developers to stay “in the zone,” also known as “deep work.” When in this state, they are immersed in writing code and solving problems they enjoy working on, and their creativity is higher, it sparks innovative ideas, and the quality and speed of their output are also higher.

DevEx is not about implementing AI and cool tools

Technology impacts developer experience, a robust generative AI tool can help create code faster, and internal developer platforms can help reduce cognitive load on developers. But again, tooling is only one aspect of it. Tools can’t fix culture or replace processes. Many DevEx considerations should be considered to ensure that when the development teams adopt a tool, it addresses their pain points and enables developers.

DevEx is not a one-person decision

DevEx should be a joint effort from the entire team. One needs to be aware of the issues to plan to fix them, so open communication and team collaboration are vital to developing and implementing a DevEx strategy, intersecting DevOps and platform engineering initiatives. Many large organizations already have DevEx teams or professionals with a bird’s-eye view of what happens within the engineering team. They are internal advocates for software engineers. They consider the developer’s journey from being new developers and their ‘Time to First Contribution’ to day-to-day activities. They work with engineers to learn which problems are a priority and identify misconceptions and bottlenecks that may slow the development process.

Conclusion

Developer experience (DevEx) is essential for creating maximum output while increasing developer satisfaction. The appropriate technology tools, workflows, and a supportive development community can help foster progress and innovation while promoting high-quality software engineering results that can become a competitive advantage and ultimately benefit the business’s bottom line.

By dedicating attention to improving the DevEx, companies will also be able to bring more talent aboard, reduce their “Time to First Contribution,” enable developers to provide higher output contributions and improve talent retention. It’s time to start focusing on superior developer experiences.

Frequently asked questions

What does business critical mean?

Business critical means essential for a business to operate and be successful. It refers to business processes, systems, or activities that are considered essential for proper functioning, success, or survival. If these elements are disrupted or compromised, the impact can significantly affect its operations, financial health, or overall business objectives. Business-critical components are often prioritized for attention, protection, and resource allocation to ensure the organization’s continued effectiveness and stability, and to remain competitive.

What is the role of a Developer Experience Engineer (DXE)?

Developer Experience Engineers are internal advocates indispensable to making life easier for developers by making workflows more efficient, implementing the same processes across the development team, and assisting in choosing tools to lighten their load. Some companies do not necessarily have engineers with that job title, and it’s instead seen as part of DevOps or Platform Engineering initiatives. Other times, the internal developer advocate natural rises from the developer community to help form an integral part of the developer team’s unity. They also champion communication and work with cross-function coworkers and feel safe means of providing constructive feedback.

How do we cultivate a positive developer community?

The importance of DevEx’s human element is now in focus. A productive and effective developer community could be seen as a flourishing habitat, strengthening cooperation and maximizing productivity through collaboration. Such an atmosphere also sustains morale among the developers, resulting in job satisfaction and contentment.

Here are some steps to build a developer community: open communication needs to become standard, successes should consistently be recognized, and avenues for growth need to exist. Diversity and acceptance are significant. Task expectations should be attainable goals and set high enough not to compromise quality but not realistic so they can be achieved without burnout and unbalanced life routines.

How does technology impact developer experience?

Technological advancements continue to change software development and impact the Developer experience. AI, ML, TDD, and internal developer platforms are some of these technologies that help reduce developers’ cognitive load. They automate complex tasks for more accuracy and enable intelligent decision-making. Besides this, generative AI has come into play in creating higher-quality code faster. At the same time, GitOps is a management approach based on one source of truth - Git, which makes collaboration smoother & boosts productivity by allowing automation. All these things undoubtedly improve the DX substantially for any developer out there!

Azure Container Services Compared: ACI vs App Service vs AKS

Lee Briggs — Tue, 12 Oct 2021 08:00:00 -0700

Containers have emerged as one of the de facto standards for running software. When adopted with the right mindset, they can drastically improve the development lifecycle and help to close the loop between local development and running your applications in the cloud.

If you’re at the stage of trying to run your application in Microsoft Azure, the choices can be overwhelming. The Azure Container product page lists 7 different products on their landing page, and for new users it can often be difficult to decide which of the myriad products is right for their use case. What can make it even more confusing is that often these container services can be interoperable, meaning you can use one container product from another!

In this post, we’re going to examine each of the main container services offered in Azure and then examine what they’re good for and what they might not be so good for. Let’s take a look!

Azure Container Instances

Azure Container Instances (ACI) bills itself as an offering that lets you “easily run containers on Azure without managing servers.”

Launched in July 2017, it was arguably the first “serverless” container offering from the major cloud providers.

What’s good about it?

ACI is a Platform-as-a-Service (PaaS) type of product that is designed to remove the burden of launching and running containers.

Simplicity

Azure Container Instances has been designed from the ground up to be straightforward to use. It’s designed to get your container launched as quickly as possible, even including integrations with many of the tools you’re probably already familiar with if you’re using containers. One example is the integration with the Docker CLI.

In many cases, the only configuration options you need to pass to your ACI provisioning mechanism is the image you’re running and some sizing decisions, like how many CPUs and how much memory you need. There is some flexibility in this decision process, but having fewer required options means you’re not bogged down with complex architectural decisions when trying to get your container running.

This lends itself particularly well to web server projects, especially at smaller scales. You can launch applications very quickly and easily by specifying the image you’ve built, and your application can be running in very short order.

Start-Up Times

ACI Containers start fast—often in a matter of seconds. This speed really helps the developer lifecycle and helps to create productivity when you’re developing your application.

Pricing

ACI will only bill you for the time your applications are running. It offers no start-up costs (which goes great with the fast start times!) and per-second billing, meaning you only pay for every second the application is actually up. The pricing is also extremely competitive against other cloud providers.

The Other Stuff

From a security perspective, ACI separates your container from others running in the same environment, meaning your application will have the same level of security as if it was running on a different virtual machine. This separation really helps to provide peace of mind and is yet another benefit of the serverless model—less infrastructure means less worries.

As expected from Microsoft, ACI has excellent support for Windows containers and .NET platform applications, which is lacking around other cloud providers. If you need to run Windows containers, this support is a huge benefit.

What’s not great about it?

Scaling

ACI supports customizing the amount of resources you can assign to a container, but it will only run one copy. There’s no horizontal scaling available, so if you need more resources, you only have one option: scaling vertically. It is possible to run N number of ACI instances and configuring load balancers across them, but it’s a very manual process and can be awkward to manage and scale successfully.

If you’re running a webserver application, horizontal scaling behind a load balancer might be a better option, so this lack of scaling flexibility and manual processing can be a real shortcoming.

In addition to this opinionated scaling mechanism, there’s also no auto scaling option for ACI. If you’re finding that you’re hitting the limits of your ACI deployment, you’ll need to manually scale the service.

Configuration

ACI has some configuration options missing, which you’d expect would be there from the beginning. One glaring omission is port mapping (for example mapping public port 80 to container port 8080). This omission can mean modifying your container just to get it running in ACI.

ACI’s opinionated architecture seems to have been designed for ease-of-use, which often means more complex workloads just aren’t possible. If you have some unique configuration options, like needing access to privileged container options or complex network requirements, ACI might not be able to support you.

What we’d use it for

The lack of flexibility in ACI means that some workloads just aren’t able to run there. If you have full control over the container images you’re building and if you just want to get off the ground quickly with minimal fuss and configuration, ACI is a great choice.

Applications with smaller and more predictable usage patterns are a great use case for ACI. The lack of horizontal scaling could be seen as a negative, but from another perspective, it means the use case is straightforward and simple. If you just want to get your application into the hands of your users and think you can accurately predict your usage patterns, choose ACI.

Azure App Service

Azure App Service is a more fully-featured offering for hosting applications, focusing more on WebApps and API services. It started life as several differing offerings (Azure Websites, Azure Mobile Service, and Azure BizTalk) before being bundled into a single service in March 2015. Its origins as multiple solutions means it has developed tight integrations with other Azure solutions and offers many value-add features depending on your use case.

Because of the myriad features Azure App Service offers, running containers is only a small part of what you can do with it.

With that in mind, let’s take a look at where it shines with regard to running containers.

What’s it good for?

Azure App Services is designed to be a one-stop shop for your web application needs, so it’s highly opinionated and pushes you in a certain direction.

Integrations

Azure App Service has many integrations with Azure. As an example, if you need to add a CDN to your web service, it’s extremely straightforward to do so with Azure CDN.

This tight integration with Azure’s many other services makes it likely to meet the needs of your application and extend it as needed, introducing common architecture components like message queues and databases. This is particularly useful when it comes to the integration with Azure’s networking model. You can run an Azure App Service inside an Azure Virtual Network which is extremely useful in many scenarios where network separation is needed, like enterprise applications.

Scaling & Availability

Azure App Service has a myriad of available scaling capabilities built out of the box. Not only can you scale the actual container you’ve deployed (while also simultaneously placing pricing caps on your service), but you can also scale related resources if necessary, which fits well with the tight integration we mentioned previously.

App service scaling for your container can either scale up (i.e., increase the amount of resources associated with your container) or scale out (ie: have more containers behind your load balancer).

This flexibility in scaling means you can be safe to assume your application will meet spiking traffic requirements and service your users’ needs.

What’s not great about it?

Opinionated

Azure App Service is highly opinionated. Its tight integrations with other Azure services mean that you’re expected to follow established patterns for achieving your goals.

This opinionated implementation means that the initial learning curve can be steep. The origins of app services means the product has grown in complexity along with its opinionated implementation, and as a result it can be overwhelming when getting started.

In addition to the learning curve, App Service is primarily focused towards web app workloads, and support for running other applications is limited at best.

What we’d use it for

The scaling options available to App Service means that it’s extremely well positioned to handle your large scale, fluctuating web applications. If you expect to have traffic spikes during peak hours, you can configure App Service to scale relatively easily in a manner that suits your budget and needs.

Azure Kubernetes Service

Azure Kubernetes Service (AKS) is Azure’s managed Kubernetes offering, which has been available since October 2017.

Azure was very quick to market with its Kubernetes offering and hired several prominent Kubernetes engineers like Brendan Burns to head up the engineering departments building the service.

Kubernetes is a very fully featured product, and AKS is a very conformant implementation of Kubernetes. Therefore, a lot of our good and bad considerations next will be an evaluation of Kubernetes, as well as AKS.

What’s it good for?

Extensibility

Kubernetes is incredibly feature rich. Out of the box with AKS, you’ll get application self-healing capabilities via the mechanism of reconcile loops built into Kubernetes, the ability to run different types of workload via native Kubernetes resources such as StatefulSets, Deployments and Jobs, and a large amount of extensibility via Kubernetes’ Custom Resource Definitions capability.

Familiarity

Kubernetes also offers a familiar API regardless of the cloud provider you’re working with. If you’re new to AKS, but have used a managed Kubernetes service from another cloud provider, you might find it relatively easy to get your container up and running in AKS.

What’s not great about it?

Complexity

Kubernetes has a steep learning curve, and AKS is no exception. A lot of the knowledge needed to run and operate Kubernetes is handled by AKS itself, but you still have to have an in-depth understanding of how Kubernetes works to get your container running.

In addition, the specification for a simple Kubernetes job can often be hundreds of lines of code. You have to learn not only how to run the container but also understand how Kubernetes exposes services to the world.

What we’d use it for

The flexibility and extensibility offered by Kubernetes as a platform means it’s possible to run many types of workloads. Large companies have battle-tested Kubernetes (and by extension, AKS), running everything from web applications to machine learning.

If you’re able to invest time into learning and understanding the ecosystem and can dedicate people to maintaining and managing your Kubernetes implementation, AKS is a fantastic option for almost any workload you might consider.

Everything Else

Azure Red Hat OpenShift

Azure Red Hat OpenShift is an enterprise grade implementation of Kubernetes developed by Red Hat. OpenShift builds on Kubernetes by adding support, enterprise-grade security, and Platform-as-a-Service integrations.

If the idea of using Kubernetes for your container solutions seems appealing but you need service level agreements (SLAs) around support and integrations, Azure’s Red Hat OpenShift solution is a great option.

Azure Service Fabric

Azure Service Fabric is a container service focused on distributed applications, like microservice architectures or complex distributed compute environments.

If you’re planning on running a complex architecture, Azure Service Fabric can be a great fit. It provides more orchestration capabilities than Azure App Service. Service Fabric can also extend outside Azure’s cloud into your on-premise data center if necessary.

If your application has needs related to low latency, especially across distributed regions, Service Fabric is a great fit.

However, Azure Service Fabric can be extremely difficult to use. It is only targeted towards distributed, complex systems - if you’re not planning on building one of those, it’s probably not the correct choice.

Azure Batch

Azure Batch is a service focused on High Performance Compute (HPC) workloads. These workloads can often scale horizontally to thousands of processes and can be difficult to orchestrate.

Azure Batch makes this process simpler by providing a managed service to handle the difficult processes.

If you’re planning on passing large amounts of data to your application via a queuing mechanism and having that data processed very quickly, Azure Batch is definitely a service you should consider.

Azure Functions

Azure Functions is Azure’s Function-as-a-Service implementation. It supports launching “function apps” inside containers as a deployment mechanism.

Function-as-a-Service products are often designed for short-lived, event-driven workloads. If you need to run a script to react to a worker queue or other event, Azure Functions are a great option. It’s important to remember that Functions are often billed based on how long they run, so short-lived workloads are often better suited.

You might also like:

Wrap-Up

There are a number of options for running containers in Azure, and choosing the right one for your workload might be difficult. We’ve tried to give an overview of the current state of the world, but Microsoft continues to add options and capabilities to all these products.

If you’ve settled on a container solution, and are ready to get started, Pulumi’s Azure Native provider supports all of the methods of running containers and can quickly get you started. Check out our Azure getting started guide, or join one of our upcoming Azure Workshops!

Top 5 Things an Azure Developer Needs to Know: Introduction

Sophia Parafina — Mon, 02 Aug 2021 00:00:00 +0000

The Azure cloud platform includes over 200 products and cloud services. Wherever you are in your Microsoft cloud engineering journey, you should be familiar with these top 5 cloud tasks that are essential building blocks commonly used to deploy applications and infrastructure to the Azure cloud.

In this series of articles, we’ll go in-depth on virtual machines, Azure Functions, static websites, building an Azure Kubernetes Service cluster and deploying applications on AKS, and DevOps with Azure App Service.

Azure - a comprehensive cloud platform

With Azure, you can develop, test, deploy and manage your applications in an integrated cloud computing environment. With the Azure Portal, you can manage the cloud infrastructure for your applications. Azure gives you the choice of a portal for managing services or managing them programmatically using service APIs and templates.

With over 200 services, knowing which one to use can be confusing. Deciding where to host your application is the first step. This series of articles covers the most commonly used Azure services such as virtual machines, serverless functions, static websites, Kubernetes, and Azure App Service. In addition, we’ll cover how to deploy applications using Azure DevOps.

In this article, we’ll match use cases to cloud services to help you navigate Azure.

Azure Virtual Machines

A common cloud migration path is to use virtual machines if you have existing infrastructure or on-premise applications. It is especially true if you want complete control over the infrastructure and application environment.

Azure provides Infrastructure as a Service (IaaS) for deploying your applications on either Linux or Windows VMs. IaaS includes all necessary support, such as Azure Virtual Network and storage. As with any IaaS solution, you are responsible for the installation of software, configuration, and maintenance of your application and any maintenance the VM might require, such as operating system patches.

If your application doesn’t fit into a Platform as a Service (PaaS) model, consider using virtual machines to provide the fine-grained control required for your deployment.

Serverless

At the opposite end of cloud infrastructure is serverless computing. Serverless eliminates the need to manage infrastructure and lets you focus on writing and deploying code. Azure automatically provisions, scales, and manages the infrastructure. You can write code that runs in response to events or on a schedule.

Azure Functions lets you focus on the application’s business logic, and the code executes when called by a webhook, an HTTP or REST request, a schedule, or an event. Serverless is particularly appealing because you can use the development language of your choice, ranging from PHP, Python, Node.js, or .NET languages. Azure functions scale as needed, and consumption-based pricing means that you’re charged only when the code runs.

If you don’t need a completely hosted project and only pay for what you use, choose Azure Functions triggered by web-based events, a schedule, or other Azure services.

Static websites

Static websites are quickly becoming the defacto way to publish content. Built from libraries and frameworks that don’t use server side rendering like React, Angular, or Vue, they include HTML, CSS, image assets, and Javascript in the application. Instead of serving assets from a server or servers scaled horizontally, the static assets are distributed through a Content Delivery Network (CDN). This reduces latency, resulting in faster websites and increased customer satisfaction.

Azure provides two ways to deploy static websites. Azure lets you deploy a static web application with Azure App Service and the recently released Azure Static Web Apps. Azure App Service deploys websites by uploading the website to Azure storage configured to serve web content. Azure App Service automatically builds and deploys full stack web apps to Azure from a code repository, which follows the Jamstack model for developing and deploying websites.

We’ll look at both methods and discuss the pros and cons of both methods.

Kubernetes

Kubernetes is the leading container orchestration service. Azure Kubernetes Service (AKS) is a hosted service that can deploy, scale, and manage containerized applications in a cluster. AKS fulfills many different use cases, for example:

If you have an existing application, think n-tier applications, you can containerize the components and “lift and shift” your application to run in Kubernetes.
You can deploy microservices on AKS to add horizontal scaling, load balancing, secrets management, and self-healing.
Data scientists are training machine learning models on AKS using TensorFlow and Kubeflow.
You can even use AKS as part of a build pipeline by pairing with a CI, such as Jenkins, to build containers for your application.

AKS supports many use cases by providing provisioning, scaling, and resource upgrades without requiring expertise in container orchestration. With AKS, the Kubernetes master nodes are managed by Azure, and you are only charged for the worker nodes in your cluster.

We’ll do two separate deep dives into deploying AKS clusters and deploying applications in AKS in this series.

Deploy AKS

Azure provides many ways to deploy an AKS cluster, including:

When you deploy an AKS Cluster, the worker nodes and Kubernetes master are configured with a basic configuration. You can additionally configure networking, storage, monitoring, and policies. We’ll cover configuring AKS in this series.

Deploy Applications

Deploying applications on AKS is equally flexible, and you can deploy using:

kubectl and YAML manifests
Helm, an open-source Kubernetes packaging tool
Azure Pipelines Infrastructure as Code

We’ll examine these options and do a deep dive on application deployment in a follow-up article.

DevOps integration

Before Continuous integration (CI) and Continuous Deployment (CD) became prevalent, applications were manually built, compiled, and maintained in a large codebase. CI/CD automation lets you build quickly, test, and deploy services. Both application fixes and new features are shipped quickly to your customers, and you can rapidly respond to changing customer demands. For example, if demand increases, you can quickly add resources to your application or add a serverless function that increases and decreases resources as needed.

If you’re deploying applications on Azure Functions, virtual machines, AKS, or provisioning infrastructure, the build process should be automated. Azure offers a range of services such as Azure Container Registry, AKS, and Azure Cosmos DB that can integrate with popular CI/CD pipelines like Azure DevOps, Jenkins, Github, and TeamCity.

If you’re interested in using Azure DevOps to automate infrastructure and application delivery, stay tuned!

Let’s Get Started!

So here are the top 5 things essential to know as an Azure developer:

configuring and deploying virtual machines
developing and deploying Azure Functions
deploying static websites on Azure
configuring Azure Kubernetes Service and deploying containerized applications
using Azure DevOps to automate the building and deployment of infrastructure and applications

First up and next in this series of articles is deploying Azure virtual machines with an application.

Empower Your Team with Policy as Code

Sophia Parafina — Mon, 08 Mar 2021 18:12:25 -0700

Policies set the guardrails for your applications and infrastructure. They define many aspects of how your company manages its applications and infrastructure. Security, safe use of resources, and compliance with external standards are just a few examples of what a policy can define.

Historically, policies were written and enforced by compliance and security teams who set down the rules as text documents. More recently, teams often use a cloud provider’s GUI to set policies. Both of these approaches are error-prone and far too slow to keep up with complex, rapidly changing infrastructure and automated systems. They also can’t take advantage of the accepted best practices for software development.

Instead, just as you define infrastructure as code, so too should you define policies as code.

What Do You Gain with Policy as Code?

The short answer to this question is that you can apply software engineering principles and approaches to your policies, just as you do with your applications and with infrastructure as code. Here are some of the specific benefits:

Clarity

Policies written as code are unambiguous pieces of logic. They can be read both by humans and by machines. There’s no way to misinterpret them, which is a real problem with text documents.

Version control

When policies are described as code, they can be checked into source control, versioned, and code-reviewed. They become a part of your automated pipelines.

Testing

As any critical system grows in complexity, people can start to feel nervous about making changes. When policies are written as code, they can be tested, just as you test your applications and infrastructure. You can integrate your policies into your automated testing system as easily as any other code you write.

Familiar tools such as IDEs

When policy is code, you can use familiar tools, such as the IDEs you use to write other pieces of code to develop new policies, refactor existing policies, and catch errors early.

Automation

As we mentioned, policy as code can be sent through your automated CI/CD pipelines for fast testing and deployment. For most companies, their infrastructure has become too large and complex to use manual procedures such as documents and GUIs to make changes.

Common Use Cases

Policies can encompass many areas. Here are just a few.

Authorization control. You can implement fine-grained access control for applications. For example, a service can make an API call to a policy engine to determine whether a request is authorized or not.
Infrastructure provisioning. You can create policies that require tagging, provisioning certain types of resources, and secure network settings.
Kubernetes control. You can manage Kubernetes resources such as pods, namespaces, and nodes. You can ensure container images come from trusted registries.
Cost control. One way to control your cloud costs is to set policies based on pricing. You can calculate the cost of a resource ahead of time and create a policy limiting the amount you spend to deploy it. For an example of how tagging on AWS can control costs, take a look at Automatically Enforcing AWS Resource Tagging Policies.

There can be many other uses. Use your imagination. Another benefit of policy as code is that it makes experimentation easy.

Learn More

Ready to learn more? With Pulumi, you can create and manage infrastructure and policies with the languages and tools you already know. To help you implement policy as code, check out this CrossGuard, our product that uses policies to enforce gated deployments. With it, administrators can apply policies to particular stacks. Any violation will gate or block an update from proceeding. Give Pulumi a try and get started for free today.

CI/CD Pipelines for Kubernetes Apps with Pulumi & Codefresh

Sophia Parafina — Tue, 19 Jan 2021 00:00:00 +0000

Delivering modern applications is complicated and requires the coordination of many moving parts. Applications are frequently updated to implement new features and improve security and performance, translating to a better user experience for your customers. To further complicate matters, infrastructure must also be deployed and maintained simultaneously with applications to avoid conflicts or dependencies.

Containerized applications deployed on Kubernetes are particularly susceptible to a misalignment between developers who frequently push changes and operators who want to maintain a stable architecture. Continuous Integration builds and tests software and delivers it as packages. Continuous Delivery or Deployment deploys applications on infrastructure. Let’s take a look at how we can accomplish CI/CD for both applications and infrastructure.

Join us for a CI/CD with Kubernetes technical session on January 21st.

CI/CD and Pipelines

CD is sometimes called Continuous Delivery or Continuous Deployment. These have the same results, i.e., deploying software artifacts to production. However, Continuous Deployment is an automated process that deploys artifacts without human intervention. Continuous Delivery occurs when a person decides when to deploy an application. The reason could be a business decision, such as coordinating the release with a marketing campaign or having a final check by an engineer before release.

Continuous integration is an automated process that begins with a code push to a repository. From there, the code can be built and tested, and eventually released as an artifact. Your organization determines the CI process, and it can include manual testing of the code to catch corner cases.

A pipeline is the deployable unit path for CI/CD. A pipeline starts when code is committed to a repository like GitHub. The next step is a notification to a build system, such as Codefresh. The build system compiles the code and runs unit tests. If your code passes the unit tests, integration tests are the next step. If your code passes both unit and integration tests, the images will be created and pushed into a registry service in the case of containers. This is the simplest example of a pipeline, but you can do many more things such as security scans, check modules for CVEs (Common Vulnerabilities and Exploits), send Slack notifications, and run quality checks. A pipeline can be fully automated or have checkpoints that require approval before resuming.

Codefresh is a modern CI/CD platform specifically created for Kubernetes and containers. A pipeline in Codefresh is composed of a series of steps, where every step is a Docker container. This means that creating a pipeline is as easy as collecting your favorite Docker images from any public or private Registry. Integration with Pulumi is trivial as Pulumi is already offered in the form of a public image.

On the deployment front, Codefresh has native integration for Kubernetes, container registries, and Git providers. This means you can set up your cluster once in a central configuration and then make it available to all your pipelines by name. Codefresh is cloud-agnostic on all fronts. All major Git providers are supported, and deployment can happen on any compliant Kubernetes cluster.

Every Codefresh account comes with a built-in graphical dashboard that allows you to inspect your Kubernetes cluster not only on the service/pod level but also on the application (i.e., Helm releases). This means that with Codefresh, you don’t need to use multiple unrelated applications to understand if your deployment was successful.

A deployment that starts from a Git commit can be monitored with Codefresh from beginning to end, following all pipeline stages from application compilation/packaging to security scanning and infrastructure deployment.

See our dedicated documentation page on how to use Pulumi and Codefresh together.

Building Modern Infrastructure

Just like your application code, you can build your infrastructure with a CI/CD pipeline. Pulumi lets developers write infrastructure using their favorite language, such as Typescript, Python, or go. Developers can take advantage of abstractions, code reuse, refactoring, favorite development environments, and testing tools.

In addition to supporting multiple languages, you can build infrastructure on any cloud such as AWS, Azure, Google Cloud, and Kubernetes and take full advantage of their service offerings. Choose your toolchain and frameworks, and you’re set to deploy infrastructure on any major cloud provider and even hybrid and on-premises environments.

By leveraging infrastructure as code combined with software development practices, engineers can achieve greater productivity while enabling their development teams to be more “self-serve” with appropriate policies and guardrails in place. Pulumi brings cloud security engineering to the infrastructure and development teams. Using one common workflow that spans any cloud environment, whether public, private, or hybrid, security teams can enforce policies that accomplish cloud governance projects of all kinds — security, compliance, cost control, and more.

To see how infrastructure as code simplifies infrastructure deployment, let’s look at an example for deploying Kubernetes with python on AWS. The full example is available on Github.

The code breaks up the Kubernetes deployment into python modules:

vpc.py creates an AWS Virtual Private Cloud containing the cluster, security group, and networking.
iam.py creates roles for the cluster, and the nodegroup and policy attachments
utils.py creates a kubeconfig file that can be used with kubectl to manage Kubernetes

The main program (main.py) creates the Kubernetes cluster by calling the modules to deploy a cluster and a nodegroup with the policies applied. Using modules, we can make changes to the vpc, networking, roles, and policies and customize it to our application. In a CI/CD, all these changes would be pushed through a pipeline before deployment.

Although this example is written in Python for AWS, there are similar examples in other languages and cloud providers in Pulumi Examples.

Putting it Together

This article described how we could build both applications and infrastructure with CI/CD pipelines. To learn more about how Codefresh and Pulumi can automate Kubernetes deployments join us for a technical session on January 21st.

re:Invent 2020 EKS Feature Releases

Sophia Parafina — Mon, 07 Dec 2020 00:00:00 +0000

Amazon announced several Elastic Kubernetes Service feature releases and updates during the first week of AWS re:Invent 2020. If we look at all the announcements as a whole, we can see the Kubernetes ecosystem maturing to make deployments and management easier for organizations. Let’s take a look at how they can benefit your use of EKS.

Amazon EKS Distro

First and foremost is the release of Amazon EKS Distro, also called EKS Anywhere. This is the same Kubernetes distro available to Amazon EKS customers on AWS as an open-source project. You can take advantage of a fully supported Kubernetes distribution built from open source with version aligned dependency updates and Common Vulnerabilities and Exposures (CVE) patches. Notifications for patches are sent from Amazon Simple Notification Service (SNS) with support for backported patches. Read more about EKS Distro here.

You can create a cluster using kubeadm, kops, or tools such as Pulumi. Learn more about creating infrastructure with EKS Distro and Pulumi on our blog.

Logging support for AWS Fargate

Amazon EKS pods running on AWS Fargate can now forward container logs to various AWS services, including Cloudwatch, S3, Elasticsearch, and Kinesis, to enable log storage and analytics. EKS with Fargate includes a native log router, eliminating the need for a sidecar. You can use ConfigMap to send routers to the service of your choice. Read more about it on the AWS blog post.

Simplified install and management for Kubernetes CNI plugin

Amazon EKS now supports installation and management of the VPC CNI. The AWS VPC CNI provides integrated AWS Virtual Private Cloud (VPC) networking for Kubernetes clusters. You can use AWS VPC networking and security best practices for building Kubernetes clusters that include VPC routing policies and security groups for network traffic isolation.

You can install and manage the CNI plugin with the Amazon EKS console, CLI, and API. Previously, you needed to install and maintain it manually after a Kubernetes upgrade. Amazon EKS lets you install, manage, and through the EKS console, CLI, and API, where it is validated by AWS and can be deployed and updated. To learn more, read the announcement.

EC2 Spot Instances in managed node groups

Spot Instances are deeply discounted On-Demand EC2 instances. EKS now supports using Spot Instances with EKS managed node groups. If you are running batch process such as ETL with Apache Spark or stateless endpoint, Spot Instances are a cost-effective way for managing surge requests in EKS.

Previously, to use Spot Instances, you had to manually configure EC2 Auto Scaling groups and upgrade the Spot nodes to the current version of Kubernetes. You can now set capacity type as SPOT and the EC2 instance types when creating a managed node group. The managed node group will provision and manage Spot nodes automatically according to best practices. You can create the node group through the EKS console, the EKS API, and eksctl. To learn more about configuring EKS node groups with Spot Instance, read the blog.

Want some hands-on training with EKS? Join our workshop on Thursday, December 10th where you will create a production-ready EKS cluster, install add-ons to prepare your cluster for developers, and finally ship an application to your cluster. Register Now

Benefits of Policy as Code

Sophia Parafina — Wed, 27 May 2020 00:00:00 +0000

Writing infrastructure policy in a high-level programming language helps automate and enforce best practices. When policies are written with code, you can apply software development practices such as testing, automated deployment, and version control. Cloud providers typically offer a GUI to create policies, but creating policies is not easily repeatable, nor can you version policies. Moreover, policies must be tested against a live system, which means using an existing system or configuring and deploying an ephemeral version.

While the benefits of writing policies as code are evident for developers and operators, the organizational benefits are even more significant. Organizations can realize cost savings, improved compliance, efficient deployments, fine-grained control over infrastructure, and better use of cloud provider native resources. Let’s take a look at these benefits in-depth.

Controlling Costs

A sizeable monthly cloud bill due to unused resources left running or using over-sized instances for small tasks is an industry cliché. One way to control costs is to set policies based on pricing. With pricing data online, we can calculate the cost of a resource ahead of time and create a policy that limits the amount spent to deploy it. In a previous article), we provided an example policy that finds all the resources in a deployment and calculates the total monthly cost. The policy sets the monthly cost permitted and sends a warning if the deployment exceeds it.

But what about unused or abandoned resources? We can use a cloud provider’s resources to implement a watchdog function with a policy that cleans up unused resources. In this article, we show how to use a serverless function to find unused resources daily and shut them down. We implemented this system at Pulumi and reduced our operating costs by 64%.

We can use cloud provider native tools and practices in combination with policy to control costs. Using AWS as an example, Joe Duffy wrote an article on using tags for cost tracking, automation, and organization. If you are not familiar with tags, they are a simple key/value pair applied to a resource. Tags let you manage, search, and filter resources.

The article showed how you could use your favorite programming language to tag a resource to enable cost tracking by project, stack, and cost center. Joe then demonstrated how to use policy as code to enforce tagging of resources when they are created. The article also shows how to automatically tag resources and enables resources to pass the tagging policy.

Compliance

Policy as Code is a way to enforce infrastructure policies that prevent inadvertent access to resources such as databases and storage or to enforce cost policies.

Controlling access to resources is basic infrastructure security. Leaving services open to the internet is less of a problem in production, but what about development environments? Developers often have much leeway to deploy resources when build a new application; similarly, testing environments maybe less secure than production. Furthermore, development instances may remain inadvertently available long after they have been used for development.

Controlling ingress and egress to and from resources and not exposing them on the Internet is a best practice. Policies that run at the level of the organization can mitigate the likelihood of unauthorized access to resources or even data breaches. Regardless of the type of environment, whether its dev, test, production, Policy as Code can enforce best practice across the organization.

Another area of concern is securing your software supply chain. Although your infrastructure runs on a cloud provider, it is not exempt form vulnerabilities as shown by CVE-2020-8835 which allows container escape to get root privileges on the host node. On Google Cloud, nodes running on Ubuntu running Kubernetes 1.16 and 1.17 were affected. You can write a policy that checks the version of GKE and prevents those version from being deployed.

Validate Before or During Deployment

One of the shortcomings of using a cloud provider GUI to create policies is that they can only be tested on deployed resources. One solution is to implement an ephemeral environment for testing, but this incurs resource costs as wells as time spent deploying. A feature of Pulumi’s deployment engine is that it constructs a preview of the resource graph. When it creates the preview, it also tests if resources are compliant with the included policies. The policies are run before a resource is registered, and inputs (configuration parameters) are validated. Out-of-compliance resources are blocked from being created or modified by the policy.

There are cases where it is necessary to deploy a resource to test policy; for example, a resource property is required to provision another resource. For these instances, the Pulumi engine supports testing either the entire stack or selected resources. This is analogous to integration testing vs. unit testing. You can run policies against a stack as a whole, i.e., when all resources are registered and will not prevent resources that are out of compliance from being created.

In either case, your infrastructure is validated before it’s deployed, saving both time and money.

Best Practices as Policies

All cloud providers offer a set of best practices for deploying resources. Best practices can be implemented as policies, but instead of managing them as individual policies, wouldn’t it be more efficient to organized similar policies as a bundle? This is the idea behind Policy Packs. They provide a way to group similar policies based on how you manage your infrastructure. For example, you may have several policies for storage based on how they are tagged. Policy packs don’t restrict which policies you combine; you can have Kubernetes policies bundled with container registry policies. You create Policy Packs according to the requirements and needs of your organization.

You can apply a Policy Pack to a single stack of resources or across multiple stacks. A group of stacks that use the same Policy Pack is a Policy Group. Note that a stack can belong to multiple Policy Groups. A typical application of Policy Groups is to set policies for environments; for example, you might have a more permissive Policy Group for your development and staging environments and more restrictive one for production.

Policy as code enables you to deploy best practices as policies. Moreover, you can organize policies in bundles or Policy Packs based on your organizational requirements. This provides repeatable and fine-grained control over the resources you deploy. You can apply Policy Packs on individual resource stacks or across multiple stacks as Policy Groups, giving you granular control over how and which resources are deployed.

Working with Cloud Native Resources

Cloud providers have methods for managing access to resources such as IAM (Identity Access and Management) policies and ACL (Access Control Lists). This is one type of policy, but it doesn’t cover the full range of actions available for managing your infrastructure. Pulumi uses cloud provider APIs to build and maintain infrastructure. The Pulumi engine works with cloud provider resources in conjunction with Policy as Code.

In a previous article, we demonstrated how to use the IAM Access Analyzer in conjunction with Policy as Code. IAM Access Analyzer validates all resources per-region with a single analyzer. It creates a record for each problem identified and shows which policy is responsible for granting wider access to resources than would be best practice. Policy as Code applies policy packs to stacks of resources anytime infrastructure is deployed.

The IAM Access Analyzer works on deployed resources, so in the example, we have to deploy the infrastructure first before running the analyzer using a Pulumi program. When the scan of a resource is complete, it returns the detailed results that we can pass to the policy for validation. In this way, we can use cloud provider native tools in conjunction with Policy as Code to manage and protect our infrastructure.

Conclusion

We often talk about Policy as Code in terms of repeatability, versioning, and testing, which benefits developers and operators directly. The benefits extend beyond DevOps and into the success of an organization. Policy as Code provides the following organizational benefits:

means for automated cost control,
compliance to avoid downtime by securing resources,
validating infrastructure before creating resources (another cost-saving measure),
encoding best practices for resource stacks,
and working with cloud provider native resources to provide best of breed security and granular control.

Learn more about using programming languages for Policy as Code with our docs.

Manage DigitalOcean Kubernetes Clusters and Workloads

Joe Duffy — Mon, 30 Sep 2019 00:00:00 +0000

We recently partnered with DigitalOcean to publish a new tutorial, How to Manage DigitalOcean and Kubernetes Infrastructure with Pulumi. This short tutorial walks you through provisioning a new DigitalOcean Kubernetes cluster, deploying an application to it, and then assigninging a stable domain name to your application’s load balancer — all in a handful of lines of infrastructure as code.

By using infrastructure as code to provision and update your infrastructure, it’s easy to create new environments, modify or scale existing ones, or automate your deployments using continuous delivery. This approach also ensures that deployments are reliable and repeatable, and can even standardize how you deploy code to different cloud providers, including DigitalOcean, AWS, Azure, GCP, and others.

We regularly talk to developers who appreciate the simplicity of working with DigitalOcean. This new tutorial spins up an entire, fully functioning managed Kubernetes environment in just 6 minutes, for instance, giving you more time to focus on application logic and less on your infrastructure configuration. In addition to managing Kubernetes clusters and applications, you can also provision Droplets, LoadBalancers, and any other DigitalOcean resource type, using a similar infrastructure as code approach. For more information on doing so, read Getting Started on DigitalOcean with Pulumi.

Finally, for more detailed information on all of the DigitalOcean resources supported, please consult the DigitalOcean API docs.

Most importantly, have fun getting up and running with DigitalOcean Kubernetes in just a few minutes!

ECS vs Fargate vs EKS: The Lowdown on Containers in AWS

Joe Duffy — Thu, 20 Jun 2019 00:00:00 +0000

Some of the code in this post is out of date. See the AWS guides for an updated overview and examples.

An updated breakdown of when to prefer Fargate and when EC2 can be found in Fargate vs EC2

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.

The Options: ECS vs Fargate vs EKS

At Pulumi, we work with customers to deploy AWS applications all the time, from early development to scaling production environments worldwide, using infrastructure as code and often continuous delivery. During this, we’ve run across a breadth of container workloads and requirements, and developed best practices, which this article distills into some basic advice. As with any advice, the right answer depends on your scenario’s specific requirements.

Here are the three major options, roughly speaking from easiest to hardest:

Option 1 - ECS Fargate

Amazon ECS with Fargate launch type allows you to deploy and scale your containerized workloads, automatically, without needing to manage clusters of EC2 instances by hand. You focus on your Dockerized applications, with minimal extra declarative metadata about the requirements of those applications, and not the details of the underlying compute itself. One could say this is “serverless containers.” Of course, there are servers running your containers, however the ECS control plane makes informed decisions on your behalf about when to add capacity, where, and by how much.

To run a workload in ECS, you use a standard Dockerfile to author, build, and publish your container image, and then run that image inside your ECS cluster. Tasks and services are authored using ECS definitions, which specify the container image to run, instance count, and any CPU, memory, networking, and disk requirements your workload has.

Using Pulumi, these definitions can be easily expressed declaratively in code, like so:

import * as awsx from "@pulumi/awsx";

// Create a load balancer on port 80 and spin up two instances of Nginx.
const lb = new awsx.lb.ApplicationListener("nginx", { port: 80 });
const nginx = new awsx.ecs.FargateService("nginx", {
 taskDefinitionArgs: {
 containers: {
 nginx: {
 image: "nginx",
 memory: 128,
 portMappings: [ lb ],
 },
 },
 },
 desiredCount: 2,
});

// Export the load balancer's address so that it's easy to access.
export const url = lb.endpoint.hostname;

This example runs 2 load balanced instances of an NGINX web server using ECS Fargate.

ECS Fargate is often a great choice when getting started, when you don’t have stringent requirements around cost, and/or if you’re a small to medium sized organization who prefers simpler solutions. Many teams are successful running it scale too, however Fargate doesn’t give you as much control over persistent storage, privileged containers, custom scheduling, or special VM types like GPUs or FPGAs. For those, EC2 backed ECS is a better choice.

Option 2 - ECS Backed by EC2 Instances

Amazon ECS with EC2 launch type gives you similar capabilities to ECS managed by Fargate – in that you can deploy containerized workloads, declaratively specify their requirements, and let ECS do the placement and overall scheduling of them – but with full control over the compute environment those containers run in. That includes control over the precise numbers of servers, AMIs they are running, and their auto-scaling policies.

To use an EC2 backed cluster, you will need to create a cluster and configure the EC2 launch and autoscaling configurations, and then simply use the awsx.ecs.EC2Service class to create your service instead. Other than these differences, the resulting code would look very similar to Option 1 - ECS Fargate above.

For sophisticated AWS organizations who already know how to fine tune and run compute at scale efficiently and cost effectively, managing your ECS cluster’s EC2 instances explicitly is often a good choice. The good news is that you can easily start with Fargate, and then over time, shift to managing the EC2 compute by hand if you prefer. Managing your cluster amounts to managing fleets of EC2 instances, CloudWatch logging, and standard AWS services.

Option 3 - Elastic Kubernetes Service (EKS)

Amazon Elastic Kubernetes Service (EKS) offers a very different approach to running containerized workloads than ECS Fargate or EC2. EKS is a fully managed offering that runs Kubernetes inside of your AWS account, making it easier to operate Kubernetes, in addition to integrating with many AWS services like ELB for load balancing, IAM for cluster authentication, and CloudWatch for logging and diagnostics. Using EKS, you don’t need to explicitly provision, manage, and upgrade the Kubernetes control plane’s configuration, compute, and storage.

Kubernetes is an open standard for running containers across a variety of public and private cloud environments. Most public cloud vendors now offer an EKS-like managed offering, including Azure (AKS), Google Cloud (GKE), and Digital Ocean, and the availability of on-premises private cloud configurations enables hybrid cloud for large organizations. Kubernetes in inherently more complicated to operate than the equivalent ECS solutions mentioned earlier, because it requires becoming an expert in Kubernetes, which requires more specialization in its tools and management practices. But the potential payoff is larger for organizations wanting to go “all in” on cloud native technologies to facilitate either multi-cloud or hybrid computing – challenges most large enterprises are facing today.

In the EKS case, as with ECS, we continue using standard Dockerfiles, however we use the Kubernetes object model to configure and run workloads. Instead of task definitions, you use Kubernetes objects like Namespaces, Pods, Deployments, and Services. This full API is available to specify in code using Pulumi, like so:

import * as eks from "@pulumi/eks";
import * as k8s from "@pulumi/kubernetes";

// Create an EKS cluster with the default configuration.
const cluster = new eks.Cluster("my-cluster");

// Deploy a small canary service (NGINX), to test that the cluster is working.
const appName = "my-app";
const appLabels = { appClass: appName };
const deployment = new k8s.apps.v1.Deployment(`${appName}-dep`, {
 metadata: { labels: appLabels },
 spec: {
 replicas: 2,
 selector: { matchLabels: appLabels },
 template: {
 metadata: { labels: appLabels },
 spec: {
 containers: [{
 name: appName,
 image: "nginx",
 ports: [{ name: "http", containerPort: 80 }]
 }],
 }
 }
 },
}, { provider: cluster.provider });
const service = new k8s.core.v1.Service(`${appName}-svc`, {
 metadata: { labels: appLabels },
 spec: {
 type: "LoadBalancer",
 ports: [{ port: 80, targetPort: "http" }],
 selector: appLabels,
 },
}, { provider: cluster.provider });

// Export the URL for the load balanced service.
export const url = service.status.loadBalancer.ingress[0].hostname;

// Export the cluster's kubeconfig.
export const kubeconfig = cluster.kubeconfig;

Like the ECS example earlier, this spins up 2 load balanced instances of the NGINX web server.

You will find that the entirety of Kubernetes is more feature rich and offers more control over scheduling and scaling your workloads, but with that richness also comes added complexity that will increase training, and time to ramp up, in addition to ongoing maintenance costs. To learn more about Pulumi’s support for Kubernetes, go here.

Private ECR Container Registries

In all of these cases, Amazon Elastic Container Registry (ECR) lets you publish Docker container images to a privately hosted repository inside your AWS account. The benefit of this is that images are stored within your AWS account, where access is governed by IAM and, where they are stored closer to your workloads (maximizing push/pull efficiency). This is an alternative approach to, say, publishing images to the Docker Hub which entails a different authentication and pushing and pulling images over the Internet, where performance can be an issue.

Next Steps

Pulumi Crosswalk for AWS supports three main options for running containers in AWS – ECS Fargate, ECS with EC2 instances, and EKS – each of which integrates deeply with other AWS services like IAM, ELB, and CloudWatch. It’s possible to use any of these services without Pulumi, but there are many benefits to Pulumi’s infrastructure as code.

In short, to get your containers up on AWS, in an easy yet production-ready way, get started for free with Pulumi for AWS today!

After getting started, here are some additional resources to go deeper on specific topics:

Pulumi: A Better Way to Kubernetes

Levi Blackstone — Tue, 21 May 2019 00:00:00 +0000

Kubernetes is a powerful container orchestrator that is being adopted rapidly across the industry. At the same time, it is notoriously complex and presents a steep learning curve for newcomers. Nobody likes programming in YAML, and templates make it even harder. It’s difficult to understand the state of the cluster – Did my deployment succeed? Why isn’t my app working? And we often need to manage hosted cloud resources in addition to Kubernetes ones.

In this post, we will see how Pulumi can help you tame these issues and make Kubernetes more accessible, using familiar languages and your favorite tools. It’s simply Kubernetes made easy!

Clusters as code

Pulumi can seamlessly manage multiple layers of your stack, from the raw infrastructure to Kubernetes resources, and all the way up to serverless app code. Rather than gluing together yet another set of tools, you can create managed Kubernetes clusters with GKE, EKS or AKS and then reference them directly in your Pulumi code!

Apps as code (not YAML!)

Pulumi exposes the full API surface of Kubernetes as classes in your SDK, so you can manage any k8s resource (including CRDs and related CustomResources) in your Pulumi code. Stop trying to work around the limitations of YAML with templates, and reap the benefits of real software development practices: abstraction, conditionals, looping, library support, packaging, testing, debugging, and more! From the obvious (use variables to manage resource metadata, to the more esoteric (gate a canary deployment with Prometheus, Pulumi keeps the simple things simple, and makes the hard things possible.

Integrate with existing Helm charts or manifests

Most projects aren’t greenfield apps, and we know it’s critical to support an incremental transition when you switch tools. Our SDKs allow you to import Helm charts and YAML manifests and then mix and match these resources within your Pulumi program. While you can keep it simple and just import the resources, you have the full power of a programming language at your disposal. Why fight with a complicated YAML templating scheme when you can accomplish the same thing (and much more) with a real programming language? Take advantage of 60 years of software engineering know-how to make your deployments more reproducible and maintainable.

Make full use of your cloud

While you can run stateful workloads on Kubernetes using StatefulSets, it’s often better to use a managed service from your cloud provider. Since Pulumi can manage cloud resources as well as k8s resources it’s easy to bridge that gap! Try adding in a managed database, message queue or object store, and see how much simpler your k8s app can be. When your app is already running in the cloud, think outside of k8s, and use the power of the cloud! It’s far easier to maintain an app at scale if you strategically mix in managed cloud resources.

Debugging failures

It can be daunting to troubleshoot failures in Kubernetes, especially for new users. What happens after I run kubectl apply? Why is my app not working? Even with a detailed guide to follow, it can feel like playing 20 questions with kubectl to get the answers you need. Pulumi’s Kubernetes provider includes sophisticated logic to check resource readiness, and proactively surfaces errors during updates. With Pulumi, it’s far easier to understand the state of your k8s resources, and get the information you need to make changes when something goes wrong.

Integrating with CI/CD

Kubernetes uses an eventual consistency model that can be difficult to integrate with CI/CD systems. How do you know when your application is ready? Common workflows involve scripting kubectl calls and parsing JSON output in Bash. This approach is brittle, and the process is a little different for every Kubernetes resource type. Pulumi’s state reconciliation model is a natural fit for CI/CD systems: review changes with a preview, and then proceed with confidence once an update succeeds. This is great for GitOps and ChatOps workflows. You don’t have to be an expert on the inner workings of Kubernetes to be productive with Pulumi.

Since you can manage a full infrastructure stack with Pulumi, you can create infrastructure on demand (k8s cluster, databases, networking, object storage, etc.), spin up your application, run tests, and then tear the whole stack back down! This saves you money and builds confidence that you can recover from disaster scenarios.

Learn more

If you’d like to learn about Pulumi and how to manage your infrastructure and Kubernetes through code, click here to get started today. Pulumi is open source and free to use.

As always, you can check out our code on GitHub, follow us on Twitter, subscribe to our YouTube channel, or join our Community Slack channel if you have any questions, need support, or just want to say hello.

If you’d like to chat with our team, or get hands-on assistance with migrating your existing configuration code (including ksonnet programs) to Pulumi, please don’t hesitate to drop us a line.

If you liked ksonnet, you'll love Pulumi!

Mike Metral — Wed, 13 Feb 2019 00:00:00 +0000

This article references ksonnet, which was deprecated in 2019. For the most up-to-date information on using Pulumi with Kubernetes, see our Kubernetes documentation.

The Kubernetes landscape is constantly evolving as end users and developers search for the right tools, approaches, and abstractions to help them manage Cloud Native infrastructure in production.

On Feb 5, Heptio (now part of VMWare) announced that work on ksonnet, a project launched by Heptio, Box, Microsoft, and Bitnami, will stop. We’re sad to see ksonnet winding down, but are thankful for the collaborative exchange of ideas between projects, and are excited to see continued investment in VMWare/Heptio’s other projects. The good news is that, if you liked ksonnet, we’re confident that you’ll love Pulumi. In this post, we’ll tell you why.

Recap of ksonnet’s Approach

In the original ksonnet launch post, Joe Beda describes the “wall of YAML” that we face when creating and configuring Kubernetes systems. This intimidates new users, making for a steep learning curve, while also leading to thankless boilerplate and copy-and-paste for the most experienced users. Systems like Helm have attempted to solve the problem by adding templates to YAML.

ksonnet, instead, introduced a new DSL – based on work from Google on the Jsonnet language (itself influenced by experience internally on Borg) – with more “language like” functionality, that could generate configuration. The result was a feature set that included:

Local variables
Functions and lambdas
Modules and imports
Mixins
Configuration concatenation and merging
Template parameterization

The idea is that you can author richer configuration in ksonnet, and from that, simply generate and apply stock Kubernetes configuration, without Kubernetes needing to know about ksonnet.

Recap of Pulumi’s Approach

Pulumi was inspired by many of the same challenges as ksonnet, but from a slightly broader perspective. As we surveyed the landscape of configuration languages, we found a bewildering array of them: plenty of stock YAML, but also JSON and YAML with “built-in” templating mechanisms (AWS CloudFormation and Azure Resource Manager Templates), templating systems bolted on top of JSON and YAML (Helm Charts), and new DSLs (Terraform), to name just a few. To add to the complexity, many engineers have to stitch multiple of them together or regularly switch between different dialects in an increasing multi-cloud environment.

Instead of creating another DSL, we wondered: Why not use languages we’re already familiar with? Is there some inherent reason that’s incompatible with configuration languages? The answer was no, it seemed to us. While Infrastructure-as-Code is based on the idea of a declarative goal state, we realized that it’s possible to use imperative languages to create that state.

By using languages like JavaScript, TypeScript, Python, and Go, we would immediately see many benefits:

All of the powerful language capabilities they already have (including the ksonnet list)
Instant access to entire package ecosystems (NPM, PyPI, etc)
Great IDE support, including integrated API documentation, syntax highlighting, statement completion, inline errors, and refactoring
Ability to test, lint, and statically analyze code using existing tools

But we didn’t want to just generate configuration files. There are systems out there that generate a configuration from languages like Python. In our experience, the underlying configuration system and its limitations always leaks through, quickly ruining the ease-of-use benefits. So, we built an engine that has a full cloud object model across providers, can diff resources, applies updates using robust Infrastructure-as-Code techniques, and provides rich status reporting.

A short tour of Pulumi for ksonnet users

Just like in ksonnet, Pulumi provides access to the complete raw Kubernetes API, so you can do everything that Kubernetes supports - but using programming languages that provide completion lists, error checking, inline documentation, and basic features like variables and control flow. Here’s an example of part of a direct port of the Guestbook example to Pulumi:

Also like in ksonnet, in Pulumi we can introduce additional features like modules/imports, components, functions, and more to structure our code and increase the level of abstraction that we work at as we author our Kubernetes configuration. This example shows the Guestbook app re-written using higher-level components in Pulumi, and you can see similar approaches to those used in the similar example with ksonnet… and just using TypeScript instead of bespoke DSL:

Unlike with ksonnet though, Pulumi programs are deployed using the pulumi CLI, which provides rich feedback on the progress a deployment is making toward being complete (as well as feedback when things go wrong!).

And finally, a major area where Pulumi goes beyond ksonnet in scope, it works with public and private cloud resources as well as Kubernetes, enabling deployment of Kubernetes resources and AWS/Azure/GCP resources using a single deployment workflow. For example, you can stand up a managed Kubernetes cluster and deploying a Helm chart to it.

[

Another fun example is provisioning and consuming an Azure CosmosDB from within your Kubernetes app.

Learn More

If you’d like to learn about Pulumi and how to manage your infrastructure and Kubernetes through code, click here to get started today. Pulumi is open source and free to use.

If you’d like to go deeper on certain topics, here are some additional resources to check out:

Overview of Pulumi Kubernetes Scenarios
Tutorial: Create a Kubernetes cluster on a cloud provider Amazon EKS, Google GKE, or Azure AKS
Tutorial: Operate and deploy to a Kubernetes cluster
Docs: Pulumi docs, including an overview of the programming model
Video: In February, we were honored to have Joe Beda show where Pulumi fits in on his TGIK livestream, highlighting how to use your favorite language and consistent workflows to create, deploy, and manage cloud resources across multiple clouds and Kubernetes. Watch Joe Beda take Pulumi for a spin here.

If you’d like to chat with our team, or get hands-on assistance with migrating your existing configuration code (including ksonnet programs) to Pulumi, please don’t hesitate to drop us a line.

Delivering Cloud Native Infrastructure as Code

Marc Holmes — Wed, 05 Dec 2018 00:00:00 +0000

Enterprise software has undergone a slow shift from containerless servers to serverless containers.

The evolution of the cloud, combined with the shift to increasingly ephemeral infrastructure, and the connection of application code and infrastructure code, demands a different view of cloud development and devops.

To a first approximation, all developers are cloud developers, all applications are cloud native, and all operations are cloud-first. Yet, there is a lack of a consistent approach to delivering cloud native applications and infrastructure. The tools and processes differ by technology generation, and even by cloud vendor, and so deny the full potential of cloud native application delivery.

In our latest white paper, Delivering Cloud Native Infrastructure as Code, we make the case for a consistent programming model for the cloud and examine:

How the cloud has already evolved three times as it increasingly moves toward stateless compute to deliver on the opportunities afforded by unprecedented economies of scope and scale.
How stateless compute has shifted infrastructure management concerns from ‘at rest’ to ‘in motion’, and moved these concerns up the stack to development.
How the growth of DSL-based tools has lead to complexity for DevOps teams, failed to deliver on the promised collaboration between development and operations functions, and does not satisfy the need for increasing delivery speed in the cloud.

You can read the paper in full here.

Let us know what you think!