Netflix no solo es la mayor plataforma de streaming del mundo.

También es uno de los mayores proveedores de APIs.

¿Por qué?

Porque han entendido algo que muchos aún no ven:

Aunque parezca un chiste, una tarea que tome ‘solo 5 minutos diarios’, toma también 35 minutos a la semana, 2.3 horas al mes, y 28 horas al año.

Como desarrolladores, deberíamos enfocarnos en las tareas que aportan más valor al producto, en lugar de repetir procesos manuales.

Además, ¿a quién no le gusta automatizar cosas? 🤷‍♂️

Esto le pasó a un desarrollador.

No un principiante, no.

Alguien con experiencia.

Quiso optimizar su aplicación.

Lo de las cookies es cosa del pasado.

Ahora Amazon ha desarrollado una API que puede predecir lo que vas a comprar antes de que lo compres.

Sí, como lo lees.

No es ciencia ficción.

Mira.

Hace unos días, un ingeniero de Google cometió un error que dejó a miles de desarrolladores en jaque.

Pensó que estaba limpiando código muerto.

Borró una API que, según él, “ya no usaba nadie”.

Ojo a esto.

Una fintech española, Embat, acaba de hacer una jugada que lo cambia todo: ha comprado Necto, una empresa de EE.UU. especializada en APIs bancarias.

¿Qué significa esto?

Que ahora pueden conectar con más de 15.000 bancos y operar en 70 divisas. Que los pagos en tiempo real ya no son cosa del futuro, sino del presente. Que la gestión financiera está dando un giro radical.

La semana pasada, en medio de un café frío y una lista interminable de tareas, recibí un mensaje de un amigo:

— Tío, mi aplicación va más lenta que un lunes sin café. La gente se va antes de que cargue la respuesta. Estoy perdiendo clientes.

No es el primero que me lo dice. Y no será el último.

Vivimos en un mundo donde la gente se desespera si un vídeo tarda más de dos segundos en cargar.

Como toda pieza de software, las APIs también deben documentarse, y para ello claramente existe un estándar 😏.

En este episodio, te enseñaremos cómo pasar de no tener absolutamente ningún tipo de documentación, a tener algo como esto:

En serio.

Podría contarte una historia.
Podría darte contexto.
Podría adornarlo todo con una anécdota interesante.

Pero mira…

Es viernes.

Pocas cosas hacen que un desarrollador piense en dejarlo todo y vender cocos en la playa.

Una API que no funciona es una de ellas.

Me pasó hace un tiempo.

Todo el sistema dependía de una API externa. Un día, dejó de responder.

Hace unos días, vi algo que me dejó pensando.

Un desarrollador contaba en un foro cómo había pasado tres semanas enteras integrando diferentes blockchains para un proyecto.

Tres. Semanas.

API tras API.
Errores sin explicación.
Documentación contradictoria.

Mira.

Hace unas semanas, me sentí como un niño en una tienda de caramelos.

Había encontrado la API perfecta para lo que estaba construyendo. Rápida, potente, con IA integrada y, encima, baratísima.

Demasiado bueno para ser verdad, ¿no?

Mira esto.

Una multinacional con oficinas de cristal, empleados con su Mac último modelo y café de especialidad en cada esquina.

Un ejército de expertos en ciberseguridad, firewalls de última generación y auditorías constantes.

Nada podía salir mal.

Si crees que ya lo has visto todo en IA, prepárate.

Porque lo que acaba de soltar OpenAI no es una simple actualización.

No es un parche.

No es una mejora menor.

Node es una de las tecnologías que están ‘mandando la parada’ hoy en día.

Se trata de un entorno de ejecución (o runtime) para JavaScript basado en el motor V8 de Chrome.

Antes de que Node existiera, no podíamos ejecutar JavaScript por fuera del navegador, pero gracias a que este incorpora el intérprete de JavaScript, entonces ahora podemos utilizarlo del lado servidor o incluso para IoT (Internet de las Cosas).

Una de las cosas que más ha llamado la atención de este runtime es su rendimiento, ya que:

Hace unos años, trabajaba en un proyecto que pintaba increíble.

Tenía todo listo: una idea brillante, un equipo motivado y un plan de desarrollo que sonaba perfecto en papel.

Hasta que nos encontramos con el muro.

Queríamos integrar varias APIs de telecomunicaciones. Acceder a datos de red, mejorar la experiencia del usuario, hacer magia con la conectividad.

Hace un par de días, me pasó algo curioso.

Estaba revisando noticias, como siempre. Que si una empresa compró a otra. Que si el mercado sube, que si baja. Lo típico.

Y, de repente, BOOM.

Una noticia me hizo detenerme en seco.

Mira,

Hace unos días, mientras navegaba por las últimas novedades tecnológicas, me topé con un dato que me dejó helado: los ataques a APIs han aumentado un 681% en el último año.

Sí, has leído bien. 681%.

Y no, no es solo un número aterrador que alguien soltó por ahí. Es la realidad.

Mira,

Veo que has decidido darte de baja de nuestra newsletter. Quizás pienses que ya lo sabes todo sobre APIs y DevOps, o tal vez prefieras enterarte de las novedades cuando ya son agua pasada.

Pero, por si acaso te queda un atisbo de curiosidad, déjame contarte algo que está revolucionando el sector:

Según un reciente artículo de DevPro Journal, se espera que las APIs impulsen un aumento en la adopción de DevSecOps en 2025 y más allá. Además, las tendencias apuntan a que las plataformas low-code y no-code están aquí para quedarse, transformando la manera en que desarrollamos software.

Mira,

Vamos a dejarnos de cuentos.

Google ya no es lo que era. La gente está dejando de buscar para empezar a preguntar.
Y la IA responde sin anuncios, sin clics innecesarios, sin perder el tiempo.

Bing se ha aliado con ChatGPT y Google está en pánico.
Porque las búsquedas, tal y como las conocemos, están muriendo.

No sé si te enteraste, pero esta semana Spotify ha metido tijera en su API.

Han restringido el acceso a ciertos datos musicales y ahora muchas aplicaciones que dependían de ellos se han quedado en el aire. Lo hicieron sin avisar demasiado y más de un desarrollador está tirándose de los pelos.

Si trabajas con APIs, esto es un recordatorio brutal de que depender de una API sin tener un plan B es jugar con fuego.

Si quieres aprender cómo gestionar y optimizar APIs sin que te pille el toro, en mi plataforma te explico cómo hacerlo con Mulesoft.

Empezamos el año bien fuerte en la industria 😅.

La llegada de DeepSeek definitivamente se ha convertido en un hito que marcará un antes y un después en el desarrollo de los LLMs.

De seguro ya habrás visto este famoso gráfico que nos permite comparar el rendimiento de DeepSeek-R1 con otros modelos, estando muy a la par. Pero lo más asombroso, es lo barato que les salió a los chinos.

Mira ,

Voy al grano.

Estoy a punto de empezar a enviar correos con noticias sobre APIs, totalmente gratis.

Cosas que te interesan. Sin paja. Sin enlaces a artículos de 15 minutos que nunca lees. Solo lo esencial, en un correo corto y claro.

Cuando tenemos una arquitectura de microservicios, por lo general mediamos su comunicación usando nuestra vieja confiable: HTTP REST, y transmitimos los datos en un formato JSON.

Pero esa no es la única manera que tenemos de comunicar microservicios. Hoy hablaremos sobre una de las formas más eficientes que hay: gRPC.

Antes que nada, hay que aclarar que gRPC no es un reemplazo de HTTP, tampoco es un protocolo.

gRPC es en realidad un framework que facilita la comunicación entre microservicios, gracias a las tecnologías que lo componen.

¿Has oído mencionar a la programación dinámica (DP) en algún lado?

Quién pensaría que ella es la solución a muchos de los problemas que parecen no tenerla. Si la aprendieras, te abriría la mente a un mundo de posibilidades que aún no te imaginas. Pero no te juzgo, pues es un tema misterioso e incomprendido por muchos.

Suficiente clickbait…

Pero lo que acabas de leer es parcialmente cierto: la programación dinámica es una herramienta superpoderosa si aprendes a manejarla.

Uno de los conceptos que todo programador experto debería conocer es el manejo de operaciones concurrentes.

Aunque pueda sonar complejo, empezaremos desde 0, e incluso, dividiremos el tema en varios episodios, pues queremos que termines con una amplia compresión de lo que la concurrencia es y cómo se aplica.

Recuerda que si tienes alguna duda, siempre puedes escribirnos un DM a Instagram y con gusto la solucionaremos 🤗.

Para empezar, remontémonos a la CPU.

En muchas ocasiones escuchamos voces externas diciéndonos que no deberíamos ‘sobrecomplicar’ nuestro sistema.

Al mismo tiempo, es normal que nos sintamos bombardeados con una cantidad de soluciones que prometen ser perfectas al asegurarnos mantenibilidad, flexibilidad, escalabilidad, calidad (…y todo lo demás que termine en ‘idad’).

Incluso, en Ingeniero Binario solemos compartir muchos patrones, principios, marcos de trabajo y otras prácticas que muchas veces se aplican cuando no son necesarias.

Hoy discutiremos algunas cosas que debes entender acerca de la sobreingeniería para saber cuándo está bien —o no— pasarse de la raya.

, estamos emocionados de que ahora hagas parte de nuestra newsletter.

A través de este medio, todos los sábados, entregamos conocimiento que te ayudará a elevar tu carrera de una manera inigualable.

✨ Recuerda que las pequeñas acciones traen consigo grandes resultados en el futuro, y eso es lo que hace especial a nuestra newsletter.

Como un regalo por confiar en nosotros, te anexamos 3 episodios anteriores que te pueden ser de gran utilidad:

¡Feliz año 2025! 🥳 Esperamos que estés tan emocionado como nosotros por seguir elevando nuestras habilidades ingenieriles y creando el futuro.

Hoy vamos a tratar un tema bien importante a la hora de diseñar sistemas distribuidos; se trata del teorema de CAP, también llamado teorema de Bewer.

Recordemos que un sistema distribuido es una colección de computadoras independientes que funcionan como un único sistema cohesivo para el usuario final.

Un claro ejemplo de esto son los microservicios.

Pero antes de ahondar en qué es lo que postula el teorema, hablemos sobre por qué se llama así.

¡Hola chicxs! Hemos llegado a nuestra última newsletter del año 😃, así que les dejamos un mensaje especial al final de este episodio.

Cuando diseñamos una base de datos, uno de los objetivos principales es garantizar que sea eficiente, fácil de mantener y libre de inconsistencias. ¿Verdad?

Para lograr esto, podemos emplear muchas prácticas, entre ellas la normalización.

La normalización es una técnica que nos da algunos estándares, llamados ‘formas normales’, con los cuales podemos minimizar la redundancia de datos y así garantizar la integridad de nuestra información.

,

Esperamos que estés disfrutando del contenido de nuestra newsletter tanto como nosotros disfrutamos creándolo para ti.

Necesitamos una pequeña ayudita tuya; nos encantaría conocer mejor tus intereses y necesidades para seguir mejorando y ofreciendo contenido que realmente te apasione y te sea útil.

Por eso, te pedimos amablemente que dediques unos minutos para completar una breve encuesta, con lo que haremos tu experiencia como suscriptor sea aún más valiosa ✨.

¿Qué tal chic@s?

En el episodio de hoy discutiremos sobre el logging, una práctica común de monitoreo que permite registrar información relevante sobre el comportamiento de un sistema para facilitar su análisis y depuración.

El logging tiene su ciencia

Quien pensaría que decidir qué registros mostrar es una de las tareas más desafiantes en el desarrollo de software.

¡Hola! Nos alegra que tenerte por acá, ya se siente la Navidad, ¿no? 🎅

Pensar que tu software no es vulnerable a ningún ataque es un craso error.

El software hoy en día es más complejo que nunca, y la cantidad de elementos que intervienen en él es lo que lo hace vulnerable a cualquier tipo de ataque.

Solo imagina: si las organizaciones más grandes y con mayores recursos enfrentan violaciones de seguridad, ahora imagínate una empresa ‘común y corriente’.

Existen muchas metodologías para desarrollar software; de seguro habrás oído mencionar el enfoque en cascada o agile debido a que son las más comunes.

Pero, en realidad, el software tiene un solo ciclo de vida, lo que pasa es que hay muchas formas de implementarlo.

Seguir el modelo estándar para desarrollar software, nos asegura que estamos entregando software de calidad al pasar por todas las etapas requeridas.

En este episodio, revisaremos paso a paso lo que debes hacer en cada etapa, además de las diferentes metodologías que implementan dicho modelo, junto con las particularidades de cada una.

Se ha llegado el fin de semana, y con él nos acercamos al último mes del año. ¿Ya se siente Navidad o no? 🎄🎅

Seguramente ya hayas utilizado SSH anteriormente, por lo que sabrás que es una herramienta útil para conectarse a servidores remotos.

Pero la cuestión es que pocas veces le sacamos el máximo provecho, pues desconocemos la cantidad de usos que tiene.

Antes que nada, repasemos un poco cómo es que funciona y luego miremos qué otras cosas es capaz de hacer.

¿Qué tal ha ido tu semana?

Independientemente de cómo haya sido, ahora ha venido el inge a arreglártela 😉. Hoy vamos a enfocarnos más en hablar sobre herramientas.

Y es que, muchas veces necesitamos de SaaS como Firebase, Heroku, Airtable, pero hay que recordar que estos son de pago y siempre viene bien ahorrar un poco —o incluso tener mayor control y privacidad sobre la información que allí almacenamos—, y pues qué mejor que hacerlo apoyando a la comunidad de código abierto.

Ahora piensa: ¿Qué tal si pudiera servir esas mismas plataformas por mi propio servidor?, algo así como tener el mapa de GTA todito para ti solo 😅.

¡Qué tal! Acá estamos de nuevo con otro episodio de la serie de patrones de diseño.

Esta vez, continuaremos con la categoría de patrones comportamentales que ya habíamos iniciado anteriormente.

¡Vamos al rollo! 🔥

En este episodio encontrarás:

¡Qué gusto tenerte otro sábado por acá! ☕

Estábamos indecisos sobre si enviar otro episodio de la serie de patrones de diseño, o resumir todos los patrones arquitectónicos que existen en una imagen. Te darás cuenta por el título que nos fuimos por la segunda.

¡Pero tranqui! La semana que viene tendremos el próximo episodio de patrones de diseño, en el que hablaremos sobre los patrones de tipo comportamental que nos faltan 🤗.

Hoy traemos un tema similar, pues también hablaremos de patrones, pero en este caso de arquitectura.

Muchas personas aún no entienden el gran potencial que tiene Kafka, así que en este episodio desglosaremos todos los conceptos que necesitas para utilizarlo, además de darte una perspectiva más amplia de lo que puedes hacer con él.

💁‍♂️ Te recomendamos leer hasta el final, pues iremos desde lo más básico hasta algunos conceptos más avanzados

Podríamos imaginar a Kafka como una cola de mensajes (o también ‘message queue‘), pero Kafka no es exactamente una de estas.

Realmente, Kafka es un ✨ sistema de transmisión de datos en tiempo real ✨. Sí.

Llegó el sábado, y con él, un nuevo correo de Ingeniero Binario. Hoy continuaremos con la serie de patrones de diseño, esta vez con los de tipo comportamental.

Esta categoría es la que más patrones tiene, por lo tanto, trataremos algunos hoy y, en el próximo episodio de la serie, explicaremos los que queden faltando.

¡Así que, prepárate tu bebida favorita y empecemos de una vez! ☕

En este episodio encontrarás:

¿Qué tal estuvo tu semana? Sin importar cómo haya sido, es fin de semana y es hora de recargar 🔋, y qué mejor que una dosis de software para ello.

En esta ocasión, hablaremos sobre la diferencia entre dos componentes esenciales en la arquitectura de un sistema: el API Gateway y el Load Balancer.

Si estas palabritas aún no te suenan, no te preocupes. Repasaremos lo que cada uno hace y te daremos algunos datos que te servirán cuando los uses. ¡Prepárate un café y empecemos!

API Gateway

¡Empezando semana con toda la actitud! 🌞

Esperando que muy bien, estamos nuevamente aquí con un episodio de la serie de patrones de diseño. Esta vez, con los patrones estructurales.

Con ‘estructurales’, nos referimos a los patrones que organizan las relaciones entre clases y objetos, con el fin de facilitar su composición y reutilización.

Quizás no los cubramos todos en este correo, con el fin de hacerlo digerible para ti. Aun así, los que nos queden faltando los trataremos en el próximo de la serie, ¿vale? 😉.

¡Empezando el finde con toda la actitud! 🔥

Hoy es un día especial porque empezamos una nueva serie de episodios sobre patrones de diseño. Hablaremos sobre las 23 soluciones probadas a problemas comunes en la programación, que fueron propuestas por el “Gang of Four”, un equipo de 4 informáticos reconocidos.

Como sería muy extenso explicarlos todos en un solo episodio, entonces los trataremos por categoría: los creacionales, los estructurales y los comportamentales; evacuaremos una categoría por cada episodio.

El día de hoy, hablaremos entonces sobre los patrones creacionales, es decir, aquellos que abordan la manera en que se crean los objetos en un sistema.

¡Hey! Que bueno tenerte por acá.

Este fin de semana vamos a hablar sobre un tema de especial importancia en el contexto de los sistemas distribuidos, pero antes, te recomendamos que veas este breve post que te dará algunos conceptos previos para lo que trataremos acá.

Generalmente, un sistema distribuido se compone de varios nodos, los cuales pueden leer/escribir datos en un medio de persistencia (como una base de datos o un almacenamiento en caché). Entonces, decimos que un software es consistente cuando todos los nodos tienen la misma versión de los datos.

Un software sin consistencia, al no poder garantizar la uniformidad de los datos, puede dar lugar a operaciones, decisiones y acciones incorrectas.

¿Te has puesto a pensar lo engorroso que es diagramar software? 🤔

Claro, es fácil plasmar una idea con nuestros propios garabatos; dibujamos por aquí, dibujamos por allá y conectamos según va fluyendo.

El problema de hacer esto es que la falta de notaciones y estándares conduce a problemas en el desarrollo, que van desde pequeñas confusiones que se pueden solucionar en minutos, hasta errores abismales que pueden cambiar el rumbo del proyecto.

Y es que, no podemos representar el software con un solo diagrama por dos razones:

¡Hey! Qué gusto tenerte por acá 👋

Tú y yo sabemos que Docker tiene una tarea muy sencilla: empaquetar una aplicación con todo lo que necesita para poder ejecutarse, con el fin de que sea portable. A este proceso de empaquetado, es a lo que conocemos como la ‘compilación’ o ‘build’ de la imagen.

A medida que una aplicación crece, el tiempo de compilación puede verse incrementado. Tanto así, que puede afectar nuestra productividad y volverse muy ineficiente.

Así que te presentaremos algunos trucos que muy pocos desarrolladores conocen para reducir estos tiempos, y que te van a ser de tanta utilidad que nos lo vas a agradecer 😉.

¿Qué tal va la semana 🤗? Es día de aprender algo nuevo con la newsletter de Ingeniero Binario.

Dentro del desarrollo de software nos encontramos con distintos patrones, que son soluciones ya probadas para problemas comunes que nos pueden brindar mayor seguridad, resiliencia o incluso una alta disponibilidad.

Ahora bien, en sistemas distribuidos uno de los mayores problemas a los que nos enfrentamos es la red, dado que desconocemos si el mensaje será entregado correctamente, o si el nodo receptor sí podrá procesarlo (o se quedará colgado).

Solo imagina un escenario en el que hayas tenido que hacer un trámite importante por internet, y por alguna razón la página no funcionaba.

¡Hey! Bienvenido a la newsletter de Ingeniero Binario, un gusto tenerte por acá 🎉.

Antes de empezar, te recordamos que puedes acceder a TODOS los episodios que hemos enviado antes de este accediendo acá, esperamos que los disfrutes.

Hace unos cuantos días les pedimos a algunos de ustedes que nos contaran un poco más sobre sus intereses, y uno de los temas que coronó fue DevOps.

Por eso, hoy vamos a compartirles algunos ‘life hacks’ que les ahorrarán mucho tiempo y errores. Si no trabajas en DevOps, igualmente estos tips te servirán de una u otra manera. Confía en mí 🙂.

¿Qué tal todo? Esperamos que estés teniendo una excelente semana 😃. En el episodio de hoy, trataremos lo pactado en uno de nuestros últimos posts de Instagram: el particionamiento de discos.

Aunque este concepto es aplicable a cualquier sistema operativo, nos centraremos en Linux ya que, usualmente, debes preocuparte de esto cuando configuras servidores y/o máquinas virtuales.

Si no tienes conocimientos previos, no te preocupes, cuando termines este episodio ya serás un(a) experto/a 🦸‍♂️.

¡Qué bueno tenerte por acá! Estamos nuevamente con otra edición de nuestra serie de preguntas y respuestas para entrevistas laborales.

En esta ocasión, nos enfocaremos en preguntas relacionadas con el ciclo de desarrollo del software y DevOps. Estamos cerca de culminar esta serie, siendo esta la parte 3/4. ¡Esperamos que logres aprender mucho 🤓!

Ciclo de desarrollo del software (SDLC)