Pulumi Blog: Multi cloud

AI infrastructure on tap with the Pulumi AICR provider

Peter Yoakum — Mon, 19 Oct 2026 00:00:00 +0000

Recently, some members of the Pulumi team spent time in San Francisco attending the CoreWeave: Fully Connected 2026 conference, where we had a chance to talk to everyone from solo developers to engineering leaders at Fortune 500 organizations and learn more about how they are building with AI.

A frequent topic of conversation was open weight models and self-hosted inference. Whether AI is integrated into your platform, your product, or your productivity pipelines, rising token costs have decision makers everywhere giving open weight models a closer look, in exchange for the promise of tighter control over spend and greater domain expertise.

If you are actively exploring the space or building with AI yourself, you may already have seen the challenges that come with serving inference at scale:

Model stability and reliability can differ (sometimes dramatically) across hardware architectures and at different traffic volumes.
Model performance and throughput can change depending on your workload type or model configuration.
Cost differences and commitments across providers can make tracking spend challenging.
Supply constraints and capacity shortages mean teams can’t source hardware when they need it most.

Many teams naturally gravitate toward multicloud strategies that combine hyperscalers with specialized GPU clouds as a way of balancing spend, performance, and reliability. One thing we’ve seen is that developers everywhere are choosing Pulumi to help them navigate the fragmented hardware ecosystem and maintain consistent environments, even when the provider is different.

As part of our ongoing commitment to building better tools for builders, we’re excited to announce the Pulumi NVIDIA AI Cluster Runtime (AICR) provider to help make your ideal self-hosted AI infrastructure available on demand. The Pulumi AICR provider lets you spin up workload-specific training and inference endpoints as you need them, configured with pre-validated recipes to match your workload with the right hardware across a number of cloud-based GPU providers.

AI performance-engineering team as code

Deploying a cluster of GPU nodes as a production AI platform is a complex and time-consuming exercise that often requires specialized expertise. NVIDIA’s AICR offers a collection of validated GPU infrastructure recipes for various cloud providers. By building a provider around AICR, Pulumi offers an efficient and reliable way to manage your GPU clusters, dramatically shortening time to first token.

In addition to bundling a complex technology stack, Pulumi makes it simple to deploy with minimal verbosity. pulumi preview shows every component the recipe expands into (namespaces, operators, schedulers, metrics, training runtime) before anything is applied. pulumi up then deploys them as children of a single resource, with a full day-2 lifecycle: diff, update, drift detection, and destroy.

This short Python snippet shows how easy it is to use AICR to deploy a simple pre-validated inference endpoint without wasting time or resources on guess-and-check configuration, so you can get started serving production traffic immediately.

import pulumi
import pulumi_labs_nvidia_aicr as aicr

config = pulumi.Config()
service = config.get("service") or "lke"
accelerator = config.get("accelerator") or "rtx-pro-6000"

# The CoreWeave Kubernetes Service (CKS) kubeconfig is a plain token config downloaded 
# from the CoreWeave console and placed in the same directory as this script (gitignored).
with open("kubeconfig.yaml") as f:
 kubeconfig = f.read()

gpu_stack = aicr.ClusterStack("nvidia-aicr",
 kubeconfig=pulumi.Output.secret(kubeconfig),
 accelerator=accelerator,
 service=service,
 intent="inference",
 nodes=2,
 skip_components=[
 "gpu-operator",
 "nfd",
 "nvidia-dra-driver-gpu",
 ],
 skip_await=True,
)

Deploying an inference endpoint to CoreWeave with the Pulumi NVIDIA AICR provider

Behind the scenes, the recipe resolves the code into the full list of Kubernetes components. Recipes are tested and validated by NVIDIA across a broad matrix of both hardware (EKS, GKE, and AKS; A100 through GB200; Ubuntu, RHEL, COS, and Talos; Kubeflow, NIM, Dynamo, Slurm, and Run:ai) and cloud provider permutations. Because AICR is open source, the SDK lends itself to configuration by new providers, giving you a future-forward inference solution that performs in all of the areas that count:

Deployment: does the running cluster match the recipe? Operator health, GPU visibility via nvidia-smi, and metrics flowing.
Conformance: dynamic resource allocation, gang scheduling, and job-level networking behave as required.
Performance: NCCL all-reduce bandwidth for training; model throughput and latency for inference.

Interested in learning more about how Pulumi can help you scale your AI infrastructure? Join the Pulumi Community Slack and the hundreds of builders there, and get help crafting your dream infrastructure today.

Self-driving infrastructure with Pulumi and Jev

Peter Yoakum — Mon, 28 Sep 2026 00:00:00 +0000

It’s been a weirdly great time to be building software. We’ve never had so many tools that help us get things done: endless cloud providers, regions, deployment frameworks, and now AI agents that can actually build and manage infrastructure for us. That’s part of what made this past week feel so big. TypeSafe AI opened early access to Jev, their SystemOne model, and we here at Pulumi were bitten by the excitement bug and got straight to work building.

Almost immediately we were able to whip up some test agentic workflows that were making real, live decisions about infrastructure. If you’re not familiar with TypeSafe’s Jev, it comes with a powerful set of AI primitives that let your apps, agents, and workflows make decisions based on context.

Jev’s decision-making primitives are the perfect complement to agentic work.

When you combine that reasoning power with Pulumi, the gap between dreaming up your ideal infrastructure and deploying it to production practically vanishes.

In the past, having more choices usually meant dealing with more complexity, which added technical debt and inevitably meant someone (perhaps you) spent hours setting things up. Now you can let agents handle provisioning and the day-to-day scaling and reliability decisions while you stay focused on defining how your infrastructure should work.

Okay, but how does it work?

Our example, GeoDeploy, answers one question: my users are in these places and I have this container image, so where should it run and what will it cost? Then it builds the answer.

You give it a deployment request with four parts:

Target geos: where your users are, what share of traffic each place sends, and any data-residency rule (EU-only, US-only, or in-country).
An image: a container image and the platforms it’s built for (amd64, arm64, or both).
A workload shape: replicas, CPU and memory per pod, egress, and storage.
Constraints: which providers are allowed, how many providers you’ll tolerate, and a budget.

From there, GeoDeploy compares every AWS, Azure, and Google Cloud region that offers managed Kubernetes, picks the best one for each geo, and provisions consistent environments across all three hyperscalers.

Three systems, three jobs

The design principle that makes this work is a strict division of labor:

System	Job	Never does
TypeScript app	Takes in the request, fetches live pricing, does all the math	Make judgment calls
Jev	Decides which region wins and which modules to use	Do arithmetic, generate code, or invent region names
Pulumi	Provisions clusters, registries, workloads, and DNS	Decide anything

Here’s how a request flows through the pipeline:

Normalize the geos. Each business region (geo) is mapped to a canonical location and residency class.
Enumerate candidates. GeoDeploy lists every region with managed Kubernetes and uses great-circle distance as a coverage measure.
Fetch live prices. Current prices come from the AWS Price List API, the Azure Retail Prices API, and the Google Cloud Billing Catalog, normalized into a single quote format.
Do the math. Plain, deterministic TypeScript bin-packs pods onto nodes, filters out instance types that don’t match the image’s architecture, and computes a monthly cost for each candidate.
Decide. Jev picks the winning region and modules for each geo (more on this below).
Compose. GeoDeploy assembles a Pulumi program from a curated registry of typed modules: EKS, AKS, or GKE; ECR, ACR, or Artifact Registry; ingress; DNS through Route 53, NS1, or Cloudflare; and observability.
Provision. The Pulumi Automation API runs a preview and then an update, with one stack per region. It won’t run at all unless your cloud credentials pass readiness checks.
Report. Every run writes a plan.json and plan.md with the full decision record, and a web UI shows the deployment on a live globe.

Why Jev, and not a general-purpose LLM?

Jev doesn’t return free text. It returns typed answers with calibrated confidence, through three primitives:

choice() picks one option from a closed list and returns the pick, a probability distribution across all options, and a confidence.
score() rates something against a rubric you describe (GeoDeploy uses 10 levels).
noul() answers a yes/no question with a single probability.

The core rule is that Jev only ever selects from closed sets. It chooses among region IDs that GeoDeploy has already priced and checked. It never writes code or does arithmetic, so a hallucinated us-west-9 or a made-up Pulumi argument can’t happen by construction.

For each geo, GeoDeploy sends Jev a shortlist of up to 40 priced candidates, along with the constraints and the image’s architecture. In a single call, it asks for:

A selection (choice): which region should serve this geo?
Five quality scores (score): coverage, cost fit, maturity, sprawl risk, and architecture consistency.
Two hard checks (noul): is data residency satisfied, and is there enough capacity?
A fallback (choice): a backup region in case the primary fails at apply time.

Here’s what that looks like in packages/decide/src/questions.ts (trimmed):

import { choice, noul, score } from "@typesafe-ai/sdk";

export function buildStageAQuestions(shortlisted: CandidateCost[]) {
 // "aws:us-east-1" -> { monthlyUsd, distanceKm, azCount, gaStatus, complianceFlags, ... }
 const options = candidateOptions(shortlisted);
 return {
 selection: choice("Which candidate region should serve this demand geo?", options),

 coverage: score("How well does the selected region cover this demand geo's users?", COVERAGE_LEVELS),
 costFit: score(
 "How favorable is this candidate's monthly cost relative to the cheapest alternative in the shortlist?",
 COST_LEVELS,
 ),
 // ...maturity, sprawlRisk, archConsistency

 residencyOk: noul("Does the selected region satisfy the stated data-residency constraint for this demand geo?", {
 true: "The region's jurisdiction and compliance flags fully satisfy the demand geo's residency class ...",
 false: "... or residency cannot be confirmed from the given compliance flags.",
 }),
 // ...capacityOk

 fallback: choice(
 "If the top-ranked candidate becomes unavailable at apply time, which candidate is the best substitute?",
 options,
 ),
 };
}

The options passed to choice() are the priced candidates themselves, keyed by ID, so Jev literally can’t answer with a region that isn’t on the list. The rubrics follow TypeSafe’s advice to “describe situations, not degrees.” Instead of “good coverage,” each of the 10 levels is a concrete scenario, running from “Serves users on a different continent with no nearby presence” up to “In-geo with multiple availability zones, directly in or adjacent to the demand geo’s primary population center.”

The whole question set goes out in one call, along with the state Jev reasons over:

const client = new TypeSafeClient();
const resultA = await client.systemOne({ state: toState(stateA), questions: questionsA });
const a = resultA.answers;
// a.selection.choice, a.selection.confidence, a.residencyOk.noul, a.coverage.score, ...

The five scores feed a ranking system that runs on weight profiles (latency-optimized by default, plus balanced, residency-first, and failure-domain). Because the weights live in code, we can re-tune the ranking without calling Jev again:

// composite = W.cost*norm(costFit) + W.coverage*norm(coverage) +
// W.maturity*norm(maturity) + W.archConsistency*norm(archConsistency) -
// W.sprawl*norm(sprawlRisk)
export const WEIGHT_PROFILES: Record<WeightProfileName, CompositeWeights> = {
 "latency-optimized": { cost: 0.13, coverage: 0.48, maturity: 0.17, sprawl: 0.1, archConsistency: 0.12 },
 balanced: { cost: 0.25, coverage: 0.25, maturity: 0.2, sprawl: 0.12, archConsistency: 0.18 },
 "residency-first": { cost: 0.12, coverage: 0.12, maturity: 0.38, sprawl: 0.23, archConsistency: 0.15 },
 "failure-domain": { cost: 0.08, coverage: 0.17, maturity: 0.48, sprawl: 0.15, archConsistency: 0.12 },
};

Sprawl risk undermines the good work we’ve done, so it’s subtracted. We’re trying to reduce our spend after all, and every extra cloud provider means more credentials, tooling, and on-call runbooks.

A second, smaller set of questions covers the modules. Cluster and registry modules follow directly from the provider (AWS always means EKS and ECR), so Jev is left with the squishy judgment calls that are genuinely open choices: ingress posture, autoscaling posture, and node-pool sizing tier.

Confidence gates keep the agent contained

The confidence score is how we decide it’s safe to let an agent touch production. Every answer is checked against a threshold matched to how risky the decision is:

Decision	Threshold	If it doesn’t pass
Data residency	0.95	Hard reject
Region for a new cluster	0.90	Top three candidates are flagged for a human to choose
Region when a stack already exists	0.75	Keep the existing region
Ingress or autoscaling module	0.85	Use the registry default
Node-pool sizing tier	0.60	Use the bin-packing result
Region pick, residency, or capacity (global floor)	0.50	Drop the AI path for that geo

Enforcing a gate is plain old deterministic code. Here’s the residency check from packages/decide/src/engine.ts, followed by a validation check that the selection really is one of the candidates:

// residencyOk is a hard gate: below 0.95, hard-reject — never soft-fail a
// compliance constraint, even by falling back to the model's own pick.
const residencyGate = applyGate(a.residencyOk.noul, GATE_THRESHOLDS.residencyOk, "residencyOk");
if (!residencyGate.passed) {
 throw new AiPathAborted(
 `residencyOk hard gate failed (${a.residencyOk.noul.toFixed(2)} < ${GATE_THRESHOLDS.residencyOk}); hard-rejecting the AI region selection`,
 stageAAttempt,
 );
}

const chosenId = a.selection.choice;
let chosenCandidate = shortlisted.find((c) => candidateId(c) === chosenId);
if (!chosenCandidate) {
 throw new AiPathAborted(`model selected an unknown candidate id "${chosenId}"`, stageAAttempt);
}

Each AiPathAborted carries the full attempt (state, questions, and answers), so even a rejected answer ends up in the audit trail.

If a gate check fails, the API times out or returns an error, or the upstream can’t be reached, GeoDeploy switches to a deterministic fallback: it compares prices across providers while still enforcing the residency and constraint checks. Run geodeploy explain to see why each region won.

Self-driving mode

When self-driving mode is enabled (geodeploy monitor), the agent periodically checks each deployment’s CPU utilization and asks Jev one joint question across all regions: no-change, scale-up:<geo>, scale-down:<geo>, or shift:<from>-><to>, plus a separate check on disruption risk. Code, not Jev, computes the actual node-count changes. Above 0.85 confidence, the resize is applied automatically. Between 0.70 and 0.85, it’s suggested for a human to approve. Below 0.70, GeoDeploy ignores Jev’s pick and falls back to a deterministic per-region rule based on the observed utilization.

For builders familiar with the sharp corners of maintaining a reliable service: CPU utilization alone makes a poor autoscaling metric. Once you’ve established a traffic baseline, it’s usually paired with other signals, such as median end-to-end request latency, error rates, or something specific to your application. For our purposes, it’s a decent approximation for proving out the test case.

The power is yours!

From here, the possibilities are quite literally endless for how we could tweak our agentic, self-driving infrastructure, and we’re honestly getting dizzy over all the ways we’d like to use Jev internally.

We’re releasing GeoDeploy as open source so you can take it and build something of your own. As long as you’ve got access to Jev and a cloud provider, you can get started today:

github.com/pulumi/devx-geodeploy

Are you currently experimenting with Jev or Pulumi in your infrastructure stack? We’d love to hear about it. @ us on X at @PulumiCorp and send us a link to what you’re building!

Ready to start building your dream infrastructure stack? Sign up for a free Pulumi account and start shipping today!

Future of the Cloud: 10 Trends Shaping 2027 and Beyond

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

Cloud infrastructure in 2027 turns on one shift: AI agents are moving from writing code to operating infrastructure directly, with humans approving changes rather than authoring every one. Hyperscaler capital spending, Kubernetes-for-AI adoption, and platform engineering are all accelerating alongside it. Here are the 10 trends shaping cloud computing through 2027 and beyond.

Last year’s edition of this piece predicted a cloud-first, AI-driven decade. The numbers came in since: Microsoft’s Azure business crossed $100 billion in trailing revenue, Google Cloud’s backlog reached $514 billion, and AWS’s AI and custom-silicon businesses each passed a $25 billion annualized run rate. The 2026 predictions held up. What follows is the update for 2027.

1. Cloud Is Becoming a Business Necessity

Cloud is now on the runway Gartner mapped out for it. According to Gartner, by 2028 cloud-native platforms will serve as the foundation for more than 95% of new digital initiatives, up from less than 50% in 2023. Gartner has also forecast that worldwide public cloud spending will exceed $1 trillion in 2027, en route to cloud becoming, in Gartner’s words, a business necessity.

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 posted its fastest revenue growth since 2021: $42.2 billion in Q2 2026, up 37% year-over-year, accelerating from 28% growth the prior quarter. AWS’s AI business and its chips business, which includes its custom Trainium and Graviton silicon, each exceeded a $25 billion annualized revenue run rate, growing triple-digit percentages year-over-year.
Microsoft Azure crossed a threshold of its own: Azure’s full fiscal-year 2026 revenue surpassed $100 billion for the first time in Microsoft’s fiscal Q4 2026 (ended June 30, 2026), with Azure revenue growing 43% year-over-year, up from 40% the prior quarter. “This year, Azure revenue surpassed $100 billion for the first time,” said Satya Nadella, Microsoft’s chairman and CEO.
Google Cloud revenue rose 82% year-over-year to $24.8 billion in Q2 2026, and its backlog reached $514 billion, up from $106 billion a year earlier. Alphabet raised its full-year 2026 capital expenditure guidance to $195–205 billion, up from an earlier $180–190 billion estimate that had itself already been raised twice this year.
Oracle reported FY2026 cloud revenue of $34.0 billion, up 39% year-over-year, with remaining performance obligations reaching $638 billion, up 363% year-over-year on the strength of large-scale AI infrastructure contracts, including prepaid and customer-supplied GPU deals now totaling $75 billion.

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%).
In Pulumi’s own 2026 survey of 510 platform, DevOps, and product engineers, multi-cloud is already the norm at the teams surveyed: 64% run on AWS, 55% on Google Cloud, and 45% on Azure, with most running more than one.

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’s September 2026 forecast, total worldwide AI spending, spanning software, hardware, and services, is forecast to reach $2.7 trillion in 2026, a 49.5% increase year-over-year. IDC predicts that by 2027, half of enterprises will be using AI agents to redefine how humans and machines collaborate, 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
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 through 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 secure third-party AI service usage and protect custom-built AI applications, and separately forecasts that total spending on securing AI will reach almost $4.8 billion in 2027, a 68.7% increase over 2026. 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.

Build for an AI-first cloud

Pulumi gives teams infrastructure as code, reusable components, and policy guardrails to deliver consistently across every cloud and AI workload.

Get started

7. Platform Engineering & Internal Developer Platforms (IDPs)

Gartner predicted that by 2026, 80% of large software engineering organizations would establish platform engineering teams as internal providers of reusable services, components, and tools for application delivery. That target year has now arrived, and CNCF’s own research shows the shift underway: its Q1 2026 Technology Radar report with SlashData found 28% of surveyed organizations already have a dedicated platform engineering team, and 35% are running a hybrid platform that combines existing developer platforms with specialized AI tooling.

“Cloud native platforms have reached a point where developers are not just experimenting but standardizing on CNCF projects that make software delivery reliable at scale,” said Chris Aniszczyk, CTO of CNCF. “What’s especially notable about this research is how organizations are extending those same platforms to support AI workloads, showing how cloud native is the base layer of powering the next era of applications.”

Mid-size to large companies continue to invest in implementing platform engineering practices, with large tech companies as first adopters. They provide Internal Developer Platforms (IDP) to elevate the Developer Experience (DX, sometimes referred to as DE or DevEx), helping teams work faster by abstracting the complexities of configuring, testing, validating, deploying infrastructure, and scanning 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 becomes agentic: from suggestions to supervised execution

AIOps in 2027 turns on one question: how much of a change does an agent execute, and how closely does a human still review it? Gartner predicts that agentic AI deployment in IT operations grows from under 5% in 2025 to 70% by 2029, while human-in-the-loop requirements in IT operations workflows fall from 95% in 2025 to 40% by 2028.

Pulumi’s own 2026 survey of 510 platform, DevOps, and product engineers shows the same shift starting inside real teams, and a gap between sentiment and practice that’s worth naming honestly:

82% agree that AI and agents will meaningfully change how they write infrastructure within 12 months.
63% say they trust agents to make production changes, yet 62% of teams still gate those changes behind manual approval, against 19% who let agents run autonomously. Pulumi’s report describes this as stated trust outrunning real guardrails.
Teams expecting agents to generate half or more of their infrastructure code rise from 45% today to 52% within six months.

That gap between trust and guardrails is exactly what a supervised, agentic operating model has to close: an agent that proposes a change, runs a preview, and waits for approval, rather than one that only writes YAML for someone else to apply by hand. Pulumi Neo is built around that loop, proposing infrastructure changes, running previews, and executing approved updates with policy guardrails in place, so the human stays the one accountable for what ships. Pulumi’s The Agentic Infrastructure Era makes the fuller case for why AIOps is headed toward this operating model rather than toward faster dashboards and alerting alone.

AIOps still includes observability, automation, and real-time analytics bridging DevOps, SRE, and IT operations. What’s changed for 2027 is that those signals increasingly feed an agent empowered to act on them, with a person still reviewing the result.

9. Kubernetes Dominance and Increased Complexity

Kubernetes will continue its ascent in 2027. According to Mordor Intelligence, the global Kubernetes market is valued at USD 3.13 billion in 2026 and is projected to reach USD 8.41 billion by 2031, a 21.85% CAGR.

The CNCF’s Q3 2025 State of Cloud Native Development report puts cloud-native adoption among professional ML/AI developers at 41%, with 30% of backend developers now using Kubernetes directly, down from a peak of 36% in Q3 2023 — a slow decrease the report says will likely stabilize at a new, lower proportion “due to the maturity of the technology.” Even so, teams still need flexible GPU scheduling, distributed pipelines, and portable execution environments as AI workloads scale.

Kubernetes is also evolving in response to AI demands, a shift Pulumi covers in more depth in its comparison of Kubernetes IaC tools. Inference workloads, powered by LLMs and GPUs, now require low-latency execution closer to the user, 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 2027, 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 have moved from novelty to everyday tooling for a large share of enterprise software teams, and the same shift is now reaching infrastructure code.

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. The July 2026 revision of the Model Context Protocol, described by its maintainers as the largest revision of the protocol to date, is part of what makes that direct action practical: AWS shipped a general-availability MCP server for its Agent Toolkit, and Kubernetes tooling vendors like Mirantis’s Lens have followed with built-in MCP servers of their own.

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: Built Around Agentic Operations

Cloud infrastructure is entering its most transformative era since the rise of Kubernetes. The trends shaping 2027 point to one clear pattern: AI now sets the organizing principle for cloud strategy, ahead of any single workload running on top of it.

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 2027 and beyond.

Try Pulumi for Free

Deploy Infrastructure to Multiple Cloud Regions at Once

Joe Duffy — Wed, 03 Aug 2022 08:00:00 -0700

Pulumi makes it easy to flexibly deploy your cloud infrastructure using code. Usually deployments encompass a single slack and a single region in your cloud of choice. If you need to go multi-region, that usually means creating a stack per-region, which Pulumi’s configuration system makes easy. A stack per region isn’t required, though! Sometimes we want a single stack to span regions for performance, scalability, resilience, or just hard requirements. In these cases, Pulumi can seamlessly orchestrate deployments to, or even across, multiple regions, accounts, or clusters. In this article, we’ll see this in action by provisioning an AWS RDS primary database into one region and a read replica in an entirely different region – all from a single Pulumi program, stack, and pulumi up incantation.

Recap of Stack Configuration

Before seeing how to span regions, let’s review how you’d typically configure your region. Every Pulumi project can have any number of stacks. These stacks are often things like dev, test, prod – and sometimes, things like prod-us-east, prod-us-west, prod-euro, and so on, to represent instances of our infrastructure running in different regions. Each stack is isolated from all others and it’s easy to switch between them.

The standard way to vary regions between stacks is to use Pulumi’s configuration system. If you’ve used Pulumi to deploy to AWS, for instance, you’ve probably uttered a CLI command like this:

$ pulumi config set aws:region us-east-1

This isn’t just about regions: it applies to anything that varies between stacks. It might include accounts, secrets like tokens and passwords, sizes or counts of instances, among many other things.

This is normally very convenient and aligns with how we want to configure our projects and stacks. But there are some relatively common circumstances in which it breaks down:

Managing a large number of multi-tenanted resources spanning multiple accounts or clusters.
Cases where a few pieces of infrastructure must run somewhere different than most of it, as is often the case with DNS or SSL/TLS certificate management services.
Situations where we want to provision resources in many places for performance, scalability, or resilience purposes.
Highly programmatic scenarios where some configuration might be fetched dynamically from an external resource.

In all of these cases, thankfully Pulumi has an answer: explicit provider configuration.

How Explicit Provider Configuration Works

Before diving into our example, let’s take a quick look at how explicit provider configuration works. Unlike ordinary configuration, which is set at the CLI, provider configuration is set programmatically inside your Pulumi program. Every Pulumi package exports a Provider resource class which can be instantiated like any other resource, with the sole difference that these resources exist to pass around to configure other resources, and don’t represent infrastructure that is to be provisioned in a cloud of any kind.

For instance, if we wanted to programmatically create an AWS provider that targets a different region than us-east-1, as shown earlier, we can do so as follows:

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

aws_west_2 = aws.Provider('aws-west-2', region='us-west-2')

awsWest2, err := aws.NewProvider(ctx, "aws-west-2", &aws.ProviderArgs{
 Region: pulumi.String("aws-west-2")
})
if err != nil {
 return err
}

var awsWest2 = new Aws.Provider("aws-west-2", new Aws.ProviderArgs
{
 Region = "us-west-2"
});

resources:
 awsWest2:
 type: pulumi:providers:aw
 properties:
 region: us-west-2

This configuration is not used automatically, however. You must pass it to any resources you’d like to use it:

const buck = new aws.s3.Bucket("my-bucket", {
 // ...
}, { provider: awsWest2 });

buck = aws.s3.Bucket('my-bucket',
 # ...
 opts=pulumi.ResourceOptions(provider=aws_west_2)
)

buck, err := s3.NewBucket("my-bucket",
 &s3.BucketArgs{
 // ...
 },
 pulumi.Provider(awsWest2)
)
if err != nil {
 return err
}

var buck = new Aws.S3.Bucket("my-bucket",
 new Aws.S3.BucketArgs
 {
 // ...
 },
 new ResourceArgs
 {
 Provider = awsWest2
 }
);

resources:
 # ...
 buck:
 type: aws:s3:Bucket
 properties:
 # ...
 options:
 provider: ${awsWest2}

This overrides the default of using whatever was set at the CLI, and will instead use the programmatically configured settings. Note also that anything you can set at the CLI is available, not just the region. You can see the full settings available in the package’s registry documentation for its Provider class (for instance, the AWS Provider.

Multi-Region Deployment In Action!

The architecture for our multi-region setup is going to be relatively straightforward so we can focus on the essentials. We will provision a single RDS primary database in one region (us-east-1) and backup to a read replica in an entirely different region – in fact, on an entirely different continent (eu-west-2)! This is relatively straightforward because many scenarios demand that we deploy to a dynamic number of regions, perhaps across dozens or hundreds of resources. By keeping it to just two resources across two regions, we can see the fundamentals in action which can scale easily to more sophisticated use cases.

This is described in AWS’s docs and is depicted in this diagram:

Now let’s dive into some infrastructure as code. There’s a bit of preamble before getting to the meat of the example:

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

// Code from below will goes here.

import pulumi
import pulumi_aws as aws
import pulumi_random as random

# Code from below goes here.

package main

import (
 "github.com/pulumi/pulumi-aws/sdk/v5/go/aws"
 "github.com/pulumi/pulumi-aws/sdk/v5/go/aws/rds"
 "github.com/pulumi/pulumi-random/sdk/v4/go/random"
 "github.com/pulumi/pulumi/sdk/v3/go/pulumi"
 "github.com/pulumi/pulumi/sdk/v3/go/pulumi/config"
)

func main() {
 pulumi.Run(func(ctx *pulumi.Context) error {
 // Code from below goes here.
 })
}

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

return await Deployment.RunAsync(() =>
{
 // Code from below goes here.
});

name: aws-multireg-rds
runtime: yaml
description: A multi-region example creating an RDS primary and read-replica in different regions

# Code from below goes here.

Next, we’ll make the retention period configurable, by default it is 30 days. Note how we can still use standard configuration features as well as explicit providers alongside one another:

// Enable backup retention to be configured, but default to 30 days.
const config = new pulumi.Config();
const retentionPeriod = config.getNumber("retentionPeriod") || 30;

# Enable backup retention to be configured, but default to 30 days.
config = pulumi.Config()
retention_period = config.get_float('retentionPeriod') or 30

// Enable backup retention to be configured, but default to 30 days.
cfg := config.New(ctx, "")
retentionPeriod := 30
if param := cfg.GetFloat("retentionPeriod"); param != 0 {
 retentionPeriod = param
}

// Enable backup retention to be configured, but default to 30 days.
var config = new Config();
var retentionPeriod = config.GetNumber("retentionPeriod") ?? 30;

# Enable backup retention to be configured, but default to 30 days.
configuration:
 retentionPeriod:
 type: Number
 default: 30

Next, we’ll create a random password for our database so we don’t need to hard-code one:

// Create a random password for the database's admin user.
const dbPassword = new random.RandomPassword("dbPassword", { length: 12 });

# Create a random password for the database's admin user.
db_password = random.RandomPassword('dbPassword', length = 12)

// Create a random password for the database's admin user.
dbPassword, err := random.NewRandomPassword(ctx, "dbPassword", &random.RandomPasswordArgs{
 Length: pulumi.Int(12),
})

// Create a random password for the database's admin user.
var dbPassword = new Random.RandomPassword("dbPassword", new()
{
 Length = 12,
});

 # Create a random password for the database's admin user.
 dbPassword:
 type: random:RandomPassword
 properties:
 length: 12

Now we’re ready to create the providers. We’ll create one per region that we will deploy into:

// Create two AWS providers, one for each region we'll deploy into.
const euProvider = new aws.Provider("euProvider", { region: "eu-west-2" });
const usProvider = new aws.Provider("usProvider", { region: "us-east-1" });

# Create two AWS providers, one for each region we'll deploy into.
eu_provider = aws.Provider('euProvider', region = 'eu-west-2')
us_provider = aws.Provider('usProvider', region = 'us-east-1')

// Create two AWS providers, one for each region we'll deploy into.
euProvider, err := aws.NewProvider(ctx, "euProvider", &aws.ProviderArgs{
 Region: pulumi.String("eu-west-2"),
})
if err != nil {
 return err
}
usProvider, err := aws.NewProvider(ctx, "usProvider", &aws.ProviderArgs{
 Region: pulumi.String("us-east-1"),
})
if err != nil {
 return err
}

// Create two AWS providers, one for each region we'll deploy into.
var euProvider = new Aws.Provider("euProvider", new()
{
 Region = "eu-west-2",
});

var usProvider = new Aws.Provider("usProvider", new()
{
 Region = "us-east-1",
});

resources:
 # Create two AWS providers, one for each region we'll deploy into.
 euProvider:
 type: pulumi:providers:aws
 properties:
 region: eu-west-2
 usProvider:
 type: pulumi:providers:aws
 properties:
 region: us-east-1

To keep things straightforward, we’ve hard-coded the regions into the program. There are more sophisticated possibilities, however. For example, we could have made the regions themselves configurable too, much like the retention period. Even more powerfully, we could use our programming language’s expressiveness to create them dynamically. For instance, we could have looped over a list of them so that the number of regions isn’t even known in advance. These advanced capabilities are helpful for many real-world scenarios.

Next up, we’ll create the primary database instance in us-east-1:

// Create the primary RDS database instance.
const primaryDb = new aws.rds.Instance("primary", {
 allocatedStorage: 10,
 engine: "mysql",
 engineVersion: "5.7",
 instanceClass: "db.t3.micro",
 username: "admin",
 password: dbPassword.result,
 backupRetentionPeriod: retentionPeriod,
 skipFinalSnapshot: true,
}, {
 provider: usProvider,
});

# Create the primary RDS database instance.
primary_db = aws.rds.Instance('primary',
 allocated_storage=10,
 engine='mysql',
 engine_version='5.7',
 instance_class='db.t3.micro',
 username='admin',
 password=db_password.result,
 backup_retention_period=retention_period,
 skip_final_snapshot=True,
 opts=pulumi.ResourceOptions(provider=us_provider)
)

// Create the primary RDS database instance.
primaryDb, err := rds.NewInstance(ctx, "primary", &rds.InstanceArgs{
 AllocatedStorage: pulumi.Int(10),
 Engine: pulumi.String("mysql"),
 EngineVersion: pulumi.String("5.7"),
 InstanceClass: pulumi.String("db.t3.micro"),
 Username: pulumi.String("admin"),
 Password: dbPassword.Result,
 BackupRetentionPeriod: pulumi.Float64(retentionPeriod),
 SkipFinalSnapshot: pulumi.Bool(true),
}, pulumi.Provider(usProvider))
if err != nil {
 return err
}

// Create the primary RDS database instance.
var primaryDb = new Aws.Rds.Instance("primary", new()
{
 AllocatedStorage = 10,
 Engine = "mysql",
 EngineVersion = "5.7",
 InstanceClass = "db.t3.micro",
 Username = "admin",
 Password = dbPassword.Result,
 BackupRetentionPeriod = retentionPeriod,
 SkipFinalSnapshot = true,
}, new CustomResourceOptions
{
 Provider = usProvider,
});

 # Create the primary RDS database instance.
 primary:
 type: aws:rds:Instance
 properties:
 allocatedStorage: 10
 engine: mysql
 engineVersion: "5.7"
 instanceClass: db.t3.micro
 username: admin
 password: ${dbPassword.result}
 backupRetentionPeriod: ${retentionPeriod}
 skipFinalSnapshot: true
 options:
 provider: ${usProvider}

The key here is that we explicitly passed the provider that was configured to use us-east-1, instructing Pulumi to use that configuration rather than the implicit default configuration set at the CLI as usual.

Now we will create the secondary database instance in eu-west-2:

// Now set up our secondary read replica database in an entirely different region.
const secondaryDb = new aws.rds.Instance("secondary", {
 instanceClass: "db.t3.micro",
 replicateSourceDb: primaryDb.arn,
 backupRetentionPeriod: retentionPeriod,
 skipFinalSnapshot: true,
}, {
 provider: euProvider,
});

# Now set up our secondary read replica database in an entirely different region.
secondary_db = aws.rds.Instance("secondary",
 instance_class="db.t3.micro",
 replicate_source_db=primary_db.arn,
 backup_retention_period=retention_period,
 skip_final_snapshot=True,
 opts=pulumi.ResourceOptions(provider=eu_provider)
)

// Now set up our secondary read replica database in an entirely different region.
secondaryDb, err := rds.NewInstance(ctx, "secondary", &rds.InstanceArgs{
 InstanceClass: pulumi.String("db.t3.micro"),
 ReplicateSourceDb: primaryDb.Arn,
 BackupRetentionPeriod: pulumi.Float64(retentionPeriod),
 SkipFinalSnapshot: pulumi.Bool(true),
}, pulumi.Provider(euProvider))
if err != nil {
 return err
}

// Now set up our secondary read replica database in an entirely different region.
var secondaryDb = new Aws.Rds.Instance("secondary", new()
{
 InstanceClass = "db.t3.micro",
 ReplicateSourceDb = primaryDb.Arn,
 BackupRetentionPeriod = retentionPeriod,
 SkipFinalSnapshot = true,
}, new CustomResourceOptions
{
 Provider = euProvider,
});

 # Now set up our secondary read replica database in an entirely different region.
 secondary:
 type: aws:rds:Instance
 properties:
 instanceClass: db.t3.micro
 replicateSourceDb: ${primary.arn}
 backupRetentionPeriod: ${retentionPeriod}
 skipFinalSnapshot: true
 options:
 provider: ${euProvider}

As expected, we passed the provider configured to use eu-west-2. Notice also that, although these resources are deployed into entirely different regions, they can reference one another! Thanks to Pulumi’s dependency system, it understands that referencing primary.arn means the secondary database depends on the primary, which Pulumi will use to ensure correct ordering of operations.

Finally, we’ll emit the primary and secondary database endpoints plus auto-generated password:

// Output the primary and secondary database ARNs, and the auto-generated admin password.
export const primary = primaryDb.endpoint;
export const secondary = secondaryDb.endpoint;
export const password = dbPassword.result;

# Output the primary and secondary database ARNs, and the auto-generated admin password.
pulumi.export('primary', primary_db.endpoint)
pulumi.export('secondary', secondary_db.endpoint)
pulumi.export('password', db_password.result)

// Output the primary and secondary database ARNs, and the auto-generated admin password.
ctx.Export("primary", primaryDb.Endpoint)
ctx.Export("secondary", secondaryDb.Endpoint)
ctx.Export("password", dbPassword.Result)
return nil

// Output the primary and secondary database ARNs, and the auto-generated admin password.
return new Dictionary<string, object?>
{
 ["primary"] = primaryDb.Endpoint,
 ["secondary"] = secondaryDb.Endpoint,
 ["password"] = dbPassword.Result,
};

# Output the primary and secondary database ARNs, and the auto-generated admin password.
outputs:
 primary: ${primary.endpoint}
 secondary: ${secondary.endpoint}
 password: ${dbPassword.result}

Using these, we can easily access our new instance. Don’t worry, the password is automatically encrypted!

For good measure, since all of our AWS resources are meant to use the explicit providers, and not the ambient default configuration, we can disable default providers altogether:

$ pulumi config set --path pulumi:disable-default-providers[0] "aws"

If we forget to pass an explicit provider, we now get an error:

error: Default provider for 'aws' disabled. 'urn:pulumi:dev::aws-multireg-rds::aws:rds/instance:Instance::primary' must use an explicit provider.

Now that we’ve got everything set up, we run pulumi up which orchestrates everything end-to-end:

$ pulumi up
Updating (dev)

 Type Name Status
 + pulumi:pulumi:Stack aws-multireg-rds-dev created
 + ├─ pulumi:providers:aws euProvider created
 + ├─ pulumi:providers:aws usProvider created
 + ├─ random:index:RandomPassword dbPassword created
 + ├─ aws:rds:Instance primary created
 + └─ aws:rds:Instance secondary created

Outputs:
 password : [secret]
 primary : "primarybe35b53.c0q7bvujknic.us-east-1.rds.amazonaws.com:3306"
 secondary: "secondaryacb6a3d.c8qninoaapw8.eu-west-2.rds.amazonaws.com:3306"

Resources:
 + 6 created

Duration: 27m0s

Deploy across regions from one stack

Configure explicit providers in your Pulumi program to provision resources across regions, accounts, and clusters from a single stack. Build and ship your multi-region infrastructure with one pulumi up.

Learn more

Winding Down

In this article, you saw some reasons why deploying your infrastructure across multiple regions, accounts, or clusters may be necessary. You saw that Pulumi supports two forms of configuration – implicit configuration set at the CLI with pulumi config as well as explicit provider configuration which is constructed and passed programmatically – and how and when to use them, often in tandem with one another.

The specific example shown to demonstrate multi-region in action deployed an AWS RDS primary database to a US region and a secondary read replica to Europe, which is a common architecture to improve resilience and performance. The power of full programming languages gives you a ton of flexibility in how you orchestrate such complex architectures.

Hopefully this post put a new tool in your infrastructure as code toolbelt! Happy cloud spelunking.

Multicloud with Kubernetes and Pulumi

Guinevere Saenger — Thu, 09 Jun 2022 11:40:47 -0700

In this article we’ll show you how to use Pulumi Components and the Pulumi Automation API to make golden path decisions which will both support your customers on multiple different clouds, and enable infrastructure teams and frontend service teams to more easily own their respective parts of your codebase.

If you’re looking for an overview of provisioning and deploying to EKS, AKS, and GKE directly, see Multicloud Kubernetes: Running Apps Across EKS, AKS, and GKE instead. This article goes a layer deeper: it builds a reusable Component and an Automation API-driven workflow so other teams can self-serve Kubernetes clusters without touching the underlying provisioning code.

Let’s say you provide a hosted service for your customers. You would like to offer customizable Kubernetes cluster provisioning, on multiple different clouds, as well as your product service itself.

There’s a lot of configuration fine-tuning and manual repetition that is required when bringing up Kubernetes clusters on different clouds.

This article is a written summary of our KubeCrash live demo, see it below. Please find the repository with the full version of the code here.

Part One: Create a component

A Component Resource is an abstraction on top of other Pulumi packages, often combining a few different providers into something that fits your infrastructure needs precisely.

Prerequisites

In our example, we are using three separate clouds, one of these being a local KinD cluster.

Nodejs
Pulumi CLI
Have the Pulumi Registry documentation handy for some Pulumi providers:
- Pulumi Civo Provider
- Pulumi Linode Provider
- Pulumi Kubernetes Provider
- Pulumi KinD Provider (Kubernetes-in-Docker) Note: As this is a community package, follow installation instructions from the README. This provider only supports Go and Nodejs.

Gather access tokens for Linode and Civo, if using, and set them in the environment or as secrets.

Start by writing the code for each cloud

The below code, when run against pulumi up, will create a single cloud stack with three separate Kubernetes clusters. The Stack output will be the cluster’s name and kubeconfig.

import * as pulumi from "@pulumi/pulumi";
import * as civo from '@pulumi/civo';
import * as linode from "@pulumi/linode";
import * as kind from "@pulumi/kind";


//Civo

// Create a firewall
const fw = new civo.Firewall("guin-fw", {
 region: "nyc1",
 createDefaultRules: true,
});

const civoCluster = new civo.KubernetesCluster("guin-civo-demo", {
 name: "guin-demo",
 region: "nyc1",
 firewallId: fw.id,
 pools: {
 nodeCount: 3,
 size: "g4s.kube.xsmall",
 }
});

export const clusterNameCivo = civoCluster.name
export const kcCivo = civoCluster.kubeconfig

//Linode

const linodeCluster = new linode.LkeCluster("guin-linode-demo", {
 k8sVersion: "1.22",
 label: "guin-demo",
 pools: [{
 count: 2,
 type: "g6-standard-2",
 }],
 region: "us-central",
 tags: ["guin-demo"],
});

export const clusterLabelLinode = linodeCluster.label
export const kcLinode = linodeCluster.kubeconfig

// Kind

const kindCluster = new kind.cluster.Cluster(
 'guin-kind',
 {
 name: pulumi.interpolate`guin-kind`,
 nodes: [
 {
 role: kind.node.RoleType.ControlPlane,
 extraPortMappings: [
 {
 containerPort: args.nodePort,
 hostPort: args.nodePort,
 },
 ],
 },
 {
 role: kind.node.RoleType.Worker,
 },
 ],
 },
)

export const clusterNameKind = kindCluster.name
export const kcKind = kindCluster.kubeconfig

We could stop here, export the kubeconfigs to a file, and start interacting with our clusters via kubectl. But that would require our cluster operators to be deeply familiar with each cloud provider’s Kubernetes implementation. Let’s see if we can do better.

Create a custom component for the Kubernetes cluster

Our goal today is to bring up a “generic” Kubernetes cluster that fits a single use case for multiple clouds. To do so, we create a default implementation as a wrapper around each cloud provider. We implement the following features:

Choice of cloud
Cluster Naming
Kubeconfig Output for later use

The Pulumi SDK allows us to wrap resources into a ComponentResource, which in our Typescript example means we create a new class that extends pulumi.ComponentResource.

export class ShinyCluster extends pulumi.ComponentResource {
 constructor(
 name: string,
 args: {},
 opts: {},
 ) {
 # ...
 }
}

Because we like all things shiny, we’ll call it a ShinyCluster, and pass pkg:index:ShinyCluster as the unique resource name.

We’ll also register the name and kubeconfig for each ShinyCluster as Outputs:

import { Output } from '@pulumi/pulumi'; // add this to dependencies

#...

export class ShinyCluster extends pulumi.ComponentResource {
 constructor(
 name: string,
 args: {},
 opts: {},
 ) {
 super('pkg:index:ShinyCluster', name, {}, opts);
 }
 name: Output<string>;
 kubeConfig: Output<string>;
}

Write the implementation for each cloud provider:

export class ShinyCluster extends pulumi.ComponentResource {
 constructor(
 name: string,
 args: {
 cloud: 'linode' | 'civo' | 'kind';
 nodePort?: number; // this is a KinD-specific add-on so we can connect to our workload
 },
 opts: {},
 ) {
 super('pkg:index:ShinyCluster', name, {}, opts);
 switch (args.cloud) {
 case 'linode':
 const linodeCluster = new linode.LkeCluster(
 'my-cluster',
 {
 label: 'guin-linode',
 k8sVersion: '1.22',
 pools: [
 {
 count: 2,
 type: 'g6-standard-2',
 },
 ],
 region: 'us-central',
 tags: ['guin'],
 },
 { parent: this },
 );
 this.name = linodeCluster.label;
 this.kubeConfig = linodeCluster.kubeconfig.apply((x) =>
 Buffer.from(x, 'base64').toString(),
 );
 break;
 case 'civo':
 const fw = new civo.Firewall(
 'guin-fw',
 {
 name: 'guin-civo',
 region: 'nyc1',
 createDefaultRules: true,
 },
 { parent: this },
 );

 const civoCluster = new civo.KubernetesCluster(
 'guin-civo',
 {
 region: 'nyc1',
 name: 'guin-civo',
 firewallId: fw.id,
 pools: {
 nodeCount: 3,
 size: 'g4s.kube.xsmall',
 },
 },
 { parent: this },
 );
 this.name = civoCluster.name;
 this.kubeConfig = civoCluster.kubeconfig;
 break;
 case 'kind':
 const kindCluster = new kind.cluster.Cluster(
 'guin-kind',
 {
 name: 'guin-kind',
 nodes: [
 {
 role: kind.node.RoleType.ControlPlane,
 extraPortMappings: [
 {
 containerPort: args.nodePort,
 hostPort: args.nodePort,
 },
 ],
 },
 {
 role: kind.node.RoleType.Worker,
 },
 ],
 },
 { parent: this },
 );
 this.name = kindCluster.name;
 this.kubeConfig = kindCluster.kubeconfig;
 }
 }
 name: Output<string>;
 kubeConfig: Output<string>;
}

We are now ready to use our component.

Read in the configuration from the config file and create a cluster:

const config = new pulumi.Config();

const shinyCluster = new ShinyCluster(
 'guin',
 {
 cloud: config.require('cloud'),
 nodePort: config.getNumber('nodePort'),
 },
 {},
);

export const shinyName = shinyCluster.name;
export const shinyConfig = pulumi.secret(shinyCluster.kubeConfig);

In our terminal, we can now create a stack called dev, set the necessary inputs in the Pulumi config, and run pulumi up:

$ pulumi stack init dev
Created stack 'dev'
$ pulumi config set shinycluster:cloud civo
$ pulumi up
Previewing update (dev)

View Live: https://app.pulumi.com/guinevere/shinycluster/dev/previews/cf968a89-dadc-461f-badd-b062601c18b4

 Type Name Plan
 + pulumi:pulumi:Stack shinycluster-dev create

At this point, we have created a Pulumi Component Resource that we can use to scaffold Kubernetes infrastructure.

Side Quest: Ship an app!

The purpose of this demo is not focused on the details of deploying a web app on Kubernetes with Pulumi, so we won’t go into too much detail here. We created a shinyapp folder to hold a Pulumi program (written in yaml!) We could now follow the Kubernetes provider configuration steps to set up and deploy our shinyapp to each of our clusters.

But if we have multiple Kubernetes backends, and would like to deploy our shinyapp to each of them, this would get tedious soon. Here is where we automate deploying our frontend as well.

Part 2: Leverage the Automation API

The Pulumi Automation API allows us to run Pulumi commands without using the CLI manually.

Let’s review our basic project file structure first, for context. We place both our shinycluster backend and shinyapp frontend Pulumi projects in their own folders, to separate concerns, and for visual clarity.

.
├── shinyapp
│ ├── Main.yaml # our web app, declared in yaml
│ └── Pulumi.yaml # Pulumi project config for `shinyapp`, with yaml runtime
├── shinycluster
│ ├── index.ts # our showcased Pulumi Component Resource for a Kubernetes cluster
│ └── Pulumi.yaml # Pulumi project config for `shinycluster`, with nodejs (Typescript) runtime

The neat thing here is that both our Kubernetes clusters and our application service are in their own contained folder, and in fact each can be deployed independently using Pulumi. Let’s go ahead and implement the functionality that allows us to automate it all by adding the following files to the root of the project:

├── Pulumi.yaml # Pulumi project config for the entire demo
├── index.ts # Input and output logic for our frontend and backend stacks
├── outputFormatter.ts # Prettify output
├── runPulumiProject.ts # Our specific automation implementation, using Automation API
└── stackModule.ts # Wrapper logic to show which types are expected by each part of our project

Not shown: dependency and package files.

The Stack Module

First, we define a generic Pulumi stack, with variable working directories and outputs, as expected by the automation API.

// stackModule.ts
import * as pulumi from '@pulumi/pulumi';

export type Unwrapped<T> = NonNullable<pulumi.Unwrap<Awaited<T>>>;

export type OutputMap<T> = {
 [K in keyof T]: {
 value: T[K];
 secret: boolean;
 };
};

export type StackModule<T> = {
 workDir: string;
 projectName: string;
 stack(): Promise<T>;
};

type StackOutputs<T> = T extends StackModule<infer O> ? O : never;

/**
 * The type of the outputs, as returned by the automation API as an "OutputMap".
 */
export type StackOutputMap<T> = OutputMap<Unwrapped<StackOutputs<T>>>;

/**
 * The type of the outputs, as if executed and run in a Pulumi program:
 */
export type StackOutputValues<T> = Unwrapped<StackOutputs<T>>;

/**
 * The type of a function that gets values by name from the outputs of a stack.
 *
 * See `stackOutputConfig`.
 */
export type StackOutputGetter<T> = <
 K extends keyof StackOutputValues<T> & string,
>(
 key: K,
) => StackOutputValues<T>[K];

Wrap the Automation API

We have a few functionalities that we can expand on and implement in just the way we like, so we put them in a file called runPulumiProject.ts.

// runPulumiProject.ts
import {
 ConfigMap,
 LocalProgramArgs,
 LocalWorkspace,
 OpMap,
 PreviewResult,
 Stack,
 UpResult
} from '@pulumi/pulumi/automation';

For the purposes of this demo repo, we added a formatter as well, but it’s not necessary for the functionality:

import chalk from 'chalk';
import { Formatter } from './outputFormatter';

And we import the output mappings we abstracted away in the stack module, above.

import { OutputMap, Unwrapped } from './stackModule';

We can now decide how we want to implement our automation options.

Let’s define the options we’d like this program to be able to run with. We need:

Directory name
Project name
Stack name
Pulumi operation to run
Extra configuration (so we can pass in that kubeconfig)
The formatter
Stack outputs

// runPulumiProject.ts
interface PulumiRunOptions {
 dir: string;
 project: string;
 stackName: string;
 operation: 'up' | 'preview' | 'destroy';
 additionalConfig: ConfigMap;
 formatter: Formatter;
}
interface PulumiRunResult<T> {
 stack: Stack;
 projectName: string;
 outputs: OutputMap<Unwrapped<T>>;
}

In this example, the pulumi commands we automate are:

Preview
Up
Destroy

export async function runPulumiProject<T extends object>({
 dir, project, stackName, operation, additionalConfig, formatter,
}: PulumiRunOptions): Promise<PulumiRunResult<T> | undefined> {
 const localProgramArgs: LocalProgramArgs = {
 stackName,
 workDir: dir,
 };
 const stack = await LocalWorkspace.createOrSelectStack(localProgramArgs, {});

 formatter(`Spinning up stack ${project}/${stackName}`);
 await stack.setAllConfig({
 ...additionalConfig,
 });

 formatter('Refreshing');
 await stack.refresh();

 let result: UpResult | PreviewResult;
 let status: string = 'succeeded';
 let outputs: OutputMap<Unwrapped<T>>;
 let summaryMessage: string | undefined;
 let operations: OpMap;
 switch (operation) {
 case 'preview':
 formatter('Previewing');

 const previewResult = await stack.preview({ onOutput: formatter });
 operations = previewResult.changeSummary;
 outputs = (await stack.outputs()) as OutputMap<Unwrapped<T>>;
 break;
 case 'up':
 formatter('Deploying');

 const upResult = await stack.up({ onOutput: formatter });
 operations = upResult.summary.resourceChanges;
 status = upResult.summary.result;
 summaryMessage = upResult.summary.message;
 outputs = upResult.outputs as OutputMap<Unwrapped<T>>;
 break;
 case 'destroy':
 formatter('Destroying');

 const destroyResult = await stack.destroy({ onOutput: formatter });
 operations = destroyResult.summary.resourceChanges;
 status = destroyResult.summary.result;
 summaryMessage = destroyResult.summary.message;
 break;
 }

 if (status !== 'succeeded') {
 formatter(result.stderr);
 formatter(summaryMessage);
 throw new Error();
 }

 if (operations) {
 formatter('Succeeded! Resource summary:');
 const fmtNum = (num?: number) => `${num}`.padStart(3);
 if (operations?.create) {
 formatter(`${fmtNum(operations?.create)} ${chalk.green('created')}`);
 }
 if (operations?.replace) {
 formatter(`${fmtNum(operations?.replace)} ${chalk.magenta('replaced')}`);
 }
 if (operations?.update) {
 formatter(`${fmtNum(operations?.update)} ${chalk.yellow('updated')}`);
 }
 if (operations?.same) {
 formatter(`${fmtNum(operations?.same)} ${chalk.bold('unchanged')}`);
 }
 }

 return {
 stack,
 projectName: project,
 outputs: outputs as OutputMap<Unwrapped<T>>,
 };
}

In addition, this code gives us the ability to take a stack’s Output and apply it to another stack, which is what we will do next, in our top-level index.js file.

Putting it all together

// index.js
import { chooseColor, outputFormatter } from './outputFormatter';
import { runPulumiProject } from './runPulumiProject';

interface ClusterOutputs {
 shinyName: string;
 shinyConfig: string;
}

ClusterOutputs defines the information we need to pass on the kubeconfig to our Kubernetes web app, and the cluster name to associate each frontend stack with its backend Kubernetes cluster.

Here, we’re deploying our shinyapp to a local KinD cluster, but we have the ability to add any cluster to this list:

const clusters = [
 {name: 'kind-local', cloud: 'kind', nodePort: 32001},
];

First, we wait for our clusters to be created (note the operation: 'up' being passed):

await Promise.allSettled(
 clusters.map(async (clusterDefinition) => {
 let theme = chooseColor();

 const serviceType = clusterDefinition.nodePort ? 'NodePort' : 'LoadBalancer';
 const serviceNodePort = `${clusterDefinition.nodePort ?? 0}`;
 const cluster = await runPulumiProject<ClusterOutputs>({
 dir: './shinycluster',
 project: 'shinycluster',
 stackName: clusterDefinition.name,
 operation: 'up',
 additionalConfig: {
 cloud: { value: clusterDefinition.cloud },
 nodePort: { value: serviceNodePort },
 },
 formatter: outputFormatter(`cluster ${clusterDefinition.name}`, theme)
 });
 // here we will call runPulumiProject, this time on the web app
 }),
 );

And then deploy our web app:

runPulumiProject({
 dir: './shinyapp',
 project: 'shinyapp',
 stackName: clusterDefinition.name,
 operation: 'up',
 additionalConfig: {
 kubeconfig: cluster.outputs.shinyConfig,
 serviceType: { value: serviceType },
 serviceNodePort: { value: serviceNodePort },
 },
 formatter: outputFormatter(`app ${clusterDefinition.name}`, theme)
});

Putting it all together:

// index.js
import { chooseColor, outputFormatter } from './outputFormatter';
import { runPulumiProject } from './runPulumiProject';

interface ClusterOutputs {
 shinyName: string;
 shinyConfig: string;
}

async function main() {
 const clusters = [
 { name: 'kind-local', cloud: 'kind', nodePort: 32001 },
 ];

 await Promise.allSettled(
 clusters.map(async (clusterDefinition) => {
 let theme = chooseColor();

 const serviceType = clusterDefinition.nodePort ? 'NodePort' : 'LoadBalancer';
 const serviceNodePort = `${clusterDefinition.nodePort ?? 0}`;
 const cluster = await runPulumiProject<ClusterOutputs>({
 dir: './shinycluster',
 project: 'shinycluster',
 stackName: clusterDefinition.name,
 operation: 'up',
 additionalConfig: {
 cloud: { value: clusterDefinition.cloud },
 nodePort: { value: serviceNodePort },
 },
 formatter: outputFormatter(`cluster ${clusterDefinition.name}`, theme)
 });

 runPulumiProject({
 dir: './shinyapp',
 project: 'shinyapp',
 stackName: clusterDefinition.name,
 operation: 'up',
 additionalConfig: {
 kubeconfig: cluster.outputs.shinyConfig,
 serviceType: { value: serviceType },
 serviceNodePort: { value: serviceNodePort },
 },
 formatter: outputFormatter(`app ${clusterDefinition.name}`, theme)
 });
 }),
 );
}

main();

Run the program

All that is left to do is run our top-level program:

$ ts-node ./index.js

Once that’s done running, go visit your webapp appear on localhost with the specified port:

$ curl localhost:32002
<!DOCTYPE html>
<html>

<head>
 <meta http-equiv="Content-Type" content="text/html" charset="utf-8">
</head>

<body>
 <h1>Made with love by Pulumi!</h1>
</body>

</html>

Summary

We chose some cloud providers for bringing up Kubernetes clusters
We created a ShinyCluster custom resource that abstracts away any cloud provider implementation details, giving us a small set of defaults we care about
We programmatically deployed infrastructure using the Automation API
We deployed an app to this infrastructure, also using Automation API.

We hope you have gotten a little bit of inspiration from our whirlwind tour through these Pulumi features. Happy coding!