Forem: Juan Jose Miranda

Pequeñas ideas, grandes comunidades: así nació Kinua

Juan Jose Miranda — Fri, 26 Sep 2025 11:18:13 +0000

No sabía el poder de la comunidad hasta que llegué al AWS User Group. Con el tiempo entendí que estos espacios no solo son para aprender, sino también el origen de nuevas ideas. Así nació Kinua, a partir del feedback del AWS Community Day Bolivia 2024 y de la convicción de que siempre se puede mejorar. En ese proceso descubrimos algo muy claro: como ingenieros podemos crear cosas increíbles, pero cuando se trata de organizar eventos, manejar la logística o incluso coordinar el swag, siempre hay retos. Tres amigos, una noche con cervezas y un propósito claro: ayudar a la comunidad con lo que mejor sabemos hacer, programar. De esa chispa nació una app pensada para que los asistentes vivan una experiencia más conectada, dinámica y memorable en cada AWS Community Day.

El reto: del pasaporte físico a la experiencia digital

El AWS Community Day Bolivia 2024 marcó un hito: fue la primera edición en nuestro país. Nos costó bastante sacarlo adelante, pero el resultado superó las expectativas: más de 27 charlas, más de 400 asistentes y lazos valiosos con sponsors que sentaron las bases para futuras ediciones. También logramos conseguir bastante swag para la comunidad. Como organizador, fue increíblemente gratificante ver tantas personas reunidas alrededor de la nube.

Sin embargo, como desarrollador, no pude dejar de notar ciertas limitaciones en la experiencia. En particular, el uso del “pasaporte físico”: una cartilla de papel que los asistentes llevaban consigo para sumar puntos visitando stands de sponsors o completar misiones y luego reclamar premios. Funcionaba, sí, pero era lento, manual, generaba filas y dependía de manejar papel en un evento que debería inspirar innovación. Algo no encajaba.

Para la edición 2025, llevé la idea a la organización: digitalizar el pasaporte y convertirlo en una experiencia gamificada moderna. La propuesta fue recibida con entusiasmo, y con el apoyo de todos, me uní a Abel y Jhonathan para ponernos manos a la obra y hacer lo que mejor sabemos hacer: codear.

Revisamos los problemas, analizamos alternativas, hicimos sesiones de fobbing y llegamos a una conclusión clara: no queríamos seguir generando procesos manuales y papeleo. Queríamos una app que reemplazara el pasaporte físico, potenciara la experiencia gamificada y mostrara lo que de verdad podemos lograr cuando mezclamos comunidad y tecnología.

Así comenzó el camino de Kinua.

Retos convertidos en oportunidades

La experiencia del primer AWS Community Day Bolivia nos dejó tres retos principales claramente identificados:

La agenda. Con más de 27 charlas en paralelo, tener una agenda estática en papel se volvió poco práctico. Queríamos que cada asistente pudiera ver todas las sesiones en un solo lugar, marcar sus favoritas, recibir notificaciones de cambios y, lo más importante, dejar su puntuación y feedback para los speakers. Una agenda viva y digital que acompañe al usuario durante todo el evento.
Las fotos del evento. En cada Community Day se generan cientos de fotos: las de la organización, las de los sponsors y las de la comunidad misma. El problema es que muchas veces los asistentes no saben en cuáles aparecen. Aquí vimos una oportunidad única: usar Amazon Rekognition para identificar a los participantes y mostrarles directamente en qué fotos salieron, creando así una experiencia personalizada y memorable.
El sistema de puntos. El famoso pasaporte físico funcionaba, pero tenía un límite. Queríamos llevarlo a otro nivel: no solo retos con sponsors, sino también con speakers en cada charla y con comunidades aliadas. Imaginamos una dinámica donde participar, aprender y conectar se tradujera en puntos y recompensas, gamificando toda la experiencia del evento y no solo las visitas a stands.

Estos tres puntos fueron nuestra brújula para diseñar lo que se convertiría en Kinua, una plataforma pensada no solo para resolver problemas logísticos, sino para crear una experiencia más rica, divertida y alineada con el espíritu de innovación que representa AWS.

Arquitectura Serverless y Decisiones Técnicas

Desde el inicio sabíamos que dos factores serían decisivos en este proyecto: el costo y el tiempo. Por un lado, queríamos minimizar los gastos operativos evitando la gestión de servidores y escalado manual; por otro, necesitábamos entregar una solución completa en pocas semanas.
La respuesta natural fue apostar por una arquitectura 100% serverless en el backend, acompañada de un frontend PWA en Angular, que nos permitió ofrecer una experiencia similar a una app nativa sin pasar por el proceso de publicación en tiendas ni requerir instalación.

Además, gracias a que una PWA (Progressive Web App) puede ejecutarse desde el navegador, incluso en condiciones de conectividad limitada, logramos un balance ideal entre velocidad de desarrollo, experiencia de usuario y facilidad de despliegue.

A continuación, comparto el diagrama general de servicios y cómo cada componente se integra dentro de nuestra solución.

Esta arquitectura no solo redujo el costo operativo en más de un 70% frente a un enfoque tradicional, sino que también nos permitió escalar automáticamente durante el evento sin ninguna intervención manual.

Impacto en la comunidad

El lanzamiento de Kinua durante el AWS Community Day Bolivia 2025 fue más que un experimento técnico: fue una experiencia real de transformación. En apenas unas semanas, pasamos de tener la idea en papel a verla funcionando en manos de cientos de asistentes.

Los resultados hablaron por sí solos:

Speakers: destacaron lo simple que fue interactuar con los asistentes y cómo las dinámicas de puntos aumentaron la participación en cada charla.

Sponsors: encontraron nuevas formas de conectar con el público, midiendo de forma clara el impacto de sus activaciones y obteniendo métricas tangibles de engagement.

La comunidad: vivió el evento de una manera más interactiva, con notificaciones en tiempo real, acceso rápido a la agenda y un sistema de puntos que convirtió cada charla en una dinámica gamificada.

Más allá de la tecnología, el verdadero impacto estuvo en cómo Kinua mejoró la experiencia del evento: los asistentes estuvieron más informados, más motivados y más conectados.

Kinua es Open Source

Kinua nació como un proyecto para el AWS Community Day Bolivia 2025, pero nuestra meta va más allá: queremos seguir mejorándolo y ponerlo a disposición de cualquier comunidad o evento que lo necesite.

El código está disponible como open source, listo para que lo uses, lo refines y lo hagas crecer. Porque las comunidades no solo se construyen con eventos, también con colaboración y tecnología compartida.

https://github.com/JuanJoseMirandaM/kinua

Hagamos que cada evento sea una experiencia única, cada conexión tenga un impacto real y que las comunidades puedan crecer. Kinua es solo el comienzo: un proyecto pensado para mejorar, crecer y estar disponible para cualquier comunidad que quiera usarlo. En AWS siempre nos dicen “Build on AWS”, y esto nos recuerda que todos somos builders; ahora la invitación está abierta para usarla, refinarla y llevarla aún más lejos.

Event-Driven Architecture con Lambda y S3

Juan Jose Miranda — Mon, 04 Aug 2025 04:14:13 +0000

Event‑Driven Architecture (EDA) es un patrón de diseño en el cual los componentes del sistema se comunican a través de eventos. Este enfoque permite construir sistemas desacoplados, escalables y reactivos, donde cada parte del sistema responde a eventos en lugar de seguir un flujo de control predefinido.

Amazon S3 puede generar eventos cuando se sube un objeto s3:ObjectCreated:* y estos eventos pueden invocar funciones AWS Lambda automáticamente. Con este patrón puedes automatizar tareas como redimensionado, análisis, notificaciones, o incluso sobreponer una marca de agua a imágenes subidas.

En este artículo construiremos un pipeline para:

Procesar imágenes subidas a S3.
Aplicar una marca de agua.
Almacenarlas en otro bucket o prefijo.

Conceptos Fundamentales

Event Source y Event Target

Event Source: Amazon S3 que emite notificaciones.
Event Target: AWS Lambda que consume el evento.

Comunicación Asíncrona

Cada imagen es procesada como un evento independiente, lo que permite procesamiento paralelo, alta tolerancia y escalabilidad.

S3 Events & Lambda Triggers

S3 permite configurar notificaciones como:

"Events": ["s3:ObjectCreated:*"]

Estas notificaciones invocan funciones Lambda cuando se produce un evento compatible.

Implementación Práctica: Aplicar Marca de Agua

Flujo

Usuario sube una imagen a bucket S3.
Lambda aplica marca de agua con el logo.
Imagen procesada se guarda en un prefijo o bucket definido.

Arquitectura

El flujo arquitectónico básico se ve así:

Configuración S3

{
  "NotificationConfiguration": {
    "LambdaFunctionConfigurations": [
      {
        "LambdaFunctionArn": "arn:aws:lambda:region:account:function:processImage",
        "Events": ["s3:ObjectCreated:*"],
        "Filter": {
          "Key": {
            "FilterRules": [
              { "Name": "suffix", "Value": ".jpg" }
            ]
          }
        }
      }
    ]
  }
}

Lambda Function

import { S3Client, GetObjectCommand, PutObjectCommand } from '@aws-sdk/client-s3';
import sharp from 'sharp';

const s3 = new S3Client({ region: 'us-east-1' });

async function streamToBuffer(stream) {
  const chunks = [];
  for await (const chunk of stream) {
    chunks.push(typeof chunk === 'string' ? Buffer.from(chunk) : chunk);
  }
  return Buffer.concat(chunks);
}

export const handler = async (event) => {
  const bucket = event.Records[0].s3.bucket.name;
  const key = event.Records[0].s3.object.key;

  // Obtener logo
  const watermarkObj = await s3.send(new GetObjectCommand({
    Bucket: 'assets-bucket',
    Key: 'community-day-logo.png'
  }));
  const watermarkBuffer = await streamToBuffer(watermarkObj.Body);

  // Redimensionar logo
  const resizedWatermark = await sharp(watermarkBuffer)
    .resize({ width: 300 })
    .png()
    .toBuffer();

  // Obtener imagen original
  const imageObj = await s3.send(new GetObjectCommand({
    Bucket: bucket,
    Key: key
  }));
  const originalBuffer = await streamToBuffer(imageObj.Body);

  // Obtener metadatos de la imagen original para calcular padding
  const metadata = await sharp(originalBuffer).metadata();

  const paddingX = 20; // 20px desde el borde derecho
  const paddingY = 20; // 20px desde el borde inferior

  // Obtener dimensiones del logo redimensionado
  const logoMetadata = await sharp(resizedWatermark).metadata();

  const top = (metadata.height ?? 0) - (logoMetadata.height ?? 0) - paddingY;
  const left = (metadata.width ?? 0) - (logoMetadata.width ?? 0) - paddingX;

  // Componer con marca de agua redimensionada y padding
  const watermarked = await sharp(originalBuffer)
    .composite([
      {
        input: resizedWatermark,
        top,
        left
      },
    ])
    .jpeg()
    .toBuffer();

  // Subir imagen final con marca de agua
  await s3.send(new PutObjectCommand({
    Bucket: bucket,
    Key: `processed/mark-${key}`,
    Body: watermarked,
    ContentType: 'image/jpeg',
  }));
};

Configuración Trigger

Seleccione "Add trigger".
En "Bucket", seleccione su bucket de origen.
En "Event types", seleccione "All object create events".
En "Recursive invocation", marque la casilla para confirmar que no se recomienda usar el mismo depósito de Amazon S3 para entrada y salida.
Seleccione "Add".

Consideraciones

Idempotencia: identifica la imagen procesada para no hacerlo dos veces.
Observabilidad: CloudWatch Logs y métricas para seguimiento.
Optimización de costos: memoria adecuada, timeouts y tamaño del paquete bien definidos.

🚨 Adiós a los 12 meses gratis en AWS: esto es lo que debes saber desde hoy

Juan Jose Miranda — Wed, 16 Jul 2025 21:05:33 +0000

Desde el 15 de julio de 2025, Amazon Web Services (AWS) le dice oficialmente adiós al mítico Free Tier de 12 meses.

Si alguna vez te registraste en AWS y disfrutaste de un año completo de EC2, S3 o RDS gratis, esta noticia te va a interesar (y quizás doler un poco).

Pero ¡tranquilo! AWS no ha eliminado su capa gratuita por completo. Lo que ha hecho es reinventarla.

En este artículo te explico qué ha cambiado, cómo aprovechar los nuevos beneficios, y qué debes tener en cuenta si planeas crear una cuenta hoy o en el futuro.

🏁 ¿Qué cambió desde el 15 de julio?

Hasta el 14 de julio, cualquier persona que se creaba una cuenta en AWS obtenía:

✅ 12 meses gratuitos de servicios como EC2 (750 horas/mes), S3 (5 GB), RDS, Lambda, CloudWatch, etc.
⏱️ Una capa gratuita con límites por servicio y duración fija.

Desde el 15 de julio de 2025, este modelo desaparece para nuevas cuentas.

Ahora el sistema se basa en créditos y actividades.

📊 Comparativa: Free Tier antiguo vs nuevo

Característica	Antes (hasta 14 de julio 2025)	Ahora (desde 15 de julio 2025)
Duración	12 meses	6 meses o hasta agotar los créditos
Modelo	Límite por servicio y tiempo	Créditos flexibles + retos para ganar más
Créditos iniciales	No	$100 USD al crear la cuenta
Créditos adicionales	No	Hasta $100 USD extras completando tareas
Servicios Always Free	Sí	Sí (más de 30 servicios disponibles)
Posibilidad de cierre de cuenta	No	Sí, si no migras al plan de pago tras usar créditos
Acceso a servicios	Amplio, sin limitaciones	Algunas restricciones (ej. sin Marketplace)

Con esta nueva estructura de créditos, AWS ya no solo nos regala tiempo: nos reta a decidir con intención.

Administrar cada dólar nos acerca a la realidad de construir sistemas sostenibles, donde cada recurso cuenta y cada decisión tiene impacto.

🧠 Una práctica perfecta para quienes quieren ir más allá del "jugar en la nube".

💳 ¿Cómo se consiguen los $100 USD adicionales?

AWS ahora incentiva a los nuevos usuarios a explorar la plataforma mediante actividades simples que desbloquean créditos extra.

Algunas de estas tareas incluyen:

Lanzar una instancia EC2.
Usar un modelo en Amazon Bedrock.
Configurar una alerta de presupuesto.
Crear una aplicación web usando AWS Lambda.
Crear una base de datos Amazon RDS.

💡 Recomendaciones para aprovechar al máximo el nuevo Free Tier

Activa presupuestos y alertas de costos desde el día uno.
Usa servicios como Lambda, DynamoDB, S3 y API Gateway, que tienen niveles gratuitos generosos.
Aprovecha los retos sugeridos por AWS para obtener más créditos.
Prueba AWS Cloud9 para desarrollar directamente en la nube.
Supervisa el uso desde el Billing Dashboard.

🔎 ¿Quién se ve afectado?

Este nuevo modelo solo aplica a cuentas creadas desde el 15 de julio de 2025.

Si ya tenías una cuenta antes de esa fecha, sigues con tu Free Tier de 12 meses y no debes preocuparte (por ahora).

🤔 ¿Mejor o peor?

Depende del caso de uso.

✅ Si sabes administrar tus recursos, puede ser más flexible y educativo.
❌ Si esperabas un año completo sin preocuparte por los costos, este cambio puede parecer un retroceso.

Lo importante es que el nuevo enfoque te entrena a pensar como si tuvieras un sistema real en producción, desde el primer día.

✍️ ¿Y tú qué opinas?

¿Crees que este nuevo enfoque es mejor o peor?

¿Ya usaste tus créditos o hiciste alguna prueba interesante con esta nueva capa gratuita?

💬 Cuéntame en los comentarios. ¡Me encantaría ver qué opinan otros desarrolladores de esta nueva era en AWS!

🛠️Simula S3 Localmente con LocalStack y Docker Compose

Juan Jose Miranda — Wed, 28 May 2025 16:00:00 +0000

¿Alguna vez quisiste trabajar con S3 sin necesidad de una cuenta AWS o cargos por uso? LocalStack es la solución. En este artículo te muestro cómo levantar LocalStack con Docker Compose, crear un bucket S3, subir un archivo y listar su contenido usando AWS CLI.

✅ Prerrequisitos

Antes de comenzar, asegúrate de tener instalado lo siguiente:

🐳 Paso 1: Docker Compose para LocalStack

Primero, crea un archivo llamado docker-compose.yml con el siguiente contenido:

version: '3.8'

services:
  localstack:
    image: localstack/localstack:latest
    container_name: localstack
    ports:
      - "4566:4566"   # Puerto principal de LocalStack
    environment:
      - SERVICES=s3
      - DEBUG=1
      - DATA_DIR=/tmp/localstack/data
      - AWS_ACCESS_KEY_ID=test
      - AWS_SECRET_ACCESS_KEY=test
      - DEFAULT_REGION=us-east-1
    volumes:
      - "./localstack:/tmp/localstack"
      - "/var/run/docker.sock:/var/run/docker.sock"

Este archivo levanta un contenedor de LocalStack con soporte solo para S3 y con credenciales fijas (test/test), ideales para desarrollo local.

🚀 Levanta el contenedor

docker-compose up -d

🔧 Paso 2: Configura AWS CLI

Configura tus credenciales con los mismos valores definidos en el docker-compose.yml:

aws configure

- AWS Access Key ID: test
- AWS Secret Access Key: test
- Region: us-east-1
- Output Format: json

🛠️ Paso 3: Crea un bucket S3 local

aws s3 mb s3://mi-bucket-local
  --region us-east-1 \
  --endpoint-url=http://localhost:4566

Verifica que el bucket fue creado:

aws s3 ls --endpoint-url=http://localhost:4566

📁 Paso 4: Sube un archivo de prueba

Primero, crea un archivo simple:

echo "Hola desde LocalStack" > ejemplo.txt

Luego, súbelo al bucket:

aws s3 cp ejemplo.txt s3://mi-bucket-local/ --endpoint-url=http://localhost:4566

📄 Paso 5: Lista los objetos en el bucket

aws s3 ls s3://mi-bucket-local/ --endpoint-url=http://localhost:4566

Salida esperada:

2025-05-28 12:45:00         23 ejemplo.txt

✅ Conclusión

Con estos simples pasos, tienes un entorno de desarrollo local que simula Amazon S3 usando LocalStack. Ideal para desarrollo, pruebas automatizadas y aprendizaje sin costos ni conexión a Internet.

¿Te gustaría extenderlo para trabajar con SDKs en Python, Node.js o integrarlo con Terraform? ¡Déjamelo saber en los comentarios! 🚀

Spring Boot Configuration: When to Require, Default, or Leave Empty Environment Variables

Juan Jose Miranda — Tue, 13 May 2025 16:11:55 +0000

Spring Boot supports flexible environment variable interpolation in your application.yml files, but it's important to know when to require a variable, leave it empty, or provide a default value.

Choosing the right approach improves reliability, avoids silent misconfigurations, and makes your application easier to maintain across environments.

Let’s break it down into three types:

🔒 1. `${VARIABLE}` — Required

This format means the variable must be defined.

If it's not present, Spring Boot will fail to start with an error.

✅ When to use:

Use this for critical configuration values your application can’t run without:

Database connection details
API credentials
Encryption keys

spring:
  datasource:
    url: ${DB_URL}       # Must be set
    username: ${DB_USER} # Must be set
    password: ${DB_PASS} # Must be set

🟡 2. `${VARIABLE:}` — Optional (empty by default)

This syntax allows the variable to be undefined, in which case it defaults to an empty string.

✅ When to use:

Use when the value is not always required, and you will handle its presence at runtime.

external:
  api-key: ${EXTERNAL_API_KEY:}  # Will be empty if not defined

📌 Remember to check if it's empty before using it in your code.

🟢 3. `${VARIABLE:default}` — Optional with fallback value

This format sets a default value if the variable is not defined.

✅ When to use:

Use when a sensible default exists and makes development easier. This avoids overconfiguring every environment unnecessarily.

server:
  port: ${SERVER_PORT:8080}  # Uses port 8080 if not set

✅ Best Practices Summary

Purpose	Syntax
Required, critical configuration	`${VAR}`
Optional, check at runtime	`${VAR:}`
Optional, default fallback	`${VAR:default-value}`

📄 Example: `application.yml` with Best Practices

spring:
  profiles:
    active: ${SPRING_PROFILES_ACTIVE:dev}  # Default to 'dev'

  datasource:
    url: ${DB_URL}           # ❗ Required
    username: ${DB_USERNAME} # ❗ Required
    password: ${DB_PASSWORD} # ❗ Required
    driver-class-name: ${DB_DRIVER:com.mysql.cj.jdbc.Driver}  # ✅ Default fallback

  jpa:
    hibernate:
      ddl-auto: ${HIBERNATE_DDL:auto}  # ✅ Default

server:
  port: ${SERVER_PORT:8080}  # ✅ Default port
  servlet:
    context-path: ${CONTEXT_PATH:/}

client:
  id: ${CLIENT_ID:localhost}     # ✅ Fallback value for local use
  api-key: ${EXTERNAL_API_KEY:}  # 🔸 Optional

management:
  endpoint:
    env:
      show-values: WHEN_AUTHORIZED  # Safer than ALWAYS
  endpoints:
    web:
      base-path: /actuator
      exposure:
        include: health,info

security:
  jwt:
    secret: ${JWT_SECRET}           # ❗ Required
    expiration: ${JWT_EXPIRATION:3600}  # ✅ Default in seconds

app:
  environment: ${APP_ENVIRONMENT:local}
  feature-flag:
    enable-beta: ${ENABLE_BETA_FEATURE:false}

🛡️ Final Advice

Always document which environment variables are mandatory and validate them early when possible. This avoids surprises during deployment and improves your system’s robustness.