Cómo mover y procesar datos
Networking para AWS, y lo que dijo alguien hace 2000 años sobre estar en varios lados a la vez
Lo que vas a ver en esta edición:
Cómo mueve y procesa datos un/a Data Engineer
Los conceptos de redes que te pueden servir en AWS (y cualquier nube)
La lección que nos comparte un sabio estoico sobre estar en varios lados a la vez
Y una herramienta muy útil si te manejas con varias cuentas en AWS
🧠 El Núcleo
Cómo mover y procesar datos
Si estás siguiendo esta newsletter desde el principio, recordarás que en ediciones anteriores vimos qué es la Ingeniería de Datos y los conceptos que hay que dominar para tener una base sólida. También charlamos un poco sobre aspectos relacionados, como Python y Git.
Es hora de entrar en lo “divertido” (que lo es, sí, pero a veces no tanto): ¿cómo es que el/la Data Engineer mueve y procesa los datos?
Sabemos que este profesional construye sistemas encargados de procesar datos. Estos sistemas ingieren datos y los llevan a cierto lugar. Las preguntas que ahora surgen son:
¿cómo lo hacen?
¿cómo se mueven los datos de un lugar a otro de manera que su estado final (o intermedio dependiendo del caso) genere valor para los interesados en dichos datos?
La respuesta es una palabrita/concepto que quizá escuchaste antes: una pipeline.
Pero antes de eso, la duda más importante es: ¿qué es procesar datos? ¿Agarro un Excel y lo paso por una picadora para obtener 200gr. de datos de clientes?
Más allá del chiste malo, la necesidad de procesar datos es muy real. Esto suele involucrar:
remover datos indeseados o que ya no son necesarios
convertir datos de un tipo hacia otro tipo que resulte más sencillo de utilizar
organizar los datos, de modo que otros interesados, como los Data Analysts, puedan encontrar fácilmente lo que necesitan
…y varios motivos más
Para lograr estos y otros cometidos se construyen sistemas que lo hagan de manera automática, eficiente y segura (aspectos muy importantes, no los olvides), como una pipeline.
Una pipeline (o tubería o canalización) de datos asegura que los datos fluyan de manera eficiente en una organización, automatizando:
Extracción
Transformación
Combinación
Validación
Carga
y otros factores…
…y de esta manera, reducir:
intervención humana
errores
el tiempo que le toma a los datos para fluir
Pero esto es tan solo la punta del iceberg:
¿sabías que generalmente cada componente de una pipeline debe ejecutarse en un orden y, a veces, intervalos específicos?
¿Y si te digo que hay formas distintas de ingerir datos desde una fuente (o sistema fuente, como vimos en la primera edición)?
Es más, ¿sabías que hay varios enfoques para mover y procesar datos?
Si te piqué la curiosidad con alguna de estas preguntas (o todas), pasate por mi blog donde toco este y otros temas relacionados con las tuberías de una manera un poco más completa en este post.
Y como suelo decir, si tenés alguna duda (o crees que hay algo que falta o podría mejorarse), no dudes en contactarme a través de mis redes.
En la próxima edición vamos a hablar sobre ETL y ELT, dos enfoques muy utilizados al momento de construir pipelines.
☁️ La Senda del Nubearquitecto
Networking para Arquitectos de Soluciones
Primero que nada, no. Con “networking” no me refiero al acto de hacer contactos. Esta vez hablo de las viejas y queridas redes de computadoras. ¿IP? ¿DNS? ¿Puertos? ¿Te suenan esos términos?
Hace ya unos meses que empecé a prepararme para la certificación SAA-C03 de AWS y llegó un momento donde tuve que frenar momentáneamente dicha preparación ya que me estaba faltando un concepto general muy importante para moverse dentro del ecosistema de AWS (aunque en realidad te sirve para cualquier nube), y eso es redes o networking.
El tema es: ¿cuánto hay que saber? Si estás interesado/a en certificarte en AWS esto seguramente te interesa. Te doy la buena noticia (y esto es mi opinión personal combinada con una pequeña investigación que hice al respecto): no hace falta saber TODO.
De hecho cuando empecé a moverme en AWS tenía muy poco conocimiento de redes en general. Y no fue muy buena idea.
Muchas cosas me hacían ruido, no las entendía y eso me dejaba en la duda de si realmente estaba ofreciendo una buena solución. Pero igual podía moverme con cierta confianza.
Mi recomendación es que no te saltes estos conceptos. Prestales atención, incorporalos, al menos tené nociones.
Vamos con lo que considero es Networking Basics para Arquitectos de Soluciones (o personas que aspiran a moverse en AWS con confianza y buenas bases).
Atenti que esto viene un poquito cargado.
Conceptos básicos de redes para la nube
Clientes y servidores
Un cliente hace una petición, un servidor responde.
Ejemplo: Tu navegador (cliente) pide una página a Google (servidor).
Hosts y dispositivos de red
Host = dispositivo final que se conecta a la red (PC, celular, servidor).
Dispositivos de red = routers, switches, access points.
Ejemplo: Tu notebook conectada al router Wi-Fi de tu casa.
Conexiones cableadas e inalámbricas
Cableadas: Ethernet, más estables.
Inalámbricas: Wi-Fi (802.11a/b/g/n/ac/ax), más cómodas pero menos estables.
Ejemplo: Conectarte al router con cable vs Wi-Fi.
Modelos de capas (TCP/IP y OSI)
Sirven para entender en qué nivel actúan los protocolos.
Ejemplo: IP (capa 3) se encarga de llegar al host, TCP (capa 4) asegura el orden de los datos, HTTP (capa 7) define el contenido.
Ethernet, MAC y ARP
Ethernet: protocolo de enlace cableado.
MAC: dirección física única de cada interfaz de red.
ARP: traduce una IP a una MAC.
Ejemplo: Tu PC necesita enviar algo a 192.168.1.10 → usa ARP para preguntar: “¿Quién tiene esta IP?”.
Protocolo IP (IPv4, IPv6, CIDR)
IP identifica hosts en la red.
CIDR (
/24,/16) define el rango de direcciones en una subnet.Ejemplo:
192.168.1.0/24→ IPs de192.168.1.1a192.168.1.254.
DHCP (Dynamic Host Configuration Protocol)
Asigna IPs automáticamente a los hosts.
Ejemplo: Te conectás al Wi-Fi y el router te da
192.168.1.45.
Enrutamiento entre redes
Los routers conectan redes distintas.
Ejemplo: Tu LAN hogareña (192.168.1.0/24) → Router → Internet (WAN).
TCP y UDP
TCP: confiable, ordenado (ej: web, correo).
UDP: rápido, sin control (ej: videollamadas, juegos online).
Ejemplo: YouTube usa TCP para cargar la página, UDP para transmitir el video.
Protocolos de la capa de Aplicación
Definen reglas de comunicación entre aplicaciones.
Ejemplo: HTTP (web), FTP/SFTP (archivos), SMTP/IMAP (correo).
Conceptos que aparecen mucho en la nube
Subnets públicas y privadas
Pública: accesible desde Internet.
Privada: accesible solo dentro de la VPC.
Ejemplo en AWS: un servidor web en subnet pública, una base de datos en subnet privada.
NAT (Network Address Translation)
Traduce IPs privadas a una IP pública para salir a Internet.
Ejemplo: 100 PCs en tu casa salen a Internet usando una sola IP pública.
Firewalls y reglas de seguridad
Definen qué tráfico entra o sale.
Ejemplo en AWS: Security Group que permite solo HTTP (80) y HTTPS (443).
VPNs y túneles
Conectan redes privadas a través de Internet de forma segura.
Ejemplo: Una empresa conecta su oficina con su VPC en AWS mediante VPN.
DNS (Domain Name System)
Traduce nombres a IPs.
Ejemplo:
google.com→142.251.128.142.En AWS: Route 53 administra tus dominios.
Load Balancers (Balanceadores de carga)
Distribuyen tráfico entre varios servidores.
Ejemplo en AWS: un ELB reparte las peticiones entre 3 instancias de tu aplicación web.
Si, parece un MONTÓN para aprender. Pero como te dije anteriormente, lo importante no es saberlo todo en profundidad.
Andá concepto por concepto, entendé lo básico pero sobre todo comprendé qué problema resuelve cada uno.
¿Te gustaría abarcar estos y otros conceptos de manera ordenada, con un montón de ejemplos y ejercicios para practicarlos?
Entonces este curso gratuito, organizando nada más y nada menos que por Cisco te va a venir de 10.
Sumate al Networking Basics. Es una verdadera inversión en tu camino profesional dentro de la nube.
💭 Debug Mental
No estés en varios lados a la vez
Hoy voy a ponerme filosófico y a darme el lujo de ser un poco hipócrita, porque sí. Yo también tengo mi lado oscuro, tengo mis falencias y hay una que otra mentira que me cuento a mi mismo. Pero peor aún, me creo esas mentiras.
Lo importante es siempre tomar consciencia de todo eso, traerlo “a la luz” y reflexionar: ¿qué es eso que sé que no está bien, que podría remediar y que realmente remediaría?
Porque yo vengo ahora a darte un consejo que yo mismo rompo en más de una oportunidad. Por lo que, de humano a humano, te pido que me tengas paciencia, y que puedas hacer el esfuerzo de “escuchar” el mensaje que quiero transmitirte.
Un gran filósofo estoico de la antiguedad dijo:
“Cuando intentas estar en demasiados sitios a la vez, no estás en ninguno. Concéntrate en algo hasta que lo consigas. Luego, a por otra cosa” — Séneca, hace un montón de años
En la sociedad moderna en la que vivimos, donde parece que se valora mucho el ser multitasking y escuchar un podcast mientras se está cocinando (si es algo que haces, por fa no te sientas atacado/a, es solo un ejemplo para ilustrar un punto), el concentrarse en una sola cosa parece un acto de rebeldía.
Y Dios mío que los que estamos en la industria IT padecemos de esto eh. Me pasó mil veces de estar estudiando algo y decirme “bueno, voy a completar este curso de punta a punta, voy a ponerme las pilas y ser constante”. ¡PERO NO!
Heme aquí…
haciendo un curso de Cisco sobre Networking (el que te pasé más arriba jeje)
preparándome para la Solutions Architect Associate de AWS
intentando ponerme al día con un programa de especialización en Ingeniería de Datos.
¿Te despierta algo de admiración todo eso que te cuento? Si por alguna razón te resulta admirable, dejame decirte que no es nada divertido…ni admirable.
Anotarme en todo es pasar por alto el consejo que dió Séneca miles de años atrás (qué loco, hace miles de años algunas personas la tenían más clara que nosotros, que vivimos en la era de la IA).
Pero esta idea no aplica solo a tus estudios, aplica a
hábitos
lecturas
proyectos
propósitos
No tenemos tiempo material ni energía mental suficiente para estar en demasiados sitios a la vez.
Sé que no es fácil aplicar algo como esto.
El mundo, que es cada vez más depredador de nuestro tiempo, nos empuja a hacer de todo y para ayer.
Pero si podés llegar a anclarte a un propósito, uno solo, el tiempo suficiente para llevarlo a cabo de la manera más eficiente que puedas, entonces creo que habrás ganado.
Igual, ojo. Esto tampoco quiere decirte que te entregues a algo y que descuide todos los demás aspectos de tu vida.
Hacer un solo curso no implica que por ejemplo descuides tu salud, o alimentación, a tu familia/hijos, etc.
Balance, mi joven padawan.
Creo que es sano tener más de un objetivo, siempre y cuando sea una cantidad manejable y realista.
Espero poder un día decirte con total confianza: “Logré concentrarme en una sola cosa. Logré dominar mi impulso y gané FOCO.”
Si ese día llega, dá por seguro que voy a contarlo por acá.
En el mientras, te acompaño en el sentimiento si esto es algo que también te cuesta. 🫂
📚 Datazo
¿Manejás varias cuentas de AWS? Esto te puede servir
Como de costumbre, en esta sección te comparto un recurso o herramienta para hacerte la vida más fácil.
Si trabajás con AWS y gestionás múltiples cuentas (la tuya, la de clientes, entornos distintos...), sabés que manejar perfiles, sesiones, y credenciales temporales puede ser un dolor de cabeza. 😵💫
Hace poco empecé a usar Leapp y me cambió la forma de trabajar con AWS.
Es una app de escritorio open source que te permite:
✅ Iniciar sesión fácil
✅ Gestionar múltiples cuentas
✅ Obtener credenciales temporales
✅ Trabajar seguro, sin exponer secretos
Yo lo uso en conjunto con boto3 (SDK de Python para AWS). En lugar de lidiar con sesiones que vencen o editar archivos .aws/credentials, simplemente elijo un perfil en Leapp, y TUKI. ¡Listo para trabajar! 🔧🐍
Ideal para devs, freelancers, y equipos que cambian seguido entre cuentas o roles.
Si usás AWS todos los días, probalo. Es de esas herramientas que no sabés que necesitás hasta que la usás.
Resumen nivel 5
Lo que quiero que te lleves de esta edición es:
Los Data Engineers construimos pipelines para mover y procesar datos. Esto nos permite automatizar la extracción, procesamiento y entrega de datos a las personas correctas, de la forma correcta, en el tiempo correcto, y de una manera eficiente y costo-efectiva.
Podés aprender AWS sin saber redes, pero no te lo recomiendo para nada. Empapate de los conceptos básicos, entendé qué problemas resuelve cada concepto y asegurate unos buenos fundamentos en tu camino en la nube.
No estés en varios lados a la vez, aunque el mundo quiera llevarte en esa dirección. 1 libro, 1 curso, 1 proyecto, 1 objetivo. Completalos, y luego a seguir con otra cosa. (Y sí, lo estoy escribiendo para mí esto también).
¿Te movés entre varias cuentas de AWS? ¡Usá Leapp papá! Hermosa herramienta
¡AH! Y por cierto, si por una de esas casualidades estás leyendo esto desde el Konex por motivo de la Nerdearla, ¡búscame! Hoy voy a estar trabajando desde allí. ¡Será un placer conocerte! 🤝🏻