Tu servidor sin servidor

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...

...en todos hay tareas repetitivas, que tienes que hacer todos los días, y llega un momento en que piensas: "¿No habrá manera de que lo haga una computadora?" Yo empezaba a sentirme así Y resulta que trabajaba en una empresa que se llama Serverless, y me dijeron: "Sabes que el producto que fabricamos te puede ayudar. ¿Verdad?"

Según Andrea, muchas personas que nunca se habían considerado desarrolladores pronto se darán cuenta de que pueden crear aplicaciones sencillas ellas mismas. Y prácticamente sin gastar nada.

Con Lambda, nunca he tenido que pagar por ninguna de las pequeñas aplicaciones que he hecho. Puedo hacer bots que se encargan de una parte de mi trabajo, y eso me permite ser más eficiente en el resto de mis tareas, claro. Pero además, ya no necesito perder tiempo en las cosas aburridas. Puedo dedicarme a lo que me gusta y es divertido.

Incluso para los desarrolladores profesionales, el efecto de la puerta automática es bastante tentador en un mundo en que vamos con los brazos llenos saliendo de la tienda de abarrotes.

Creo que a la gente le gusta mucho la idea de poner en marcha prototipos con un equipo de una o dos personas en muy poco tiempo. Digamos, en un par de días. Pueden poner en marcha un prototipo. Creo que es muy emocionante para la gente el comenzar a darse cuenta de que pueden dedicarse a lo que impulsa el valor comercial de su aplicación, de sus productos o de su empresa. Pueden concentrarse en ese valor comercial.

Aquí les va otro término. ¿Listos? Funciones como servicio. Esa es la oferta de los lugares sin servidor como Lambda de AWS o Apache OpenWhisk. El término “funciones como servicio” significa que una función única puede ejecutarse cuando alguien la solicita, y solo cuando se activa. Y eso es mucho más eficiente.

Y así ya no tenemos que preocuparnos tanto por la capacidad de procesamiento y el tiempo de ejecución. A fin de cuentas, esa oferta sin servidor puede ser una gran ventaja. De hecho, algunas personas incluso han comenzado a pensar si pasaremos de lleno a la informática sin servidor... ¿Podría reemplazar a los contenedores?...

Entiendo el argumento.

Michael Hausenblas es developer advocate de AWS.

Si te fijas en todo lo que tenemos aquí, OpenShift y Cloud Foundry y todo lo demás, básicamente son abstracciones. Es la idea de que el Heroku, esencialmente, generó una especie de flexión. ¿Me explico? Es una manera de decir, ya no te preocupes por cómo va a correr la ejecución, ni por cómo se va a ver. Solo danos el código y nosotros nos encargamos del resto.

Sí. Eso suena muy bien. Se parece al sueño de un entorno “sin operaciones”. Donde todo está automatizado y abstraído. Es como la versión de diseño de interiores minimalista para desarrolladores. Superficies limpias y agradables.

Pero Michael quiere que vuelvas a la dura realidad.

¡Sin operaciones! ¿Verdad? Queremos que desaparezcan como por arte magia. Vemos chistes así en Hacker News y Twitter. Sin servidores... ¡Pero por supuesto que hay servidores! Yo sé, claro que hay servidores. Y hay operaciones.

Alguien tiene que hacerlo, alguien tiene que organizar los servidores. Alguien tiene que parchar el sistema operativo. Alguien tiene que crear imágenes de contenedor, porque adivina dónde se ejecutan esas funciones. Claro, en algún tipo de contenedor.

Entonces, no es un todo o nada. Las funciones como servicio no reemplazan directamente a los contenedores. Al contrario, agregan una herramienta más. Y hay otra cosa. Usar esa nueva herramienta, usar la informática sin servidor no solo implica que ya le pasamos el problema de las operaciones a otra persona. Todavía tienes que pensar en tus propias operaciones.

Hay pequeñas partes de las operaciones del lado de la infraestructura. Pero también del lado de los desarrolladores. Si es un caso extremo, como Lambda, por ejemplo, pues no tienes acceso a ningún tipo de administrador. ¿No?

No puedes simplemente llamar o mandarle un mensaje a algún administrador de la infraestructura. Alguien de tu empresa va a tener que ocuparse de eso, obviamente. A mí me da miedo que muchas empresas solo piensan en que es sencillo y barato. No tenemos que hacer esto, ni esto, ni esto otro. Pero se les olvida pensar en quién es responsable, o sea, ¿hay algún responsable? ¿Ya tienen alguna estrategia para eso?

Porque si no, entonces antes que nada hay que diseñar un plan, antes de meterse de lleno.

Alguien necesita estar a cargo. Incluso si "eliminas los servidores", todavía tienes que pensar en todo eso. Todavía tienes que organizar tus operaciones.

Cuando mencionamos el término "funciones como servicio", ¿sentiste escalofríos? Desde hace un tiempo, el desarrollo basado en la nube ha acuñado una bola de términos que terminan en "como servicio". Tenemos infraestructuras como servicio, plataformas como servicio, software como servicio, datos como servicio. Bases de datos como servicio. Bueno, creo que ya me expliqué.

Si no entiendes bien las diferencias, no eres el único. Por eso nos comunicamos con Himanshu Pant. Es director tecnológico del Royal Bank of Scotland, en Delhi, India. Y pasó muchos años analizando las diferencias.

Los paradigmas informáticos tienen nombres tan parecidos a la idea de la informática sin servidor, que uno tiende a olvidar las diferencias o a confundirse respecto a la razón por las que a algunos no se los llama "sin servidor". Mientras que a otros sí se los llama "sin servidor".

Entonces la informática sin servidor no es lo mismo que los contenedores. Tampoco es plataforma como servicio. Pero Himanshu quería aclararlo. ¿Qué pueden proporcionar exactamente las funciones como servicio? ¿Y qué no?

Nos contó dos anécdotas sobre dos veces en que entendió cuándo optar por la informática sin servidor y cuándo no. El primer momento llegó durante un hackatón de 24 horas. Himanshu estaba tratando de crear un chat bot.

Había varios indicativos de que esto sería una venta. Por ejemplo, la cobertura de la estructura lógica del código, el costo en el que se incurriría y la escalabilidad. Empecé a hacer este trabajo con la informática sin servidor.

Conforme avanzaba, me di cuenta de que el factor costo era un aspecto que realmente inclinaba la balanza a mi favor. Entonces, aunque todos los demás participantes tuvieron mucha mejor... Me atrevo a decir cobertura, o tal vez cobertura de la estructura lógica... O las situaciones de procesamiento de lenguajes naturales, o sus casos...

Pero, en lo que respecta al costo y la escalabilidad, yo iba a ganar sin duda alguna, porque con la informática sin servidor, todo dependía de la cantidad de llamadas que hiciera la gente en ese chat bot. Las funciones se activarían con eso. Ese fue un caso de uso en el que estaba muy contento de utilizar la informática sin servidor, por el costo: simplemente no había costo. Porque me dio un tiempo de desarrollo más rápido y porque, la verdad, no era una carga de trabajo a escala de producción en ese momento.

Podía arreglármelas con las herramientas pequeñas de la plataforma. Fue una victoria para mí.

Qué bien. En ese momento la informática sin servidor era lo indicado. Pero en el banco en el que actualmente trabaja Himanshu, están migrando los sistemas de las plataformas originales a la nube. Y con eso surgen diferentes tipos de objetivos.

Intentamos ver qué carga de trabajo puede dirigirse a qué paradigma. ¿Para esto debe usarse IS, BAS, FAS...? Evidentemente, en los que llegan al espacio empresarial, se necesita ver que no haya ciertos aspectos, como, por ejemplo, en primer lugar, que no se dependa de un solo proveedor. Y segundo, que esa tecnología esté ampliamente comprobada. Sobre todo en una industria reacia a los riesgos, como el sector bancario, por ejemplo.

Entonces, aquí es donde una plataforma como servicio, que tiene mejor verificación, mejor capacidad y un mejor tipo de herramientas, toma la ventaja.

Himanshu analiza sus propias necesidades, y sus propios niveles de comodidad, y decide qué cargas de trabajo tienen sentido en qué paradigma de cloud computing.

Digamos que alguien que nos escucha está trabajando en una tienda y quiere desarrollar algo, una aplicación por eventos. Para él, o ella, la informática sin servidor no es lo ideal porque la latencia no ayuda en ese tipo de aplicación destinada a cierto objetivo particular.

A fin de cuentas, el enfoque se debe decidir caso por caso. No se trata de apostarle todo al mismo color. Cuando pensamos en qué arquitectura basada en la nube es la adecuada para el trabajo que queremos realizar, necesitamos pensar en otra cosa. Hay que pensar cómo el sacar todo eso del juego, cómo el liberarte de todas esas cosas, puede terminar cambiando no solo nuestra vida laboral, sino el trabajo terminado en sí.

Extraer parte de nuestra carga de trabajo puede significar menos capacidad para personalizar las cosas. Piensa en algún auto que hayas comprado. Funciona. Se puede conducir. Pero luego, piensa en un auto que hayas construido tú. Funciona de la manera en que tú decidiste que funcionara.

Pero tiene un costo.

Rania Khalaf es directora de Ingeniería de Inteligencia Artificial en IBM Research.

Al usar estas aplicaciones sin servidor, puede ser que no tengas el control total de todo lo que sucede. No tienes control del cronograma ni del lugar ni el momento en que se ejecuten.

Pero habrá que sacrificar algo, ¿no? Es posible perder el control preciso al usar la informática sin servidor.

Se le quita tanto al usuario final que si deseas tener más control, un cronograma diferente, más verificaciones y estimaciones, diferentes valores sobre el tiempo en que una función puede ejecutarse... ...y cosas así... Entonces realmente es mejor tener acceso a todo, aunque tengas que esforzarte, para poder crear tus propias implementaciones.

Pero entonces se necesita algo nuevo. Un nuevo tipo de informática sin servidor que las comunidades de código abierto ya están desarrollando para poder usarlas. Rania y su equipo de IBM son parte de ese movimiento.

Primero trabajamos en un lenguaje que era... Básicamente, eran extensiones de JavaScript que te permiten crear composiciones de servicio interactivas y de varios hilos, que son el punto de partida para ofrecer un método más liviano. Eso fue aproximadamente al mismo tiempo en que la nube, los microservicios y las plataformas como servicio comenzaban a aumentar.

Así que simplemente fue combinar esas dos tendencias y pensar que existe la idea de poder crear funciones de orden superior para muchos elementos pequeños que tal vez hayas generado tú o tal vez no...

Rania y su equipo estaban desarrollando OpenWhisk de Apache. Una plataforma de funciones de código abierto.

A OpenWhisk lo hicimos de código abierto desde el principio. Gran parte de eso fue para permitir que la comunidad realmente participara con nosotros. Pero también para quitar las protecciones. Y dar el control a la gente que desea operar sus propios entornos informáticos sin servidor, para que puedan personalizarlos según sus necesidades. Quizás poner sus propios controles, ver cómo funciona realmente y controlarlo mejor.

Pero también ofrecer un tipo de control más preciso que no tendrían si solo se ofreciera como servicio.

Darle el control a cualquier persona que desee operar su propio entorno sin servidor... Es la informática sin servidor de nivel superior. Al unirnos a OpenWhisk, tenemos acceso a otras plataformas de código abierto como Fission y Gestalt. Y empezamos a ver que el campo de la informática sin servidor evoluciona y se vuelve más adaptable y más poderoso que antes.

Para comprender realmente la importancia de una versión de código abierto de la informática sin servidor, pude conversar con uno de los fundadores de OpenWhisk.

Hola, Rodric. ¿Cómo estás?

Bien. ¿Y tú? Gracias por invitarme.

Rodric Rabbah es uno de los tres desarrolladores que concibieron y fundaron OpenWhisk. Esta es nuestra conversación.

Tiende a ser confuso o engañoso para los demás, porque la gente tiende a pensar: "¿Pero cómo es posible la informática sin servidores?"

Claro. El servidor está allí en algún lugar, simplemente yo ya no tengo que preocuparme por eso.

Exactamente. Esa es realmente la belleza de este modelo. Si empiezas a desarrollar en un modelo sin servidor, ya no lo vas a querer cambiar. Por ejemplo, hace casi cuatro años que estoy en esto, y he desarrollado algunas aplicaciones con calidad de producción.

Ya es la única forma en que desarrollo aplicaciones. Si me dices que tengo que aprovisionar una máquina e instalarle un sistema operativo, para mí eso ya es muy raro. Ya ni siquiera estoy seguro de saber hacerlo.

Sí. Cuando lo dices así, suena como quitarse un gran peso de encima, ¿no? Porque la primera vez que oyes hablar de la informática sin servidor, dices: "Uf, tengo que aprender otra cosa".

Pero cuando lo dices así, suena muy bien.

Sí, suena muy bien. Pero bueno, luego hay que recordar que no todo es miel sobre hojuelas. No es una solución milagrosa.

¿Qué riesgos o problemas tiene, que probablemente la gente desconozca o no tenga en cuenta al comenzar?

Creo que la falta de transparencia es posiblemente el más importante. De cierta forma me recuerda la tecnología que surgió cuando aparecieron nuevos lenguajes y elevaron un nivel de abstracción en relación con la computadora. Actualmente en la informática sin servidor existe un efecto sorprendente más o menos similar.

En que escribes, normalmente una función, y luego simplemente la implementas. Queda disponible instantáneamente para ejecutarse, por ejemplo, en la web como punto APIN. Escala enormemente. O sea, puedes ejecutar miles de instancias sin ningún trabajo de tu parte.

Pero, si algo sale mal, dices, ¿cómo lo depuro? O, por ejemplo, quiero revisar el contexto en el que falló la función. Por lo general, esas funciones se ejecutan dentro de procesos y tú no tienes acceso; ni siquiera puedes ingresar a la máquina para ver dónde se está ejecutando tu código. Tal vez se ejecuten en entornos de contenedores que están cerrados. Y no sabes lo que contienen.

Entonces es difícil obtener un poco de transparencia. Aquí es donde ayudan las herramientas. Pero, la falta de herramientas es un obstáculo para que la gente entienda el fallo.

Ah, quedó todo muy claro. Bueno. Volvamos a OpenWhisk, ¿sí? Cuéntame sobre eso.

El proyecto comenzó aproximadamente cuando Lambda de Amazon anunció su oferta, que fue realmente donde la informática sin servidor comenzó a entrar en la terminología y a ganar reputación. Cuando vimos Lambda, empezamos a pensar: “Se necesita desarrollar mucha tecnología. No solo en la capa inferior en términos de la nueva informática en la nube, sino en términos del modelo de programación que ponemos encima para que el acceso sea más fácil para los programadores”. Y como veníamos de IBM Research, teníamos... un conjunto de habilidades bastante sólidas en torno al diseño de los lenguajes de programación, experiencia en la compilación y en el tiempo de ejecución.

Era un equipo pequeño, éramos tres personas…

Vaya.

...y nos reunimos sobre todo para hacer el desarrollo inicial y creamos un prototipo de lo que luego se convirtió en OpenWhisk, con las herramientas de la línea de comando, que de hecho es la interfaz de programación para la informática sin servidor de la actualidad… ...los conceptos del modelo de programación, y luego la arquitectura en sí, a la que debe dar soporte, esencialmente, esta función del modelo de servicio para ofrecer todos los beneficios de la informática sin servidor.

El origen fue realmente el hecho de que llegara Lambda de Amazon para mostrar que existe este nuevo modelo de computación. Pongan atención.

¿Cuánto tiempo tardó? O, bueno, la primera versión.

Muy rápido. De hecho, cuando IBM anunció... Bueno, lo que en ese momento era OpenWhisk de IBM. Fue un año después de nuestro primer commit.

¡Guau! Dios mío.

Fue muy emocionante.

Muy impresionante. En realidad, cuando acababa de empezar no era OpenWhisk, solo era Whisk. ¿No?

Sí, Whisk era el nombre interno. Se me ocurrió a mí. La idea era moverse rápida y ágilmente.

Qué bien.

"Whip" significa "batir", y lo que yo quería era dar a entender que generar una función es tan fácil y rápido como batir unos huevos. Luego pones tu función al sartén, ¡y listo!

Ah, qué buen ejemplo, porque probablemente muchos de nuestros escuchas hayan pensado en una tortilla. En ¡batir unos huevos y hacer tortilla!

Claro. Y con el nombre nos han salido bien algunas cosas, y otras no tanto. Cuando abrimos el código de una tecnología, y la ponemos en GitHub, le ponemos el prefijo “Open” para enfatizar que es abierto como en código abierto y que es de uso, descarga y contribución gratuitos.

Sí.

Y nuestro objetivo de ponerla en código abierto era en realidad elevar el nivel en términos de lo que está disponible en estos días para ejecutarse como plataforma sin servidor. Para nosotros era importante construir una plataforma que no solo estuviera lista para su producción, y para compartirla con el mundo, sino también para hacer posible la investigación académica o la investigación en general. Probablemente como veníamos de IBM Research, nos preocupamos demasiado por eso.

Pero, valió la pena, porque conozco universidades que realmente usan OpenWhisk para su propia investigación, desde Cornell hasta Princeton. He ido a varias 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.

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.