<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Devops on Simple Enough Blog</title><link>https://blog.dev.simpleenough.net/tags/devops/</link><description>Recent content in Devops on Simple Enough Blog</description><generator>Hugo</generator><language>en</language><lastBuildDate>Wed, 27 May 2026 15:55:01 +0200</lastBuildDate><atom:link href="https://blog.dev.simpleenough.net/tags/devops/index.xml" rel="self" type="application/rss+xml"/><item><title>What is a Harness for AI Agents? Understanding the Infrastructure Behind Claude Code and Cursor</title><link>https://blog.dev.simpleenough.net/blog/harness_intro/</link><pubDate>Wed, 27 May 2026 15:55:01 +0200</pubDate><guid>https://blog.dev.simpleenough.net/blog/harness_intro/</guid><description>&lt;h2 id="i-what-is-a-harness-for-ai-agents" class="heading">I. What is a Harness for AI Agents?&lt;a href="#i-what-is-a-harness-for-ai-agents" aria-labelledby="i-what-is-a-harness-for-ai-agents">
&lt;!-- &lt;i class="fas fa-link anchor">&lt;/i> -->
 &lt;svg class="svg-inline--fa fas fa-link anchor" fill="currentColor" aria-hidden="true" role="img" viewBox="0 0 640 512">&lt;use href="#fas-link">&lt;/use>&lt;/svg>&amp;nbsp;
 &lt;/a>
&lt;/h2>
&lt;p>When you first discover tools like &lt;strong>Claude Code&lt;/strong>, &lt;strong>Cursor&lt;/strong>, or &lt;strong>OpenAI Codex&lt;/strong>, it is easy to assume that a simple language model is capable of understanding an entire codebase, fixing bugs, executing commands, and running tests autonomously.&lt;/p>
&lt;p>However, the technical reality is far more interesting.&lt;/p>
&lt;p>The AI model is often only one piece of the system. Behind these tools lies a much more important layer than it first appears: the &lt;strong>harness&lt;/strong>.&lt;/p></description></item><item><title>EC2 Checklist: 7 Things to Do After Launching an Instance</title><link>https://blog.dev.simpleenough.net/blog/ec2_checklist/</link><pubDate>Wed, 20 May 2026 19:30:00 +0100</pubDate><guid>https://blog.dev.simpleenough.net/blog/ec2_checklist/</guid><description>&lt;h1 id="ec2-checklist-7-things-to-do-after-launching-an-instance" class="heading">EC2 Checklist: 7 Things to Do After Launching an Instance&lt;a href="#ec2-checklist-7-things-to-do-after-launching-an-instance" aria-labelledby="ec2-checklist-7-things-to-do-after-launching-an-instance">
&lt;!-- &lt;i class="fas fa-link anchor">&lt;/i> -->
 &lt;svg class="svg-inline--fa fas fa-link anchor" fill="currentColor" aria-hidden="true" role="img" viewBox="0 0 640 512">&lt;use href="#fas-link">&lt;/use>&lt;/svg>&amp;nbsp;
 &lt;/a>
&lt;/h1>
&lt;p>Launching an EC2 instance is easy.&lt;/p>
&lt;p>A few clicks in the AWS Console, and your machine is running.&lt;/p>
&lt;p>In reality, however, &lt;strong>a launched instance is not a production-ready instance&lt;/strong>.&lt;/p>
&lt;p>Many production incidents stem from small details that were overlooked immediately after launch:&lt;/p>
&lt;ul>
&lt;li>Misconfigured security groups&lt;/li>
&lt;li>No backups&lt;/li>
&lt;li>No monitoring&lt;/li>
&lt;li>Missing IAM role&lt;/li>
&lt;li>Poor SSH configuration&lt;/li>
&lt;li>Insufficient storage&lt;/li>
&lt;li>Missing tags&lt;/li>
&lt;/ul>
&lt;p>Here is a simple and practical checklist of &lt;strong>7 things you should verify immediately after launching an EC2 instance&lt;/strong>.&lt;/p></description></item><item><title>Nx Is Not a JavaScript Tool: It Is a Work Orchestrator</title><link>https://blog.dev.simpleenough.net/blog/nx/</link><pubDate>Wed, 13 May 2026 12:00:00 +0100</pubDate><guid>https://blog.dev.simpleenough.net/blog/nx/</guid><description>&lt;h2 id="i-nx-is-not-a-javascript-tool-it-is-a-work-orchestrator" class="heading">I. Nx Is Not a JavaScript Tool: It Is a Work Orchestrator&lt;a href="#i-nx-is-not-a-javascript-tool-it-is-a-work-orchestrator" aria-labelledby="i-nx-is-not-a-javascript-tool-it-is-a-work-orchestrator">
&lt;!-- &lt;i class="fas fa-link anchor">&lt;/i> -->
 &lt;svg class="svg-inline--fa fas fa-link anchor" fill="currentColor" aria-hidden="true" role="img" viewBox="0 0 640 512">&lt;use href="#fas-link">&lt;/use>&lt;/svg>&amp;nbsp;
 &lt;/a>
&lt;/h2>
&lt;p>Nx is often presented — and perceived — as a JavaScript tool.&lt;br>
“A thing for Angular,” or at best “a monorepo runner for Node.”&lt;/p>
&lt;p>That perception is understandable…&lt;br>
but &lt;strong>fundamentally incorrect&lt;/strong>.&lt;/p>
&lt;p>Nx is not a JS tool.&lt;br>
&lt;strong>Nx is a work orchestrator.&lt;/strong>&lt;/p>
&lt;p>And that is precisely why it appears almost naturally
as soon as a repository becomes &lt;strong>polyglot&lt;/strong>.&lt;/p></description></item><item><title>Introduction to AWS Lambda: the complete guide for beginners and developers</title><link>https://blog.dev.simpleenough.net/blog/lambda_intro/</link><pubDate>Wed, 06 May 2026 10:00:00 +0100</pubDate><guid>https://blog.dev.simpleenough.net/blog/lambda_intro/</guid><description>&lt;h2 id="i-what-is-aws-lambda" class="heading">I. What is AWS Lambda?&lt;a href="#i-what-is-aws-lambda" aria-labelledby="i-what-is-aws-lambda">
&lt;!-- &lt;i class="fas fa-link anchor">&lt;/i> -->
 &lt;svg class="svg-inline--fa fas fa-link anchor" fill="currentColor" aria-hidden="true" role="img" viewBox="0 0 640 512">&lt;use href="#fas-link">&lt;/use>&lt;/svg>&amp;nbsp;
 &lt;/a>
&lt;/h2>
&lt;p>AWS Lambda is a &lt;strong>serverless compute&lt;/strong> service launched by Amazon in 2014.&lt;br>
The idea is simple: you provide a function (a piece of code), and AWS runs it on demand, without you having to manage any servers.&lt;/p>
&lt;p>You don’t provision servers, you don’t maintain an OS, and you don’t configure autoscaling manually.&lt;/p></description></item><item><title>Why Is Docker Cache Insufficient for a Monorepo?</title><link>https://blog.dev.simpleenough.net/blog/cache_docker/</link><pubDate>Tue, 28 Apr 2026 10:00:00 +0100</pubDate><guid>https://blog.dev.simpleenough.net/blog/cache_docker/</guid><description>&lt;h2 id="i-why-is-docker-cache-insufficient-for-a-monorepo" class="heading">I. Why Is Docker Cache Insufficient for a Monorepo?&lt;a href="#i-why-is-docker-cache-insufficient-for-a-monorepo" aria-labelledby="i-why-is-docker-cache-insufficient-for-a-monorepo">
&lt;!-- &lt;i class="fas fa-link anchor">&lt;/i> -->
 &lt;svg class="svg-inline--fa fas fa-link anchor" fill="currentColor" aria-hidden="true" role="img" viewBox="0 0 640 512">&lt;use href="#fas-link">&lt;/use>&lt;/svg>&amp;nbsp;
 &lt;/a>
&lt;/h2>
&lt;p>Docker is everywhere.&lt;br>
And with it, a widely shared idea:&lt;/p>





 &lt;blockquote class="blockquote">
 &lt;p>&lt;em>“If we structure our Dockerfiles well, Docker cache will speed up our CI.”&lt;/em>&lt;/p>
 &lt;/blockquote>
&lt;p>That is &lt;strong>true&lt;/strong>&amp;hellip; but only &lt;strong>up to a certain point&lt;/strong>.&lt;/p>
&lt;p>As soon as you work in a &lt;strong>monorepo&lt;/strong> — with multiple projects, multiple languages, and multiple logical pipelines — Docker cache quickly shows its limits.&lt;/p></description></item><item><title>What Should You Really Cache in a CI/CD Pipeline?</title><link>https://blog.dev.simpleenough.net/blog/cache_cicd/</link><pubDate>Tue, 21 Apr 2026 10:00:00 +0100</pubDate><guid>https://blog.dev.simpleenough.net/blog/cache_cicd/</guid><description>&lt;h2 id="i-introduction" class="heading">I. Introduction&lt;a href="#i-introduction" aria-labelledby="i-introduction">
&lt;!-- &lt;i class="fas fa-link anchor">&lt;/i> -->
 &lt;svg class="svg-inline--fa fas fa-link anchor" fill="currentColor" aria-hidden="true" role="img" viewBox="0 0 640 512">&lt;use href="#fas-link">&lt;/use>&lt;/svg>&amp;nbsp;
 &lt;/a>
&lt;/h2>
&lt;p>When trying to speed up a CI/CD pipeline, the first idea that almost always comes up is:&lt;/p>





 &lt;blockquote class="blockquote">
 &lt;p>&lt;em>“we need to add cache”&lt;/em>&lt;/p>
 &lt;/blockquote>
&lt;p>But very quickly, another question appears:&lt;br>
&lt;strong>what exactly are we caching?&lt;/strong>&lt;/p>
&lt;p>Files? Folders? Docker images? Dependencies?&lt;br>
And above all: &lt;strong>which cache has a real impact, and which one just makes the system more complex?&lt;/strong>&lt;/p></description></item><item><title>Thinking Top-Down in a Complex World</title><link>https://blog.dev.simpleenough.net/blog/top_down/</link><pubDate>Tue, 07 Apr 2026 17:30:00 +0100</pubDate><guid>https://blog.dev.simpleenough.net/blog/top_down/</guid><description>&lt;h2 id="i-two-fundamental-ways-of-reasoning" class="heading">I. Two Fundamental Ways of Reasoning&lt;a href="#i-two-fundamental-ways-of-reasoning" aria-labelledby="i-two-fundamental-ways-of-reasoning">
&lt;!-- &lt;i class="fas fa-link anchor">&lt;/i> -->
 &lt;svg class="svg-inline--fa fas fa-link anchor" fill="currentColor" aria-hidden="true" role="img" viewBox="0 0 640 512">&lt;use href="#fas-link">&lt;/use>&lt;/svg>&amp;nbsp;
 &lt;/a>
&lt;/h2>
&lt;p>When we observe how we design &lt;strong>complex systems&lt;/strong> today — DevOps infrastructures, distributed platforms, modern software, or even educational pathways — we almost always find the same intellectual tension. On one side, there is a &lt;strong>progressive and incremental&lt;/strong> approach, which starts from the basics and moves toward something more elaborate. On the other, there is an &lt;strong>outcome-oriented&lt;/strong> approach, which begins by defining a &lt;strong>goal&lt;/strong>, then works backward to determine what is needed to achieve it.&lt;/p></description></item><item><title>Everyday Chaos Engineering: Learning to Love the Wave</title><link>https://blog.dev.simpleenough.net/blog/wave/</link><pubDate>Tue, 24 Mar 2026 10:00:00 +0100</pubDate><guid>https://blog.dev.simpleenough.net/blog/wave/</guid><description>&lt;p>We all dream of a stable, predictable, “calm” system.
And yet, the reality of a modern platform is a living sea: deployments, external dependencies, cloud quotas, flaky networks, traffic spikes, human error—and sometimes… just “something” that should never have happened.&lt;/p>
&lt;p>Chaos engineering is often presented as a spectacular discipline—“we cut an AWS zone,” “we kill a cluster,” “we take Kafka down.”
In real life (and especially in small teams), that’s neither necessary nor desirable at the beginning.&lt;/p></description></item><item><title>DevOps Cycle or a Misunderstanding of the Role?</title><link>https://blog.dev.simpleenough.net/blog/devops_cycle/</link><pubDate>Tue, 17 Mar 2026 11:00:00 +0100</pubDate><guid>https://blog.dev.simpleenough.net/blog/devops_cycle/</guid><description>&lt;h2 id="introduction" class="heading">Introduction&lt;a href="#introduction" aria-labelledby="introduction">
&lt;!-- &lt;i class="fas fa-link anchor">&lt;/i> -->
 &lt;svg class="svg-inline--fa fas fa-link anchor" fill="currentColor" aria-hidden="true" role="img" viewBox="0 0 640 512">&lt;use href="#fas-link">&lt;/use>&lt;/svg>&amp;nbsp;
 &lt;/a>
&lt;/h2>
&lt;p>The term &lt;em>DevOps&lt;/em> is frequently used to describe a heterogeneous set of topics: CI/CD, cloud, Kubernetes, security, observability, incident management, cost management, and more. This breadth of meanings creates a recurring confusion: an organization expresses a need for “DevOps” without specifying the expected value, the associated responsibilities, or the target operating model.&lt;/p>
&lt;p>The outcome is well known: a succession of urgent periods, followed by automation initiatives, and then a gradual return to the same difficulties. This is often described as the “DevOps cycle.” In many cases, this cycle is not intrinsic to DevOps itself, but rather the indicator of a &lt;strong>misunderstanding of the role&lt;/strong>: DevOps is used as a compensating function (support, firefighting, implicit ownership of production) instead of as a structuring organizational capability.&lt;/p></description></item><item><title>The Real Cost of a Bad CI Workflow: Cognitive Load</title><link>https://blog.dev.simpleenough.net/blog/chargecognitiveci/</link><pubDate>Wed, 25 Feb 2026 10:00:00 +0100</pubDate><guid>https://blog.dev.simpleenough.net/blog/chargecognitiveci/</guid><description>&lt;h2 id="i-the-real-cost-of-a-bad-ci-workflow-cognitive-load" class="heading">I. The Real Cost of a Bad CI Workflow: Cognitive Load&lt;a href="#i-the-real-cost-of-a-bad-ci-workflow-cognitive-load" aria-labelledby="i-the-real-cost-of-a-bad-ci-workflow-cognitive-load">
&lt;!-- &lt;i class="fas fa-link anchor">&lt;/i> -->
 &lt;svg class="svg-inline--fa fas fa-link anchor" fill="currentColor" aria-hidden="true" role="img" viewBox="0 0 640 512">&lt;use href="#fas-link">&lt;/use>&lt;/svg>&amp;nbsp;
 &lt;/a>
&lt;/h2>
&lt;p>People talk a lot about CI pipeline performance.&lt;br>
We measure minutes.&lt;br>
We optimize caches.&lt;br>
We parallelize.&lt;/p>
&lt;p>But the real cost of a bad CI workflow is not machine time.&lt;/p>
&lt;p>It is &lt;strong>cognitive load&lt;/strong>.&lt;/p>
&lt;p>And it is far more expensive.&lt;/p>
&lt;hr>




&lt;h2 id="ii-the-invisible-problem" class="heading">II. The Invisible Problem&lt;a href="#ii-the-invisible-problem" aria-labelledby="ii-the-invisible-problem">
&lt;!-- &lt;i class="fas fa-link anchor">&lt;/i> -->
 &lt;svg class="svg-inline--fa fas fa-link anchor" fill="currentColor" aria-hidden="true" role="img" viewBox="0 0 640 512">&lt;use href="#fas-link">&lt;/use>&lt;/svg>&amp;nbsp;
 &lt;/a>
&lt;/h2>
&lt;p>An inefficient CI pipeline is visible:&lt;/p></description></item><item><title>AWS multi-accounts: architectural solution or disguised organizational debt?</title><link>https://blog.dev.simpleenough.net/blog/multiaccounts_aws/</link><pubDate>Wed, 18 Feb 2026 17:30:00 +0100</pubDate><guid>https://blog.dev.simpleenough.net/blog/multiaccounts_aws/</guid><description>&lt;h2 id="i-introduction" class="heading">I. Introduction&lt;a href="#i-introduction" aria-labelledby="i-introduction">
&lt;!-- &lt;i class="fas fa-link anchor">&lt;/i> -->
 &lt;svg class="svg-inline--fa fas fa-link anchor" fill="currentColor" aria-hidden="true" role="img" viewBox="0 0 640 512">&lt;use href="#fas-link">&lt;/use>&lt;/svg>&amp;nbsp;
 &lt;/a>
&lt;/h2>
&lt;p>Creating multiple AWS accounts is now widely presented as a &lt;strong>near-universal best practice&lt;/strong>.&lt;br>
It is often introduced through simple, console-oriented tutorials that give the impression that the problem boils down to a few clicks.&lt;/p>
&lt;p>This view is misleading.&lt;/p>
&lt;p>&lt;strong>Multi-account&lt;/strong> is not an implementation detail, but a &lt;strong>fundamental architectural choice&lt;/strong>.&lt;br>
It directly impacts:&lt;/p>
&lt;ul>
&lt;li>how teams work,&lt;/li>
&lt;li>how security is enforced,&lt;/li>
&lt;li>cost visibility,&lt;/li>
&lt;li>the ability to automate,&lt;/li>
&lt;li>and organizational resilience to human error.&lt;/li>
&lt;/ul>
&lt;p>When misunderstood, it creates &lt;strong>organizational debt&lt;/strong> just as costly as traditional technical debt.&lt;/p></description></item><item><title>Entering the Cloud: The Gates of Hell</title><link>https://blog.dev.simpleenough.net/blog/hell/</link><pubDate>Wed, 04 Feb 2026 09:10:00 +0100</pubDate><guid>https://blog.dev.simpleenough.net/blog/hell/</guid><description>&lt;p>Entering the cloud is rarely experienced as a simple infrastructure change.&lt;br>
For many organizations, it is a brutal—almost violent—break
with their habits, tools, and mental models.&lt;/p>
&lt;p>What was supposed to bring simplicity instead reveals a complexity
that had long been hidden.&lt;br>
And this complexity is not only technical.&lt;/p>
&lt;hr>




&lt;h2 id="i-the-call-of-the-cloud" class="heading">I. The Call of the Cloud&lt;a href="#i-the-call-of-the-cloud" aria-labelledby="i-the-call-of-the-cloud">
&lt;!-- &lt;i class="fas fa-link anchor">&lt;/i> -->
 &lt;svg class="svg-inline--fa fas fa-link anchor" fill="currentColor" aria-hidden="true" role="img" viewBox="0 0 640 512">&lt;use href="#fas-link">&lt;/use>&lt;/svg>&amp;nbsp;
 &lt;/a>
&lt;/h2>
&lt;p>The cloud always begins with a seductive promise.&lt;/p></description></item><item><title>Test-Driven Infrastructure: Applying TDD to Infrastructure as Code</title><link>https://blog.dev.simpleenough.net/blog/infratdd/</link><pubDate>Wed, 14 Jan 2026 13:45:30 +0200</pubDate><guid>https://blog.dev.simpleenough.net/blog/infratdd/</guid><description>&lt;h1 id="test-driven-infrastructure" class="heading">Test-Driven Infrastructure&lt;a href="#test-driven-infrastructure" aria-labelledby="test-driven-infrastructure">
&lt;!-- &lt;i class="fas fa-link anchor">&lt;/i> -->
 &lt;svg class="svg-inline--fa fas fa-link anchor" fill="currentColor" aria-hidden="true" role="img" viewBox="0 0 640 512">&lt;use href="#fas-link">&lt;/use>&lt;/svg>&amp;nbsp;
 &lt;/a>
&lt;/h1>




&lt;h2 id="applying-tdd-to-infrastructure-as-code" class="heading">Applying TDD to Infrastructure as Code&lt;a href="#applying-tdd-to-infrastructure-as-code" aria-labelledby="applying-tdd-to-infrastructure-as-code">
&lt;!-- &lt;i class="fas fa-link anchor">&lt;/i> -->
 &lt;svg class="svg-inline--fa fas fa-link anchor" fill="currentColor" aria-hidden="true" role="img" viewBox="0 0 640 512">&lt;use href="#fas-link">&lt;/use>&lt;/svg>&amp;nbsp;
 &lt;/a>
&lt;/h2>
&lt;p>&lt;strong>Test-Driven Development (TDD)&lt;/strong> is now well established on the application side.&lt;br>
However, when it comes to &lt;strong>infrastructure&lt;/strong>, many still consider TDD unnecessary, too complex, or unsuitable.&lt;/p>
&lt;p>That is a mistake.&lt;/p>
&lt;p>&lt;strong>TDD applied to infrastructure&lt;/strong> already exists, often without being named as such. When properly understood, it becomes a major lever for &lt;strong>securing, structuring, and evolving a cloud platform&lt;/strong>.&lt;/p></description></item><item><title>Using Constants in TDD with Go</title><link>https://blog.dev.simpleenough.net/blog/consttdd/</link><pubDate>Tue, 23 Dec 2025 10:08:49 +0200</pubDate><guid>https://blog.dev.simpleenough.net/blog/consttdd/</guid><description>&lt;h2 id="best-practices-pitfalls-and-design-signals" class="heading">Best Practices, Pitfalls, and Design Signals&lt;a href="#best-practices-pitfalls-and-design-signals" aria-labelledby="best-practices-pitfalls-and-design-signals">
&lt;!-- &lt;i class="fas fa-link anchor">&lt;/i> -->
 &lt;svg class="svg-inline--fa fas fa-link anchor" fill="currentColor" aria-hidden="true" role="img" viewBox="0 0 640 512">&lt;use href="#fas-link">&lt;/use>&lt;/svg>&amp;nbsp;
 &lt;/a>
&lt;/h2>
&lt;p>&lt;strong>Test-Driven Development (TDD)&lt;/strong> is not only about writing tests.&lt;br>
Its primary purpose is to &lt;strong>design software&lt;/strong>.&lt;/p>
&lt;p>In Go, the use of &lt;strong>constants&lt;/strong> is often misunderstood in TDD:&lt;/p>
&lt;ul>
&lt;li>should they be exposed?&lt;/li>
&lt;li>tested?&lt;/li>
&lt;li>injected?&lt;/li>
&lt;li>avoided?&lt;/li>
&lt;/ul>
&lt;p>This article proposes a &lt;strong>pragmatic and idiomatic Go approach&lt;/strong>, based on real-world experience, to understand &lt;strong>when a constant represents good design&lt;/strong>… and &lt;strong>when it hides a deeper problem&lt;/strong>.&lt;/p></description></item><item><title>Interfaces, Functions and Modules in Go: Structuring Your Code for TDD Without Adding Unnecessary Complexity</title><link>https://blog.dev.simpleenough.net/blog/go-tdd-interfaces-functions/</link><pubDate>Mon, 15 Dec 2025 10:08:49 +0200</pubDate><guid>https://blog.dev.simpleenough.net/blog/go-tdd-interfaces-functions/</guid><description>&lt;h2 id="i-introduction" class="heading">I. Introduction&lt;a href="#i-introduction" aria-labelledby="i-introduction">
&lt;!-- &lt;i class="fas fa-link anchor">&lt;/i> -->
 &lt;svg class="svg-inline--fa fas fa-link anchor" fill="currentColor" aria-hidden="true" role="img" viewBox="0 0 640 512">&lt;use href="#fas-link">&lt;/use>&lt;/svg>&amp;nbsp;
 &lt;/a>
&lt;/h2>
&lt;p>Go is a minimalist language, but this simplicity can sometimes make developers feel like something is “missing” — especially when dealing with more advanced architectures, Test-Driven Development, or the need to mock dependencies. Developers coming from Java, C#, or Python often ask the same questions:&lt;/p>
&lt;ul>
&lt;li>&lt;em>Should I turn all my functions into structs + interfaces to test them?&lt;/em>&lt;/li>
&lt;li>&lt;em>How should I organize my packages to keep them modular and testable?&lt;/em>&lt;/li>
&lt;li>&lt;em>Where should interfaces live — in the provider or the consumer?&lt;/em>&lt;/li>
&lt;li>&lt;em>How do I isolate a package that only exports functions?&lt;/em>&lt;/li>
&lt;li>&lt;em>How does Go automatically detect signature changes?&lt;/em>&lt;/li>
&lt;/ul>
&lt;hr>




&lt;h2 id="ii-gos-model-simple-modular-but-different" class="heading">II. Go&amp;rsquo;s Model: Simple, Modular, but Different&lt;a href="#ii-gos-model-simple-modular-but-different" aria-labelledby="ii-gos-model-simple-modular-but-different">
&lt;!-- &lt;i class="fas fa-link anchor">&lt;/i> -->
 &lt;svg class="svg-inline--fa fas fa-link anchor" fill="currentColor" aria-hidden="true" role="img" viewBox="0 0 640 512">&lt;use href="#fas-link">&lt;/use>&lt;/svg>&amp;nbsp;
 &lt;/a>
&lt;/h2>
&lt;p>Unlike Java or C#, Go does not rely on inheritance, classes, or heavy dependency injection frameworks.&lt;/p></description></item><item><title>Consumer-Reported Dependency Health</title><link>https://blog.dev.simpleenough.net/blog/dependencyhealth/</link><pubDate>Mon, 08 Dec 2025 11:18:06 +0200</pubDate><guid>https://blog.dev.simpleenough.net/blog/dependencyhealth/</guid><description>&lt;h2 id="i-rethinking-how-we-evaluate-the-health-of-distributed-systems" class="heading">I. Rethinking How We Evaluate the Health of Distributed Systems&lt;a href="#i-rethinking-how-we-evaluate-the-health-of-distributed-systems" aria-labelledby="i-rethinking-how-we-evaluate-the-health-of-distributed-systems">
&lt;!-- &lt;i class="fas fa-link anchor">&lt;/i> -->
 &lt;svg class="svg-inline--fa fas fa-link anchor" fill="currentColor" aria-hidden="true" role="img" viewBox="0 0 640 512">&lt;use href="#fas-link">&lt;/use>&lt;/svg>&amp;nbsp;
 &lt;/a>
&lt;/h2>
&lt;p>In modern distributed architectures, a system’s health depends as much — if not more — on the state of its &lt;strong>dependencies&lt;/strong> as on its own internal state. Yet most monitoring strategies still rely on synthetic or dedicated healthchecks: &lt;code>/health&lt;/code> endpoints, liveness/readiness probes, external scripts, and similar mechanisms.&lt;/p></description></item><item><title>Why AWS Spot Instances Become Impossible to Get in December</title><link>https://blog.dev.simpleenough.net/blog/spotdecember/</link><pubDate>Mon, 01 Dec 2025 17:08:49 +0200</pubDate><guid>https://blog.dev.simpleenough.net/blog/spotdecember/</guid><description>&lt;h1 id="i-why-aws-spot-instances-become-impossible-to-get-in-december" class="heading">I. Why AWS Spot Instances Become Impossible to Get in December&lt;a href="#i-why-aws-spot-instances-become-impossible-to-get-in-december" aria-labelledby="i-why-aws-spot-instances-become-impossible-to-get-in-december">
&lt;!-- &lt;i class="fas fa-link anchor">&lt;/i> -->
 &lt;svg class="svg-inline--fa fas fa-link anchor" fill="currentColor" aria-hidden="true" role="img" viewBox="0 0 640 512">&lt;use href="#fas-link">&lt;/use>&lt;/svg>&amp;nbsp;
 &lt;/a>
&lt;/h1>
&lt;p>&lt;strong>EC2 Spot Instances&lt;/strong> are a fantastic way to save 50–70% on your AWS compute costs.&lt;br>
They use the unused capacity of AWS data centers… but in &lt;strong>December&lt;/strong>, this unused capacity almost completely disappears.&lt;/p>
&lt;p>Result:&lt;/p>
&lt;ul>
&lt;li>Auto Scaling Groups fail to launch new instances&lt;/li>
&lt;li>deployments get stuck&lt;/li>
&lt;li>“insufficient capacity” everywhere&lt;/li>
&lt;li>Spot interruptions become much more frequent&lt;/li>
&lt;/ul>
&lt;p>If you’ve experienced this, rest assured: it’s &lt;strong>not your fault&lt;/strong>, and not a configuration issue.&lt;br>
It’s a &lt;strong>seasonal phenomenon&lt;/strong>, and it happens every single year.&lt;/p></description></item><item><title>Karpenter: The Intelligent Autoscaler for EKS</title><link>https://blog.dev.simpleenough.net/blog/karpenter/</link><pubDate>Mon, 24 Nov 2025 11:18:06 +0200</pubDate><guid>https://blog.dev.simpleenough.net/blog/karpenter/</guid><description>&lt;h2 id="i-what-is-karpenter" class="heading">I. What is Karpenter?&lt;a href="#i-what-is-karpenter" aria-labelledby="i-what-is-karpenter">
&lt;!-- &lt;i class="fas fa-link anchor">&lt;/i> -->
 &lt;svg class="svg-inline--fa fas fa-link anchor" fill="currentColor" aria-hidden="true" role="img" viewBox="0 0 640 512">&lt;use href="#fas-link">&lt;/use>&lt;/svg>&amp;nbsp;
 &lt;/a>
&lt;/h2>
&lt;p>&lt;strong>Karpenter&lt;/strong> is an open-source autoscaler for Kubernetes, created by AWS.&lt;br>
Its purpose is to &lt;strong>automatically adjust the EC2 node capacity of an EKS cluster based on real workload demand.&lt;/strong>&lt;/p>
&lt;p>In short:&lt;/p>
&lt;ul>
&lt;li>When your cluster is short on resources, &lt;strong>Karpenter adds new nodes.&lt;/strong>&lt;/li>
&lt;li>When nodes become unnecessary, &lt;strong>it removes them.&lt;/strong>&lt;/li>
&lt;/ul>
&lt;p>But more importantly:&lt;/p>
&lt;p>It does this &lt;strong>faster&lt;/strong>, &lt;strong>more intelligently&lt;/strong>, and &lt;strong>more efficiently&lt;/strong> than Kubernetes’ traditional autoscaler (&lt;strong>Cluster Autoscaler&lt;/strong>).&lt;/p></description></item><item><title>This is who IAM</title><link>https://blog.dev.simpleenough.net/blog/iam/</link><pubDate>Tue, 27 May 2025 15:33:47 +0200</pubDate><guid>https://blog.dev.simpleenough.net/blog/iam/</guid><description>&lt;h2 id="i-iam-core-components-and-concepts" class="heading">I. IAM: Core Components and Concepts&lt;a href="#i-iam-core-components-and-concepts" aria-labelledby="i-iam-core-components-and-concepts">
&lt;!-- &lt;i class="fas fa-link anchor">&lt;/i> -->
 &lt;svg class="svg-inline--fa fas fa-link anchor" fill="currentColor" aria-hidden="true" role="img" viewBox="0 0 640 512">&lt;use href="#fas-link">&lt;/use>&lt;/svg>&amp;nbsp;
 &lt;/a>
&lt;/h2>
&lt;p>IAM is based on &lt;strong>entities&lt;/strong> and &lt;strong>policies&lt;/strong>.&lt;/p>




&lt;h3 id="iam-entities" class="heading">IAM Entities&lt;a href="#iam-entities" aria-labelledby="iam-entities">
&lt;!-- &lt;i class="fas fa-link anchor">&lt;/i> -->
 &lt;svg class="svg-inline--fa fas fa-link anchor" fill="currentColor" aria-hidden="true" role="img" viewBox="0 0 640 512">&lt;use href="#fas-link">&lt;/use>&lt;/svg>&amp;nbsp;
 &lt;/a>
&lt;/h3>
&lt;ul>
&lt;li>&lt;strong>Users&lt;/strong>: Represent people or applications. Example: a developer named &amp;ldquo;alice&amp;rdquo;.&lt;/li>
&lt;li>&lt;strong>Groups&lt;/strong>: Collections of users sharing the same permissions.&lt;/li>
&lt;li>&lt;strong>Roles&lt;/strong>: IAM entities that can be temporarily assumed by others. Ideal for &lt;strong>federation&lt;/strong> or services like EC2 or Lambda.&lt;/li>
&lt;li>&lt;strong>Policies&lt;/strong>: JSON documents that define permissions attached to an entity.&lt;/li>
&lt;/ul>




&lt;h3 id="sample-json-policy" class="heading">Sample JSON Policy&lt;a href="#sample-json-policy" aria-labelledby="sample-json-policy">
&lt;!-- &lt;i class="fas fa-link anchor">&lt;/i> -->
 &lt;svg class="svg-inline--fa fas fa-link anchor" fill="currentColor" aria-hidden="true" role="img" viewBox="0 0 640 512">&lt;use href="#fas-link">&lt;/use>&lt;/svg>&amp;nbsp;
 &lt;/a>
&lt;/h3>
&lt;div class="mb-3 syntax-highlight">&lt;div class="highlight">&lt;pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;">&lt;code class="language-json" data-lang="json">&lt;span style="display:flex;">&lt;span>{
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span> &lt;span style="color:#f92672">&amp;#34;Version&amp;#34;&lt;/span>: &lt;span style="color:#e6db74">&amp;#34;2012-10-17&amp;#34;&lt;/span>,
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span> &lt;span style="color:#f92672">&amp;#34;Statement&amp;#34;&lt;/span>: [
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span> {
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span> &lt;span style="color:#f92672">&amp;#34;Effect&amp;#34;&lt;/span>: &lt;span style="color:#e6db74">&amp;#34;Allow&amp;#34;&lt;/span>,
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span> &lt;span style="color:#f92672">&amp;#34;Action&amp;#34;&lt;/span>: &lt;span style="color:#e6db74">&amp;#34;s3:ListBucket&amp;#34;&lt;/span>,
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span> &lt;span style="color:#f92672">&amp;#34;Resource&amp;#34;&lt;/span>: &lt;span style="color:#e6db74">&amp;#34;arn:aws:s3:::example_bucket&amp;#34;&lt;/span>
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span> }
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span> ]
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>}&lt;/span>&lt;/span>&lt;/code>&lt;/pre>&lt;/div>&lt;/div>&lt;p>This IAM policy allows an AWS entity (user, role, or group) to list the objects in a specific S3 bucket named &lt;code>example_bucket&lt;/code>. It uses the standard IAM version format (&lt;code>2012-10-17&lt;/code>) and allows the &lt;code>s3:ListBucket&lt;/code> action on the resource identified by its ARN. It lets the entity see the list of objects (names, sizes, metadata), but not read or modify them—unless additional permissions are granted. This minimal policy is often used for inventory or bucket navigation via the AWS Console or API.&lt;/p></description></item><item><title>3 Simple Ways to Save Up to 90% on EC2 Costs: Spot Instances</title><link>https://blog.dev.simpleenough.net/blog/spot/</link><pubDate>Fri, 02 May 2025 17:08:49 +0200</pubDate><guid>https://blog.dev.simpleenough.net/blog/spot/</guid><description>&lt;h2 id="i-introduction-to-spot-instances" class="heading">I. Introduction to Spot Instances&lt;a href="#i-introduction-to-spot-instances" aria-labelledby="i-introduction-to-spot-instances">
&lt;!-- &lt;i class="fas fa-link anchor">&lt;/i> -->
 &lt;svg class="svg-inline--fa fas fa-link anchor" fill="currentColor" aria-hidden="true" role="img" viewBox="0 0 640 512">&lt;use href="#fas-link">&lt;/use>&lt;/svg>&amp;nbsp;
 &lt;/a>
&lt;/h2>
&lt;p>&lt;strong>Amazon EC2 Spot Instances&lt;/strong> offer a powerful way to drastically reduce cloud computing costs. Designed to utilize unused Amazon EC2 capacity, these instances are available at a &lt;strong>price up to 90% lower&lt;/strong> than On-Demand instances.&lt;/p>
&lt;p>While these savings are appealing, Spot Instances are not suitable for all workloads. They are ideal for &lt;strong>flexible, interruption-tolerant&lt;/strong>, or distributed jobs such as data processing, machine learning training, or performance testing.&lt;/p></description></item><item><title>A problem. Don’t panic, prepare a support ticket</title><link>https://blog.dev.simpleenough.net/blog/assistance/</link><pubDate>Fri, 25 Apr 2025 13:10:00 +0100</pubDate><guid>https://blog.dev.simpleenough.net/blog/assistance/</guid><description>&lt;h2 id="i-identify-and-reproduce-the-problem-precisely" class="heading">I. Identify and Reproduce the Problem Precisely&lt;a href="#i-identify-and-reproduce-the-problem-precisely" aria-labelledby="i-identify-and-reproduce-the-problem-precisely">
&lt;!-- &lt;i class="fas fa-link anchor">&lt;/i> -->
 &lt;svg class="svg-inline--fa fas fa-link anchor" fill="currentColor" aria-hidden="true" role="img" viewBox="0 0 640 512">&lt;use href="#fas-link">&lt;/use>&lt;/svg>&amp;nbsp;
 &lt;/a>
&lt;/h2>
&lt;p>Before contacting AWS Support, it&amp;rsquo;s crucial to clearly document the observed behavior. The goal is to enable the &lt;strong>support team&lt;/strong> to quickly analyze the context. Start by identifying the service involved: EC2, S3, Lambda, or another component of your cloud infrastructure. Documenting an incident clearly is key to avoiding unnecessary back-and-forth.&lt;/p></description></item><item><title>Why and how to use Git submodules</title><link>https://blog.dev.simpleenough.net/blog/gitsubmodules/</link><pubDate>Tue, 22 Apr 2025 10:00:00 +0100</pubDate><guid>https://blog.dev.simpleenough.net/blog/gitsubmodules/</guid><description>&lt;h2 id="i-introduction-to-git-submodules" class="heading">I. Introduction to Git Submodules&lt;a href="#i-introduction-to-git-submodules" aria-labelledby="i-introduction-to-git-submodules">
&lt;!-- &lt;i class="fas fa-link anchor">&lt;/i> -->
 &lt;svg class="svg-inline--fa fas fa-link anchor" fill="currentColor" aria-hidden="true" role="img" viewBox="0 0 640 512">&lt;use href="#fas-link">&lt;/use>&lt;/svg>&amp;nbsp;
 &lt;/a>
&lt;/h2>
&lt;p>&lt;strong>Git submodules&lt;/strong> are a built-in feature that lets you include one Git repository inside another. This approach is useful when you need to manage &lt;strong>dependencies&lt;/strong> between different codebases while keeping them autonomous.&lt;/p>
&lt;p>Submodules point to a &lt;strong>specific commit&lt;/strong> of an external repository. This ensures that every version of the main project uses exactly the same revision of its submodules, providing &lt;strong>consistency and reproducibility&lt;/strong>.&lt;/p></description></item><item><title>Introduction to AWS ELB</title><link>https://blog.dev.simpleenough.net/blog/elb/</link><pubDate>Sat, 15 Mar 2025 21:11:49 +0000</pubDate><guid>https://blog.dev.simpleenough.net/blog/elb/</guid><description>&lt;h2 id="i-introduction-to-load-balancers-in-aws" class="heading">I. Introduction to Load Balancers in AWS&lt;a href="#i-introduction-to-load-balancers-in-aws" aria-labelledby="i-introduction-to-load-balancers-in-aws">
&lt;!-- &lt;i class="fas fa-link anchor">&lt;/i> -->
 &lt;svg class="svg-inline--fa fas fa-link anchor" fill="currentColor" aria-hidden="true" role="img" viewBox="0 0 640 512">&lt;use href="#fas-link">&lt;/use>&lt;/svg>&amp;nbsp;
 &lt;/a>
&lt;/h2>
&lt;p>An Elastic Load Balancer (ELB) acts as a traffic distributor, automatically spreading incoming traffic across multiple target resources such as &lt;strong>EC2 instances&lt;/strong>, &lt;strong>containers&lt;/strong>, or &lt;strong>IP addresses&lt;/strong>.&lt;/p>
&lt;p>This functionality is a cornerstone of fault-tolerant and highly available cloud application design. AWS offers three types of ELB tailored to different use cases, each with specific features.&lt;/p></description></item><item><title>What is a Bundle? Understanding the Concept</title><link>https://blog.dev.simpleenough.net/blog/bundleconcept/</link><pubDate>Mon, 03 Feb 2025 10:00:00 +0100</pubDate><guid>https://blog.dev.simpleenough.net/blog/bundleconcept/</guid><description>&lt;p>The term &lt;strong>&amp;ldquo;bundle&amp;rdquo;&lt;/strong> is widely used in web development and DevOps. It refers to a &lt;strong>grouping of files, resources, or elements&lt;/strong> to simplify their management and improve performance.&lt;/p>
&lt;p>However, a &lt;strong>bundle&lt;/strong> does not have the same meaning everywhere. In this article, we will explore its &lt;strong>different uses&lt;/strong> in three key areas:&lt;/p>
&lt;p>&lt;strong>Hugo (static site generator)&lt;/strong>&lt;br>
&lt;strong>CSS &amp;amp; JavaScript (front-end development)&lt;/strong>&lt;br>
&lt;strong>DevOps (Docker, Kubernetes, Helm, etc.)&lt;/strong>&lt;/p>
&lt;hr>




&lt;h2 id="1-bundle-in-hugo-organizing-files-smartly" class="heading">1. Bundle in Hugo: Organizing Files Smartly&lt;a href="#1-bundle-in-hugo-organizing-files-smartly" aria-labelledby="1-bundle-in-hugo-organizing-files-smartly">
&lt;!-- &lt;i class="fas fa-link anchor">&lt;/i> -->
 &lt;svg class="svg-inline--fa fas fa-link anchor" fill="currentColor" aria-hidden="true" role="img" viewBox="0 0 640 512">&lt;use href="#fas-link">&lt;/use>&lt;/svg>&amp;nbsp;
 &lt;/a>
&lt;/h2>
&lt;p>In Hugo, a &lt;strong>bundle&lt;/strong> is a folder containing a page and its associated resources (images, JSON files, etc.). There are two types of &lt;strong>Page Bundles&lt;/strong>:&lt;/p></description></item></channel></rss>