Some of the largest and most complex deployments that teams manage are hybrid and multi-cloud deployments. Kubernetes is a common component in these deployments because it enables platform teams to provide a common set of services across cloud and on-premises infrastructure and simplifies the process of migrating and scaling workloads as demand fluctuates. Pulumi simplifies these deployment scenarios but teams often need to manage different flavors of Kubernetes for on-premises deployments versus cloud deployments.
Cloudflare Workers provides a serverless execution environment that allows you to create entirely new applications or augment existing ones without configuring or maintaining infrastructure. They support NodeJS and WebAssembly (WASM), as well as any language that can compile to WASM.
Delivered from over 250 locations worldwide, Cloudflare could be the best way to bring down that latency that’s plaguing your customers. Claiming 0ms for cold starts, automatic scaling, 100k free requests per day, and edge storage built-in: Cloudflare offers a pretty compelling edge compute platform for serverless workloads.
Let’s see how we can deploy a low-latency serverless URL shortener to Cloudflare Workers with Pulumi.
Let’s face it, at some point someone is going to modify your carefully-crafted and automated infrastructure without updating your Pulumi program. These changes cause the desired state of our Pulumi program’s to be inconsistent with the state of the world. These inconsistencies are often referred to as “drift”. In this article, I want to cover a couple of patterns for detecting and reconciling this drift with your Pulumi programs.
It’s a surprise to nobody that Pulumi’s YAML support has me rather excited, even though I’m unlikely to use YAML itself for Pulumi. So why do I find it exciting? Well, because it’s an open interface to provide support to many other programming languages for Pulumi.
Let’s take a look at using YAML as a bridge for CUE, JSONNET, and Rust.
With the launch of Amazon Elastic Kubernetes Service (EKS) in 2017, it is now easier than ever to build, secure, operate and maintain Kubernetes clusters in the cloud. Notably, EKS removed the need to manage and configure underlying compute resources and scaling for clusters. Further, EKS Anywhere brings many benefits to hybrid and on-premises deployments.
These developments have proved to be a huge leap forward in productivity for teams that manage cloud infrastructure, enabling them to focus their efforts on deploying applications to meet the needs of customers and stakeholders.
March 15th, 2022… just two weeks ago. The Go team released Go 1.18 to the world. What seems like a trivial point release actually brings a huge new feature to the Go language: Generics.
In this article, I want to show you how you can use this new feature to build a great developer experience with your abstractions for your Pulumi programs.
Today, we’re excited to announce that we’re working with the Pulumi community to provide a place to interact and collaborate on Pulumi-based libraries, projects, and educational materials: the Pulumiverse.
Hello, my name is David Flanagan, and I own more domains than I need. The problem is I have too many ideas; and as we all know, ideas don’t become real until you buy the domain name. Unfortunately, more often than not, that’s about as far as my ideas go—because, life. That being said, I do try to keep my DNS records under control in the event that life affords me the time to follow-up on one of these ideas.
A really common question that we receive on the Pulumi team is, “How can we set config at a project level, that can be used across all stacks?”. When I say “really common” … I mean really, really common. This issue was first open in 2018 and has received 52 votes from the community. Not only that, we’ve had plenty of similar issues created over the years too. Feature-Request: project-wide secrets #2445 Feature Request: Global Config Values How to share a config between projects Project-wide variables (not stack specific) #6719 This is clearly a feature that our community has asked for and we’re currently working on delivering it as soon as we can.
Last year, we introduced a new Pulumi feature that allows you to import existing infrastructure into your Pulumi program. Not only did it bring the resource into the Pulumi state file, but it could generate the source code for your Pulumi program too. Today, we’re excited to announce that we’ve listened to feedback and delivered a plethora of updates and fixes to streamline the import experience; to make it more useful, more convenient, and more powerful.