<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Aws on Danilo Falcão da Silva</title><link>https://falcao.org/tags/aws/</link><description>Recent content in Aws on Danilo Falcão da Silva</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Thu, 21 May 2026 23:00:00 -0300</lastBuildDate><atom:link href="https://falcao.org/tags/aws/index.xml" rel="self" type="application/rss+xml"/><item><title>Terraform, OpenTofu and Pulumi: Why I Still Run Terraform in 2026</title><link>https://falcao.org/posts/terraform-opentofu-pulumi-2026/</link><pubDate>Thu, 21 May 2026 23:00:00 -0300</pubDate><guid>https://falcao.org/posts/terraform-opentofu-pulumi-2026/</guid><description>&lt;p>Infrastructure as Code stopped being a single-answer question a couple
of years ago. Terraform went &lt;strong>BSL&lt;/strong> in August 2023, &lt;strong>OpenTofu&lt;/strong> forked
under MPL, &lt;strong>Pulumi&lt;/strong> kept arguing that infrastructure should be real
code in real languages, and IBM closed the &lt;strong>$6.4B HashiCorp
acquisition&lt;/strong> in February 2025. Three legitimate tools, three different
bets on who owns the abstraction.&lt;/p>
&lt;p>I still run &lt;strong>Terraform&lt;/strong>. For everything.&lt;/p>
&lt;p>This post is the honest version of why. I&amp;rsquo;ve read the OpenTofu release
notes, watched Pulumi talks, played with both on weekend projects, and
read more migration write-ups than I can remember. I have never put
&lt;strong>OpenTofu&lt;/strong> or &lt;strong>Pulumi&lt;/strong> in front of production traffic. Most of what
follows about those two is research, not muscle memory — and I&amp;rsquo;ll flag
that as I go.&lt;/p></description></item><item><title>AWS Lambda Still Matters in 2026: Glue, Burst, and Honest Trade-offs</title><link>https://falcao.org/posts/aws-lambda-still-matters/</link><pubDate>Thu, 21 May 2026 18:00:00 -0300</pubDate><guid>https://falcao.org/posts/aws-lambda-still-matters/</guid><description>&lt;p>I have spent most of my career running things that boot. Bare metal,
VMs, containers, Kubernetes — boxes that come up, hold state, and need
somebody to think about their lifecycle. &lt;strong>AWS Lambda&lt;/strong> is the opposite
of that mental model, and for a long time I treated it the way a lot of
old-school infrastructure people treat it: useful for toy apps, fine for
a Slack bot, not a serious tool.&lt;/p></description></item><item><title>Where to Hide Kubernetes Secrets: AWS, Azure, GCP, and On-Prem Compared</title><link>https://falcao.org/posts/kubernetes-secrets-aws-azure-gcp-onprem/</link><pubDate>Wed, 20 May 2026 22:25:00 -0300</pubDate><guid>https://falcao.org/posts/kubernetes-secrets-aws-azure-gcp-onprem/</guid><description>&lt;p>The Kubernetes &lt;code>Secret&lt;/code> object is a YAML manifest with a base64-encoded
value in it. That&amp;rsquo;s the entire encryption story. Anyone with &lt;code>get&lt;/code>
permission on the namespace can read every credential the workload
holds. &lt;strong>Base64 is not encryption.&lt;/strong> It is barely obfuscation.&lt;/p>
&lt;p>Teams discover this the wrong way — usually during a security
review, occasionally during an incident — and the next question is
always the same: &lt;em>so where do the real secrets live?&lt;/em>&lt;/p></description></item></channel></rss>