Descifrando el código de la nube abierta

Ingrid Burrington quería caminar dentro de una nube. Pero no simplemente “una nube”. La nube.

No sé cómo se ve Internet, no creo que se vea así. Simplemente quería averiguar.

Ingrid es periodista. Por una serie de artículos que escribió para The Atlantic, logró entrar en uno de los centros de datos, donde se materializa más y más nuestra vida en línea.

Lo que descubrió no fue algo suave y blanco, sino bastante físico. Primero, le toman una foto para una etiqueta de identificación. Luego, pasa por los controles de seguridad y firma un acuerdo de no divulgación. Finalmente, consigue ver las máquinas. Las salas de servidores son básicamente almacenes… Y hay algo hermoso en ese aspecto de almacén, porque todo está allí expuesto.

Racks de servidores sin uso, y por arriba de todos ellos, los cables que conectan con el mundo, corriendo por guías en el techo. Hay una especie de luz azul, como de tron. Pero principalmente, hay filas y filas de servidores muy hambrientos.

Los centros de datos consumen más energía al año que todo el Reino Unido. Y eso significa que generan cantidades impresionantes de calor, por eso cuando Ingrid mira alrededor...

Es un edificio diseñado principalmente para tener el sistema de climatización más perfecto que se pueda imaginar.

Ingrid descubrió que todo en el centro de datos es pragmático, así que, sí, son solo un montón de máquinas y algunos ventiladores en muchos terrenos baratos que usan un montón de agua barata para mantenerlo fresco.

No se parece mucho a lo que representa la palabra “nube”, pero, por otro lado, nuestra vida, nuestro trabajo, nuestras voces rebotan en ese almacén de máquinas.

Sí, puede ser un poco surrealista porque no es como si supiera que esa máquina tiene el correo electrónico de alguien y en esa otra máquina hay otra cosa. Pero simplemente darme cuenta de cuánto sucede en torno a mí de un modo implícito, que no puedo ver, pero que puedo escuchar en el sentido del zumbido de las máquinas y el mayor uso del espacio.

Hay algo un poco inquietante al respecto y quiero decir, hay una especie de asombro industrial...

Es muy importante recordar que estos edificios realmente están allí, en algún lugar, emitiendo un zumbido detrás de la cerca.

Porque esto es lo que sucede, cuando hablamos de almacenar cosas en la nube o construir una aplicación en la nube, a veces nos engañamos pensando que es como una nube en el cielo, algo que nadie puede tocar. Pero la realidad es que es exactamente lo opuesto, y una vez que recordamos dónde vive la nube, podemos comenzar a hablar de quién es el dueño de la nube. ¿Quién controla todos esos servidores y cables y ventiladores?

Y ¿cómo cambia eso la forma en que los desarrolladores construyen el futuro? Porque en la ciudad de la nube vivimos todos juntos.

Esto es Command Line Heroes en español. Un podcast original de Red Hat, episodio seis: Decifrando el código de la nube abierta

La nube no existe, es simplemente la computadora de otra persona.

Chris Watterston es un diseñador que se molestó ante la confusión respecto a la nube.

Esa palabra había difuminado la idea de los centros de datos, como el que visitó Ingrid. Cuando puso ese eslogan en una calcomanía, se hizo famoso en Internet. Esa frase “There is no cloud, it's just someone else's computer”, ahora está en camisetas, sudaderas, tazas, carteles, portavasos y en más de una presentación.

La gente todavía usa la nube como si subieran algo al cielo, las personas que no entienden bien qué es, aún pueden interpretarlo mal y no comprender que sus datos pasan por cables de cobre o fibras y llegan a un dispositivo de almacenamiento que, en realidad, lo gestiona otra persona y pertenece a otra persona. Y esto, obviamente, para algunas personas, si tienen contenido privado que desean ocultar, podría ser muy atemorizante.

Así que piensa en la calcomanía de Chris la próxima vez que vayas a subir algo a la nube. ¿A dónde lo estás subiéndo realmente? Lo mismo sucede con trabajar en una aplicación, aunque se habla mucho de la informática Serverless, realmente no existe tal cosa. Es el servidor de otra persona, la computadora de otra persona. En cierto sentido, esta historia trata sobre la madurez. Durante toda la temporada, hemos estado rastreando la evolución del código abierto.

Desde sus orígenes rebeldes con el movimiento del software gratuito y el surgimiento de Linux, hasta la actualidad, cuando las herramientas y los métodos de código abierto nos han llevado lejos de casa hasta la nube. Piénsalo de esta manera, cuando una persona encuentra un apartamento para alquilar, va a firmar un contrato, mudarse y hacerlo propio. Cuando los desarrolladores buscan un proveedor de nube, tienen que hacer lo mismo. Ese es el momento en el que estamos ahora, hay un mundo entero de desarrolladores que está haciendo su transición a una serie de nubes y comenzando a comprender qué dice realmente el contrato de alquiler.

Solo para saber: ¿por qué estamos tan apresurados en subirnos a una nube en primer lugar?

Los desarrolladores no quieren tener que gestionar la infraestructura que ejecuta sus aplicaciones.

He aquí Brandon Butler, Senior Editor de Network World, quien ha estado ocupándose del cloud computing por años.

Quieren desarrollar aplicaciones y quieren distribuir esas aplicaciones, y quieren que esas aplicaciones simplemente funcionen. Y cada vez más, vemos cosas como informática serverless, y functions-as-a-service, contenedores y plataformas de gestión de contenedores, como Kubernetes.

Escucha el episodio cinco, por cierto, para un resumen sobre los contenedores y Kubernetes.

Todas estas cosas ayudan a abstraer la infraestructura subyacente en la que deben ejecutarse las aplicaciones. Y esa será una tendencia que vamos a seguir viendo desarrollarse en el futuro.

Una gran parte de esa atracción se resume en la palabra hiperescala. Si la nube te proporciona toda la infraestructura, puedes tomar una startup y ampliarla, o reducirla, tan rápido como quieras. Ya no estás construyendo tu propia infraestructura, simplemente alquilas tanto espacio en la nube como necesites. Brandon explica qué significa hiperescala para una startup.

Todo este modelo de usar la nube pública para el desarrollo de aplicaciones ha sido un avance enorme para los desarrolladores de aplicaciones. Se ha creado una nueva variedad de startups y empresas que surgieron poco a poco y que se han convertido en importantes empresas que cotizan en bolsa Si piensas en una compañía como Netflix que ejecuta gran parte de la infraestructura de su back-end en la nube de Amazon, y otros proveedores de nube también, ellos llegaron a ser lo que son gracias al uso de la nube.

Entonces, el impacto que la nube ha tenido en los desarrolladores no puede subestimarse. Ha sido el principal cambio en el desarrollo de aplicaciones durante la última década.

Nick Bush, un sysadmin de Meadowbrook Insurance recuerda qué complicados eran los cambios a la infraestructura antes de la nube.

Antes, si alguien proponía una idea para hacer un determinado proyecto, le decíamos: “Se necesitaría hardware para hacer eso”. Entonces la persona preguntaba: “Bueno, ¿cómo lo hacemos?” Así que siempre estábamos limitados por la memoria, y las máquinas virtuales en general era la parte difícil. Y estábamos limitados por la cantidad de máquinas virtuales que podíamos crear en un determinado momento. Así que teníamos que obtener una cotización para procesadores nuevos, memoria nueva, hardware nuevo, $5000 de espacio adicional, y cosas como esas. Y una vez que teníamos esos presupuestos de un par de proveedores diferentes, pasaba a la gerencia y ellos se tomaban un tiempo. Era un proceso largo, interminable, solo para obtener el hardware.

Y sin mencionar construir las máquinas virtuales y activarlas, probarlas y cosas como esas. Entonces, lo que quiero decir es que había varios meses de trabajo en la interfaz de usuario mientras que ahora definitivamente podemos lograrlo en un par de horas. Lo creamos, y lo entregamos al día siguiente. Así que hay una gran diferencia en los plazos de entrega.

Entre escalabilidad, velocidad y precio, la nube puede parecer muy tentadora. Para volver a la analogía del alquiler de un apartamento, las opciones de nube pueden verse como obtener un mayordomo y un chofer sin costo adicional. Es difícil decir que no, y hoy hay cuatro proveedores de nube muy ambiciosos tratando de convencernos. Todos quieren ser tu nuevo arrendador en la ciudad de la nube. Pero, aguarda, todos los que alguna vez alquilaron saben que no es lo mismo que comprar. No puedes simplemente derribar una pared o instalar un nuevo jacuzzi. Tienes que pasar por el arrendador.

De cierta forma, ¿podríamos quedarnos atascados si nos comprometemos con una sola compañía propietaria? Brandon Butler.

Cuando contrastas a un proveedor de nubes propietario, existen diferentes maneras de utilizarlo. Puedes usarlo de una manera que acepte estándares de código abierto y plataformas de código abierto y ejecutar esas plataformas de código abierto sobre una nube que incluso puede ser exclusiva, o puedes usar herramientas nativas de esos proveedores que quizás no son de código abierto, pero que están mejor integradas a la plataforma de la nube pública.

Entonces, es un gran compromiso que los usuarios finales tienen que considerar. ¿Quiero utilizar herramientas nativas del proveedor de nube que pueden estar mejor integradas a los servicios que ofrece este proveedor y otros servicios que podría querer utilizar también en esa nube, o quiero priorizar el uso

de una plataforma de código abierto que me dará más libertad para ejecutar todo eso en mi propia infraestructura o en la de otro proveedor de nube?

A medida que las nubes siguen creciendo y los cuatro grandes proveedores de nube se pelean por el dominio, los desarrolladores tenemos una opción. ¿Renunciamos a nuestra independencia y dependemos de que un único proveedor de nube proteja nuestro trabajo o podríamos tomar otro camino, maximizar la escalabilidad de la nube y seguir manteniendo nuestra independencia?

En otras palabras, ¿podemos firmar un contrato de alquiler que diga: “No hay problema. Haz lo que quieras con el lugar. Derriba una pared. Haz como si fuera tu casa?”

Pero, ¿cuál es el problema de renunciar a un poco de independencia? Si eres desarrollador, el problema podría no ser muy obvio. Eso es porque, en gran parte, son los equipos de operaciones los que nos han estado animando a avanzar con cautela. Notaron las cuestiones fundamentales. Él es Major Hayden. Es un ingeniero de software principal en Red Hat.

Los desarrolladores verán con el tiempo que quizás tienen diferentes necesidades: un determinado tipo de almacenamiento especializado, o quizás una máquina virtual de cierto tamaño o un tipo de prestación que el proveedor de nube no ofrece, y también hay ciertas cosas que debes mirar y que los desarrolladores no siempre son los primeros en ver, donde debes hacer un análisis de costo-beneficio para comprender y decir:

“Bien, tengo mucha flexibilidad en la nube pública, pero ¿cuánto me cuesta eso realmente?”

Major señala otro problema, uno que va más allá de las cuestiones prácticas y refleja mucho lo que creen los desarrolladores como yo. Estoy hablando del modelo Open Source. Incluso si los proveedores de nube te permitieran usar tus herramientas de código abierto, ellos no usan código abierto.

Bueno, el código abierto en la nube es un tema interesante de abordar porque hay muchas tecnologías de código abierto que te permiten aprovechar una nube pública, pero no todas las nubes públicas ofrecen su infraestructura como código abierto. Por ejemplo, si tomas Amazon, no puedes ver realmente lo que están utilizando para crear máquinas virtuales o desarrollar otros servicios, entonces, si quisieras hacer un ajuste para eso, en realidad no podrías hacerlo, o si quisieras ver detrás de escenas y comprender mejor cómo funciona, eso sería difícil.

Si escuchaste nuestro episodio sobre DevOps, sabes que hay muchos beneficios al derribar el muro entre desarrolladores y operaciones. Te presento al sysadmin Nick Bush. En su equipo las personas están listas para saltar a la nube. Los desarrolladores están cansados de estar atascados con hardware físico que queda viejo cada cinco años, y a todos les gusta la idea de expandirse tan rápido como quieran, pero Nick quiere señalar cuestiones que los desarrolladores podrían no estar considerando.

Sí. Quiero decir, hay una latencia inherente. O sea, es un servidor de bases de datos en Montana, Estados Unidos, en comparación con mi conexión de 10 gigas aquí a la vuelta, así que, hacer llamadas locales a la base de datos llevará más tiempo. El camino es más largo, y hay otras cuestiones de seguridad por las que no teníamos que preocuparnos en las instalaciones físicas. Aquí, teníamos el control de nuestro hardware y ese tipo de cosas. Una vez que estás en la nube, debes pensar en las otras conexiones que entran en juego.

Tienes que preocuparte por la seguridad, creo, un poco más y es una cuestión de precio. Cada mes, quieres una máquina virtual rápida, que ocupa espacio de almacenamiento. Hay un costo por gigabyte transferido y almacenado, cuando antes hacíamos una compra única y lo teníamos allí, y podíamos almacenarlo, incluso usarlo. No teníamos que pagar más dinero, siempre y cuando tuviéramos espacio para guardarlo.

Para que conste, Nick cree que las ventajas superan las desventajas. Pero simplemente no quiere que finjamos que es un sistema perfecto. ¿Qué sucede si tu proveedor sufre un corte de servicio y quieres volver a implementar una aplicación en otra nube? ¿O si usar nubes distintas para diferentes cosas representa una ventaja en precios? Muchos de los problemas que plantean los amigos de Ops pueden resumirse en una sola idea: dependencia de un proveedor. Probablemente estés familiarizado con este término.

Es el concepto de que construir en el servidor de otra persona te ata cada vez más a su plataforma. Te genera dependencia. De repente, recibes actualizaciones a la fuerza, hay cambios de costos y nuevos límites que tú no habrías elegido. Entiendes la idea.

Si pensamos como DevOps, podemos trabajar juntos para anticipar la dependencia y planificar, pero cuando estamos sumergidos en nuestro propio código, a veces nos olvidamos de mirar el panorama completo

¿Qué pasa si encontramos la combinación correcta, trabajar tanto en la nube pública como en la privada? La solución podría ser una nube híbrida, con lo mejor de las dos. Llamé a Bridget Kromhout para conocer su perspectiva. Ella es Principal Cloud Developer Advocate en Microsoft, y conoce estas cuestiones muy bien.

Bueno, si pensamos en una solución híbrida que tenga un poco de la nube pública, pero también parte de la nube privada, ¿es ese el equilibrio perfecto entre las dos? ¿Es esa la solución ideal para los desarrolladores? Si es híbrida, puedo hacer lo que quiera y usar las herramientas que quiero, pero aun así obtener algunos de los beneficios de los grandes proveedores de nube pública.

Sí, absolutamente. Por ejemplo, tengo amigos que trabajan en investigación de informática de alto rendimiento en empresas manufactureras, y tienen todo tipo de información súper secreta, acuerdos de confidencialidad, cosas que prefieren no subir a la nube pública, y quizás trabajarán en sus centros de datos en esas cargas de trabajo, procesando todos esos números para los clientes, los números de investigación, y luego pueden tener otras... Tienen otras cargas de trabajo que sí prefieren subir a la nube pública, pero creo que esto es una cuestión de...

Y a veces también hay preguntas de si la nube pública es idónea para algunas de las cargas de trabajo, por ejemplo, si planeas utilizar interconexiones InfiniBand entre tus notas, ¿cuánto de eso podrás aprovisionar en la nube pública?

Pero esta no es necesariamente la solución perfecta. Bridget cree que las nubes híbridas traen sus propias complicaciones.

El problema con lo híbrido es que a veces las personas se engañan y piensan que pueden tomar algo que realmente no estaba funcionando, por ejemplo, si sus viejos procesos tenían un tiempo de espera de dos semanas nada más que para obtener una sola máquina virtual, tienen ese escenario que no funcionaba bien, y luego tienen un grupo de personas que han comenzado a llevar sus tarjetas de crédito a los proveedores de nube pública porque están frustrados, e intentan unir esas cosas, se producen problemas con la procedencia y latencia de los datos, conjuntos de datos desincronizados, muchas cosas que pueden salir mal. Creo que si trabajas con tu proveedor de nube, puedes agregar algunas de las cosas de conexión directa disponibles y lograr una mejor sincronización, eso puede ayudar.

Sí. Entonces, cuando hablamos de la nube en el contexto de código abierto, tengo la sensación de que a la mayoría de nosotros, como desarrolladores, realmente nos gusta el código abierto, especialmente si estás escuchando este podcast.

¿Cierto? Quieres que todo sea abierto y transparente, y compartir el código y eso, pero siento que cuando hablamos de la nube, pues no se siente que tenga su propio código base, no se siente como un proyecto en sí, sino que es el entorno, es eso que podemos usar como ayuda para ejecutar nuestro código, ¿los desarrolladores son tan insistentes en esa parte de que tenga código abierto y sea transparente, con el énfasis que ponemos a veces cuando se trata de nuestros proyectos y nuestra base de códigos?

Me parece una pregunta muy razonable, y creo que también tiene que ver con la parte de la pila por la que elijes preocuparte, porque si lo piensas, ¿cuánto acceso e información tienes sobre los chips?

Sí, eso es cierto. Puede ser.

Están allí, con un poco de silicio y algunos secretos. No es que están revelándotelos.

Sí, silicio y secretos. Es un buen nombre para un podcast, por cierto.

¿Cierto? Tal vez la pregunta no es si todo es abierto, sino si todo lo que necesitas que sea abierto lo es y, por supuesto, si tu proveedor será transparente contigo cuando las cosas no funcionen exactamente como deberían, porque, con suerte, lo será.

Entiendo la perspectiva de Bridget como proveedora de nube pública y tiene un argumento interesante. ¿Qué tan granular debe ser el control de un desarrollador en la nube? ¿Qué es lo que no quieres sacrificar a cambio de algunas de las bondades de la nube pública? Supongamos que una aplicación se está ejecutando en una nube pública, y la escalas o hay nuevos requisitos de cumplimiento y eso hace que tenga más sentido que tu aplicación esté en una nube privada.

Cuando mueves la aplicación de punto a punto, necesitas saber que va a funcionar. Necesitas saber que las cosas están empaquetadas de la misma manera, configuradas de la misma manera. En otras palabras, necesitas saber que siempre es posible pasar de una nube a otra.

¿Cuál es la alternativa? ¿Depender de solo un proveedor de nube? ¿Un proveedor que incluso podría lograr un monopolio total sobre todos los demás? No tener la opción de pasar a un entorno diferente es como intentar programar atado de manos.

Entonces, no queremos quedar atrapados y atascados con una sola nube. Queremos poder pasar de una nube a otra cuando nos convenga. En las palabras inmortales de la leyenda del rock, Queen, tú quieres ser libre. Queremos acceder a esa fantástica escalabilidad que te dan las nubes públicas, pero sin renunciar a las libertades que esperamos cuando usamos herramientas y métodos abiertos.

Y esta es la buena noticia. El trabajo en esas nubes híbridas ya está en marcha. Mike Ferris, vicepresidente de desarrollo corporativo y estrategia de Red Hat da una excelente explicación de cómo las nubes híbridas nos ayudan a mantener el espíritu del código abierto.

El código abierto es realmente la base de casi todas las nubes del mundo y ahora muchas, si no la mayoría, de las infraestructuras de aplicaciones del mundo y las herramientas evolucionan a partir de eso, las capacidades de gestión, todo lo que la gente utiliza para construir y emplear aplicaciones críticas, así como aplicaciones no críticas, todo se basa en el código abierto.

El concepto de híbrido realmente va de la mano con esto: tener la capacidad de usar estas cosas donde sea que estén para aprovechar los mejores conjuntos de funciones en la infraestructura que sea, todo con base en el concepto de que el código abierto

realmente ayuda a definir los estándares que impulsan esta próxima generación de desarrollo mientras continúan sacando provecho de las inversiones que se han realizado en el pasado.

La nube quiere ser abierta. Hemos pasado mucho tiempo esta temporada hablando de los orígenes del código abierto. Incluso se puede argumentar que cierta versión de lo híbrido sería una extensión de esos mismos ideales.

Lo que ha cambiado en las actividades de desarrollo de código abierto a lo largo de las últimas décadas ha sido que mucha más gente se ha involucrado, incluida la gente de Microsoft, IBM.

Están utilizando código abierto para sus ofertas o están construyendo código abierto y retribuyéndolo a la comunidad o alguna combinación de ambas. Esta afluencia de necesidades realmente importantes de clientes a través de esas grandes corporaciones ha ayudado a que el código abierto evolucione de

ser algo que originalmente tenía como objetivo desplazar los entornos Solaris y UNIX a algo que es la base no solo para el uso de la comunidad y los aficionados, sino también para el uso empresarial crítico.

El código abierto está creciendo rápidamente. Ahora tenemos la oportunidad de asegurarnos de recordar de dónde venimos. A medida que nos subimos a la nube, podemos reclamar parte de ella para nosotros mismos y mantener la nube abierta.

Afortunadamente, construir puentes de código abierto entre nubes está volviéndose mucho más fácil gracias al trabajo de plataformas como OpenStack®. Major Hayden, ingeniero principal de software en Red Hat, describe sus orígenes.

Realmente surgió cuando Rackspace y la NASA se reunieron y dijeron: “Miren esta es una nueva forma de construir infraestructura y debemos hacerlo públicamente. Debemos obtener más de estas entradas. Debemos hablar con más personas. Debemos obtener más casos de uso”. OpenStack es un grupo de aplicaciones que funcionan muy bien juntas para crear infraestructura, para gestionar la infraestructura globalmente.

Ya sea que necesites máquinas virtuales complejas, redes complejas, que tengas requisitos de almacenamiento extraños, OpenStack sirve para casi todo eso.

Major está hablando de agregar algo que el código abierto sabe cómo lograr. Adaptabilidad.

Cuando miro OpenStack, lo observo como un conjunto interconectado de aplicaciones de código abierto que te permiten construir la infraestructura que quieres. Si no puedes construir lo que quieres, puedes acudir a la comunidad y hacer cambios. Me encanta la reacción cuando voy a hablar con los clientes y dicen: “Bueno, queremos cambiar esto. Queremos cambiar aquello”. Les decimos: “Bueno, pueden hacerlo”.

¿Cómo nos aseguramos de que ese nivel de adaptabilidad se plasme en la nube del mañana? Al igual que muchos problemas sobre los que hemos hablado en episodios anteriores, todo está en comunidades sólidas. Brandon Butler, Senior Editor de Network World.

Por ejemplo, hemos visto que se creó la Cloud Native Computing Foundation para crear estándares y el uso de contenedores de aplicaciones y Kubernetes. Hemos visto que se creó la OpenStack Foundation para reunir a los usuarios de OpenStack y hablar sobre mejores prácticas cuando se crean nubes de servicio de infraestructura de código abierto.

Las comunidades que sostienen estas comunidades de código abierto son sumamente importantes para desarrollar la próxima tanda de herramientas de código abierto, aprender mejores prácticas para usar estas plataformas de código abierto y alentar a los proveedores de nube pública a adoptar estándares de código abierto.

Una vez que comenzamos a construir esa nube híbrida, abriéndola lo más posible, el potencial realmente parece infinito. Aquí está Major.

Lo que más me entusiasma es simplemente ver más cosas que pueden confluir en nubes diferentes. Por ejemplo, OpenStack proporciona una gran capa base de infraestructura, pero puedes hacer mucho a partir de allí. Creo que a veces diferentes compañías adoptan OpenStack y luego dicen: “Oye, ¿qué hago ahora?” Tengo toda esta libertad. No sé qué hacer”. Es como cuando tienes un refrigerador lleno de comida y dices: “Ay, no sé qué preparar”.

Me encanta tener ese problema. Chris Watterson podría haber estado en lo cierto con lo que nos dijo.

There is no cloud. It's just someone else's' computer.

Pero ese no es el final de la historia. Con nubes híbridas, podemos escribir el siguiente capítulo. La clave para crear una aplicación de nube híbrida probablemente todavía no haya sido descifrada. Gestionar el trabajo en múltiples nubes, esa será una tarea enorme para los héroes de la línea de comandos de hoy.

Habrá un proceso de ensayo y error, pero vale la pena hacerlo, porque lo que sí sabemos es que permanecer abiertos significa que los desarrolladores siempre pueden construir el mundo en el que desean trabajar. Ese tipo de flexibilidad es la manera en que mantendremos el espíritu rebelde que tan bien refleja el código abierto.

En el próximo episodio, el último de la temporada, nos alejamos y hacemos una vista panorámica de cómo se ve el código abierto como fenómeno global, de formas que te sorprenderán. También veremos el futuro del código abierto y cómo los desarrolladores preservan su espíritu rebelde, incluso mientras reinventan su industria.

Command Line Heroes en español es un podcast original de Red Hat.

Para recibir nuevos episodios de forma automática y gratuita, asegúrate de suscribirte al programa. Simplemente busca Command Line Heroes en español en Spotify, Apple Podcasts, Google Podcasts y otros reproductores de podcast. Luego, haz clic en suscribirte para ser el primero en saber cuando hay disponibles nuevos episodios. Gracias por escucharnos y sigan programando.