Show logo
Explora todos los episodios

Tu servidor sin servidor

  |    
Desarrollo y distribución de aplicaciones.
Historia de la tecnología

Command Line Heroes • • Command Line Heroes: segunda temporada: Tu servidor sin servidor

Command Line Heroes: segunda temporada: Tu servidor sin servidor

About the episode

¿Qué significa realmente la informática sin servidor? Los servidores siguen existiendo: los conceptos básicos de Internet no han cambiado. Pero y si alguien más los maneja, ¿a qué podrían dedicarse los desarrolladores, qué podrían lograr?

La informática sin servidor facilita a los principiantes la implementación de las aplicaciones, y vuelve el trabajo más eficiente para los especialistas. Andrea Passwater explica que el olvidarse de los elementos de la infraestructura del desarrollo puede ayudar mucho. Pero al igual que cualquier avance, la informática sin servidor tiene sus inconvenientes. Rodric Rabbah nos cuenta que el quedarse sin servidor puede implicar renunciar al control de las implementaciones, además de que limita la capacidad para responder a los problemas, razón por la cual colaboró con la creación de Apache OpenWhisk, un entorno de código abierto sin servidor. Y Himanshu Pant plantea cuándo es conveniente utilizar los servicios sin servidor.

El objetivo de la informática sin servidor debe ser dar más libertad a los desarrolladores. Pero incluso para simplificar nuestras herramientas, necesitamos pensar en todo el panorama.

Command Line Heroes Team Red Hat original show

Suscribir

Subscribe here:

Listen on Apple Podcasts Listen on Spotify Subscribe via RSS Feed

Transcripción

But now, of course, all over the United States of America and all over the world the internet is revolutionizing our lives. Es 1998. Google acaba de contratar a su primer empleado, y el vicepresidente de los Estados Unidos, Al Gore, habla con la prensa. Escucha lo que dijo: Está explicando que, en los últimos cinco años, Internet ha crecido de 50 sitios a un ecosistema lleno de casi todo lo que se nos pueda ocurrir, incluso servicios que envían flores virtuales. This technology is still in its infancy. When president Bill Clinton and I came into the White House there were only 50 sites. And look at it now. I got a bouquet of virtual flowers on my birthday. Sí. Me imagino que estás arqueando las cejas. ¿Que por qué te pasamos una grabación de la historia de Internet de hace 20 años? Porque queremos recordarte que los aspectos básicos de Internet siguen siendo los mismos. Claro, ahora hay más de 50 sitios. Pero todavía enviamos flores virtuales. Y desde la perspectiva de los desarrolladores, si eliminamos todos los avances increíbles que hemos logrado, veremos que seguimos con el mismo modelo cliente-servidor que dio comienzo a todo. Un modelo cliente-servidor que permite una red distribuida. Hoy en día, los desarrolladores hablan mucho de pasar a la informática sin servidor, lo cual suena a que vamos a deshacernos del Internet cliente-servidor de Al Gore. Y si no somos cuidadosos, podemos eliminar una parte tan grande de la infraestructura que olvidamos que todavía hay servidores que siguen funcionando. ¿Pero cuando hablamos de la informática sin servidor nos referimos literalmente a que no se utilicen servidores? ¿De verdad? ¿O es simplemente que la relación del desarrollador con los servidores está evolucionando? En este episodio, hablaremos con personas de todo el mundo para analizar qué es la informática sin servidor. Esto es Command Line Heroes en español. Un podcast original de Red Hat. ¿Sabías que en algún lugar el Internet inalámbrico tiene cables? Andrea Passwater es una estratega de contenido que solía trabajar para una empresa que se llama... Adivina. Serverless. Crearon un marco popular de código abierto para desarrollar aplicaciones sin servidor. Andrea se dio cuenta de que las organizaciones buscan ansiosamente una manera de sacar la infraestructura de la ecuación, que es lo que siempre promete la frase mágica "informática sin servidor". Creo que el término simplemente se refiere al hecho de que si eres desarrollador y trabajas en aplicaciones sin servidor, los servidores ya no cuentan para ti. Ya no tienes que preocuparte por ellos. Solo tienes que codificar e implementar el código en un proveedor de nube, sin tener que preocuparte por la administración. A eso se refiere realmente la informática sin servidor. Para Andrea, los encantos de la informática sin servidor son bastante evidentes. Si desarrollas aplicaciones sin servidor, ya no tienes que pensar en las partes rutinarias y tediosas de implementarlas y mantenerlas, sino que puedes enfocarte en el valor comercial. Puedes concentrarte en ser creativo. Otra gran ventaja de la informática sin servidor es que es menos probable que tengas que reinventar la rueda. Imagínate que vas cargando muchos alimentos de la tienda, y vas tambaleando hasta una puerta. La puerta se abre de una forma sencilla y amable, como diciéndote: "Permíteme". Esa es la informática sin servidor. Es el mecanismo que nos abre la puerta, para que el desarrollo sea mucho menos engorroso. De hecho, a medida que las organizaciones avanzan hacia las configuraciones de nube híbrida y el movimiento de la informática sin servidor se pone en marcha, desaparecen las barreras hacia el desarrollo. Andrea ha escuchado muchos comentarios sobre el desarrollo sin desarrolladores. Sí, anécdotas de muchas personas que siempre habían pensado que no podían escribir código, y que ahora juegan el juego de la ingeniería de software gracias a la tecnología sin servidor. Y pueden desarrollar herramientas que automatizan sus propios flujos de trabajo y cosas así. En todos los trabajos, no importa cuál... Realmente puede ayudarte a ser más productivo y eficiente. Andrea hace que parezca que la informática sin servidor es la respuesta a todos nuestros problemas. Pero como cualquier tecnología, tiene sus pros y contras. Para obtener una perspectiva más equilibrada, hablé con Michael Hausenblas, Developer Advocate en Red Hat. La informática sin servidor definitivamente tiene sus ventajas, especialmente para ciertos tipos de cargas de trabajo. Pero es importante entender que no es una solución universal. Michael explica que la informática sin servidor funciona especialmente bien para aplicaciones que tienen patrones de tráfico impredecibles o esporádicos. Si tienes una aplicación que recibe mucho tráfico durante ciertas horas del día y muy poco el resto del tiempo, la informática sin servidor puede ser muy eficiente en términos de costos. Solo pagas por el tiempo de cómputo que realmente usas. Pero también hay desventajas que los desarrolladores deben considerar. Una de las principales limitaciones es lo que llamamos "cold start". Cuando una función sin servidor no se ha ejecutado por un tiempo, puede tomar varios segundos inicializarse. Para aplicaciones que requieren respuestas inmediatas, esto puede ser problemático. También está la cuestión del vendor lock-in - quedar atado a un proveedor específico. Cada proveedor de cloud tiene su propia implementación de funciones sin servidor. AWS tiene Lambda, Azure tiene Functions, Google tiene Cloud Functions. Aunque hacen cosas similares, no son directamente compatibles entre sí. Esta falta de portabilidad puede ser preocupante para las organizaciones que quieren evitar depender demasiado de un solo proveedor. Para entender mejor cómo las organizaciones están navegando estos desafíos, hablé con Himanshu Pant, director tecnológico del Royal Bank of Scotland. En el banco, evaluamos muy cuidadosamente cuándo usar tecnologías sin servidor. No es apropiado para todo, pero para ciertos casos de uso, puede ser transformador. Himanshu explica que el banco usa funciones sin servidor principalmente para procesamiento de eventos y integraciones entre sistemas. Por ejemplo, cuando un cliente realiza una transacción, eso puede desencadenar varias funciones sin servidor que actualizan bases de datos, envían notificaciones, y ejecutan verificaciones de fraude. Es perfecto para este tipo de procesamiento basado en eventos. Pero Himanshu también enfatiza la importancia de tener una estrategia clara. No puedes simplemente adoptar tecnologías sin servidor porque están de moda. Tienes que entender dónde agregan valor real y dónde podrían crear complejidades innecesarias. Una de las complejidades que menciona es el monitoreo y debugging de aplicaciones distribuidas. Cuando tu aplicación está compuesta por docenas o cientos de funciones pequeñas, rastrear problemas puede ser muy desafiante. Necesitas herramientas y procesos muy sofisticados para mantener visibilidad sobre lo que está sucediendo. Estas preocupaciones sobre control y visibilidad son algunas de las razones por las que muchas organizaciones están interesadas en plataformas de código abierto para funciones sin servidor. Una de las plataformas más prominentes es Apache OpenWhisk, y hablé con uno de sus creadores, Rodric Rabbah. Soy Rodric Rabbah, uno de los creadores de Apache OpenWhisk y cofundador de Nimbella Corporation. OpenWhisk nació de la necesidad de tener una plataforma de funciones sin servidor que fuera verdaderamente abierta y portable. Rodric explica que OpenWhisk se diseñó desde el principio para ser una alternativa de código abierto a las plataformas propietarias de funciones sin servidor. La idea era que las organizaciones pudieran ejecutar funciones sin servidor en su propia infraestructura, o moverlas fácilmente entre diferentes proveedores de cloud, sin quedar atadas a una plataforma específica. Esta portabilidad es especialmente importante para organizaciones que tienen requisitos estrictos de seguridad o cumplimiento. En sectores como la banca o la salud, no siempre puedes usar servicios de cloud público para procesar datos sensibles. Tener una plataforma de código abierto te permite obtener los beneficios de la computación sin servidor mientras mantienes control total sobre dónde se ejecuta tu código. Pero Rodric también reconoce que OpenWhisk y otras plataformas de código abierto enfrentan desafíos. Los servicios managed de los grandes proveedores de cloud son muy convenientes. No tienes que preocuparte por instalar, configurar, o mantener la plataforma. Con código abierto, obtienes más control, pero también más responsabilidad. Es el trade-off clásico entre conveniencia y control que vemos en muchas tecnologías. Pero Rodric cree que hay un futuro brillante para las plataformas de código abierto en el espacio sin servidor. A medida que las organizaciones maduran en su adopción de tecnologías sin servidor, muchas empiezan a valorar más la portabilidad y el control. Quieren poder elegir dónde ejecutar sus funciones basándose en factores como costo, rendimiento, y proximidad a sus usuarios. Y aquí es donde la naturaleza abierta de proyectos como OpenWhisk se convierte en una ventaja significativa. Con código abierto, puedes contribuir mejoras que benefician a toda la comunidad. Si desarrollas una característica que necesitas, esa misma característica puede ayudar a miles de otras organizaciones. Rodric ha visto esto de primera mano en su trabajo con universidades. He dado charlas en universidades como Brown, Williams College, MIT, CMU, y he dado charlas para alentar a los estudiantes a analizar realmente los problemas relacionados con la informática sin servidor y las funciones del servicio... las herramientas, el modelo de programación, para entusiasmarlos con la tecnología. Y para lograrlo les muestro que si realmente contribuyen al proyecto de código abierto, sus contribuciones se incorporan a las funciones de nube de IBM y pueden ejecutarse generalmente en una semana. Vaya. Es muy rápido. Para algunos es sorprendente. Es un proceso super eficiente. Realmente muestra cómo desarrollamos mucha tecnología abierta. No es un modelo de núcleo abierto en que se hayan ocultado algunos de los componentes. Lo que se ejecuta en la nube de IBM es todo lo que está en el proyecto OpenWhisk de Apache. Esta transparencia total es una de las grandes ventajas del desarrollo de código abierto. Pero también plantea preguntas interesantes sobre el futuro de la computación sin servidor. ¿Hacia dónde se dirige esta tecnología? Cuando piensas en el futuro de la informática sin servidor y en las opciones que podemos tener en el futuro, ¿crees que serán abiertas? Creo que actualmente hay un fuerte debate sobre el valor del código abierto, especialmente en la nube. Claro, sí. Si consideras por qué la gente va a la nube, o por qué podría sentir aversión por ir a la nube, es todo el concepto de la dependencia de un proveedor… donde se pierde transparencia. El código abierto ha ayudado a solucionar algunos de estos problemas. Y luego vemos esfuerzos como Kubernetes, que simplemente se está comiendo a la nube en términos de contenedores y del sistema de gestión. Y lo exitoso que ha sido. Si haces algo que tenga que ver aunque sea un poco con los contenedores, ¿vale la pena siquiera pensar en mantener el código cerrado, dado lo dominante que es? Yo me inclino a pensar que dejar que el código sea abierto ayuda. Es atractivo desde la perspectiva de los desarrolladores. Rodric hace un punto interesante sobre Kubernetes. Al igual que Kubernetes se ha convertido en el estándar de facto para orquestación de contenedores, podríamos ver emerger estándares similares en el espacio sin servidor. De hecho, ya hay esfuerzos en marcha para crear estándares que permitan mayor portabilidad entre plataformas sin servidor. Pero Rodric también cree que el futuro de la computación sin servidor irá más allá de simplemente ejecutar funciones en la nube. Si piensas en el futuro del ecosistema sin servidor, en las herramientas, los proyectos y los servicios que va a haber, ¿cómo te lo imaginas? O sea, ¿tú cómo te imaginas el futuro de la informática sin servidor? Creo que cada vez vamos a pensar menos en la tecnología subyacente, y más en la experiencia de programación y las herramientas que se necesitan. Las herramientas para depurar, para gestionar la implementación, para analizar el rendimiento, para la seguridad... Creo que todas y cada una de ellas son muy importantes. La mecánica subyacente de cómo ejecutas la función, ya sea que se ejecute en un contenedor o en alguna tecnología futura, ya sea que puedas ejecutarla en una nube, o multinube, creo que pasa a segundo plano. Como lo que hacía Kubernetes para los contenedores y la gestión de contenedores. De manera similar, va a haber una capa superior, que es la función de la capa de servicio, para dar la sensación de la informática sin servidor. Entonces, realmente se trata del nuevo middleware que vaya encima. De cómo empoderar a los desarrolladores para que realmente aprovechen esta nueva cloud computing y las herramientas que vas a poner a su disposición para que su experiencia sea agradable. Sí. ¿Y cómo se puede empoderar a los desarrolladores? Fomentando la eficiencia, en pocas palabras. Para que yo como desarrollador pueda enfocarme simplemente en las cosas que son importantes para mí o para la empresa en que trabajo, si ese es el caso. Y entonces, pues, puedes generar innovaciones más rápido, gracias a que ya no tienes que dedicarte a pensar en la infraestructura ni en cómo se escalan las cosas, ni en cómo proteger el hardware... Ahora realmente puedes dedicarte a crear innovaciones, porque ya liberaste toda esa energía mental que ahora puedes usar para producir innovaciones más rápido, para ofrecer más valor a tus usuarios finales. Todo eso se resumiría en una mayor eficiencia. Esta visión de empoderar a los desarrolladores liberándolos de la gestión de infraestructura es realmente el corazón de la promesa de la computación sin servidor. Pero como hemos visto a lo largo de este episodio, la realidad es más compleja. La computación sin servidor no es una panacea, sino una herramienta más en el toolkit del desarrollador. La clave está en entender cuándo usarla y cuándo no. Para aplicaciones con patrones de tráfico impredecibles, procesamiento de eventos, o integraciones simples, puede ser increíblemente efectiva. Pero para aplicaciones que requieren control granular sobre el rendimiento, estado persistente, o integración profunda con sistemas existentes, las arquitecturas tradicionales podrían ser más apropiadas. Y como siempre en tecnología, el panorama está evolucionando rápidamente. Las limitaciones de hoy podrían ser resueltas por las innovaciones de mañana. Lo que es seguro es que la computación sin servidor está aquí para quedarse. La pregunta no es si la adoptaremos, sino cómo la integraremos sabiamente en nuestras arquitecturas. Y aquí es donde el código abierto juega un papel crucial. Proyectos como OpenWhisk están asegurando que tengamos opciones abiertas y portables, no solo servicios propietarios de proveedores de cloud. Esto es especialmente importante a medida que la computación sin servidor madura y las organizaciones buscan más control sobre sus deployments. Al final, la computación sin servidor es sobre democratizar el acceso a capacidades de computación sofisticadas. Es sobre permitir que más personas construyan aplicaciones poderosas sin tener que convertirse en expertos en infraestructura. Y esa democratización es más efectiva cuando está basada en estándares abiertos y tecnologías que cualquiera puede usar, modificar, y mejorar. Y para lograrlo les muestro que si realmente contribuyen al proyecto de código abierto, sus contribuciones se incorporan a las funciones de nube de IBM y pueden ejecutarse generalmente en una semana. Vaya. Es muy rápido. Para algunos es sorprendente. Es un proceso super eficiente. Realmente muestra cómo desarrollamos mucha tecnología abierta. No es un modelo de núcleo abierto en que se hayan ocultado algunos de los componentes. Lo que se ejecuta en la nube de IBM es todo lo que está en el proyecto OpenWhisk de Apache. Cuando piensas en el futuro de la informática sin servidor y en las opciones que podemos tener en el futuro, ¿crees que serán abiertas? Creo que actualmente hay un fuerte debate sobre el valor del código abierto, especialmente en la nube. Claro, sí. Si consideras por qué la gente va a la nube, o por qué podría sentir aversión por ir a la nube, es todo el concepto de la dependencia de un proveedor… donde se pierde transparencia. El código abierto ha ayudado a solucionar algunos de estos problemas. Y luego vemos esfuerzos como Kubernetes, que simplemente se está comiendo a la nube en términos de contenedores y del sistema de gestión. Y lo exitoso que ha sido. Si haces algo que tenga que ver aunque sea un poco con los contenedores, ¿vale la pena siquiera pensar en mantener el código cerrado, dado lo dominante que es? Yo me inclino a pensar que dejar que el código sea abierto ayuda. Es atractivo desde la perspectiva de los desarrolladores. Si piensas en el futuro del ecosistema sin servidor, en las herramientas, los proyectos y los servicios que va a haber, ¿cómo te lo imaginas? O sea, ¿tú cómo te imaginas el futuro de la informática sin servidor? Creo que cada vez vamos a pensar menos en la tecnología subyacente, y más en la experiencia de programación y las herramientas que se necesitan. Las herramientas para depurar, para gestionar la implementación, para analizar el rendimiento, para la seguridad... Creo que todas y cada una de ellas son muy importantes. La mecánica subyacente de cómo ejecutas la función, ya sea que se ejecute en un contenedor o en alguna tecnología futura, ya sea que puedas ejecutarla en una nube, o multinube, creo que pasa a segundo plano. Como lo que hacía Kubernetes para los contenedores y la gestión de contenedores. De manera similar, va a haber una capa superior, que es la función de la capa de servicio, para dar la sensación de la informática sin servidor. Entonces, realmente se trata del nuevo middleware que vaya encima. De cómo empoderar a los desarrolladores para que realmente aprovechen esta nueva cloud computing y las herramientas que vas a poner a su disposición para que su experiencia sea agradable. Sí. ¿Y cómo se puede empoderar a los desarrolladores? Fomentando la eficiencia, en pocas palabras. Para que yo como desarrollador pueda enfocarme simplemente en las cosas que son importantes para mí o para la empresa en que trabajo, si ese es el caso. Y entonces, pues, puedes generar innovaciones más rápido, gracias a que ya no tienes que dedicarte a pensar en la infraestructura ni en cómo se escalan las cosas, ni en cómo proteger el hardware... Ahora realmente puedes dedicarte a crear innovaciones, porque ya liberaste toda esa energía mental que ahora puedes usar para producir innovaciones más rápido, para ofrecer más valor a tus usuarios finales. Todo eso se resumiría en una mayor eficiencia. Rodric Rabbah es fundador de OpenWhisk. ¿Recuerdan lo que hablamos al comienzo del programa? El antiguo modelo cliente-servidor en el que se basa Internet en realidad ya no va a ningún lado. Lo que está cambiando es la forma en que pensamos sobre los servidores. En un mundo sin servidores, la idea es que ya no tengamos que preocuparnos por la infraestructura, para poder concentrarnos en el código en sí. Lo interesante de esto es qué decidiremos sacar de la ecuación, y cómo mantendremos el control del trabajo que implique lo que decidamos conservar. El objetivo principal de la informática sin servidor debe ser ayudar a los desarrolladores. Liberarlos de las tareas de aplicar parches, escalar y administrar la infraestructura. Pero, al mismo tiempo, tenemos que seguir pensando en cómo funciona el todo, incluso a medida que abstraemos algunas partes. La pregunta es, ¿a qué controles renuncio y qué controles quiero conservar? El próximo episodio es el muy esperado final de la temporada dos. Command Line Heroes en español... hará un viaje a Marte. Veremos que el róver que la NASA envió a Marte está generando toda una revolución en el mundo del código abierto. Y conversaremos con el director de tecnología del laboratorio de propulsión a chorro de la NASA. Nada importante. Para aprender cómo el código abierto le está dando forma al futuro de la exploración espacial. Hasta la próxima, sigan programando.

Sobre el podcast

Command Line Heroes

During its run from 2018 to 2022, Command Line Heroes shared the epic true stories of developers, programmers, hackers, geeks, and open source rebels, and how they revolutionized the technology landscape. Relive our journey through tech history, and use #CommandLinePod to share your favorite episodes.