Get the newsletter!
Four different pathways to deprecation that AWS has trod over the past few years. Some approaches are more customer- or partner-friendly than others, while others are painfully slow or silently abrupt.
On a longer planning horizon than many companies seem to operate, it would appear that the approach that most of the existing cloud providers are taking today is suboptimal. Their messaging, their product offerings, their enhancements around existing services, and their hiring all swirls around a central theme: migrating enterprise workloads into cloud.
Compared to many of its large tech company peers, Amazon has historically struggled with its relationship to Open Source. Google has Kubernetes, Chrome, the Go programming language, and a mountain more. Microsoft has gone from the bad old days of being generally obnoxious, to being the de facto stewards of everyone else’s open source code by way of GitHub, as well as putting out Visual Studio Code, the TypeScript programming language, and a mountain more.
Everyone learns in different ways. Some methods work super well for one person, while someone else just doesn’t “get it.” While most of us know this intellectually, it’s easy to forget that other people aren’t all like we are. I’m speaking in this case, of course, about myself.
I’ve been an advocate for AWS SSO for a while, but the official tooling used to log in and work with various accounts within your organization has been somewhat lacking, to put it mildly. That’s why I was so pleased to stumble across granted recently.
Ubiquiti filed a lawsuit against Brian Krebs for reporting he’d done previously around an alleged Ubiquiti security breach.
Corey suggests that S3’s native features aren’t a substitute for a thoughtful backup strategy.
Google increases cloud pricing
Usually when I talk about AWS regions and availability zones, it ties back to [data transfer pricing] or some other model of cloud economics. Today I want to take a different angle: it’s my belief that how I think about AWS regions and how AWS talks about them are somewhat far apart. The reason I’m doing this in blog form instead of as a Twitter stunt or whatnot is that I’m not particularly intending to be funny, and to be transparent, I’m not completely sure whether I’m right or not. Let’s dive in.
You want to find a way to maturely and sensibly store those secrets in ways that are centralized (so you don’t have to update every server / container / function whenever one changes), secure (so they remain secret), and accessible (in practice, there’s little difference between a service going down and you losing your credentials to talk to the service). There are a number of ways to do this with native AWS services.
Status Paging You Last week The Register did an analysis piece on the AWS Status Page that heavily quoted me. This is a good thing; I’m a big fan of seeing my name in print, and that goes double for a publication that played no small part in my decision to enter the technology field […]
The Trials and Travails of AWS SSO Our newest Principal Cloud Economist Alex Rasmussen hails from a data engineering background. This is a capability that we and our consulting clients have increasingly needed, but his experience means that he’s been focused on different specific areas of the AWS universe than we have. As a result, […]