It’s fun to think about how much data there is swirling around in the global datasphere these days. However you choose to measure it (and there are various ways), it’s a quantity so massive — hundreds of zettabytes, by some estimates — that it’s kind of a hard thing to quite get your head around. If you could convert all the world’s data into droplets of water, for instance, at one megabyte per drop, you’d have enough 1MB drops to fill two more Lake Washingtons.
One thing I love about Pulumi is how easy it is to configure a stack. As a builder mainly of web applications, I’m always thinking about how I’ll configure my apps from one environment to the next, and being able to use Pulumi’s built-in support for configuration and secrets to manage the API keys and database credentials for my dev, staging, and production stacks individually is incredibly convenient. For larger teams and organizations, though, where multiple applications rely on a set of common configuration settings — dozens of apps, say, depending on the the same API service or database — having to keep all of those config settings in sync across all of those individually can become a bit of a pain.
When I was a kid growing up in Southern California, there was a phone number you could call to find out what time it was. It was a local number, 853-1212 (easy to remember as the arrangement of the numbers on the keypad made a capital T), and I used it all the time, to set my watch, adjust the alarm clock, fix the display on the VCR. I don’t recall the last time I used it, probably sometime in the mid ’90s, but I do remember clearly the sound of the voice at the other end of the line.
As a developer, I get lots of ideas for web apps—little things, mostly: nifty ways to keep track of my kids’ allowances, habit trackers, shopping lists. Most of them, however, never see the light of day, and not just because I’m lazy; I also tend to get hung up trying to decide what to use for the technology stack.
As a reader of this blog, you’ve probably heard of the Pulumi Service, the default state-management backend of the Pulumi CLI, and if that’s the case, there’s a good chance you’ve also heard of many of its key features. But did you know we’re adding new features to the Service all the time—some of which are incredibly easy to miss? In this post, we’ll highlight a few of those lesser-known features that we think make it even easier to manage your infrastructure with Pulumi.
If you’ve spent any time with Amazon API Gateway, you know it’s all about making it easier to manage a serverless REST API. But did you know you can do more with API Gateway than just invoke Lambdas? In this post, you’ll learn how to use Pulumi to connect API Gateway with EventBridge, Amazon’s serverless event bus, to build loosely coupled, scalable and maintainable apps and systems.
It’s been a few years since Google shut down Google Reader, and while a number of nice commercial alternatives have sprung in its wake, none of them has ever been quite the right fit for me personally.
So a while back, after far too much time spent wandering the blogsphere manually, typing URLs into address bars by hand, I decided to go looking to see whether the universe had produced an open-source solution to this problem — and to my surprise and delight, it had! Miniflux is an excellent little open-source RSS server and reader, written in Go and backed by PostgreSQL, that also happens to be packaged as a Docker container. So in this post, I’ll show how easy it is to deploy a Miniflux server of your own on AWS, using only Pulumi and a few lines of TypeScript.