Blog v3: simplificando y mejorando mi blog

---

Para el contexto completo de v1 y v2, el artículo original es este: Cómo decidí la tecnología del blog.

1. El objetivo original

Cuando creé este blog, el objetivo era muy concreto:

Usar cuantos más servicios de AWS mejor, para practicar con ellos en un proyecto real, a un coste de casi cero euros.

Y se cumplió. Durante años, el blog fue mi laboratorio personal: desplegué Amplify, migré a Terraform, usé CodePipeline y CodeBuild para el CI/CD, monté un backend serverless completo con API Gateway, Lambda, Step Functions, DynamoDB, SES, SNS, SSM Parameter Store y EventBridge para formularios de contacto, feedback y suscripciones. Llegué a gestionar exactamente 7 repositorios relacionados con el blog, sin coste gracias al free tier y a créditos AWS.

Cada servicio que añadía tenía un propósito claro: no era usar algo por primera vez en teoría, sino construirlo yo mismo en producción, integrarlo, romperlo, entender sus límites reales y aprender de la experiencia. Eso es lo que buscaba.

Llegado ese punto, surgió la siguiente pregunta:

¿Sigo manteniendo todo esto por inercia, o simplifico y me quedo solo con lo que todavía tiene sentido?

2. El inventario de lo que había

Para ver la magnitud real, este era el estado anterior.

Repositorios archivados

Repositorio	Descripción	Visibilidad
blog-legacy-web-code	Código fuente Jekyll del blog original	Público
blog-legacy-web-code-pipeline	Pipeline CI/CD para el despliegue del código web	Privado
blog-legacy-frontend-infrastructure	Infraestructura Terraform del blog, principalmente S3 y CloudFront	Privado
blog-legacy-frontend-infrastructure-pipeline	Pipeline de CodePipeline para desplegar la infraestructura	Privado
blog-legacy-contact-service	AWS SAM: Step Functions, Lambda, DynamoDB, SES y servicios auxiliares para el formulario de contacto	Privado
blog-legacy-feedback-service	AWS SAM: Step Functions, Lambda, DynamoDB, SES y servicios auxiliares para el formulario de feedback	Privado
blog-legacy-backend-infrastructure	CDK TypeScript: API Gateway, Lambda, DynamoDB y recursos de backend para comentarios y suscripciones	Público

En total: 7 repositorios exactos.

Servicios AWS eliminados

La capa de hosting se mantuvo, pero toda la parte de backend y CI/CD gestionada dentro de AWS desapareció.

Estos son los servicios principales que dejé de usar para el blog:

• Amazon CodePipeline: pipelines para frontend, infraestructura, contact service y feedback service
• AWS CodeBuild: builds de Terraform y SAM asociados
• Amazon API Gateway: endpoints REST para los formularios
• AWS Lambda: funciones de procesado de contacto, feedback y suscripciones
• AWS Step Functions: orquestación de los flujos de formulario
• Amazon DynamoDB: tablas para contactos, feedback y suscriptores
• Amazon SES: notificaciones por email
• Amazon SNS: mensajería y notificaciones auxiliares
• AWS Systems Manager Parameter Store: configuración y parámetros usados por los servicios
• Amazon EventBridge: eventos y automatizaciones relacionadas con el backend
• Amazon EventBridge Pipes: conexiones entre fuentes de eventos y servicios de procesamiento
• AWS CDK / CloudFormation: stacks de backend y recursos asociados
• IAM roles y policies: permisos necesarios para todos esos servicios
• Amazon CloudWatch Logs: logs asociados a Lambdas, builds, Step Functions y otros componentes

No todos estos elementos tenían el mismo peso, pero todos formaban parte del ecosistema de servicios. El blog llegó a tener más de 15 recursos AWS si se cuenta toda la arquitectura de backend, CI/CD, observabilidad, configuración y permisos.

Todo esto estaba desplegado, funcionaba, era serverless y costaba cero euros. Y lo eliminé igualmente.

3. Por qué eliminar algo que funciona

Cada uno de esos recursos existía por una razón válida en su momento. El problema es que esa razón ya no aplica.

Conocía esos servicios. Los había construido, integrado, roto y escrito sobre ellos aquí en mi blog. Una vez hecho eso, mantener la infraestructura desplegada no añadía nada nuevo. Era solo algo más que mantener, y en arquitectura, lo que no aporta valor es deuda. Puede que no ahora, pero lo será a futuro. Seguro.

Saber qué eliminar, y cuándo, es tan importante como saber qué construir.

El cambio de mentalidad es este: antes elegía los servicios para aprender; ahora los elijo para resolver. La solución más simple que funciona gana, independientemente de si viene de AWS o de cualquier otro sitio.

4. La arquitectura actual: v3

4.1. Hosting: se mantiene la parte que sí tenía sentido

La capa de hosting prácticamente no cambió respecto a v2. S3 + CloudFront sigue siendo la opción correcta para un sitio estático: sin servidores que gestionar, distribución global de caché, HTTPS y coste prácticamente nulo.

flowchart LR
  A(Usuario) --> B(Route53)
  B --> C(CloudFront)
  C --> F("CloudFront Functions")
  C --> D(S3)

Actualmente, los servicios AWS que siguen formando parte del blog son:

• S3: sitio estático generado por Jekyll
• CloudFront: CDN global, caché por tipo de recurso y HTTPS
• CloudFront Functions: reescritura de rutas para que Jekyll funcione correctamente detrás de CloudFront
• ACM: certificado SSL del dominio
• Route53: DNS

En total: 5 servicios AWS mantenidos.

El cambio relevante en esta capa fue sustituir Lambda@Edge por CloudFront Functions. Para este caso de uso, una reescritura sencilla de rutas, no necesitaba la flexibilidad extra de Lambda@Edge. CloudFront Functions encaja mejor: menos complejidad, menos piezas y suficiente para resolver el problema.

Lo que sí cambió es cómo lo gestiono. En v2, el blog tenía su propio repositorio de infraestructura. En v3, la infraestructura vive dentro de un proyecto Terraform común que uso para desplegar todas mis webs estáticas. Cada web tiene su propia carpeta de configuración, pero comparte la misma base reutilizable.

deploy-websites/
├── s3.tf
├── cloudfront.tf
├── cert_generation.tf
├── route53.tf
└── proyectos/
    └── blog/      ← variables específicas del blog

Un repositorio compartido en vez de un repositorio de infraestructura específico para cada proyecto.

4.2. CI/CD: de CodePipeline a GitHub Actions

Antes, en v2:

flowchart LR
  A(GitHub push) --> B(Amazon CodePipeline)
  B --> C(AWS CodeBuild)
  C --> D(Terraform apply)
  D --> E(S3 + CloudFront)

Ahora, en v3:

flowchart LR
  A(GitHub push) --> B(GitHub Actions)
  B --> C(Terraform apply / Jekyll build)
  C --> D(S3 + CloudFront)

El resultado es idéntico. GitHub Actions vive en el mismo repositorio que el código, es más directo de mantener, elimina toda la gestión de pipelines en AWS y es gratuito.

Nota: El cambio no vino motivado por coste. Mi solución de la v2 no era gratuita, pero me terminaba costando cero euros. El motivo principal fue la simplicidad operativa: menos piezas, menos repositorios, menos pipelines y menos superficie que mantener.

4.3. Backend: eliminado

Los formularios de contacto y feedback existían en el blog, pero en la práctica nadie los usaba y yo tampoco estaba intentando cambiar eso. La suscripción por email era diferente: sí había suscriptores guardados en DynamoDB, pero nunca llegué a implementar el envío automatizado, y sinceramente tampoco tenía intención de hacerlo. Preferí eliminar esos datos y evitar mantener una funcionalidad a medias que no estaba aportando valor real.

Mantener API Gateway, Lambda, Step Functions, DynamoDB, SES, SNS, SSM Parameter Store, EventBridge, EventBridge Pipes, permisos, logs y despliegues asociados para funcionalidades que no aportaban valor real no tenía ningún sentido. Sí, era serverless y al no tener uso me costaba cero euros, pero aun así.

Que algo no tenga coste no significa que no tenga impacto. Cada recurso añade configuración, permisos, logs, dependencias y posibles puntos de fallo. Cuando deja de aportar valor, lo único que hace es aumentar la complejidad de la solución y el esfuerzo necesario para entenderla y mantenerla.

Los comentarios siguen funcionando con giscus y GitHub Discussions, una solución externa sin infraestructura propia que gestionar.

5. Rediseño completo y asistentes de IA

La simplificación no fue solo técnica. También cambió la forma en la que construyo y mantengo el blog.

La v3 incluye un rediseño completo de UX: nueva estructura de navegación, contenido reorganizado y una experiencia más limpia en general. En realidad, empecé estos cambios hace casi 9 meses, motivado por la aparición de Kiro, pero lo dejé a medias porque no me terminó de convencer y porque acabé centrándome en otros proyectos. Ya era hora de retomarlo y dar por cerrada esta nueva v3 del blog.

Y claro, los asistentes de IA también han cambiado mucho mi forma de trabajar. Me ayudan a ordenar ideas, revisar estructura, mejorar redacción, desarrollar funcionalidades del propio blog, generar borradores para iterar y detectar mejoras que antes tardaban mucho más en aparecer.

La IA no lo hace todo, pero sí acelera el proceso. Es un potenciador increíble, pero asegúrate de que seas tú el que tienes el control, y que entiendes lo que hace.

Yo no quiero que la IA me haga el trabajo, ¿qué sentido tendría? Quiero que me ayude a hacerlo mejor y más rápido, pero quiero que el blog siga siendo mío. Es mi espacio para jugar, aprender y compartir lo que voy descubriendo. Cuando deje de ser así, el blog habrá perdido gran parte de su razón de existir.

Tengo un artículo donde hablo de aprendizajes usando un asistente de código después de seis meses de uso intensivo si quieres ver cómo lo aplico en la práctica.

6. Antes vs ahora

Aspecto	v2	v3
Repositorios	7 repositorios exactos relacionados con el blog	2 repositorios: blog-web-code y deploy-websites
CI/CD	CodePipeline + CodeBuild	GitHub Actions
Hosting	S3 + CloudFront + Lambda@Edge, con repositorio Terraform propio	S3 + CloudFront + CloudFront Functions, dentro de un módulo Terraform compartido
Backend	API Gateway + Lambda + Step Functions + DynamoDB + SES + SNS + SSM Parameter Store + EventBridge + EventBridge Pipes	Eliminado
Servicios AWS mantenidos	Más de 15 servicios implicados en total	5 servicios: S3, CloudFront, CloudFront Functions, Route53 y ACM
Infraestructura como código	CDK + SAM + Terraform	Terraform
UX y contenido	Diseño original, crecimiento orgánico	Rediseño completo
Proceso creativo	Principalmente manual	Apoyado por asistentes de IA
Criterio de elección	Más servicios AWS = más aprendizaje	La solución más simple que resuelve el problema

7. Reflexión

Construir ese ecosistema completo fue una decisión deliberada y valió la pena. Desmontarlo también lo ha sido, y de momento no me arrepiento.

La diferencia entre las dos fases no es técnica. Es de criterio: al principio elegía los servicios para aprender, y ahora quiero simplicidad, eficiencia y foco.

Esa, probablemente, es una de las mejores señales de evolución en arquitectura: no añadir más piezas, sino saber cómo simplificar y cuáles ya no necesitas.

Antes aprendía añadiendo servicios. Ahora aprendo simplificando soluciones.