DVA-C02 es un examen para desarrolladores que evalua no solo el conocimiento de infraestructura en la nube, sino tambien como escribir codigo para trabajar con los servicios de AWS. Este articulo explica, de manera accesible para principiantes, como los desarrolladores se comunican con los servicios de AWS (SDK), como intercambiar mensajes de forma segura (SQS) y como procesar datos en tiempo real (Kinesis).
SDK de AWS — Controlar servicios de AWS a traves del codigo
El SDK (Software Development Kit) es un conjunto de herramientas que permite a los desarrolladores usar lenguajes de programacion como Python, Java o Node.js para operar los servicios de AWS a traves del codigo. Piensalo como un traductor que permite que tu codigo hable con los servicios de AWS. Si quieres subir un archivo a S3 o guardar datos en DynamoDB desde tu codigo Python, usas el SDK.
Para usar AWS desde tu codigo, necesitas credenciales para demostrar quien eres. El SDK sigue un orden fijo (la cadena de credenciales) cuando busca estas credenciales. Primero revisa las variables de entorno, luego el archivo de credenciales compartidas y finalmente el rol IAM adjunto al servidor. Conocer este orden te ayuda a resolver rapidamente situaciones de "por que estoy obteniendo un error de permisos".
La configuracion de region consiste en especificar que centro de datos de AWS (region) usar al crear un cliente SDK. Tambien se puede establecer mediante variables de entorno.
La paginacion es una funcion en la que el SDK divide automaticamente grandes conjuntos de resultados en multiples paginas cuando hay demasiados resultados para devolver de una vez. Recibes los resultados en fragmentos, como capitulos de un libro.
Desarrollo con SQS — Entrega segura de mensajes
SQS es un sistema postal para intercambiar mensajes de forma segura entre servicios. El emisor (productor) y el receptor (consumidor) no necesitan estar directamente conectados.
Ciclo de vida del mensaje
Veamos paso a paso como se procesa un mensaje.
Primero, el productor envia un mensaje a la cola. Cuando un consumidor toma el mensaje, el timeout de visibilidad comienza en ese momento. El timeout de visibilidad es un bloqueo temporal que dice "este mensaje se esta procesando, otros consumidores no lo toquen". Una vez que el consumidor termina el procesamiento, elimina el mensaje. Si el mensaje no se elimina dentro del timeout de visibilidad (por fallo o retraso en el procesamiento), reaparece en la cola y otro consumidor puede manejarlo.
Dead Letter Queue (DLQ)
Algunos mensajes pueden seguir fallando sin importar cuantas veces se reintenten. Dejar estos mensajes sin resolver provoca intentos de reprocesamiento repetidos que desperdician recursos. La DLQ mueve los mensajes que han fallado mas de un numero establecido de veces (maxReceiveCount) a una cola de aislamiento separada para su custodia. Los desarrolladores pueden analizar despues la DLQ para encontrar la causa raiz de los errores. Piensalo como una sala de aislamiento en un hospital.
Long Polling vs Short Polling
Hay dos formas de obtener mensajes de SQS.
Short Polling pregunta inmediatamente a la cola "hay mensajes?" y devuelve una respuesta vacia de inmediato si no hay ninguno. El problema es que sigue preguntando incluso cuando no hay mensajes, desperdiciando costos de llamadas a la API.
Long Polling espera hasta 20 segundos a que llegue un mensaje. Esto se configura con WaitTimeSeconds. Las respuestas vacias se reducen, el numero de llamadas a la API disminuye y los costos son menores. Long Polling es generalmente el enfoque recomendado.
!Short Polling vs Long Polling
Kinesis Streaming — Procesamiento de datos en tiempo real
A diferencia de SNS y SQS, Kinesis es un servicio de streaming que procesa grandes volumenes de datos en tiempo real. Mientras SNS y SQS manejan mensajes individuales, Kinesis maneja datos que fluyen continuamente como un rio. Por ejemplo, se puede usar para analizar en tiempo real los registros de uso de millones de usuarios de una app, o para procesar datos de sensores IoT.
Kinesis Data Streams esta organizado en unidades llamadas shards. Piensa en los shards como carriles de una autopista. Los productores usan partition keys para dirigir los datos a carriles especificos (shards), y los consumidores leen datos de cada carril.
Enhanced Fan-out es una funcion que garantiza throughput dedicado por consumidor cuando multiples consumidores leen del mismo stream. Cada consumidor recibe datos de forma independiente a 2MB por segundo por shard.
El periodo de retencion de datos por defecto es de 24 horas y se puede ampliar hasta 365 dias.
Patrones de codigo resiliente
Logica de reintento — Exponential Backoff
Cuando ocurre un error de red o una interrupcion temporal del servicio, reintentar inmediatamente puede en realidad aumentar la carga del servidor. Exponential Backoff duplica el intervalo de reintento cada vez que ocurre un fallo: reintentar despues de 1 segundo, luego 2 segundos si eso falla, luego 4 segundos, 8 segundos, y asi sucesivamente. Esto esta integrado por defecto en el SDK de AWS, pero puede necesitar implementacion personalizada en algunos casos.
Patron Circuit Breaker
Como un disyuntor en sistemas electricos, este patron detiene temporalmente las llamadas a un servicio externo cuando sigue fallando. Si sigues enviando solicitudes a un servicio que falla consistentemente, tu propio servicio puede ralentizarse o desconectarse tambien. El Circuit Breaker decide "este servicio tiene problemas ahora mismo, asi que voy a cortar la conexion temporalmente", evitando que los fallos se propaguen por todo el sistema.
Puntos clave para el examen
"Mover mensajes fallidos a una cola separada" -- Dead Letter Queue
"Reducir llamadas API y evitar respuestas vacias" -- Long Polling (WaitTimeSeconds)
"Reintentar con intervalos progresivamente mas largos" -- Exponential Backoff
"Detener llamadas a servicio externo que falla" -- Patron Circuit Breaker
"Streaming de datos en tiempo real" -- Kinesis Data Streams
"Throughput dedicado por consumidor" -- Kinesis Enhanced Fan-out
"Orden en que el SDK busca credenciales" -- Cadena de credenciales
El timeout de visibilidad de SQS debe ser mayor que el tiempo de procesamiento