Pulumi Blog: Multi cloud

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.

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)

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

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.

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!