<?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/blog/</link><description>Recent content in Blog on I am Lino</description><generator>Hugo</generator><language>es</language><lastBuildDate>Mon, 30 Mar 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://iamlino.net/blog/index.xml" rel="self" type="application/rss+xml"/><item><title>Infra as Code: por qué tu infraestructura merece versionado igual que tu código</title><link>https://iamlino.net/blog/infra-as-code-por-que-tu-infraestructura-merece-versionado-igual-que-tu-codigo/</link><pubDate>Mon, 30 Mar 2026 00:00:00 +0000</pubDate><guid>https://iamlino.net/blog/infra-as-code-por-que-tu-infraestructura-merece-versionado-igual-que-tu-codigo/</guid><description>&lt;p&gt;Durante años hemos tratado &lt;strong&gt;infraestructura&lt;/strong&gt; y &lt;strong&gt;software&lt;/strong&gt; como si fueran dos religiones distintas con sus propios dioses, sus propios rituales y, sobre todo, sus propios culpables. El código estaba en Git, la infraestructura &amp;ldquo;en AWS&amp;rdquo;, como una cosa etérea que &amp;ldquo;ya se gestiona con scripts y con la consola&amp;rdquo;.&lt;/p&gt;
&lt;p&gt;Pero la verdad es que tu infraestructura ya se comporta como software: tiene estados, dependencias, bugs, versiones y efectos secundarios cuando la cambias.&lt;/p&gt;</description></item><item><title>IA en todas partes: el síndrome del échale kétchup a todo</title><link>https://iamlino.net/blog/ia-en-todas-partes-el-sindrome-del-echale-ketchup-a-todo/</link><pubDate>Mon, 23 Mar 2026 00:00:00 +0000</pubDate><guid>https://iamlino.net/blog/ia-en-todas-partes-el-sindrome-del-echale-ketchup-a-todo/</guid><description>&lt;p&gt;Cada cierto tiempo, la industria tecnológica encuentra una palabra y la repite hasta vaciarla de significado. Antes fue &amp;ldquo;cloud&amp;rdquo;, luego &amp;ldquo;blockchain&amp;rdquo;, luego &amp;ldquo;web3&amp;rdquo;. Ahora la palabra mágica es &amp;ldquo;IA&amp;rdquo;. Si no pones &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; en la página de producto parece que tu producto viene en blanco y negro y con un Nokia 3310 de regalo (para mis estimados lectores jovenzuelos, eran esos teléfonos indestructibles que solo hacían llamadas y duraban una semana con batería).&lt;/p&gt;</description></item><item><title>Cómo tomar decisiones técnicas sin vender tu alma al hype</title><link>https://iamlino.net/blog/como-tomar-decisiones-tecnicas-sin-vender-tu-alma-al-hype/</link><pubDate>Mon, 16 Mar 2026 00:00:00 +0000</pubDate><guid>https://iamlino.net/blog/como-tomar-decisiones-tecnicas-sin-vender-tu-alma-al-hype/</guid><description>&lt;p&gt;Hay decisiones técnicas que se toman con datos, tiempo y algo de criterio.&lt;/p&gt;
&lt;p&gt;Y luego están las otras: las que se toman después de ver tres charlas, dos hilos de X y un &lt;a href="https://garden.io/blog/seven-hard-earned-lessons-learned-migrating-a-monolith-to-microservices" target="_blank" rel="noopener"&gt;caso de estudio&lt;/a&gt;
 mal leído, y acaban en frases como &amp;ldquo;bueno&amp;hellip; ahora ya que lo tenemos montado, habrá que aprovecharlo, ¿no?&amp;rdquo;.&lt;/p&gt;
&lt;p&gt;Un día estás feliz con tu API en un VPS normalito y, al siguiente, te descubres montando una arquitectura &lt;strong&gt;serverless-event-driven-data-mesh-multi-cloud&lt;/strong&gt; porque viste un video donde decía que &amp;ldquo;así lo hace Netflix&amp;rdquo;.&lt;/p&gt;</description></item><item><title>Microservicios, monolitos y otras criaturas mitológicas</title><link>https://iamlino.net/blog/microservicios-monolitos-criaturas-mitologicas/</link><pubDate>Mon, 09 Mar 2026 00:00:00 +0000</pubDate><guid>https://iamlino.net/blog/microservicios-monolitos-criaturas-mitologicas/</guid><description>&lt;p&gt;Hay arquitecturas que se eligen con calma, con datos, con un café delante.&lt;/p&gt;
&lt;p&gt;Y luego está la vida real, donde eliges tecnología como quien elige equipo de fútbol: porque la viste en una charla molona, porque la usa una empresa famosa o porque alguien tuiteó que &amp;ldquo;si no tienes 80 microservicios en Kubernetes eres un dinosaurio&amp;rdquo;.&lt;/p&gt;
&lt;p&gt;De repente, pasas de tener un monolito entrañable, un poco caótico pero funcional, a un zoológico de servicios donde nadie sabe muy bien qué habla con qué, tu factura de cloud da miedo y el único microservicio que funciona impecable es el que cobra a fin de mes. Y todo porque, en algún punto, se dejó de hacer la única pregunta importante:&lt;/p&gt;</description></item><item><title>El modelo de suscripción apesta</title><link>https://iamlino.net/blog/el-modelo-de-suscripcion-apesta/</link><pubDate>Thu, 05 Mar 2026 00:00:00 +0000</pubDate><guid>https://iamlino.net/blog/el-modelo-de-suscripcion-apesta/</guid><description>&lt;p&gt;Hubo una época feliz en la que comprabas un CD, un juego, un Word 2003, un Photoshop, y aquello era tuyo &amp;ldquo;para siempre&amp;rdquo;, o hasta que cambiabas de ordenador o de gusto musical.&lt;/p&gt;
&lt;p&gt;Ahora pestañeas y descubres que &lt;strong&gt;todo&lt;/strong&gt; es una suscripción: pelis, series, música, gimnasio, coche, cuchillas de afeitar, comida para el gato, cursos, IDEs, suites de diseño, servidores&amp;hellip; y, si te descuidas, tu propio sofá te cobra por respirar a su lado.&lt;/p&gt;</description></item><item><title>Fundamentos de arquitectura moderna (sin vender humo)</title><link>https://iamlino.net/blog/fundamentos-de-arquitectura-moderna-sin-vender-humo/</link><pubDate>Mon, 02 Mar 2026 00:00:00 +0000</pubDate><guid>https://iamlino.net/blog/fundamentos-de-arquitectura-moderna-sin-vender-humo/</guid><description>&lt;p&gt;Imagina que alguien te dice: &amp;ldquo;he montado mi aplicación en un servidor on-premises con Oracle 9i, pero tranquilo, es arquitectura moderna porque lleva Docker&amp;rdquo;. Es en ese momento cuando entiendes por qué la gente abandona las reuniones de arquitectura fingiendo una urgencia dental.&lt;/p&gt;
&lt;p&gt;Cuando hablamos de &lt;strong&gt;&amp;ldquo;arquitectura moderna&amp;rdquo;&lt;/strong&gt; no hablamos de ponerle Kubernetes a cualquier cosa ni de ver cuántos palabros caben en una diapositiva. Hablamos de otra cosa mucho menos vistosa y mucho más difícil: construir sistemas que sobrevivan en el &lt;a href="https://apptastic-coder.com/tutorials/2025-11-3-architecture-comparison/" target="_blank" rel="noopener"&gt;ecosistema actual&lt;/a&gt;
 sin quedarse obsoletos ni explotar cada vez que negocio cambia un requisito &amp;ldquo;tonto&amp;rdquo;. Sistemas que viven en la nube (o en varias), hablan por redes que fallan, guardan datos repartidos por medio planeta y tienen que seguir respondiendo cuando alguien decide que &amp;ldquo;ahora también tenemos que ser multi-región porque lo ha dicho un cliente importante&amp;rdquo;.&lt;/p&gt;</description></item><item><title>El coste psicológico de estar siempre "actualizado"</title><link>https://iamlino.net/blog/coste-psicologico-estar-siempre-actualizado/</link><pubDate>Thu, 26 Feb 2026 00:00:00 +0000</pubDate><guid>https://iamlino.net/blog/coste-psicologico-estar-siempre-actualizado/</guid><description>&lt;p&gt;Hay un cansancio muy concreto que solo entiende quien vive en tecnología. No es sueño, no es pereza, no es &amp;ldquo;odio programar&amp;rdquo;. Es ese momento en el que cierras el portátil a una hora razonable, te vas a hacer la cena&amp;hellip; y cinco minutos después abres el móvil &amp;ldquo;solo para mirar&amp;rdquo; LinkedIn o X. En ese &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;micro-infierno particular&lt;/a&gt;
, todo el mundo parece haber lanzado un proyecto personal, contribuido a open source, migrado a otro framework, metido IA hasta en la lista de la compra y escrito un hilo explicando cómo tú también puedes hacerlo &lt;a href="https://www.linkedin.com/pulse/spotting-developer-burnout-strategies-achieving-work-life-miriti-pz4df" target="_blank" rel="noopener"&gt;&amp;ldquo;si te organizas bien&amp;rdquo;&lt;/a&gt;
.&lt;/p&gt;</description></item><item><title>Guía de "higiene profesional" para desarrolladores</title><link>https://iamlino.net/blog/guia-higiene-profesional-desarrolladores/</link><pubDate>Mon, 23 Feb 2026 00:00:00 +0000</pubDate><guid>https://iamlino.net/blog/guia-higiene-profesional-desarrolladores/</guid><description>&lt;p&gt;Hay un momento, en casi todas las carreras técnicas, en el que te pillas a ti mismo pensando: &amp;ldquo;igual el problema soy yo&amp;rdquo;.&lt;/p&gt;
&lt;p&gt;No es porque no te guste programar, sino porque sientes que vas siempre dos frameworks por detrás, tres publicaciones por debajo y cinco certificaciones a la zaga de lo que sugiere tu &lt;em&gt;feed&lt;/em&gt; de LinkedIn. Abres Twitter un domingo por la mañana y parece que todo el mundo ha contribuido a &lt;em&gt;open source&lt;/em&gt;, ha hecho un proyecto personal en Rust y se ha leído el último libro de arquitectura&amp;hellip; mientras tú estabas, no sé, &lt;a href="https://www.reddit.com/r/ExperiencedDevs/comments/vbceu5/avoiding_long_term_burnout_associated_with/" target="_blank" rel="noopener"&gt;viviendo&lt;/a&gt;
.&lt;/p&gt;</description></item><item><title>SLOs, SLAs y SLIs: ponerle números a "funciona más o menos"</title><link>https://iamlino.net/blog/slos-slas-slis/</link><pubDate>Fri, 20 Feb 2026 00:00:00 +0000</pubDate><guid>https://iamlino.net/blog/slos-slas-slis/</guid><description>&lt;p&gt;En casi todas las empresas hay una frase mágica que se usa para describir la salud de un sistema: &amp;ldquo;más o menos funciona&amp;rdquo;. Traducido al castellano plano: nadie sabe cuántas veces se cae, cuántas peticiones fallan, ni cuánto dinero se pierde cuando decide no funcionar. Pero, oye, &amp;ldquo;más o menos&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;
 y &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;
 son la versión adulta de esa frase. Son la forma de pasar de &amp;ldquo;yo creo que va bien&amp;rdquo; a &amp;ldquo;esto es lo que aguanta, esto es lo que prometemos y esto es lo que nos estamos jugando&amp;rdquo;, sin tener que recurrir al clásico &amp;ldquo;confía en mí, soy ingeniero&amp;rdquo;.&lt;/p&gt;</description></item><item><title>Estrategia de métricas y observabilidad: medir sin autoengañarte</title><link>https://iamlino.net/blog/estrategia-metricas-observabilidad/</link><pubDate>Wed, 18 Feb 2026 00:00:00 +0000</pubDate><guid>https://iamlino.net/blog/estrategia-metricas-observabilidad/</guid><description>&lt;p&gt;En casi todos los equipos hay un momento mágico en el que alguien abre un panel, señala una gráfica verde y dice: &amp;ldquo;¿Veis? Estamos genial&amp;rdquo;. Mientras tanto, soporte está en llamas, la API de pagos se cae a ratos y la gente en desarrollo lleva tres semanas durmiendo regular.&lt;/p&gt;
&lt;p&gt;La diferencia entre un equipo sano y uno que vive en ese teatro constante suele estar en cómo usa las métricas: como linterna para ver mejor&amp;hellip; o como palo para pegarse entre sí.&lt;/p&gt;</description></item><item><title>Checklist de "¿esta idea merece un artículo técnico?"</title><link>https://iamlino.net/blog/checklist-esta-idea-merece-articulo/</link><pubDate>Mon, 16 Feb 2026 00:00:00 +0000</pubDate><guid>https://iamlino.net/blog/checklist-esta-idea-merece-articulo/</guid><description>&lt;p&gt;La mayoría de los buenos artículos técnicos nacen de lo mismo: alguien se ha hecho daño con un problema real y ha decidido que, ya que ha sangrado, al menos que otros no tropiecen en el mismo sitio.
Luego está el otro tipo de artículo: el que sale después de ver el enésimo post en LinkedIn diciendo que &amp;ldquo;X va a revolucionar el desarrollo de software&amp;rdquo; y pensar &amp;ldquo;esto huele a humo, pero déjame mirarlo por si acaso&amp;rdquo;.&lt;/p&gt;</description></item><item><title>De "move fast" a "ship crap": cuando la velocidad se come a la calidad</title><link>https://iamlino.net/blog/de-move-fast-a-ship-crap/</link><pubDate>Sun, 15 Feb 2026 00:00:00 +0000</pubDate><guid>https://iamlino.net/blog/de-move-fast-a-ship-crap/</guid><description>&lt;p&gt;Estábamos al borde del abismo y hemos dado un gran paso adelante.&lt;/p&gt;
&lt;p&gt;Durante años nos han vendido el &amp;ldquo;move fast&amp;rdquo; como si fuera una virtud absoluta.
El problema es que, en demasiados equipos, se ha traducido en &amp;ldquo;ship crap&amp;rdquo;: entregar rápido, romper cosas… y luego vivir atrapado en la deuda técnica, los bugs, los cabreos de tus clientes y la frustración.
En este artículo te voy a contar cómo las métricas mal planteadas (OKR, velocity, &amp;ldquo;features por trimestre&amp;rdquo;) están empujando a muchos productos al abismo, y a darte alguna solución, que no todo está (tan) mal.&lt;/p&gt;</description></item></channel></rss>