<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Blog on I am Lino</title><link>https://iamlino.net/en/blog/</link><description>Recent content in Blog on I am Lino</description><generator>Hugo</generator><language>en</language><lastBuildDate>Mon, 30 Mar 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://iamlino.net/en/blog/index.xml" rel="self" type="application/rss+xml"/><item><title>Infrastructure as Code: Why Your Infrastructure Deserves Version Control Just Like Your Code</title><link>https://iamlino.net/en/blog/infrastructure-as-code-why-your-infrastructure-deserves-version-control-just-like-your-code/</link><pubDate>Mon, 30 Mar 2026 00:00:00 +0000</pubDate><guid>https://iamlino.net/en/blog/infrastructure-as-code-why-your-infrastructure-deserves-version-control-just-like-your-code/</guid><description>&lt;p&gt;For years we&amp;rsquo;ve treated &lt;strong&gt;infrastructure&lt;/strong&gt; and &lt;strong&gt;software&lt;/strong&gt; as two separate religions, each with their own gods, their own rituals, and most importantly, their own people to blame. The code lived in Git; the infrastructure lived &amp;ldquo;in AWS,&amp;rdquo; some ethereal thing that &amp;ldquo;we manage with scripts and the console.&amp;rdquo;&lt;/p&gt;
&lt;p&gt;But the truth is your infrastructure already behaves like software: it has state, dependencies, bugs, versions, and side effects when you change it.&lt;/p&gt;</description></item><item><title>AI everywhere: the ketchup-on-everything syndrome</title><link>https://iamlino.net/en/blog/ai-everywhere-the-ketchup-on-everything-syndrome/</link><pubDate>Mon, 23 Mar 2026 00:00:00 +0000</pubDate><guid>https://iamlino.net/en/blog/ai-everywhere-the-ketchup-on-everything-syndrome/</guid><description>&lt;p&gt;Every so often, the tech industry latches onto a word and repeats it until it&amp;rsquo;s completely hollow. First it was &amp;ldquo;cloud&amp;rdquo;, then &amp;ldquo;blockchain&amp;rdquo;, then &amp;ldquo;web3&amp;rdquo;. Now the magic word is &amp;ldquo;AI&amp;rdquo;. If you don&amp;rsquo;t put &amp;ldquo;&lt;a href="https://www.forbes.com/sites/bernardmarr/2024/04/25/spotting-ai-washing-how-companies-overhype-artificial-intelligence/" target="_blank" rel="noopener"&gt;AI-powered&lt;/a&gt;
&amp;rdquo; on your product page, it looks like your product comes in black and white with a Nokia 3310 thrown in for free (for my younger readers: those were the indestructible phones that only made calls and lasted a week on a single charge).&lt;/p&gt;</description></item><item><title>How to Make Technical Decisions Without Selling Your Soul to the Hype</title><link>https://iamlino.net/en/blog/how-to-make-technical-decisions-without-selling-your-soul-to-the-hype/</link><pubDate>Mon, 16 Mar 2026 00:00:00 +0000</pubDate><guid>https://iamlino.net/en/blog/how-to-make-technical-decisions-without-selling-your-soul-to-the-hype/</guid><description>&lt;p&gt;There are technical decisions made with data, time, and a bit of judgment.&lt;/p&gt;
&lt;p&gt;And then there are the other kind: the ones made after watching three conference talks, scrolling through two X threads, and half-reading a &lt;a href="https://garden.io/blog/seven-hard-earned-lessons-learned-migrating-a-monolith-to-microservices" target="_blank" rel="noopener"&gt;case study&lt;/a&gt;
, that somehow end with phrases like &amp;ldquo;well&amp;hellip; now that we&amp;rsquo;ve set it all up, we might as well get some use out of it, right?&amp;rdquo;&lt;/p&gt;
&lt;p&gt;One day you&amp;rsquo;re perfectly happy with your API running on a plain old VPS, and the next you find yourself building a &lt;strong&gt;serverless-event-driven-data-mesh-multi-cloud&lt;/strong&gt; architecture because you watched a video claiming &amp;ldquo;that&amp;rsquo;s how Netflix does it.&amp;rdquo;&lt;/p&gt;</description></item><item><title>Microservices, Monoliths, and Other Mythical Creatures</title><link>https://iamlino.net/en/blog/microservices-monoliths-mythical-creatures/</link><pubDate>Mon, 09 Mar 2026 00:00:00 +0000</pubDate><guid>https://iamlino.net/en/blog/microservices-monoliths-mythical-creatures/</guid><description>&lt;p&gt;Some architecture decisions are made calmly, with data, over a nice cup of coffee.&lt;/p&gt;
&lt;p&gt;And then there&amp;rsquo;s real life, where you pick your tech stack the same way you pick a favorite sports team: because you saw it in a cool conference talk, because some big-name company uses it, or because someone tweeted that &amp;ldquo;if you don&amp;rsquo;t have 80 microservices running on Kubernetes, you&amp;rsquo;re a dinosaur.&amp;rdquo;&lt;/p&gt;
&lt;p&gt;Next thing you know, you&amp;rsquo;ve gone from a lovable monolith — a little messy but functional — to a circus of services where nobody really knows what talks to what, your cloud bill is terrifying, and the only microservice running flawlessly is the one that charges you at the end of the month. All because, at some point, somebody stopped asking the only question that actually matters:&lt;/p&gt;</description></item><item><title>The subscription model sucks</title><link>https://iamlino.net/en/blog/subscription-model-sucks/</link><pubDate>Thu, 05 Mar 2026 00:00:00 +0000</pubDate><guid>https://iamlino.net/en/blog/subscription-model-sucks/</guid><description>&lt;p&gt;Back in the day, you&amp;rsquo;d buy a CD, a game, a copy of Word 2003, and that thing was yours &amp;ldquo;forever&amp;rdquo; &amp;ndash; or at least until you switched computers or your music taste moved on.&lt;/p&gt;
&lt;p&gt;Now you blink and discover that &lt;strong&gt;everything&lt;/strong&gt; is a subscription: movies, TV shows, music, the gym, your car, razor blades, cat food, courses, IDEs, design suites, servers&amp;hellip; and if you&amp;rsquo;re not careful, even your couch will hit you with a monthly fee just for sitting near it.&lt;/p&gt;</description></item><item><title>Modern Architecture Fundamentals (No Snake Oil Included)</title><link>https://iamlino.net/en/blog/modern-architecture-fundamentals-no-snake-oil-included/</link><pubDate>Mon, 02 Mar 2026 00:00:00 +0000</pubDate><guid>https://iamlino.net/en/blog/modern-architecture-fundamentals-no-snake-oil-included/</guid><description>&lt;p&gt;Imagine someone telling you: &amp;ldquo;I&amp;rsquo;ve set up my app on an on-premises server with Oracle 9i, but don&amp;rsquo;t worry, it&amp;rsquo;s modern architecture because it runs Docker.&amp;rdquo; That&amp;rsquo;s the moment you understand why people bail on architecture meetings pretending they have a dental emergency.&lt;/p&gt;
&lt;p&gt;When we talk about &lt;strong&gt;&amp;ldquo;modern architecture,&amp;rdquo;&lt;/strong&gt; we&amp;rsquo;re not talking about slapping Kubernetes onto everything or cramming as many buzzwords as possible into a slide deck. We&amp;rsquo;re talking about something far less flashy and far more difficult: building systems that survive in &lt;a href="https://apptastic-coder.com/tutorials/2025-11-3-architecture-comparison/" target="_blank" rel="noopener"&gt;today&amp;rsquo;s ecosystem&lt;/a&gt;
 without going obsolete or blowing up every time the business changes a &amp;ldquo;simple&amp;rdquo; requirement. Systems that live in the cloud (or several clouds), communicate over networks that fail, store data scattered across half the planet, and still need to keep responding when someone decides &amp;ldquo;we also need to go multi-region because an important client said so.&amp;rdquo;&lt;/p&gt;</description></item><item><title>The psychological cost of always being "up to date"</title><link>https://iamlino.net/en/blog/psychological-cost-always-up-to-date/</link><pubDate>Thu, 26 Feb 2026 00:00:00 +0000</pubDate><guid>https://iamlino.net/en/blog/psychological-cost-always-up-to-date/</guid><description>&lt;p&gt;There&amp;rsquo;s a very specific kind of tiredness that only people in tech truly understand. It&amp;rsquo;s not sleepiness, it&amp;rsquo;s not laziness, it&amp;rsquo;s not &amp;ldquo;I hate coding.&amp;rdquo; It&amp;rsquo;s that moment when you close your laptop at a reasonable hour, go make dinner&amp;hellip; and five minutes later open your phone &amp;ldquo;just to check&amp;rdquo; LinkedIn or X. In that &lt;a href="https://blogs.embarcadero.com/preventing-developer-burnout-from-reactive-fixes-to-a-proactive-approach-to-well-being/" target="_blank" rel="noopener"&gt;personal micro-hell&lt;/a&gt;
, everyone seems to have launched a side project, contributed to open source, migrated to another framework, shoved AI into everything including their grocery list, and written a thread explaining how you can do it too &lt;a href="https://www.linkedin.com/pulse/spotting-developer-burnout-strategies-achieving-work-life-miriti-pz4df" target="_blank" rel="noopener"&gt;&amp;ldquo;if you just get organized&amp;rdquo;&lt;/a&gt;
.&lt;/p&gt;</description></item><item><title>A "professional hygiene" guide for developers</title><link>https://iamlino.net/en/blog/professional-hygiene-guide-developers/</link><pubDate>Mon, 23 Feb 2026 00:00:00 +0000</pubDate><guid>https://iamlino.net/en/blog/professional-hygiene-guide-developers/</guid><description>&lt;p&gt;There comes a moment, in almost every tech career, when you catch yourself thinking: &amp;ldquo;maybe the problem is me.&amp;rdquo;&lt;/p&gt;
&lt;p&gt;Not because you don&amp;rsquo;t enjoy coding, but because you feel like you&amp;rsquo;re always two frameworks behind, three blog posts short, and five certifications trailing whatever your LinkedIn feed suggests you should be. You open Twitter on a Sunday morning and it looks like everyone has contributed to open source, built a side project in Rust, and read the latest architecture book&amp;hellip; while you were, I don&amp;rsquo;t know, &lt;a href="https://www.reddit.com/r/ExperiencedDevs/comments/vbceu5/avoiding_long_term_burnout_associated_with/" target="_blank" rel="noopener"&gt;living&lt;/a&gt;
.&lt;/p&gt;</description></item><item><title>SLOs, SLAs, and SLIs: putting numbers on "it kinda works"</title><link>https://iamlino.net/en/blog/slos-slas-slis/</link><pubDate>Fri, 20 Feb 2026 00:00:00 +0000</pubDate><guid>https://iamlino.net/en/blog/slos-slas-slis/</guid><description>&lt;p&gt;In almost every company, there&amp;rsquo;s a magical phrase used to describe a system&amp;rsquo;s health: &amp;ldquo;it more or less works.&amp;rdquo; Translated into plain English: nobody knows how often it goes down, how many requests fail, or how much money is lost when it decides not to work. But hey, &amp;ldquo;more or less.&amp;rdquo;&lt;/p&gt;
&lt;p&gt;&lt;a href="https://cloud.google.com/blog/products/devops-sre/sre-fundamentals-slis-slas-and-slos" target="_blank" rel="noopener"&gt;&lt;strong&gt;SLI&lt;/strong&gt;&lt;/a&gt;
, &lt;a href="https://sre.google/sre-book/service-level-objectives/" target="_blank" rel="noopener"&gt;&lt;strong&gt;SLO&lt;/strong&gt;&lt;/a&gt;
, and &lt;a href="https://dzone.com/articles/the-key-differences-between-sli-slo-and-sla-in-sre" target="_blank" rel="noopener"&gt;&lt;strong&gt;SLA&lt;/strong&gt;&lt;/a&gt;
 are the grown-up version of that phrase. They&amp;rsquo;re the way to go from &amp;ldquo;I think it&amp;rsquo;s fine&amp;rdquo; to &amp;ldquo;this is what it handles, this is what we promise, and this is what&amp;rsquo;s at stake&amp;rdquo; — without having to fall back on the classic &amp;ldquo;trust me, I&amp;rsquo;m an engineer.&amp;rdquo;&lt;/p&gt;</description></item><item><title>Metrics and observability strategy: measuring without fooling yourself</title><link>https://iamlino.net/en/blog/metrics-observability-strategy/</link><pubDate>Wed, 18 Feb 2026 00:00:00 +0000</pubDate><guid>https://iamlino.net/en/blog/metrics-observability-strategy/</guid><description>&lt;p&gt;In almost every team, there&amp;rsquo;s a magical moment when someone opens a dashboard, points at a green graph, and says: &amp;ldquo;See? We&amp;rsquo;re doing great.&amp;rdquo; Meanwhile, support is on fire, the payments API is going down every other hour, and the development team hasn&amp;rsquo;t slept properly in three weeks.&lt;/p&gt;
&lt;p&gt;The difference between a healthy team and one stuck in that endless theater usually comes down to how they use metrics: as a flashlight to see better&amp;hellip; or as a stick to beat each other with.&lt;/p&gt;</description></item><item><title>Checklist: "Is this idea worth a tech article?"</title><link>https://iamlino.net/en/blog/is-this-idea-worth-tech-article/</link><pubDate>Mon, 16 Feb 2026 00:00:00 +0000</pubDate><guid>https://iamlino.net/en/blog/is-this-idea-worth-tech-article/</guid><description>&lt;p&gt;Most good technical articles are born the same way: someone got burned by a real problem and decided that, since they&amp;rsquo;d already bled, the least they could do was save others from tripping over the same spot.
Then there&amp;rsquo;s the other kind: the one you end up writing after seeing yet another LinkedIn post claiming that &amp;ldquo;X is going to revolutionize software development&amp;rdquo; and thinking, &amp;ldquo;this smells like snake oil, but let me take a look just in case.&amp;rdquo;&lt;/p&gt;</description></item><item><title>From "Move Fast" to "Ship Crap": When Speed Eats Quality</title><link>https://iamlino.net/en/blog/from-move-fast-to-ship-crap/</link><pubDate>Sun, 15 Feb 2026 00:00:00 +0000</pubDate><guid>https://iamlino.net/en/blog/from-move-fast-to-ship-crap/</guid><description>&lt;p&gt;We were standing right on the edge of the cliff… and decided to take a big step forward.&lt;/p&gt;
&lt;p&gt;For years, &amp;ldquo;move fast&amp;rdquo; has been sold to us as an unquestionable virtue.
The problem is that, in far too many teams, it&amp;rsquo;s been translated into &amp;ldquo;ship crap&amp;rdquo;: ship fast, break things… and then spend months trapped in technical debt, bugs, angry customers, and general frustration.&lt;/p&gt;
&lt;p&gt;In this article I want to show you how bad metrics (OKRs, velocity, &amp;ldquo;features per quarter&amp;rdquo;) are pushing a lot of products over the edge—and what you can do about it, because it&amp;rsquo;s not &lt;em&gt;all&lt;/em&gt; doom and gloom.&lt;/p&gt;</description></item></channel></rss>