Los pilotos fallan en producción cuando no existe un mapa claro entre conocimiento, orquestación, validación y modelos.

DISCLAIMER: Todo proyecto, y más uno de IA, debe tener objetivos claros y un proceso ágil de incepción correcto. Más aún, en temas de IA, el no tener claridad del ¿qué?, el ¿cómo? y las métricas de éxito van a derivav en frustación y proyectos fallidos.

La AI Periodic Table, creado por IBM, es un enfoque evergreen y minimalista para arquitectos, jefes y líderes técnicos: separa la solución en elementos composables (como una tabla periódica) y te ayuda a decidir qué necesitas para cada caso de uso (chatbot, RAG, agente) con control, trazabilidad y confianza.

Row 1 — Primitives (lo mínimo que debe existir)

Pr — Prompts (con foco en system prompt)

Qué es: el diseño de instrucciones que gobiernan el comportamiento del modelo. En particular, el system prompt define rol, políticas, restricciones, formato, prioridades y criterio de “verdad”. Es la capa que siempre aplica, incluso si el usuario intenta desviarla.

Ejemplo (banca/fintech): system prompt para un asistente interno de pagos:

• “Responde solo usando evidencia del contexto recuperado. Si no hay evidencia, di: No encontrado en fuentes.”
• “No reveles PII, secretos, llaves, credenciales ni datos de clientes.”
• “No ejecutes acciones; sugiere pasos y valida supuestos.”
• “Devuelve: Resumen (1–2 líneas) + Evidencia (citas) + Recomendación (pasos).”

Em — Embeddings

Qué es: representaciones numéricas del significado del texto (y a veces de otros formatos) para comparar similitud semántica y recuperar conocimiento relevante.

Ejemplo: embebes runbooks de conciliación y reglas ISO 20022. Luego consultas “cómo mapear endToEndId” y recuperas el fragmento correcto aunque el usuario use otras palabras.

Lg — LLM (modelo predictivo)

Qué es: un modelo de lenguaje es, en esencia, un modelo predictivo de tokens: estima el siguiente token más probable dada la entrada (system prompt + contexto recuperado + conversación). Con el contexto correcto, habilita síntesis, explicación, clasificación y razonamiento.

Ejemplo (open source): usas un LLM open source como Llama 3 (en una VPC o en entorno local) para resumir incidentes, generar borradores operativos y responder preguntas internas basadas en evidencia (vía RAG) y bajo políticas (guardrails).

Row 2 — Compositions (cuando pasa de demo a producto)

Fc — Function call

Qué es: un mecanismo para invocar herramientas (APIs, DB, motores de reglas) con parámetros estructurados. Reduce “inventos” porque los datos vienen del sistema fuente.

Ejemplo: “¿Cuál fue el estado del lote 7781?” → llamada a get_settlement_batch_status(batch_id=7781) y respuesta con estado real, timestamps y códigos.

Vx — Vector (vector store / vector search)

Qué es: la infraestructura para almacenar embeddings y hacer búsqueda semántica (kNN). Es el índice de conocimiento para recuperar contexto.

Ejemplo: OpenSearch Vector indexa manuales antifraude, catálogos de códigos y procedimientos. Para cada pregunta, recuperas “top 5 chunks” con score y los pasas a RAG.

Rg — RAG

Qué es: patrón de recuperar + generar: primero recuperas evidencia desde tu base documental (vector o híbrido) y luego el LLM genera respuesta basándose en esa evidencia.

Ejemplo: “¿Qué campos ISO 20022 son obligatorios para pacs.008 en nuestro flujo?” → recuperas el apartado exacto de tu estándar interno y respondes con lista + citas.

Gr — Guardrails

Qué es: controles de seguridad y calidad: políticas (PII/secretos), límites de herramientas, formatos obligatorios, detección de inyección, y rechazo seguro.

Ejemplo: si el usuario solicita datos de cliente, se bloquea. Si la respuesta no tiene evidencia, se fuerza: “No encontrado en fuentes”.

Mm — Multimodal

Qué es: capacidad para trabajar con más de texto (por ejemplo, imagen + texto). Útil para diagramas, capturas, formularios y pantallazos.

Ejemplo: un analista sube una captura de un diagrama de pagos y el sistema devuelve componentes, flujo, puntos de control y sugerencias de observabilidad.

Row 3 — Deployment (operación real: costo, riesgo y mejora continua)

Ag — Agent (componente, no un LLM)

Qué es: un componente de control que coordina pasos para lograr un objetivo. El agente usa uno o varios LLMs, herramientas y memoria, pero no es el modelo. Decide cuándo recuperar contexto, cuándo llamar herramientas, cómo validar y cuándo detenerse.

Ejemplo: “resolver un incidente de conciliación” → el agente identifica el fallo, recupera runbooks (RAG), ejecuta chequeos (function calls), valida hallazgos y produce un plan de mitigación trazable.

Ft — Finetune (entrenamiento adicional)

Qué es: entrenar (fine-tuning) un modelo con datos propios para aprender patrones de salida, taxonomías, formatos o decisiones recurrentes. Es especialmente útil cuando prompt + RAG no logran consistencia suficiente.

Ejemplo: entrenas para que el asistente clasifique tickets en categorías internas (riesgo, fraude, cumplimiento), y redacte respuestas en un formato de auditoría consistente.

Fw — Framework

Qué es: librerías para construir flujos con control (estados, routing, tools, memoria, evaluación, observabilidad). Reduce código “pegamento” y mejora mantenibilidad.

Ejemplo: defines un flujo: intención → retrieve → responder → (si pide acción) tool_call → validar → respuesta final con reintentos y límites por política.

Rt — Red-teaming

Qué es: pruebas adversarias para romper el sistema antes de producción: jailbreak, prompt injection, exfiltración, abuso de herramientas y sesgos.

Ejemplo: inyectas instrucciones maliciosas en documentos (“ignora políticas”) y verificas que el sistema no obedezca; también pruebas pedidos de acciones riesgosas y confirmas que no se ejecutan sin autorización y controles.

Sm — Small (distilled)

Qué es: modelos pequeños para tareas específicas con menor costo/latencia; permiten enrutar y filtrar, reservando el modelo grande para lo complejo.

Ejemplo: un modelo small clasifica intención (FAQ/operación/incidente/riesgo) y solo las complejas pasan a LLM grande + RAG.

Row 4 — Emerging (calidad, confianza y ventaja competitiva)

Ma — Multi-agent

Qué es: varios agentes especializados que colaboran y revisan. Aumentan calidad y reducen errores frente a una sola “mente”.

Ejemplo: agente de pagos redacta, agente de seguridad valida PII, agente de compliance revisa lenguaje regulatorio, agente QA verifica evidencia y consistencia.

Sy — Synthetic data

Qué es: datos sintéticos para entrenamiento y evaluación: casos borde, Q&A, conversaciones, escenarios raros. Permite escalar pruebas sin exponer data sensible.

Ejemplo: generas 2,000 preguntas sintéticas sobre AML y conciliación para medir recuperación correcta, tasa de alucinación y cumplimiento de guardrails.

In — Interpretability (confianza y trazabilidad)

Qué es: mecanismos que elevan confianza y auditabilidad: qué fuentes se usaron, por qué se eligieron, qué reglas se aplicaron y qué herramientas se llamaron. Es clave para operación en entornos regulados.

Ejemplo: cada respuesta incluye “fuentes (con score)”, “reglas aplicadas” y “acciones ejecutadas (si aplica)”, habilitando revisión y mejora continua.

Th — Thinking (reasoning)

Qué es: capacidades/modelos orientados a razonamiento profundo para problemas multi-paso y trade-offs.

Ejemplo: compara 3 diseños (multi-cuenta vs multi-región), evalúa seguridad, resiliencia y costos, y entrega recomendación con supuestos y justificación.

Analogía final: “predecir reacciones” con la AI Periodic Table

Esta tabla te ayuda a anticipar qué solución obtendrás al combinar elementos.

Reacción 1: Chatbot confiable (con evidencia y control)

help to predict reactions

chatbot: Em, Vx, Rg, Pr, Gr y Lg

• Em + Vx: recuperación semántica
• Rg: evidencia al contexto del modelo
• Pr: reglas globales (system prompt)
• Gr: seguridad/calidad
• Lg: generación predictiva guiada por evidencia

Reacción 2: Agentic loop orientado a objetivo (con acciones)

agentic loop (goal): Ag <-> Fc, Fw [Pr, Mm, Ft, Lg]

• Ag coordina pasos
• Fc conecta con sistemas reales
• Fw gobierna el flujo
• Pr/Mm/Ft/Lg ajustan comportamiento, entrada multimodal, entrenamiento y potencia del modelo

Regla de oro

always try to mapping you problem with it

Antes de elegir proveedor o modelo, mapea tu problema con la tabla: te dirá qué necesitas para evidencia, control, operación y confianza, sin perderte.

IBM es el creador de esta propuesta mira acá:

Una API no es solo un endpoint: es un contrato vivo entre equipos, servicios y, muchas veces, organizaciones completas. Cuando ese contrato se rompe —por un despliegue defectuoso, un cambio no controlado o una brecha de seguridad— el impacto es inmediato en el negocio.

Por eso existen pruebas que no son negociables. No dependen del lenguaje, del framework ni del proveedor cloud. Son la base mínima para evitar desplegar código roto o vulnerable en producción.

En esta guía revisamos las pruebas esenciales en APIs de microservicios, explicando qué validan, cómo implementarlas y por qué son críticas, utilizando un caso de negocio realista para aterrizar cada concepto.

Caso de negocio de referencia

Plataforma de pagos digitales B2C, basada en microservicios:

• Payment API → recibe y orquesta pagos
• Account API → valida saldo y estado de la cuenta
• Ledger API → registra movimientos contables
• Notification API → notifica al cliente

Cada servicio expone APIs REST y participa en flujos síncronos y asíncronos.

Smoke Testing en APIs de microservicios: confirmar que el sistema “respira”

El Smoke Testing valida lo más básico después de un despliegue:

¿La API está disponible y responde sin fallar?

Ejemplo de negocio

Al iniciar la jornada operativa, un comercio necesita confirmar que la plataforma puede aceptar pagos, aunque aún no ejecute flujos completos.

Cómo se prueba (ejemplo práctico)

• Tras desplegar una nueva versión de Payment API, se ejecuta automáticamente:
  • GET /health
  • POST /payments con un payload mínimo mockeado
• Se valida:
  • Respuesta HTTP distinta de 5xx
  • Tiempo de respuesta dentro de un umbral aceptable
  • Que el servicio no se reinicia ni lanza errores fatales

Valor arquitectónico

El smoke testing asegura que la API es enrutable, que la configuración es correcta y que las dependencias mínimas están disponibles. Es la primera barrera antes de exponer tráfico real.

Functional Testing en APIs: validar el contrato, no la implementación

El Functional Testing garantiza que la API cumple exactamente con su contrato, independientemente de cómo esté implementada internamente.

Ejemplo de negocio

Un cliente realiza un pago desde una app móvil y espera una respuesta clara e inmediata.

Cómo se prueba (ejemplo práctico)

Input válido

{
  "accountId": "ACC-001",
  "amount": 150,
  "currency": "USD",
  "paymentMethod": "CARD"
}

Output esperado

• HTTP 201
• Estado: AUTHORIZED
• transactionId generado

Input inválido (saldo insuficiente)

• HTTP 422
• Mensaje funcional explícito (sin ambigüedad para el consumidor)

Valor arquitectónico

El functional testing protege el contrato frente a cambios internos, permite que múltiples consumidores evolucionen sin fricción y reduce dependencias implícitas entre equipos.

Integration Testing en microservicios: validar el flujo real de negocio

El Integration Testing prueba el sistema como opera en producción, incluyendo dependencias reales.

Ejemplo de negocio

Un pago exitoso debe validar saldo, registrar el movimiento y notificar al cliente.

Cómo se prueba (ejemplo práctico)

1. Payment API recibe la orden
2. Account API confirma saldo
3. Ledger API registra el débito
4. Notification API envía confirmación

Se valida que:

• El estado sea consistente entre servicios
• La transacción se registre una sola vez (idempotencia)
• Los fallos parciales se manejen correctamente (timeouts, retries, estados intermedios)

Valor arquitectónico

El integration testing detecta problemas de orquestación o coreografía, evita estados inconsistentes y refuerza la confiabilidad del flujo de negocio.

Regression Testing en APIs: proteger lo que ya funciona

En microservicios, el cambio es constante. Cada modificación introduce riesgo. El Regression Testing confirma que los cambios nuevos no rompen funcionalidades existentes.

Ejemplo de negocio

Se habilitan pagos con billetera digital, manteniendo pagos con tarjeta.

Cómo se prueba (ejemplo práctico)

• Antes del despliegue, se ejecutan flujos históricos:
  • Pagos con tarjeta
  • Reembolsos
  • Pagos rechazados
• Se valida que:
  • No cambian status codes
  • No se rompen contratos existentes
  • Los consumidores actuales siguen funcionando sin cambios

Valor arquitectónico

El regression testing permite evolucionar la plataforma sin miedo, protege integraciones externas y reduce incidentes post-deploy.

Security Testing en APIs de microservicios: seguridad por diseño

Las APIs son uno de los principales vectores de ataque en sistemas distribuidos. El Security Testing busca vulnerabilidades comunes y valida controles de acceso, datos y comportamiento ante ataques.

Ejemplo de negocio

Un atacante intenta ejecutar pagos usando tokens robados o manipulando datos sensibles.

Cómo se prueba (ejemplo práctico)

• Token inválido → HTTP 401
• Token sin scope payments.write → HTTP 403
• Intentos de modificar accountId → bloqueados
• Payloads maliciosos → sanitizados / rechazados según regla

Además:

• Los errores no filtran información sensible
• Los logs no exponen datos críticos

Valor arquitectónico

El security testing reduce la superficie de ataque, refuerza cumplimiento regulatorio y protege la confianza del negocio.

Conclusión: las pruebas como parte del diseño de la API

En arquitecturas basadas en APIs de microservicios, las pruebas no son una fase posterior. Son parte integral del diseño arquitectónico.

• Smoke Testing → disponibilidad
• Functional Testing → contrato
• Integration Testing → flujo real
• Regression Testing → estabilidad
• Security Testing → confianza

Para un arquitecto de software, no definir estas pruebas es dejar decisiones críticas al azar.

Introducción: Cómo migrar a la nube paso a paso

La migración a la nube no es solo una decisión tecnológica, es un cambio estratégico que redefine la operación y la innovación en tu organización. Para lograrlo con éxito, necesitas un enfoque estructurado que:

• Identifique capacidades organizacionales clave.
• Desarrolle un ciclo completo de adopción, desde la planificación hasta la optimización.
• Establezca un proceso de madurez progresiva en aprendizaje, liderazgo, escalabilidad y seguridad.

En esta guía, se propone un enfoque de cómo migrar a la nube de manera eficiente y segura, logrando beneficios tangibles para tu negocio.

Fase 1: Estrategia – Define la Visión, los recursos y los resultados esperados

Antes de dar el primer paso, define claramente tus motivaciones y objetivos de negocio. Los términos podrían ser:

• Reducción de costos: Transición de CAPEX a OPEX mediante pago por uso, especialmente en sistemas legados.
• Escalabilidad y agilidad: Responde a la demanda sin límites físicos. ¿Cuál es tu respuesta a la agilidad empresarial?.
• Innovación: Accede a tecnologías avanzadas como analítica e inteligencia artificial, sin incurrir en gigantes inversiones.

El segundo paso es hacer un inventario de recursos y definir métricas relacionadas a los mismos:

• Inventario inicial de workloads: Identifica aplicaciones y sistemas críticos, secundarios y no críticos.
• Métricas de éxito tempranas: Define indicadores como reducción de costos (TCO) y tiempos de respuesta.
• En términos de Innovación se puede pensar en métricas como número de iniciativas habilitadas, lead time de implementación de iniciativas o número de iniciativas estables.

Fase 2: Planificación – Diseña tu Roadmap y Cierra Brechas

Crea una Hoja de Ruta Clara

Un plan sólido garantiza una transición ordenada y controlada. Considera estos elementos:

1. Evaluación de recursos y habilidades:

• Análisis de capacidades organizacionales: Evalúa el nivel de habilidades técnicas y liderazgo dentro de tu equipo.
• Capacitación: Crea un plan de upskilling progresivo para roles clave.

2. Definición de “Zonas de Aterrizaje”:

• Define entornos base seguros y escalables para desplegar workloads (aplicaciones o sistemas). Los términos de una zona de aterrizaje incluyen cuestiones como: estandarización, seguridad, cumplimiento, escalabilidad y niveles de automatización.

3. Clasificación de cargas de trabajo:

• Lift & Shift: Movimientos rápidos y sin cambios.
• Optimización parcial: Mejoras mínimas (replatforming).
• Modernización avanzada: Rediseño de aplicaciones para cloud-native.
  Estas son estrategias de migración y puedes saber más de ellas en: Estrategias de Migración a la Nube(7Rs).

Fase 3: Preparación – Establece la Base Correcta

Pilares Fundamentales para una Migración Exitosa

1. Infraestructura y Automatización:

• Implementa Infraestructura como Código (IaC) con herramientas como Terraform, OpenTofu o scripts automatizados.
• Automatiza despliegues con pipelines CI/CD para reducir errores humanos.

2. Seguridad y Gobernanza:

• Establece políticas de acceso con gestión de identidades (IAM).
• Crea controles automatizados de costos y recursos para evitar desperdicios.
• Aplica un enfoque de seguridad por capas:
• Autenticación y cifrado.
• Segmentación de redes y monitoreo constante.

3. Preparación del Entorno:

• Una vez definidas, implementa las zonas de aterrizaje con configuraciones optimizadas para cargas de trabajo específicas.

Criterios de éxito:

• Reducción de tiempos de aprovisionamiento (de semanas a minutos).
• Cumplimiento de políticas de seguridad y gobernanza en todo el entorno.

Fase 4: Adopción – Ejecuta con Control y Escalabilidad

En esta fase, la iteración y la agilidad son clave para minimizar riesgos.

Pasos en una Adopción

1. Prioriza workloads no críticos: Permite ganar experiencia antes de mover aplicaciones complejas.
2. Migración por fases: Despliega en etapas para validar rendimiento y estabilidad.
3. Monitoreo continuo: Implementa herramientas nativas de observabilidad para identificar cuellos de botella:

• Cloud Monitoring: Tando desde el punto de vista de operacoines, como el de desempeño de aplicaciones y como el de seguridad.
• Cost Management: Evaluar iterativamente el gasto en nube.
• SLA/SLO Tracking: Evaluar el cumplimiento de los acuerdos y objetivos de nivel de servicio definidos para aplicaciones, datos y sistemas.

Fase 5: Optimización e Innovación Continua

La migración a la nube no termina una vez que los workloads están activos. El verdadero valor surge cuando optimizas y transformas tu negocio.

Optimización

1. Automatización avanzada: Mejora pipelines CI/CD y aprovecha soluciones serverless.
2. Right-sizing: Ajusta recursos para maximizar eficiencia de costos.
3. Replatform: Busca servicios autogestionados que reemplazen a soluciones como bases de datos, OAauth 2.0 servicios, etc.

Innovación con la Nube

• Aprovecha el poder de los datos con analítica avanzada:
• Plataformas de big data y machine learning.
• Desarrolla nuevas capacidades en la nube, como IA para análisis predictivo o personalización en tiempo real.

Métricas de éxito:

• Reducción de costos: Optimización del 20%-30% en recursos.
• Mayor agilidad: Despliegues de nuevas aplicaciones en horas en lugar de semanas.
• Capacidad de innovación: Nuevas soluciones que impactan directamente en la experiencia del cliente.

Conclusión: Cómo Migrar a la Nube con Éxito

Migrar a la nube es un viaje estratégico que transforma la forma en que operas, escalas e innovas. El éxito no depende solo de la tecnología, sino de la capacidad de tu organización para aprender, adaptarse y liderar en un entorno digital.

Claves para una migración exitosa:

• Una estrategia clara con objetivos definidos.
• Un roadmap práctico con un ciclo iterativo de adopción y optimización.
• La consolidación de habilidades, procesos y tecnologías enfocadas en escalabilidad y seguridad.

Historias de Éxito: Migración a la Nube

Sabe como migrar a la nube, involucra más estrategia y tácticas alrededor de objetivos, que una receta definida. Muchas empresas empiezan su camino por ejes y lo expanden progresivamente. Estas empresas, entre otras, son ejemplos de transformaciones digitales en la nube.

FICO: Impulsando la Analítica Predictiva con AWS

FICO, líder mundial en soluciones de analítica predictiva, migró a AWS para modernizar su infraestructura. Este movimiento permitió reducir costos operativos y acelerar el desarrollo de sus plataformas, ofreciendo servicios más ágiles a sus clientes. Leer más sobre la historia de FICO.

3M Health Information Systems: Transformación de la Analítica Sanitaria

3M HIS eligió Amazon Redshift para construir una plataforma de analítica en salud, logrando una solución escalable que procesa millones de registros médicos en tiempo real. La decisión de migrar a la nube transformó su capacidad de ofrecer insights críticos a los profesionales de la salud. Descubre cómo lo hizo 3M HIS.

Preguntas Frecuentes (FAQs)

1. ¿Qué necesito para migrar a la nube?
   Una evaluación clara de tu infraestructura, capacidades y un plan estructurado.
2. ¿Cuánto tiempo tarda una migración a la nube?
   Depende del alcance, pero suele implementarse por fases.
3. ¿Cuáles son los mayores beneficios de migrar a la nube?
   Reducción de costos, mayor agilidad y acceso a tecnologías avanzadas como IA y big data.

Ya sea simplemente mover aplicaciones existentes (migración a la nube) o rediseñar completamente tu infraestructura digital para aprovechar al máximo las capacidades de la nube (transformación en la nube), requiere de una estrategia adecuada, AWS promueve 7 estrategias de migración a la nube (las 7Rs):

• Rehost
• Replatform
• Repurchase
• Refactor / Re-architect
• Retire
• Retain
• Realocate

Este artículo te ayudará a entender cada una, cuándo utilizarlas, los pros y contras asociados, de forma que puedas tomar una decisión informada, buscando la innovación y optimización de recursos.

Estrategias de Migración a la Nube (7Rs)

Rehost (Lift and Shift)

El Rehost, o “lift and shift”, es una estrategia de migración a la nube que implica trasladar aplicaciones y datos a la nube con pocos o ningún cambio. Es una opción ideal para organizaciones que buscan una transición rápida, sin la necesidad de rediseñar su infraestructura actual.

Replatform (Lift, Tinker, and Shift)

Replatform es una estrategia de migración que implica hacer ligeros ajustes a la aplicación para optimizar su rendimiento en la nube. A diferencia de Rehost, esta estrategia aprovecha algunas capacidades de la nube sin realizar un rediseño completo, lo que puede llevar a una mayor eficiencia operativa.

Repurchase (Drop and Shop)

Repurchase implica abandonar una aplicación existente y migrar a una nueva solución SaaS en la nube. Esta estrategia es adecuada cuando una aplicación legada no justifica el esfuerzo de migración y una solución en la nube ofrece mayores beneficios.

Refactor / Re-architect

Refactor o re-architect es una estrategia de transformación en la nube que implica rediseñar una aplicación para aprovechar completamente las capacidades de la nube, como la escalabilidad automática o el uso de microservicios. Esta estrategia se utiliza cuando el objetivo es optimizar el rendimiento y la agilidad a largo plazo.

Retire

Retire implica desactivar/decomisar aplicaciones o componentes que ya no son necesarios. Esta estrategia forma parte del proceso de migración a la nube, ayudando a simplificar el entorno de TI y reducir costos.

Retain (Retener)

Retain es la decisión de mantener aplicaciones o componentes en su estado actual, en lugar de migrarlos a la nube. Esta estrategia de migración se utiliza cuando la migración no es viable o necesaria en el corto plazo, permitiendo una transformación en la nube más gradual.

Relocate

Relocate es similar al Rehost, pero se enfoca en mover una infraestructura completa, como máquinas virtuales VMware, directamente a la nube de AWS. Esta estrategia de migración a la nube es útil para organizaciones que buscan trasladar sus centros de datos sin realizar cambios significativos.

Planificación y Evaluación de la Migración

Antes de decidir cuál estrategia de migración es la más adecuada para tu organización, es crucial realizar un análisis exhaustivo del portafolio de aplicaciones.
AWS proporciona una guía detallada sobre cómo evaluar y planificar la migración de tu portafolio de aplicaciones existentes, lo que es fundamental para asegurar una migración a la nube exitosa y efectiva. Este análisis te permitirá identificar qué aplicaciones deben ser rehosteadas, replatformadas, o incluso retiradas, optimizando así la estrategia de migración de tu empresa.
Para más detalles sobre cómo realizar esta evaluación, consulta esta guía de AWS sobre planificación de la migración.

Pensamiento finales

Entender estas estrategias de migración es clave para desarrollar una estrategia que se alinee con los objetivos de tu empresa. Ya sea que busques una simple migración a la nube o una transformación completa, combinar diferentes estrategias puede ayudarte a maximizar los beneficios y minimizar los riesgos.

Recomendaciones:

1. Evaluación Inicial: Realiza una auditoría detallada de tus aplicaciones y recursos antes de elegir una estrategia de migración.
2. Combinación de Estrategias: Considera usar una combinación de “Rehost” y “Refactor” para balancear entre rapidez y optimización.
3. Evolución Continua: Piensa en “Replatform” y “Refactor” como parte de un proceso evolutivo en la nube, donde inicialmente puedes optar por “Rehost” y luego optimizar progresivamente.

¿Qué es Elastic Beanstalk?

Elastic Beanstalk es un servicio de AWS que simplifica el despliegue de aplicaciones en la nube. ¿Cómo lo hace? Este servicio tiene más de 100 servicios asociados y es compatible con aplicaciones desarrolladas en los lenguajes Go, Java, .NET, Node.js, PHP, Python y Ruby, y los orquesta creando una infraestructura basada en el código desplegado de la aplicación y archivos de configuración adicionados en el despliegue.

El desarrollador no tiene que aprovisionar nada.. o casi nada manualmente.

¿Porqué este tutorial?

Actualmente, existen muchos ejemplos de cómo desplegar aplicaciones en Elastic Beanstalk, y los puedes encontrar aquí. Sin embargo, ninguno de ellos aborda específicamente el despliegue de una aplicación Java con Spring Boot y Docker en Elastic Beanstalk. Este artículo asume que tienes conocimientos básicos de este servicio, por lo que si aún no estás familiarizado con el mismo, revisa aquí.

Contenido

En este tutorial, vamos a ver cómo desplegar una aplicación de ejemplo desarrollada con Java, utilizando el framework Spring Boot y diseñada para ser desplegada como contenedor Docker.

Además, realizaremos el proceso manualmente (por línea de comandos) y no a través de la consola web de AWS, ya que interactuar con la consola web cada vez que queremos hacer cambios en una aplicación y subirla a la nube, no es automatizable y puede ser largo y complejo.

Por lo tanto, los pasos a seguir son:

1. Descargar la aplicación y probarla localmente.
2. Instalar y configurar el cliente Elastic Beanstalk CLI.
3. Desplegar una primera versión en desarrollo (dev).
4. Desplegar una versión en QA (próximamente).

Descargar la aplicación y probarla localmente

La aplicación de ejemplo es un simple CRUD, que puedes descargar aquí con el comando:

git clone https://github.com/pazfernando/crud-spring-boot-example.git

Ve a la carpeta donde se descargó y compílala con (requieres tener instalado Java 17+):

cd crud-spring-boot-example
./mvnw clean install

Ejecuta la aplicación con:

java -jar target/crud-0.0.1-SNAPSHOT.war

Prueba la aplicación en tu navegador con:

http://localhost:8080/

Instalar y configurar el cliente Elastic Beanstalk CLI

IMPORTANTE: El procedimiento a continuación es para ambiente Linux, ya que tiene mejor soporte para herramientas y frameworks de desarrollo en general. Si no tienes Linux o Mac, instala WSL en Windows. Mira las instrucciones aquí. Por defecto tendrás un Ubuntu instalado en Windows y podrás usarlo ejecutando en PowerShell lo siguiente:

wsl

Listo, asumimos desde aquí que tienes Linux, Mac o WSL en Windows.

Instalación de pyenv

Empezamos instalando un manejador de versiones de Python llamado pyenv. Encuentra cómo aquí.

Post instalación de pyenv

Añade o verifica estas líneas en .bashrc de $HOME:

export PYENV_ROOT="$HOME/.pyenv"
[[ -d $PYENV_ROOT/bin ]] && export PATH="$PYENV_ROOT/bin:$PATH"
eval "$(pyenv init -)"

Actualiza tu .bashrc con:

source ~/.bashrc

Instala la última versión estable de Python

Encuentra la documentación de versiones estables en https://devguide.python.org/versions/. La instalación es con el comando:

pyenv install 3.11

IMPORTANTE: A la fecha de creación de este artículo, puedes usar Python 3.11 máximo.

Configura esta versión como la de defecto en tu ambiente:

pyenv global 3.11

Instala virtualenv para aislar tu ambiente de Python

Encuentra cómo hacerlo aquí.

Instala Elastic Beanstalk CLI

Encuentra cómo hacerlo aquí.

Actualiza tu .bash_profile para incluir los ejecutables de Elastic Beanstalk CLI en tu PATH:

echo 'export PATH="/home/pazfernando/.ebcli-virtual-env/executables:$PATH"' >> ~/.bash_profile

Refresca tus archivos de ambiente en tu $HOME:

source ~/.bash_profile
source ~/.profile

Desplegar una primera versión en desarrollo (dev)

Ve a la carpeta del proyecto (donde se descargó).

Configura el Elastic Beanstalk CLI, mira cómo hacerlo aquí.

Aspectos importantes previos

Antes de desplegar la aplicación, hay ciertos puntos esenciales a entender acerca de Elastic Beanstalk, ya que este conocimiento nos dará el entendimiento de por qué se despliega una aplicación de una forma u otra.

Ignorando archivos con .ebignore

Cuando desplegamos aplicaciones con Elastic Beanstalk CLI, debemos saber qué archivos son ejecutables, cuáles son de configuración, cuáles son de apoyo, etc. Esto se debe a que CLI empaqueta dichos archivos en un archivo .zip para luego extraerlo y desplegarlo en la instancia o instancias de la infraestructura que sirve la aplicación.

Por defecto, Elastic Beanstalk CLI busca el archivo .gitignore para saber, desde la carpeta donde se están ejecutando los comandos, qué archivos debe excluir de este archivo .zip. Pero como sabemos, para los proyectos Java, el archivo .gitignore excluye el directorio target/, el cual es esencial pues tiene el artefacto compilado del proyecto, y en su lugar empaqueta src/ y otros archivos que son fuentes de la aplicación, y que en este caso no aplican.

Esta estrategia funciona muy bien en proyectos tipo Python o PHP donde no hay compilados, pero no en el caso de Java. Aquí aparece otro archivo, .ebignore, que es otro recurso que busca por defecto Elastic Beanstalk CLI ante la ausencia de un archivo .gitignore o incluso lo precede si existiera. Por esta razón, el archivo .ebignore en este tipo de proyectos es tan importante, y por eso nosotros tenemos en los fuentes este contenido:

HELP.md
src/
*
!Dockerfile
!target/
!.ebextensions

Esto asegura y le dice a Elastic Beanstalk CLI qué ignorar y por ende qué sí empaquetar. En nuestro caso, es importante Dockerfile, target/ y .ebextensions.

Configuración avanzada con .ebextensions

Desplegar una aplicación con Elastic Beanstalk no es siempre, o nunca lo es, algo tan simple como desplegar un artefacto. Si bien la infraestructura se aprovisiona automáticamente, la aplicación suele requerir de variables de ambiente, datos de conexión con servicios externos, capacidades mínimas, etc.

¿Cómo especificamos esto sin tocar el código? La respuesta es con archivos de configuración o archivos .ebextensions.

En nuestro caso, tenemos el archivo env-vars.config donde configuramos ciertas variables de ambiente para que funcione la aplicación:

option_settings:
  aws:elasticbeanstalk:application:environment:
    SPRING_PROFILES_ACTIVE: dev
    CRUD_DB_URL: 'jdbc:postgresql://${RDS_ENDPOINT}/crud_spring_boot_example'
    CRUD_DB_USERNAME: ebroot
    CRUD_DB_PASSWORD: clave

Algo a destacar es SPRING_PROFILES_ACTIVE que determina cómo va a funcionar la aplicación Java + Spring Boot. En la vida real, tenemos cientos de configuraciones posibles que podemos hacer a través de estos archivos. Puedes aprender más aquí.

La documentación es un poco confusa, por eso te dejo dos enlaces más de los tipos de opciones: comando opciones y de las opciones a detalle aquí.

Trabajando con aplicaciones del tipo Docker

Para empezar, necesitas un Dockerfile que en nuestro caso contiene:

FROM amazoncorretto:17.0.11-alpine
ARG JAR_FILE=target/*.war
COPY ${JAR_FILE} app.jar
EXPOSE 8080
CMD ["java", "-jar", "/app.jar"]

Muy simple y claro, y que será incluido en el archivo .zip gracias a nuestro archivo .ebignore.

No tenemos en este caso Docker Compose y lo haremos a partir de ese archivo. Sin embargo, si quieres saber más de las opciones de despliegue, puedes mirarlo aquí.

IMPORTANTE: Hay otra forma de hacerlo en un clúster de Amazon ECS (Elastic Container Service), que está fuera de esta explicación pero que puedes consultarla aquí.

Despliega la aplicación

Excelente, ahora para desplegar vamos a ejecutar el comando:

eb create --single

El --single nos ayuda a desplegar una infraestructura simple, sin redundancia y alta disponibilidad, y que aplica en este caso del tutorial.

Verás algo como:

Enter Environment Name
(default is crud-spring-boot-example-dev): 
Enter DNS CNAME prefix
(default is crud-spring-boot-example-dev): 

Would you like to enable Spot Fleet requests for this environment? (y/N): 
Creating application version archive "app-0048-240801_111838855018".
Uploading: [##################################################] 100% Done...
...
2024-08-01 16:21:52    INFO    Application available at crud-spring-boot-example-dev.us-east-1.elasticbeanstalk.com.
2024-08-01 16:21:54    INFO    Successfully launched environment: crud-spring-boot-example-dev

IMPORTANTE: Si no eliges --single, adicionalmente te preguntarán alguna información necesaria para el despliegue, sigue las siguientes recomendaciones:

• Usa Application Load Balancer ALB (por defecto)
• Di que no a Spot Fleet (por defecto)
• Todo lo demás que no sepas deja por defecto.

Prueba tu aplicación visitando precisamente el url de la salida:

http://crud-spring-boot-example-dev.us-east-1.elasticbeanstalk.com/

Finaliza el despliegue IMPORTANTE IMPORTANTE IMPORTANTE

Si fallas este paso tu factura puede salir muy alta, especialmente si no usaste --single, así que ejecuta este comando para finalizar el tutorial:

eb terminate

Pensamientos finales

Desplegar una aplicación Java con Spring Boot en Elastic Beanstalk de AWS utilizando Docker es algo más complejo, pero siguiendo estos pasos detallados, el proceso se vuelve manejable y entendible, por lo que espero que sea de valor para ustedes.

Elastic Beanstalk de AWS simplifica enormemente el proceso de despliegue y gestión de aplicaciones, permitiendo enfocarte en el desarrollo sin preocuparte por la infraestructura. Utilizar Docker agrega una capa de consistencia y portabilidad, asegurando que tu aplicación funcione de la misma manera en cualquier entorno.

Es vital seguir entender prácticas como el uso adecuado de archivos .ebignore y .ebextensions para asegurar que solo los archivos necesarios se incluyan en el despliegue y que la configuración de tu aplicación sea flexible y segura. Además, siempre finaliza los entornos no utilizados para evitar costos innecesarios.

Usar perfiles de Maven es un poco más complicado, pero la idea es trabajar con .ebextension para configurar los valores requeridos, si hay recursos relacionados como bases de datos servicios colas y demás, la recomendación es que se creen fuera de el scope de la aplicación.

La implementación de una aplicación en la nube es un proceso iterativo. A medida que te familiarices con Elastic Beanstalk y Docker, encontrarás formas de optimizar y mejorar tu flujo de trabajo. Comparte tus experiencias y cualquier obstáculo que encuentres, y sigue aprendiendo de la documentación y la comunidad de AWS.

Explorando Límites de AWS Lambda – Porque

Es muy común implementar una solución Serverless en AWS utilizando los servicios API Gateway, AWS Lambda y DynamoDB, y, probar esta arquitectura para nuestro caso de uso es crucial al diseñar una solución.

Así, cuando trabajamos la charla ¿Como manejar 100K conexiones simultáneas en AWS? en Serverless o probamos los nuevos límites de AWS Lambda de acuerdo al anuncio Las funciones de AWS Lambda ahora escalan 12 veces más rápido cuando manejan solicitudes de gran volumen, nos vimos en la necesidad de crear recursos y ambientes, una y otra vez hasta crear el escenario perfecto.

Por eso decidimos crear un proyecto base como infraestructura como código que pueda apoyarlos para sus propias pruebas. El repositorio es público y de código abierto, y lo pueden encontrar aquí serverless-limits-playbook-test.

Arquitectura

La idea principal en esta versión es crear una arquitectura de un API RESTful con API Gateway integrado a un función AWS Lambda para llamadas sincrónicas, y crear una instancia EC2 con una instalación de JMeter para lanzar pruebas de carga.

Aunque en el código podrán observar también:

• Habilitación de CORS
• Bloque de código para llamadas asincrónicas (comentado)
• Configuración para reserve concurrency en AWS Lambda.
• El script setup.sh para adicionar configuraciones a su instancia EC2.
• El script index.mjs para definir la implementación real de su función AWs Lambda.
• Un identificador único para peticiones desde a lambda (opcional podrían eliminarlo).

Prerequisitos

Dependiendo de su caso de uso necesitarán configuraciones generales en su cuenta, pero aquí presentamos las básicas.

• Tener una Default VPC en la region que vayan a probar.
• Crear un Role en IAM que permita escribir desde API Gateway a CloudWatch.
• Asignar dicho rol a las configuraciones del servicio API Gateway en la región donde se va ha hacer pruebas.
• Tener los Server Limits adecuados a su prueba, especialmente los de AWS Lambda “Burst Concurrency” y “Concurrent Executions“.

Despliegue de recursos

Al ser un proyecto IaaC construido con AWS CDK, pues evidentemente usamos los comando apropiados. A continuación la lista de pasos:

• Cambiar las variables const targetRegion y const targetAccount en el archivo de los fuentes /bin/infra.ts apropiadamente.
• Instala AWS CLI la última versión.
• Instala Node.js 20 o superior.
• Instala el último AWS CDK.
• En la carpeta del proyecto corre cdk boostrap para preparar la región para IaaC.
• Ejecuta cdk synth para verificar que tus fuentes estén correctos.
• Ejecuta cdk deploy para crear los recursos descritos en la arquitectura.

Usamos AWS CDK para este proyecto, pero podrías reemplazar o hacer tus versiones con Terraform u OpenTofu respectivamente. Hacerlo con AWS Cloud Formation es otra opción aunque no lo recomiendo.

Lanzamiento de carga masiva

Para ejecutar las pruebas masivas con JMeter es necesario ingresar a la instancia EC2 creada a través de la Consola Web y con EC2 Instance Connect, dado que no se asoció un server key al momento de su creación.

Una vez en el shell los comandos son los siguientes:

• Cambia a root el usuario: sudo -i.
• Edita el archivo LambdaConcurrencyLimits.jmx con vi /tmp/LambdaConcurrencyLimits.jmx con el url de tu API RESTful (esa url la obtienes como salida del comando cdk deploy al final del log).

Ejecuta los test JMeter de carga con

rm -Rf /var/www/html/stats/* && rm -f /tmp/stats.jtl && /opt/apache-jmeter-5.6.2/bin/jmeter -n -t /tmp/LambdaConcurrencyLimits.jmx -l /tmp/stats.jtl -e -o /var/www/html/stats.

Pruebas en JMeter

Mientras se puede escribir un blog entero de pruebas en JMeter, el archivo creado esta compuesto de las siguintes características:

• Cinco grupos de usuarios (hilos)
• Primer grupo lanza 1001 usuarios en 10 segundos.
• Segundo grupo lanza 2001 usuarios en 20 segundos.
• Tercer grupo lanza 3001 usuarios en 30 segundos.
• Cuarto y quinto grupo lanza 0 usuarios, y están en el archivo jmx para que los usen como lo prefieran para su caso de prueba.
• Se prueba una URL con un HTTP Request de tipo GET al API RESTful creado.
• El URL del API Gateway RESTful esta externalizado en el argumento url-api-gateway.

Evidentemente estas pruebas no se ajustan a tu caso de uso y deberás cambiarlas apropiadamente, sin embargo el mecanismo de lanzamiento y la instancia EC2 configurada va a reducir el tiempo para esta operación.

Métricas

Una vez desplegada la infraestructura, y ejecutados las pruebas podremos monitorear los recursos y tomar las acciones correspondientes.

A continuación algunos gráficos que vamos a poder obtener:

API Gateway

AWS Lambda

Además siempre vamos a tener Grupos de Logs en Amazon CloudWatch apropiados para el caso de uso y por servicio para analizar los resultados:

IMPORTANTE: siempre al finalizar las pruebas no olviden ejecutar cdk destroy para decomisar los recursos usados y evitar facturación innecesaria.

Conclusiones y Pensamientos Finales

En este Playbook Explorando Límites de AWS Lambda, hemos podido plasmar un proyecto de código abierto para que puedan acelerar sus pruebas de implementaciones. Sin embargo hay mucho que mejorar en el mismo, como la inclusión de secrets con Secrets Manager para gestionar números de cuenta y otros parámetros sensibles y que NO deben estar en su repositorio de fuentes.

También este proyecto nos ayuda en la inmersión en el mundo apasionante que significa AWS CDK, y con el cual pueden gestionar su infraestructura de forma completamente automatizada.

Vale mencionar que en un proyecto de AWS CDK jamás deben subir el directorio cdk.out, dado que aquí como resultado de la compilación de los archivos Typescript a archivos propios de AWS Cloud Formation ((JSON por ejemplo), puede y va a quedar información sensible como números de cuenta y/o claves.

Para hacer uso de este enfoque de despliegue es necesario estar familiarizado con AWS CLI ya que con este generarán perfiles que contengan accesos de los usuarios de su cuenta, y con tales accesos se crearán los recursos. Entonces es importante que los usuarios asociados tengan los permisos correspondientes.

Los límites que tengan para su cuenta y por región van a incidir directamente en sus pruebas en caso de altas cargas de procesamiento, por lo que se debe tener en cuenta los mismos al momento de planificar la implementación.

Les animamos a dejar su feedback para mejorar el proyecto, sea aquí o en el repositorio de GitHub, y esperamos que sea de utilidad este proyecto “Explorando Límites de AWs Lambda”.

Esta estrategia, Endpoint Proxy en API Gateway, es muy adecuada especialmente porque tenemos los siguientes beneficios:con

• Implementar el escenario Rehost (lift and shift) para una migración.
• No realizar ninguna modificación a la implementación del API.
• Mantener el servicio web en una red privada y sin acceso a internet.
• Acceder a mejoras de seguridad del API de negocio y poder monitorearlo, dado que vamos a usar API Gateway.
• Posibilita el versionamiento del API de negocio con menor esfuerzo.
• Integración con el escudo de seguridad AWS WAF.

Tutorial Endpoint Proxy con API Gateway

Se piensa en implementar con Amazon API Gateway un Endpoint Proxy de tipo HTTP API, que puede brindar la solución a lo requerido.

Escenario API Público

Para este escenario vamos a utilizar el API ejemplo de Swagger https://petstore.swagger.io/ como referencia, que nos ayuda a probar operaciones RESTful comunes.

Probamos la operación https://petstore.swagger.io/#/pet/findPetsByStatus para mirar los datos disponibles.

Ok, el API está funcionando correctamente.

Definimos una arquitectura Cloud para este efecto en AWS.

Creamos el API Gateway HTTP con el nombre proxy-swagger-api.

Creamos la ruta $default.

La ruta $default actúa como un “catch-all” es decir gestiona cualquier petición que no coincida con otras rutas definidas. Puedes saber más aquí.

Creamos la integración.

Probamos el API RESTful de la misma forma que lo hicimos al inicio.

Debemos cambiar el Endpoint a el nuevo del API Gateway: https://gl1p0rt1gc.execute-api.us-east-2.amazonaws.com/ (reemplaza para tu caso con el apropiado).

Esta vez la prueba la vamos ha hacer desde Postman.

¡Excelente! Funciona igual y como un Endpoint Proxy con las ventajas y funcionalidades que ofrece API Gateway.

Escenario API Privado

¿En la vida real como sería un ejemplo?

Vamos a ver una arquitectura donde este API es una implementación privada que esta en una instancia EC2 en una subred privada de una VPC de la empresa. Por tanto el único que permite acceso y controla los flujos es el API Gateway.

Para este escenario vamos a usar la implementación de un CRUD API RESTful construído con Spring de Código Libre / Opensource en GitHub.

Descargamos el proyecto en la instancia EC2 en la red privada, lo compilamos y corremos de acuerdo a las instrucciones del archivo README.mb en el código .fuente.

Seguido a esto hacemos una prueba. En este caso nos ayudamos de AWS CloudShell.

Son dos comandos curl, que insertan un registro visita y luego recuperan todas los registros visitas.

Cabe mencionar que antes debemos conectarnos a esa máquina con los protocoles estándar de SSH + Server Key, y, primero pasando por un Bastion Host… ya se mucha información pero ese es el camino dado que el servidor EC2 esta en una subred privada.

Creamos un Endpoint Proxy de tipo HTTP API, igual que en primer escenario.

Creamos una Route (ruta) proxy $default.

Para poder direccionar el tráfico a un recurso en una red privada, vamos a usar un Aplication Load Balancer (ALB), el mismo que va incluir en su Target Group a la instancia EC2 que provee el API privado.

El ALB debe ser de tipo “internal” es decir solo se puede usar dentro de la VPC (no desde Internet).

Evidentemente necesitas tener un Target Group que contenga el servidor EC2 privado donde esta el API al cual el ALB va a dirigir las peticiones. Por esto en medio de la creación del ALB tendrás que crear este Target Group.

Debes asegurarte que el grupo de seguridad del ALB permite el tráfico al puerto donde esta el listener.

Continúa con la creación del ALB.

Bien, vamos a continuar con la creación de la integración de nuestro API proxy-api-crud, para esto vamos al servicio API Gateway para iniciar.

La integración debe ser de tipo “Private resource” y en método seleccionamo9s “Select manually” para tener la opción de elegir un ALB/NLB como Target service.

En la lista desplegada de los ALBs, seleccionamos nuestro proxy-alb recién creado.. Además vamos a tener que crear “Create new VPC link” en la selección correspondiente, ya que este será el puente entre nuestro API creado con API Gateway y por defecto en una red propia de AWS, con nuestra VPC propia de la empresa.

Para este caso la VPC es proxy-vpc-vpx, pero debes elegir la correspondiente en tu infraestructura.

Aquí una ampliación al concepto de VPC Link, un VPC Link es un recurso que permite crear una integración con los recursos privados de una VPC desde una ruta del API Gateway de tipo HTTP. De esta forma no tienes que exponer ningún recurso de la VPC al público e igual puedes usarlo como destino final de un API Gateway que si sea público. Si quieres saber más de integraciones privadas para API Gateway HTTP a recursos de tu VPC puedes mirar aquí.

Luego en las opciones siguientes es importante elegir a qué subredes tiene acceso este nuevo VPC Link y que grupos de seguridad se le asignan.

Las subredes son importantes porque deben ser las subredes asociadas a tu ALB y su correspondiente Target Group.

El grupo de seguridad, es que que permite el acceso al puerto correspondiente donde el Listener del ALB esta escuchando peticiones.

Realizada la integración vamos a identificar el url (Invoke URL) del Endpoint Proxy con API Gateway creado.

Listo, con ese url, si todo es correcto podemos hacer las siguientes peticiones:

Para crear una visita:

curl --location 'https://bg4gmloull.execute-api.us-east-2.amazonaws.com/api/visits' \
--header 'Content-Type: application/json' \
--data '{"date":"2024-01-19","name":"Fer","comment":"by CloudIO Strategy"}'

Para consultar visitas:

curl --location 'https://bg4gmloull.execute-api.us-east-2.amazonaws.com/api/visits'

Son las mismas peticiones que usamos con consultar el servicio web RESTful desde el shell de la instancia EC2 mostrada en el ejemplo.

¡Excelente! Hemos creado un Endpoint Proxy con API Gateway, son tocar la implementación, con la funcionalidad esperada y todos los beneficios que tenemos en el servicio Amazon API Gateway.

Conclusiones y pensamientos finales

Hoy en este tutorial hemos visto como podemos implementar un Endpoint Proxy con API Gateway, un requerimiento que viene a partir de una migración al estilo Rehost del cliente que no desea entrar en temas de modificación a sus aplicaciones.

Presentamos dos escenarios, un proxy para un API público, que es infrecuente, y, un proxy a un API privado que si es muy frecuente y en ambos casos el servicio Amazon API Gateway nos permite implementar tal necesidad.

Nuestra arquitectura es solo una posibilidad de implementación del requerimiento, sin embargo en nuestra opinión es la más simple y rápida para dar una respuesta adecuada.

Vimos un concepto “VPC Link” que es importantísimo a la hora de integrar un API HTTP con recursos privados en la VPC, y en nuestro caso, nos integramos a un ABL o Aplication Load Balancer, sin embargo podríamos habernos integrado por ejemplo a AWS Cloud Map. Dado esto, no es la única forma de integración que podrían usar.

El ALB nos habilita todas las ventajas que tenemos de un Load Balancer por ejemplo resiliencia o escalamiento horizontal, y aunque representa un costo adicional es justificable frente a un lineamiento SRT (Server Response Time) del negocio.

Evidentemente, falta muchas configuraciones complementarias a una arquitectura de este estilo, como por ejemplo lo relacionado a las decisiones de stages del API, las seguridades, el monitoreo y la trazabilidad. Además la buena práctica es conectar este API Gateway a un dominio o subdominio apropiado de su empresa para facilidad de uso y estrategias de contingencia, entre otros.

Introducción a Amazon VPC

Amazon VPC significa Amazon Virtual Private Cloud.

El servicio Amazon VPC permite a los usuarios crear una sección virtual y aislada de la nube de AWS, donde pueden lanzar recursos en una red virtual definida por ellos mismos. Esto brinda un control granular sobre el entorno de red, incluida la selección de rangos de direcciones IP, creación de subredes, y configuración de tablas de rutas y gateways de red.
Amazon VPC es esencial para mantener la seguridad y el aislamiento de los recursos, y para crear redes escalables y flexibles que se integren con otros servicios de AWS.

IMPORTANTE

• Cuando comienzas a utilizar AWS, se crea de forma predeterminada una VPC en cada región de AWS. Una VPC predeterminada viene con una subred pública en cada zona de disponibilidad (AZ), una puerta de enlace de Internet (IGW).
• La idea es que puedas comenzar rápidamente y lanzar instancias públicas como un blog o un sitio web simple.
• Siempre podrás modificar esta configuración inicial, mientras evoluciona tu arquitectura.

Características de Amazon VPC

Las siguientes son las características o componentes que ayudan a entender ¿qué es Amazon VPC? y que Amazon VPC permite crear en la nube AWS.

5 Beneficios principales de Amazon VPC

Seguido a la descripción de las características de Amazon VPC, veamos como las mismas tienen la capacidad de ofrecer opciones muy poderosas para tu infraestructura en la Nube.

1. Seguridad y Control de Acceso
   Amazon VPC permite crear un entorno de red aislado con control granular sobre el acceso, asegurando que solo el tráfico autorizado acceda a tus recursos.
2. Personalización y Flexibilidad
   Permite configurar tu red virtual según las necesidades específicas de tu empresa, incluyendo la selección de rangos de direcciones IP y la creación de subredes.
3. Escalabilidad
   Puedes adaptar fácilmente tus recursos de red a medida que crece tu empresa, sin la necesidad de invertir en infraestructura física costosa.
4. Integración con Otros Servicios de AWS
   Te provee de mecanismos de integración de Amazon VPC con otros servicios de AWS (VPC endpoints) para una implementación y gestión eficiente de aplicaciones en la nube.
5. Opciones de Conectividad Híbrida
   Conexión de forma segura de tu VPC con tu red local mediante opciones como VPN y AWS Direct Connect, permitiendo un entorno de red híbrido.

Precios de Amazon VPC

No hay cargos por configurar y usar VPCs, los cargos vienen de otros servicios (activados a demanda) que se usan para personalizar el control, monitoreo, seguridad o conectividad en la VPC.
Los casos incluyen, entre otros, servicios como:

• VPC Flow Logs y Trafic Mirroring.
• Transferencia de datos fuera de la red de AWS con redes privadas o VPCs en otras regiones.
• IPs públicas reservadas pero no usadas con servicios AWS en ejecución.
• Servicios adicionales de conexión como NAT Gateways, VPNs, VPC Endpoints o AWS Direct Connections.
  Evidentemente, hay más servicios que vamos a aprovisionar en la VPC, como Amazon EC2 o Amazon RDS o Amazon Load Balancers, los cuales tendrán cada uno su costo independiente.

Puedes encontrar más detalles en Precio de Amazon VPC.

Pensamientos finales

¿Qué es Amazon VPC? En este artículo hemos descrito a Amazon VPC como servicio esencial dentro de AWS que permite a las empresas crear redes virtuales seguras y escalables y ofrece un control granular sobre el entorno de red.
Los beneficios de usar Amazon VPC incluyen seguridad mejorada, escalabilidad, integración con otros servicios de AWS y opciones de conectividad híbrida.
Al migrar a la nube de AWS, es importante realizar una evaluación exhaustiva de los requisitos de la aplicación, planificar adecuadamente la arquitectura de red, seleccionar una estrategia de migración adecuada, y tener en cuenta los costos y el cumplimiento.
Es clave entonces saber que es Amazon VPC y conocer exaustibamente las posibilidades que nos ofrece para diseñar arquitectura seguras por sobre todo pero al mismo tiempo que nos optimice siempre el costo OPEX en la nube.

Las instancias EC2 tipo T están en el grupo de propósito general, lo cual significa que su configuración es la más estándar posible y podría usarse para cargas de trabajo (workloads) que impliquen un balanceo moderado de recursos, tanto de CPU, memoria, red y acceso al almacenamiento.

Concretamente los siguientes son los casos de uso de las instancias EC2 tipo T recomendados por Amazon Web Services:

1. En desarrollo y pruebas: ¿necesitas un lugar para probar nuevas ideas sin estresar tus principales servidores? las instancias tipo T pueden ser la respuesta, ya que manejan a la perfección picos ocasionales de CPU.
2. En sitios Web y aplicaciones de bajo tráfico: ¿tu sitio Web o aplicación no tiene tráfico masivo 24/7? las instancias tipo T podrían ser tu solución ideal, ya que tienen un costo más económico (especialmente la Txg), y puedes servir ese sistema ERP, CRM, etc. con una inversión moderada.
3. En microservicios: si tus microservicios necesitan un picos ocasionales para manejar tareas intensivas de CPU, las instancias tipo T están listas y pueden ayudar. Aunque hay otras opciones de cómputo, puedes usar este esquema y pasar a otro si la carga es intensiva o impredecible.
4. Para pequeñas bases de datos: para bases de datos que no necesitan siempre estar a pleno rendimiento, una instancia tipo T podría ser una opción eficiente y económica. Cabe señalar que si tienes muchos I/O en el disco es recomendable combinar esta instancia con volúmenes #AmazonEBS de tipo io2.
5. Para servidores de respaldo: ¿tienes servidores que están en stand-by la mayoría del tiempo?, es decir están ahí para planes de continuidad. Las instancias tipo T son ideales gracias a su modelo de rendimiento “burstable” que ayudarán hasta reactivar tu esquema principal.

Hay que tomar en cuenta que las instancias tipo T no son las más adecuadas para cargas de trabajo que requieren un alto rendimiento constante de CPU (ahí necesitaras instancias tipo C o M). pero para muchas otras tareas, son excelentes.

Hay otros tipos de instancias de propósito general y puedes ver más información en Tipos de instancias EC2 en AWS., donde encontrarás sus variantes como T4g, T3, T3a y T2.

Cada variante tienen unas características de hardware específicas, así T4g significa que usa el procesador Graviton o T3a significa que usa el procesador AMD.

Tecnologías Serverless en AWS

¿Qué es Serverless?

El término “Serverless” se refiere a un enfoque de arquitectura en el cual los desarrolladores no necesitan gestionar ni mantener servidores para ejecutar sus aplicaciones. En lugar de esto, las aplicaciones se construyen utilizando servicios en la nube que automáticamente escalan y se encargan de la administración de recursos, como el cómputo, el almacenamiento y la red.

Ventajas de las tecnologías Serverless

• Costo: Solo pagas por lo que usas, ya que las tecnologías Serverless se facturan según el consumo de recursos y el tiempo de ejecución en lugar de tener costos fijos de servidores. Esto puede resultar en un ahorro significativo en comparación con la administración de infraestructura propia.
• Escalabilidad: Las aplicaciones Serverless escalan automáticamente según la demanda, lo que garantiza un rendimiento óptimo incluso en momentos de alta demanda. Esta escalabilidad dinámica elimina la necesidad de planificar la capacidad de los recursos y facilita el manejo de picos de tráfico inesperados.
• Desacoplamiento: Las tecnologías Serverless permiten desarrollar aplicaciones modulares y desacopladas, lo que facilita la actualización y el mantenimiento del software, a diferencia de un paradigma monolítico.
• Independencia tecnológica: Al no depender de una infraestructura específica, las aplicaciones Serverless pueden adaptarse fácilmente a cambios en los requisitos de negocio o tecnología.
• Foco en el negocio: Los desarrolladores pueden centrarse en la lógica de la aplicación para crear valor al negocio, en lugar de preocuparse por la administración y el mantenimiento de la infraestructura. Esto permite a los equipos de desarrollo ser más ágiles y entregar nuevas funcionalidades más rápidamente.
• Resiliencia: Dado que las aplicaciones Serverless se construyen con servicios en la nube de alta disponibilidad y tolerantes a fallos, es menos probable que experimenten interrupciones o tiempo de inactividad. Además, las aplicaciones Serverless pueden beneficiarse de la redundancia geográfica y el balanceo de carga que ofrecen los proveedores de servicios en la nube como AWS.

Principales servicios Serverless en AWS

Otros Servicios

Dependiendo del caso de uso los siguientes son servicios Serverless que son usados menos frecuentemente o para casos de negocios específicos. Así tenemos: AWS AppSync (servicio que facilita el desarrollo de aplicaciones basadas en datos en tiempo real y offline, utilizando una única API GraphQL), Amazon RDS Proxy (proxy de conexiones a Amazon RDS sin servidor), Amazon Aurora Serverless (base de datos relacional sin servidor), Amazon Redshift Serverless (bodega de datos Bigdata sin servidor), Amazon Neptune Serverless (base de datos de grafos sin servidor), Amazon Opensearch Serverless (base de datos clave-valor sin servidor).

Casos de uso frecuentes de tecnologías Serverless

Aplicaciones web y móviles:

Las tecnologías Serverless en AWS permiten construir aplicaciones web y móviles escalables y de alto rendimiento sin la necesidad de administrar infraestructura. En paradigmas como BaaS y FaaS, los desarrolladores pueden centrarse en la lógica de la aplicación y la experiencia del usuario, mientras que AWS se encarga de la escalabilidad, la seguridad y el mantenimiento de la infraestructura.

Procesamiento de imágenes y vídeos:

Las aplicaciones Serverless pueden procesar y transformar imágenes y vídeos en respuesta a eventos, como la carga de archivos en Amazon S3 o la solicitud de un usuario. Los servicios de AWS, como Amazon Lambda, Amazon Comprehend y/o Amazon Elastic Transcoder, pueden ayudar a automatizar tareas como el redimensionamiento de imágenes, reconocimiento de imágenes, extracción de metadatos y la transcodificación de vídeos.

Análisis de datos en tiempo real:

Las tecnologías Serverless en AWS pueden utilizarse para procesar y analizar grandes volúmenes de datos de diversas fuentes, como registros de aplicaciones, eventos de IoT o transacciones de comercio electrónico. Los servicios de AWS, como Amazon Kinesis, AWS Glue y Amazon Athena, pueden ayudar a extraer información valiosa de los datos y generar informes y visualizaciones en tiempo real o por lotes.

Automatización de flujos de trabajo (Workflows):

Las aplicaciones Serverless pueden automatizar y optimizar procesos empresariales, como la aprobación de documentos y requerimientos internos. Los servicios de AWS, como Step Functions y Amazon Simple Workflow Service (SWF), pueden ayudar a modelar, coordinar y ejecutar flujos de trabajo complejos y tareas de larga duración.

Pensamientos finales

Las tecnologías Serverless en AWS ofrecen una gran cantidad de ventajas y oportunidades para los desarrolladores y las empresas que buscan construir y desplegar aplicaciones en la nube.

Al eliminar la necesidad de aprovisionar, administrar y mantener la infraestructura, las aplicaciones serverless permiten a los equipos centrarse en el desarrollo de nuevas funcionalidades y mejorar la experiencia del usuario.

La escalabilidad y resiliencia implícita en estos servicios nos da la tranquilidad de tener continuidad en el negocio a un costo por uso y reducido frente a un provisionamiento y tecnologías on-demand.

Las tecnologías Serverless en AWS están transformando la forma en que las organizaciones desarrollan y despliegan aplicaciones en la nube. Al adoptar estas tecnologías y seguir las mejores prácticas de arquitectura y desarrollo, las empresas pueden reducir costos, mejorar la eficiencia y entregar soluciones innovadoras que satisfagan las necesidades y expectativas de sus usuarios y clientes.