DEV Community: Fernando

Pruebas en APIs de microservicios: 5 esenciales para arquitectos de software

Fernando — Mon, 16 Feb 2026 17:41:30 +0000

Las pruebas en APIs de microservicios son un pilar fundamental en arquitecturas modernas basadas en integración distribuida. Para arquitectos de software y líderes técnicos, la calidad ya no se limita a que “funcione”, sino en garantizar confiabilidad, seguridad y estabilidad operativa en sistemas distribuidos que evolucionan constantemente.

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)

Payment API recibe la orden
Account API confirma saldo
Ledger API registra el débito
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.

AI Periodic Table: el mapa minimalista para diseñar soluciones de IA sin perderte

Fernando — Mon, 16 Feb 2026 17:21:02 +0000

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á:

Arquitectura de Microservicios: qué es, ventajas y desventajas

Fernando — Mon, 25 Jul 2022 15:58:10 +0000

Iniciando desde la interfaz del usuario (en algunos casos), pasando por una o varias capas de lógica de negocio, la capa de persistencia, y, hasta la base de datos, el producto de Software se construía como un solo concepto, y a menudo se ejecuta como un solo binario o unidad entregable (JAR, WAR, EAR, Folder, etc.).

La Arquitectura de Microservicios es un enfoque para el desarrollo de un producto de Software, en donde cada concepto específico de negocio es construido en una unidad pequeña de código accesible a través de una API liviana y bien definida.

El TODO del producto de Software entonces, constituye la ejecución sincronizada de un conjunto de estos servicios, cada uno con su propia e independiente definición, para el proceso de una transacción padre disparada desde una interfaz de usuario o sistema.

Características de los Microservicios

Aunque parece no existir una especificación única para crear Microservicios, y más depende del caso de negocio y/o planificación; generalmente se sugiere que deban cumplir las siguientes características:

Interfaz Única

Cada Microservicio debe proveer una interfaz ligera y bien definida para consumo, que aísle todos los detalles técnicos, estructura de datos y datos de la capacidad de negocio que maneja, a sus clientes.

Especializado

Cada servicio es diseñado con un conjunto limitado de capacidades que resuelvan uno y solo un problema de negocio, y que incluye su propia estructura de datos persistentes.

Autónomo

Cada servicio puede ser desarrollado, desplegado, operado y escalado sin afectar o depender de otros servicios o sistemas, o, de otros datos fuera de su especialización.

Claramente una Arquitectura de Microservicios es una aplicación del paradigma de Cómputo Distribuido, lo que representa muchas ventajas para el negocio pero también muchos retos en la operación y mantenimiento.

Ventajas de la Arquitectura de Microservicios

Agilidad Este paradigma de desarrollo permite crear equipos pequeños e independientes que se apropian de la especialización de los servicios, acelerando el tiempo de desarrollo, facilitando la auto-organización e incluso el soporte post-producción.	Escalamiento Esta división de funcionalidad hace más fácil la medición y observabilidad de la implementación, permitiendo planificar mejor la disponibilidad y escalabilidad.
Simplificación de Despliegue Una unidad pequeña de implementación, permite ciclos de CI/CD más simples, reduciendo el tiempo de despliegue de la misma y el rollback en caso de fallos. Esto agiliza las operaciones y al mismo tiempo reduce el riesgo de innovación con nuevas características.	Resiliencia A diferencia de una Arquitectura Monolítica, un fallo en una Arquitectura de Microservicios compete a un componente específico, lo que hace más fácil su recuperación y no desestabiliza el producto de Software por completo, sino la capacidad de negocio concreta que le compete.
Independencia Tecnológica El uso de una sola tecnología no es una restricción en la Arquitectura de Microservicios, dado que su interfaz de consumo abstrae los detalles de implementación y habilita a la selección de la mejor herramienta de acuerdo a la especialización del servicio.	Reutilización de Código Evidentemente una vez construido un servicio que atiende una capacidad de negocio, el mismo puede ser utilizado por otros productos de Software de forma que su construcción aproveche la funcionalidad ya implementada.

Desventajas de la Arquitectura de Microservicios

Más que desventajas, se puede hablar de retos a la hora de adoptar una Arquitectura de Microservicios, y entre los principales tenemos:

Versionamiento Un Microservicio, al ser autónomo, suele evolucionar independientemente del producto o de los productos de Software a los cuales provee funcionalidad. Esto significa que su interfaz API y la validación del esquema de datos varía continuamente, sin embargo para no afectar la estabilidad de sus clientes antiguos debe mantener un versionamiento de los mismos y obviamente mantenerlos operando. Esto tanto para áreas de operaciones y de desarrollo implica una tarea adicional en su implementación.	Pruebas Si bien un Microservicio por sí solo es más simple de probar, su orquestación con otros servicios (test de integración) y las pruebas integrales (pruebas end to end) son mucho más complejas. Esto resulta a menudo en una cobertura incompleta de escenarios de pruebas y un esfuerzo redoblado en su desarrollo.
Rollback y Sistemas Distribuidos El reto más grande, para mí, es el diseño de sistemas distribuidos, puesto que hay que definir qué sucede en caso de fallos esperados o inesperados en la orquestación de los servicios, analizar patrones de resiliencia y recuperación de transacciones, mirar la atomicidad de operaciones y consistencia de datos, entre otros. Claro está, que para esto nos podemos apoyar en conceptos como “Patrones de Integración Empresarial”, “Mallas de servicios” o similares, pero sin duda estas decisiones son extremadamente relevantes no solo para el desarrollo sino para el soporte post-producción.	Coordinación de equipos Si bien, al desarrollar un Microservicio, paradigmas como la Agilidad y un equipo responsable puede representar una gran ventaja para generar valor e innovación constante en su implementación, al tener decenas o centenas de microservicios con decenas o centenas de equipos responsables, la cooperación y comunicación de estos equipos es un reto, pues el TODO de un Sistema y su evolución se puede poner en riesgo cuando se carece de una acción combinada.
Sobrecarga de infraestructura En la Arquitectura Monolítica un operador a menudo mira un servidor y un Software correspondiente con su archivo log; en un paradigma de Arquitectura de Microservicios puede enfrentarse a escenarios donde un Software tiene 100 servicios y centenas de servidores, con uno o varios balanceadores, muchos archivos de logs y decenas de formatos. Aunque hoy existen esquemas de contenerización como Docker y Kubernetes, la administración sigue siendo un reto y se necesita varias tecnologías complementarias para enfrentarlo.	Tiempo y esfuerzo 1x A este punto del artículo ya hemos descrito muchas actividades adicionales en el diseño, implementación, operación y mantenimiento de la Arquitectura de Microservicios, por su característica de Sistema Distribuido. Por este motivo es importante sopesar el beneficio de este paradigma en contraste con el caso de negocio y los resultados esperados a corto, medio y largo plazo; del mismo modo debemos pensar en el soporte post implementación, en relación al equipo, sus capacidades.
Despliegue ¡Si!, desplegar un solo microservicio es simple, sin embargo desplegar cientos de ellos de forma manual se vuelve imposible. El orden de despliegue, los cambios de base de datos que implica, la estratégia de entrega (Blue-Green, Canary, etc.), entre otros, son cosas a planificar y deben estar automatizadas, con prácticas DevOps entre otras como Integración Continua (CI) y entrega Continua (CD).	Logs y Monitoreo De la misma manera, un producto de Software Monolítico deja un solo log de operación y se puede medir su performance centralizadamente. En una Arquitectura de Microservicios, vamos a tener tantos logs como servicios implementados para el producto de Software y además si estos son redundantes, tendremos logs multiplicados por cada servicio. Debemos planificar una estratégia para rastrear errores, identificar la salud de cada servicio y del sistema como tal.
Debug Encontrar un problema no siempre va a ser posible revisando logs (que al ser tantos ya nos agrega una complejidad), a veces vamos a tener que depurar la implementación y esto en un sistema distribuido no va a ser factible, por lo que se requerirá de otras técnicas y patrones que permitan repetir ciertas ciclos de transacciones.

Pensamientos Finales

A este punto del artículo, puede sonar complejo decidir por microservicios, y la verdad lo es; sin embargo, esta complejidad no se evidencia desde el momento cero de una implementación, sino que irá apareciendo gradualmente mientras vamos creando más microservicios y escalándolos.

Son muchas sus ventajas, y aunque hay retos, en una estratégia digital a largo plazo es sin duda el camino a adoptar, y así mismo, debe venir acompañada de un soporte directivo dado que la estructura organizacional, técnica y de costos va a tener que evolucionar también.

¿Debo usar Microservicios? La realidad es que muchos desarrollos de Software nacen con este enfoque, sin abordar en un primer momento las soluciones a estos desafíos, pero eventualmente lo harán. Les invito a ver una interesante conversación entre Martin Fowler y Sam NewMan sobre cuando usar microservicios y cuando no.

El soporte de este tipo de aplicaciones es complejo, pues detectar un fallo en una Arquitectura de Microservicios requiere de un entrenamiento en el flujo de negocio, en los puntos de integración y en la interpretación de los logs de información. En muchos casos al soporte de primera línea le faltan insumos para responder y el escalamiento de las incidencias es muy rápido al equipo técnico, resultando en una sobrecarga de operación y costo.

Amazon Lightsail un esquema de costo fijo AWS

Fernando — Thu, 12 May 2022 21:11:35 +0000

Una de las más grandes preocupaciones para los Líderes de TI y en general para los CFO de las empresas es como manejar los costos relacionados a la nube. En este artículo vamos a revisar el servicio Amazon Lightsail un esquema de costo fijo AWS, en donde tu empresa se puede apalancar para dar el salto a la Nube de una forma controlada.

Amazon Lightsail, en más que un servicio, en realidad es un conjunto de servicios de AWS con la visión de tener un completo control de costos y una simplificación de administración.

El enfoque es poder acceder a una arquitectura de CERO a failover, con una reducción importante de complejidad en la configuración y un control completo de los costos, y claro, más la velocidad, rentabilidad y oportunidad de innovación que ofrece AWS para tu empresa.

Una Arquitectura de CERO a failover

Para efectos de explicar los servicios de Amazon Lightsail, vamos a tomar como referencia la siguiente arquitectura que nos da alta disponibilidad y failover.

Evidentemente, la arquitectura puede ser mucho mejor y dependerá de tu requerimiento, pero vamos a asumirla como la deseada para una aplicación monolítica Web.

Vamos a empezar de atrás hacia adelante:

Base de Datos

Amazon Lightsail nos ofrece el servicio de Amazon RDS para motores MySQL y PostgreSQL a un costo fijo, con varias opciones de rendimiento, que van desde 1 GB hasta 8 GB.

Adicionalmente, una de las grandes ventajas es que Amazon RDS es una solución completamente administrada, es decir, no te encargas de instalar, administrar, parchear o respaldar la base de datos.

Una opción interesante que posibilita el Failover a través de su configuración Multi-AZ, en donde Amazon RDS se encargará automáticamente del switch en caso de falla.

Servidores de Aplicación

Las instancias de servidores para tu aplicación Web, son aprovisionadas para tu caso de negocio con el servicio Amazon EC2, de igual forma con costo fijo, en donde puedes elegir instancias de entre 2 GB a 32 GB.

Te ofrece, además, la posibilidad de seleccionar el Sistema Operativo Linux más adecuado a tu aplicación, estando entre los principales: CentOS, Ubuntu y Amazon Linux 2.

Una de las ventajas, en mi opinión, es que te da la opción de la instalación optimizada de aplicaciones de Software más comunes en hosting como Wordpress, Joomla y Prestashop entre otros o, la instalación de Software necesario para tus aplicaciones Web como LAMP, Node.js o Nginx.

Balanceador de Carga

Uno de los componentes claves de un esquema de alta disponibilidad es tener un balanceador de carga, que puede afrontar un eventual fallo de un servidor o gestionar alto tráfico de peticiones entre varios servidores.

Con Amazon Lightsail puedes aprovisionar un balanceador con la tecnología de su servicio Elastic Load Balancer.

Este balanceador permitirá monitorear la salud de los servidores destino, balancear la carga y enrutar el tráfico con protocolos HTTP y HTTPS, y, de igual forma, tiene un costo fijo mensual para tu estrategia de costos fijos.

CDN

Bien, como sabes, un CDN nos ayuda a servir todos esos recursos que no cambian en nuestra aplicación Web como imágenes, hojas de estilo y librerías JavaScript. Esto supone una gran ventaja, pues la experiencia del cliente al consumir la aplicación va a ser mucho más rápida en ese aspecto.

Amazon Lightsail nos ofrece una distribución CDN en la cual se va a almacenar en caché estos contenidos y serán servidor de forma acelerado a tu usuario dependiendo de la región del mundo, en los más de 300 data centers de AWS alrededor del mundo.

Otros Servicios

Es importante mencionar que Amazon Lightsail también tiene la posibilidad de aprovisionar otros servicios que contribuyen a tu estrategia de arquitectura. Así podemos mencionar a los siguientes:

Contenedores

Amazon Lightsail te permite aprovisionar contenedores para servir tus aplicaciones. Bajo una administración de costos fijos puedes aprovisionar nodos desde 512 MB hasta 8 GB de RAM, y, hasta 20 nodos por región, lo que te da la posibilidad de correr desde microservicios hasta aplicaciones completas contenerizadas.

El servicio te proporciona un endpoint del clúster de contenedores a donde puedes apuntar tus peticiones, abstrayéndote de toda la complejidad que puede significar aprovisionar y gestionar un clúster de contenerización.

Cabe mencionar aquí, que puedes monitorear el clúster, incrementar su capacidad de manera automática o manual y sincronizar tus imágenes de contenedores con un servicio de registro como Amazon ECR u otro.

Certificados SSL

Todos los endpoints tanto del CDN, balanceador de carga y clúster de servidores, suelen requerir, y se recomienda encarecidamente, el uso de protocolo HTTPS para su acceso. Este requiere de generación de certificados SSL y su asociación con dominios de internet.

Para esto, Amazon Lightsail te permite crear los certificados, firmados por Amazon como entidad certificadora oficial, y asociarlos a estos dominios sin costo en cualquiera de sus servicios (incluso en los que no son a través de Amazon Lightsail) de forma amigable.

IPs estáticas

A menudo, especialmente para backend se suele requerir tener IPs estáticas para los servidores aprovisionados, de manera que las instancias creadas, que al principio tienen una IP pública temporal, no pierdan su IP al ser recreadas por actualizaciones o mantenimiento.

En este caso, Amazon Lightsail te permitirá tener IPs estáticas para tu arquitectura y asociarlas a tus instancias cuando lo desees. Es importante mencionar que las mismas no tienen costos siempre que están asociadas a una instancia.

Emparejamiento con otros servicios de AWS

Sabemos que la arquitectura base de este artículo, no es la adecuada en muchos casos, y a menudo se quiere tener acceso a un NFS (Amazon EFS), un almacenamiento de objetos como Amazon S3, otros servidores en Amazon EC2 o en general a otros servicios proporcionados por AWS.

Pensado en esto, Amazon Lightsail tiene la opción de activar la característica llamada VPC peering, la misma que permite a los recursos aprovisionados en Amazon Lightsail mirar a los recursos aprovisionados de toda la Nube AWS.

Esta configuración se activa desde la opción “Account → Advanced” de la consola de Amazon Lightsail y se empareja con la VPC por defecto de tu infraestructura en AWS normal.

¿Hasta donde usar Amazon Lightsail?

Bueno, la idea siempre será optimizar costos, y mientras los mismos dentro de Amazon Lightsail sean menores a los causados con la misma arquitectura en el aprovisionamiento normal que llevaría en AWS, deberíamos considerar seguir con Amazon Lightsail.

Por otro lado, tenemos ciertos requerimientos que no van a poder ser cumplidos con Amazon Lightsail, como demanda de instancias HPC (cómputo de alto rendimiento), bases de datos propietarias como Oracle, SQLServer, etc., servicios de colas como SQS, etc. en donde sería mejor opción un esquema de aprovisionamiento normal en AWS.

La otra principal razón, en mi opinión, es la simplificación, pues una gestión de un esquema failover y de alta disponibilidad en aprovisionamiento normal en AWS, es mucho más complejo y demandante de conocimiento (empezando en como diseñar apropiadamente tu VPC), que hacerlo en Amazon Lightsail en donde hay muchas opciones por defecto que cubren el escenario.

Conclusiones

En este artículo hemos mirado como la solución, Amazon Lightsail un esquema de costo fijo AWS, representa una opción para esas empresas que prefieren tener un control total de la inversión en la Nube.

Amazon Lightsail permite crear esquemas de arquitectura que incluye desde un simple servidor hasta un esquema completo de alta disponibilidad y failover para sus aplicaciones.

Además, Amazon Lightsail cuenta con opciones de contenerización, con lo cual podrías aprovisionar arquitecturas que requieran microservicios y escalamiento contenerizado, de forma automática o manual.

Por otro lado y muy importante, hemos visto como los servicios aprovisionados en Amazon Lightsail pueden convivir con tus servicios aprovisionados en toda la Nube AWS a través de VPC peering, lo que te da opciones para seguir usando los otros servicios que no incluye Amazon Lightsail como Amazon S3, Amazon EFS, AWS Lambda, Amazon Redshift, etc.

Amazon Lightsail no es para todas las arquitecturas, y habrá que evaluar en términos de costo y carga de gestión, si es más apropiado utilizar un esquema tradicional o el simplificado que nos ofrece este servicio.

Como parchear servidores en AWS

Fernando — Wed, 06 Apr 2022 18:35:31 +0000

Una de las principales dudas de los equipos TI en relación con el aprovisionamiento de infraestructura en la Nube AWS o cualquier Nube en realidad, es como parchear servidores en AWS y más específicamente las instancias EC2.

La respuesta corta a esta pregunta es a través de su servicio AWS Systems Manager (con la abreviatura SSM) y en concreto con la funcionalidad Patch Manager.

Sin embargo, hay que mencionar que la solución AWS Systems Manager no solamente nos ayuda con la aplicación de parches a nivel del Sistema Operativo y a nivel del Software instalado, también nos ofrece una administración y monitorización completa de los recursos desplegados en AWS e incluso de los recursos On-premises que deseemos adicionar a su gestión.

Es realmente impresionante el nivel de gestión que se puede alcanzar con esta herramienta para toda tu infraestructura, te animo mirar todas las posibilidades en la página Características de AWS Systems Manager. Por supuesto, si deseas tener una versión resumida de esta herramienta, me dejas saber en los comentarios 🙂.

Aplicando parches en instancias EC2 en AWS

Vale resaltar que no es lo mismo parchear 2 o 3 instancias EC2 que parchear decenas, cientos o miles de instancias distribuidas en varias regiones a lo largo de AWS.

A continuación vamos a describir un conjunto de pasos para poder aplicar los parches en instancias EC2 en AWS:

El primer paso, y parte de las buenas prácticas de aprovisionamiento de recursos en AWS, es marcar los mismos a través de AWS Tags, que son etiquetas asociadas a los recursos aprovisionados en AWS que nos permitirán identificarlos y clasificarlos de acuerdo a nuestra estrategia de Gobierno TI.

Ya ingresando al servicio AWS Systems Manager o SSM, el segundo paso es usar una Línea Base (Baseline) predefinida en la opción Patch Manager de este servicio; esta es una definición de Sistema Operativo y criticidad de actualizaciones preestablecida, y que es aplicable a nuestras instancias EC2.

Claro que tú puedes crear tu propia Línea Base, si tienes algún requerimiento especial que no encuentres en las múltiples opciones que encontrarás predefinidas allí.

Luego, como tercer paso, y que mi criterio es muy recomendado, especialmente si tienes desde decenas de servidores o un nivel de continuidad de negocio que lo exige, es crear Grupos para Parches (Patch groups) en tu definición de Línea Base. La idea es identificar con una etiqueta a un grupo de instancias a parchear que contengan esa definición en sus AWS Tags.

¡Ten cuidado!, y por esto es importante tener definidos Grupos para Parches, ya que AWS no prueba los parches antes de ponerlos a disposición en Patch Manager, porque pertenecen en su mayoría a los fabricantes del Software.

AWS no prueba los parches antes de ponerlos a disposición en Patch Manager.

La definición de una ventana de cambios (Maintenance Windows) viene a ser el cuarto paso, y se la define a través del servicio AWS Systems Manager. Aquí vamos a especificar el horario, la duración y la recurrencia en la cual se va a ejecutar las acciones asociadas a la misma.

El quinto paso, y el más largo, es asociar la ventana de mantenimiento con la Línea Base y el Grupo para Parches, aunque también podrías asociarla con instancias específicas EC2 lo cual no sería recomendado y práctico.

El comando objetivo para correr la Línea Base definida es “AWS-RunPatchBaseline” y lo observarás en las opciones correspondientes en Patch Manager.

Patch Manager no admite actualizaciones de versiones principales (major versions) de Sistemas Operativos como ir de Windows Server 2019 a 2022 o RHEL 7 a RHEL 8.

¡Listo!, una vez realizado estos pasos, está automatizado el proceso de aplicación de parches en tus instancias EC2 en AWS y lo podrás monitorizar desde la opción Managed Instances en el servicio AWS Systems Manager.

Te recomiendo ver una versión más detallada de este proceso en el Blog Aplicación de parches a sus instancias de Windows EC2 con AWS Systems Manager Patch Manager de Stefan Minhas 😉.

Conclusiones

Es completamente posible automatizar la aplicación de parches en los recursos en AWS incluso en instancias On-premises que han sido asociadas al servicio AWS Systems Manager.

AWS Systems Manager es un servicio para la gestión y monitorización de los recursos en AWS que nos permite mantener una administración adecuada de la Nube.

Patch Manager nos provee de Líneas Base predefinidas para mantener actualizados a nuestros servidores de forma automática, pero es importante comprender que AWS no prueba estás actualizaciones previamente ya que en su mayoría son de terceros, por lo que debemos considerarlo en nuestra estrategia de gestión.

Patch Manager maneja solamente actualizaciones menores (minor versions), no está pensado para hacer migraciones de versiones principales.

Hay muchas otras opciones de Patch Manager que no se han visto en esta guía de como parchear los servidores en AWS, como notificaciones, reportes y evaluación de cumplimiento; sin embargo, son muy útiles ya en un escenario empresarial y deberían considerarse.

Tipos de Instancias EC2 en AWS – Ficha Técnica

Fernando — Fri, 25 Mar 2022 17:26:08 +0000

AWS del servicio Amazon EC2 con múltiples opciones a la hora de aprovisionar un servidor en la Nube; pero elegir uno u otro depende del requerimiento de negocio y a menudo existen dudas sobre cuál elegir. Hoy les traemos una ficha técnica de los tipos de instancias EC2 en AWS, de forma que les pueda ayudar a tomar una decisión para su Empresa y requerimiento.

Vamos a ver en la ficha técnica de instancias EC2 en AWS, el grupo de Instancias de Propósito General; sin embargo, existen otros tipos de instancias para necesidades más específicas como instancias optimizadas para cómputo, para uso memoria, para acelerar el cómputo u para optimizar el acceso al almacenamiento. Puede encontrar toda de esa oferta especializada aquí.

Tipos de Instancias EC2 en AWS – Propósito General

Mira el siguiente enlace para obtener la ficha técnica Tipos de Instancias EC2 en AWS - Ficha Técnica : Propósito General

¿Como elegir una instancia EC2 en AWS apropiada para mi caso de uso?

En general tenemos tres escenarios: despliegue de una nueva aplicación, despliegue de una aplicación existente o despliegue de un Producto de Software de un proveedor.

En el caso de Productos de Software, tal vez la decisión es más sencilla, pues seguramente tenemos ya especificaciones de Hardware definidas por el vendedor, las mismas que debemos tratar de cumplir eligiendo la instancia EC2 correcta. Incluso hay ya muchos Productos de Software de vendedores que traen una especificación clara para su funcionamiento en la Nube.

En el caso de aplicaciones existentes, debemos tener métricas históricas acerca del desempeño y uso de recursos informáticos On-premises (CPU, RAM, almacenamiento y Red) como soporte para seleccionar el tipo de instancia EC2 apropiada. Sin embargo, hay que tomar en cuenta también otros aspectos de la aplicación como su arquitectura, sus dependencias y las estrategias de resiliencia definidas por el negocio, ya que no hacerlo nos va a significar dolores de cabeza relacionados con reinstalaciones, reconfiguraciones y sobre todo problemas de latencia.

El último y más frecuente caso suele ser las aplicaciones nuevas, en donde no tenemos un histórico de funcionamiento, pero si podemos hacer una proyección a tres meses de concurrencia de usuarios, número de transacciones diarias y capacidades mínimas del Software base; partiendo de allí la recomendación es ser lo más modesto posible y medir la utilización de recursos y el rendimiento de la aplicación semanalmente de forma que podamos ir aumentando las capacidades del tipo de instancia EC2 inicial o cambiar de tipo de instancia para optimizar costos.

Es clave usar inicialmente un modelo de precios On-demand, que aunque no es el menos costoso, te permitirá en los 3 a 6 primeros meses aprender de la real demanda de tu aplicación o Productos de Software para luego confirmar o cambiar el tipo de instancia adecuada, adquiriendo la misma en un modelo de precios como más conveniente como el Reservado o Spot.

Claro que existirá el caso de aprovisionar un NFS o un FTP o algo similar, pero hacerlo a través de una instancia EC2 tal vez no sea el mejor camino dado que AWS tiene servicios especializados para estos fines.

Conclusiones

Fue muy interesante revisar estas características técnicas pues aclaran el propósito de cada tipo de instancia, suele ser confuso y abrumador leer tanta documentación o tener tantas opciones y esta ficha puede ayudarle en el primer momento a saber que camino profundizar.

Estos son los puntos importantes que en mi opinión destacan en esta ficha técnica de tipos de instancias EC2 en AWS:

Ya tenemos una opción para obtener una máquina Mac a un precio excelente y cubrir la necesidad de desarrollos para esa plataforma.

Elegir T4g siempre que se pueda, esto significa siempre que el software base que necesitemos este disponible en esta arquitectura, porque supone menores costos.
Elegir T3a o T3 por sobre T2, considerando también la compatibilidad del software base. Aunque la mayoría de Sistemas Operativos y programas son ampliamente soportados en procesadores AMD.
Si la necesidad es un servidor mediano o grande, ir por las instancias M; por ejemplo, servidores de aplicaciones como SAP, Sharepoint, IAS, JBOSS, etc.
De los servidores M la mejor opción es el M6g por costo-rendimiento, pero de igual forma el software base es clave aquí. Los procesadores Graviton son espectaculares y cuestan menos por su significativo ahorro de energía lo que supone menos contaminación también 😉 puede encontrar más en AWS y sus procesadores Graviton.
Si requieres alto tráfico de red (throughput) piense en instancias M5n o M5zn.

Finalmente, te animamos a contribuir con ideas para mejorar esta Ficha Técnica de Instancias en AWS.