Capítulo 1. Introducción Introducción
Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: translation-feedback@oreilly.com
Cloud Run es una plataforma en Google Cloud que te permite crear aplicaciones web escalables y fiables. Como desarrollador, puedes estar muy cerca de poder simplemente escribir tu código y enviarlo, y luego dejar que la plataforma despliegue, ejecute y escale tu aplicación por ti.
La nube pública ha proporcionado a los desarrolladores y a las empresas la oportunidad de convertir los servidores físicos y los centros de datos en virtuales, disminuyendo enormemente el tiempo de espera y convirtiendo las grandes inversiones iniciales en servidores físicos y centros de datos en gastos operativos continuos. Para la mayoría de las empresas, esto ya es un gran paso adelante.
Sin embargo, las máquinas virtuales y las redes virtuales siguen siendo una abstracción de nivel relativamente bajo. Puedes dar un salto aún mayor si diseñas tu aplicación para aprovechar al máximo la moderna plataforma en la nube. Cloud Run proporciona un mayor nivel de abstracción sobre la infraestructura real del servidor y te permite centrarte en el código, no en la infraestructura.
Utilizar la abstracción de alto nivel que proporciona Cloud Run no significa que te ates a Google Cloud para siempre. En primer lugar, Cloud Run requiere que tu aplicación esté empaquetada en un contenedor, una forma portátil de implementar y ejecutar tu aplicación. Si tu contenedor se ejecuta en Cloud Run, también puedes ejecutarlo en tu propio servidor, utilizando Docker, por ejemplo. En segundo lugar, la plataforma Cloud Run se basa en la especificación abierta Knative, lo que significa que puedes migrar tus aplicaciones a otro proveedor o a tu propio hardware con un esfuerzo limitado.
Aplicaciones sin servidor
Probablemente has comprado este libro porque te interesa crear una aplicación sin servidor. Tiene sentido ser específico sobre lo que significa aplicación, porque es un término muy amplio; tu teléfono ejecuta aplicaciones, y un servidor también. Este libro trata de aplicaciones basadas en web, que reciben peticiones (o eventos) a través de HTTPS y responden a ellas.
Ejemplos de aplicaciones basadas en la web son los sitios con los que interactúas utilizando un navegador web y las API con las que puedes programar. Estos son los dos casos de uso principales en los que me centro en este libro. También puedes crear canalizaciones de procesamiento de eventos y automatización de flujos de trabajo con Cloud Run.
Una cosa que quiero subrayar es que cuando digo HTTP, me refiero a toda la familia de protocolos HTTP de , incluido HTTP/2 (la versión más avanzada y de mayor rendimiento). Si te interesa leer más sobre la evolución de HTTP, te sugiero que leas este resumen bien escrito en MDN.
Ahora que he delimitado lo que significa "aplicación" en el contexto de este libro, echemos un vistazo a sin servidor. Si utilizas componentes sin servidor para crear tu aplicación, tu aplicación no tiene servidor. Pero, ¿qué significa "sin servidor"? Es un término abstracto y sobrecargado que significa cosas diferentes para personas diferentes.
Cuando intentes comprender el concepto "sin servidor", no debes centrarte demasiado en la parte de "sin servidores": es más que eso. En general, esto es lo que creo que la gente quiere decir cuando llama a algo "sin servidor" y por qué les entusiasma:
Simplifica la experiencia del desarrollador al eliminar la necesidad de gestionar la infraestructura.
Es escalable desde el primer momento.
Su modelo de costes es de "pago por uso": pagas exactamente por lo que utilizas, no por la capacidad que reservas por adelantado. Si no utilizas nada, no pagas nada.
En las próximas secciones, exploraré más a fondo estos tres aspectos de la tecnología sin servidor.
Una experiencia sencilla para el desarrollador
Eliminar la gestión de la infraestructura significa que puedes centrarte en escribir tu código y dejar que otro se preocupe de la implementación, ejecución y escalado de tu aplicación. La plataforma se ocupará de todos los detalles importantes y aparentemente sencillos que son sorprendentemente difíciles de hacer bien, como el autoescalado, la tolerancia a fallos, el registro, el monitoreo, las actualizaciones, la implementación y la conmutación por error.
Una cosa que específicamente no tienes que hacer en el contexto sin servidor es la gestión de la infraestructura. La plataforma ofrece una capa de abstracción. Esta es la razón principal por la que la llamamos "sin servidor".
Cuando ejecutas un sistema pequeño, la gestión de la infraestructura puede no parecer un gran problema, pero los lectores que gestionan más de 10 servidores saben que puede ser una responsabilidad importante que requiere mucho trabajo para hacerlo bien. He aquí una lista incompleta de tareas que ya no necesitas realizar cuando ejecutas la lógica de tu aplicación en una plataforma sin servidor:
Aprovisionar y configurar servidores (o establecer la automatización)
Aplicar parches de seguridad a tus servidores
Configurar redes y cortafuegos
Configurar certificados SSL/TLS, actualizarlos anualmente y configurar un servidor web
Automatización de la implementación de aplicaciones en un clúster de servidores
Automatización de edificios capaz de gestionar fallos de hardware de forma transparente
Configurar el registro y el monitoreo de métricas para proporcionar información sobre el rendimiento del sistema
¡Y eso sólo en servidores! La mayoría de las empresas tienen expectativas cada vez más altas en cuanto a la disponibilidad de los sistemas. Más de 30 minutos de inactividad al mes suele ser inaceptable. Para alcanzar estos niveles de disponibilidad , tendrás que automatizar la salida de cada modo de fallo: no hay tiempo suficiente para la resolución manual de problemas. Como puedes imaginar, esto supone mucho trabajo y aumenta la complejidad de tu infraestructura. Si creas software en un entorno empresarial, te resultará más fácil obtener la aprobación de los equipos de seguridad y operaciones, porque muchas de sus responsabilidades pasan al proveedor.
La disponibilidad también está relacionada con las Implementaciones de software, ahora que es más habitual desplegar nuevas versiones de software a diario en lugar de mensualmente. Cuando despliegues tu aplicación, no querrás experimentar tiempos de inactividad, ni siquiera cuando la implementación falle.
La tecnología sin servidor te ayuda a centrarte en resolver los problemas de tu negocio y crear un gran producto mientras otra persona se preocupa de los aspectos fundamentales del funcionamiento de tu aplicación. Esto suena muy cómodo, pero no debes tomarlo como que desaparecen todas tus responsabilidades. Lo más importante es que sigues teniendo que escribir y parchear tu código y asegurarte de que es seguro y correcto. También tienes que gestionar algunas configuraciones, como establecer requisitos de recursos, añadir límites de escalado y configurar políticas de acceso.
Autoescalable desde el principio
Los productos sin servidor están construidos para aumentar y disminuir su capacidad automáticamente, siguiendo de cerca la demanda. La escala de la nube garantiza que tu aplicación podrá manejar casi cualquier carga que le lances. Una característica clave de los productos sin servidor es que muestran un rendimiento estable y consistente, independientemente de la escala.
Uno de nuestros clientes dirige un sitio de fútbol bastante popular en Holanda. El sitio tiene una sección que muestra los resultados en directo, lo que significa que experimentan picos de carga durante los partidos. Cuando llega un partido popular, aprovisionan más servidores y los añaden al pool de instancias. Luego, cuando termina el partido, vuelven a eliminar las máquinas virtuales para ahorrar costes. En general, esto les ha funcionado bien, y han visto pocas razones para cambiar las cosas.
Sin embargo, no estaban preparados cuando, de repente, a uno de nuestros clubes nacionales le fue muy bien en la Liga de Campeones de la UEFA. En contra de todas las expectativas, este club llegó a semifinales. Mientras todos los aficionados al fútbol de Holanda se unían para apoyar al equipo, nuestro cliente sufrió varios cortes, que no pudieron solucionarse añadiendo más servidores.
La cuestión es que, aunque puede que ahora mismo no sientas los inconvenientes de un sistema serverful, puede que en el futuro necesites las ventajas de escalabilidad de serverless cuando tengas que hacer frente a circunstancias imprevistas. La mayoría de los sistemas tienden a escalar bien hasta que se encuentran con un cuello de botella y el rendimiento se degrada de repente. La arquitectura de Cloud Run te proporciona barandillas que te ayudan a evitar errores comunes y a construir aplicaciones más escalables por defecto.
Un modelo de costes diferente
El modelo de costes de la plataforma sin servidor es diferente: pagas sólo por el uso real, no por la preasignación de capacidad. Cuando no estás gestionando solicitudes en una plataforma sin servidor, no pagas nada. En Cloud Run, pagas por los recursos del sistema que utilizas para gestionar una solicitud con una granularidad de 100 ms y una pequeña cuota por cada millón de solicitudes. El pago por uso también puede aplicarse a otros tipos de productos. Con una base de datos sin servidor, pagas por cada consulta y por los datos que almacenas.
Presento esto con una advertencia: no estoy afirmando que la tecnología sin servidor sea barata. Aunque la mayoría de los primeros usuarios parecen experimentar una reducción de costes, en algunos casos, la tecnología sin servidor puede resultar más cara. Uno de estos casos es cuando actualmente consigues utilizar cerca del 100% de la capacidad de tu servidor todo el tiempo. Creo que esto es muy raro; las tasas de utilización del 20 al 40% son mucho más comunes. Son muchos servidores ociosos por los que estás pagando.
El modelo de costes sin servidor proporciona al proveedor un incentivo para asegurarse de que tu aplicación escale rápidamente y esté siempre disponible. Ellos tienen la piel en el juego.
Así es como funciona: pagas por los recursos que realmente utilizas, lo que significa que tu proveedor quiere asegurarse de que tu aplicación gestiona todas las peticiones que llegan. En cuanto tu proveedor deja de atender una petición, potencialmente deja de monetizar los recursos de su servidor.
Sin servidor no son funciones como servicio
La gente suele asociar serverless con funciones como servicio (FaaS) productos como Cloud Functions o AWS Lambda. Con FaaS, normalmente utilizas una función como "código pegamento" para conectar y ampliar los servicios existentes de Google Cloud. Las funciones utilizan un marco de tiempo de ejecución: despliegas un pequeño fragmento de código, no un contenedor. En el fragmento de código, sólo implementas una función o anulas un método, que gestiona una solicitud entrante o un evento. No estás iniciando tú mismo un servidor HTTP.
FaaS es sin servidor porque tiene una experiencia sencilla para el desarrollador: no tienes que preocuparte del tiempo de ejecución de tu código (aparte de configurar el lenguaje de programación) ni de crear y gestionar el punto final HTTPS. El escalado está incorporado, y pagas una pequeña cuota por cada millón de peticiones.
Como descubrirás en este libro, Cloud Run es sin servidor, pero tiene más capacidades que una plataforma FaaS. La tecnología sin servidor tampoco se limita a gestionar peticiones HTTPS. Las demás primitivas que utilices para construir tu aplicación también pueden ser serverless. Antes de dar una visión general de los demás productos sin servidor de Google Cloud, ha llegado el momento de presentar la propia Google Cloud.
Nube de Google
Google Cloud comenzó en 2008, cuando Google lanzó App Engine, una plataforma de aplicaciones sin servidor. App Engine era serverless antes de que empezáramos a utilizar la palabra serverless. Sin embargo, por aquel entonces, el tiempo de ejecución de App Engine tenía muchas limitaciones, lo que en la práctica significaba que sólo era adecuado para proyectos nuevos. A algunos les encantó, a otros no. Entre los casos notables de éxito de clientes se encuentran Snapchat y Spotify. App Engine tuvo una tracción limitada en el mercado.
Impulsado por esta tibia reacción a App Engine y una enorme demanda del mercado de infraestructura de servidores virtuales, Google Cloud lanzó Compute Engine en 2012. (Eso es seis años después de que Amazon lanzara EC2, el producto que ejecuta máquinas virtuales en AWS). Esto me lleva a creer que la mentalidad de Google siempre ha sido sin servidor.
He aquí otra perspectiva: hace unos años, Google publicó un documento sobre Borg, la infraestructura global de contenedores en la que ejecutan la mayor parte de su software, incluidos Google Search, Gmail y Compute Engine (así es como se ejecutan las máquinas virtuales).1 Así es como lo describen (el énfasis es mío):
Borg ofrece tres ventajas principales: (1) oculta los detalles de la gestión de recursos y la gestión de fallos para que sus usuarios puedan centrarse en el desarrollo de aplicaciones; (2) funciona con una fiabilidad y disponibilidad muy altas, y admite aplicaciones que hacen lo mismo; y (3) nos permite ejecutar cargas de trabajo en decenas de miles de máquinas de forma eficaz.
Deja que esto se hunda un poco: Google lleva trabajando en una infraestructura de contenedores a escala planetaria desde al menos 2005, según las pocas cuentas públicas sobre Borg. Uno de los principales objetivos de diseño del sistema Borg es permitir a los desarrolladores centrarse en el desarrollo de aplicaciones en lugar de en los detalles operativos de la ejecución de software, y escalar a decenas de miles de máquinas. Eso no es sólo escalable, es hiperescalable.
Si estuvieras desarrollando y ejecutando software a la escala a la que lo hace Google, ¿querrías molestarte en mantener una infraestructura de servidores, por no hablar de preocuparte por elementos básicos como direcciones IP, redes y servidores?
A estas alturas debería estar claro que me gusta trabajar con Google Cloud. Por eso estoy escribiendo un libro sobre la creación de aplicaciones sin servidor con Google Cloud Run. No voy a compararlo con otros proveedores de la nube, como Amazon y Microsoft, porque carezco de los profundos conocimientos de otras plataformas en la nube que serían necesarios para que valiera la pena leer una comparación de este tipo. Sin embargo, ten por seguro que los principios generales de diseño de aplicaciones que recogerás en este libro se trasladan bien a otras plataformas.
Sin servidor en Google Cloud
Echa un vistazo a la Tabla 1-1 para ver un resumen de los productos sin servidor de Google Cloud que están relacionados con el desarrollo de aplicaciones. También he anotado información sobre la compatibilidad de código abierto de cada uno para indicar si existen alternativas de código abierto que puedas alojar en un proveedor diferente. Esto es importante, porque la vinculación con el proveedor es la preocupación número uno con la tecnología sin servidor. Cloud Run sale bien parado en este aspecto porque es compatible con la API de un producto de código abierto.
| Producto | Propósito | Compatibilidad con el código abierto |
|---|---|---|
Mensajería |
||
Eventos |
Propietario1 |
|
Tareas retrasadas |
Propietario1 |
|
Tareas programadas |
Propietario1 |
|
Eventos |
Compatible con OSS |
|
Calcula |
||
Plataforma de contenedores |
Compatible con OSS |
|
Plataforma de aplicación |
Propietario2 |
|
Conectar servicios existentes de Google Cloud |
Propietario2 |
|
Almacenamiento de datos |
||
Almacenamiento Blob |
Propietario3 |
|
Almacén clave-valor |
Propietario |
|
|
||
En la oferta sin servidor de Google Cloud falta una base de datos relacional. Creo que hay muchas aplicaciones para las que utilizar una base de datos relacional tiene mucho sentido, y la mayoría de los lectores ya están familiarizados con esta forma de arquitectura de aplicaciones. Por eso, en el Capítulo 4 te mostraré cómo utilizar Cloud SQL, una base de datos relacional gestionada. Como servicio gestionado, proporciona muchas de las ventajas de la tecnología sin servidor, pero no escala automáticamente. Además, pagas por la capacidad que asignas, aunque no la utilices.
Carrera en las nubes
Cloud Run es una plataforma sin servidor que ejecuta y escala tu aplicación basada en contenedores. Se implementa directamente sobre Borg, la infraestructura de contenedores hiperescalable que Google utiliza para impulsar Google Search, Maps, Gmail y App Engine.
El flujo de trabajo del desarrollador es un proceso sencillo de tres pasos. En primer lugar, escribe tu aplicación utilizando tu lenguaje de programación favorito. Tu aplicación debe iniciar un servidor HTTP. En segundo lugar, construyes y empaquetas tu aplicación en una imagen de contenedor. El tercer y último paso es implementar la imagen del contenedor en Cloud Run. Cloud Run crea un recurso de servicio y te devuelve un punto final HTTPS invocable(Figura 1-1).
Figura 1-1. Flujo de trabajo del desarrollador de Cloud Run
Servicio
Quiero detenerme aquí y dirigir tu atención a la palabra servicio, porque es un concepto clave en Cloud Run. Cada servicio tiene un nombre único y un punto final HTTPS asociado. Interactuarás principalmente con un recurso de servicio para realizar tus tareas, como desplegar una nueva imagen de contenedor, retroceder a una versión desplegada previamente y cambiar ajustes de configuración como variables de entorno y límites de escalado.
Imagen del contenedor
Dependiendo de lo lejos que estés en tu viaje de aprendizaje, puede que no sepas lo que es una imagen de contenedor . Si sabes lo que es, puede que asocies la tecnología de contenedores con un montón de sobrecargas de infraestructura de bajo nivel que no te interesa ni remotamente aprender. Quiero tranquilizarte: no necesitas convertirte en un experto en contenedores para ser productivo con Cloud Run. Dependiendo de tu caso de uso, puede que nunca tengas que crear tú mismo una imagen de contenedor. Sin embargo, comprender qué son los contenedores y cómo funcionan es ciertamente útil. Cubriré los contenedores desde los primeros principios en el Capítulo 3.
Por ahora, basta con entender que una imagen de contenedor es un paquete que contiene tu aplicación y todo lo que necesita para ejecutarse. El modelo mental de que "una imagen contenedor contiene un programa que puedes iniciar" funciona bien para entender este capítulo.
Cloud Run no es sólo una forma cómoda de lanzar un contenedor. La plataforma tiene características adicionales que la convierten en una plataforma adecuada para ejecutar un gran sistema de producción. El resto de esta sección te dará una visión general de esas características y te ayudará a comprender algunos de los aspectos más importantes de Cloud Run. Luego, en el Capítulo 2, exploraré Cloud Run en profundidad.
Escalabilidad y Autocuración
Las peticiones entrantes a tu servicio Cloud Run serán atendidas por tu contenedor. Si es necesario, Cloud Run añadirá instancias adicionales de tu contenedor para atender todas las peticiones entrantes. Si un contenedor falla, Cloud Run lo sustituirá por una nueva instancia. Por defecto, Cloud Run puede añadir hasta mil instancias de contenedor por servicio, y puedes aumentar aún más este límite mediante un aumento de cuota. La escala de la nube realmente trabaja contigo aquí. Si necesitas escalar a decenas de miles de contenedores, eso podría ser posible: la arquitectura de Cloud Run está diseñada para estar limitada únicamente por la capacidad disponible en una determinada región de Google Cloud (un centro de datos físico).
Servicio HTTPS
Por defecto, Cloud Run crea automáticamente un único punto final HTTPS que puedes utilizar para llegar a tu contenedor. También puedes utilizar tu propio dominio o enganchar tu servicio a la pila de redes virtuales de Google Cloud si necesitas integraciones más avanzadas con aplicaciones existentes que se ejecuten in situ o en máquinas virtuales en Google Cloud, o con funciones como la mitigación de DDoS y un cortafuegos de aplicaciones web.
También puedes crear servicios Cloud Run internos que no sean de acceso público. Son ideales para recibir eventos de otros productos de Google Cloud, por ejemplo, cuando se sube un archivo a un bucket de Almacenamiento en la Nube.
Soporte para microservicios
Cloud Run admite el modelo de microservicios, en el que divides tu aplicación en servicios más pequeños que se comunican mediante llamadas a API o colas de eventos. Esto puede ayudarte a escalar tu organización de ingeniería y, posiblemente, a mejorar la escalabilidad. Cubro un ejemplo de múltiples servicios trabajando juntos en el Capítulo 6.
Gestión de Identidad, Autenticación y Acceso
Cada servicio Cloud Run tiene una identidad asignada, que puedes utilizar para llamar a las API de Cloud y a otros servicios Cloud Run desde el contenedor. Puedes establecer políticas de acceso que regulen qué identidades pueden invocar tu servicio.
Especialmente si estás construyendo una aplicación más seria, un sistema de identidad es importante. Querrás asegurarte de que cada servicio de Cloud Run sólo tenga los permisos para hacer lo que se supone que debe hacer (principio del menor privilegio) y que el servicio sólo pueda ser invocado por las identidades que se supone que deben invocarlo.
Por ejemplo, si tu servicio de pago recibe una solicitud para confirmar un pago, quieres saber quién envió esa solicitud, y quieres estar seguro de que sólo el servicio de pago puede acceder a la base de datos que almacena los datos del pago. En el Capítulo 6, exploro más a fondo la identidad y autenticación del servicio.
Monitoreo y registro
Cloud Run captura métricas estándar de contenedores y solicitudes, como la duración de la solicitud y uso de CPU, y los registros de tu aplicación se reenvían a Cloud Logging. Si utilizas registros estructurados, puedes añadir metadatos que te ayudarán a depurar problemas en producción. En el Capítulo 9, profundizaré en los registros estructurados con un ejemplo práctico.
Implementaciones transparentes
No sé a ti, pero personalmente, tener que soportar Implementaciones lentas o complicadas me produce ansiedad. Diría que ver una película de suspense es comparable. Puedes duplicarlo si tengo que realizar mucha orquestación en mi máquina local para hacerlo bien. En Cloud Run, las implementaciones y los cambios de configuración no requieren mucha ayuda, y las estrategias de implementación más avanzadas, como el despliegue gradual o las implementaciones "verde-azul", son compatibles desde el primer momento. Si te aseguras de que tu aplicación está lista para recibir nuevas solicitudes segundos después de iniciar el contenedor, reducirás el tiempo que se tarda en desplegar una nueva versión.
Pago por uso
Cloud Run te cobra por los recursos (CPU y memoria) que utilizan tus contenedores cuando sirven peticiones a . Incluso si Cloud Run, por alguna razón, decide mantener tu contenedor en funcionamiento cuando no está sirviendo peticiones, no pagarás por ello. Sorprendentemente, Cloud Run mantiene esos contenedores inactivos en funcionamiento mucho más tiempo del que cabría esperar. Explicaré esto con más detalle en el Capítulo 2.
Preocupaciones sobre la ausencia de servidor
Hasta ahora, sólo he destacado las razones por las que querrías adoptar la tecnología sin servidor. Pero debes ser consciente de que, aunque la tecnología sin servidor resuelve ciertos problemas, también crea otros nuevos. Hablemos de lo que debería preocuparte. ¿Qué riesgos corres al adoptar serverless, y qué puedes hacer al respecto?
Costes imprevisibles
El modelo de costes es diferente con el serverless, y esto significa que la arquitectura de tu sistema tiene una influencia más directa y visible en los costes de funcionamiento de tu sistema. Además, el rápido autoescalado conlleva el riesgo de una facturación impredecible. Si ejecutas un sistema sin servidor que se escala elásticamente, cuando surja una gran demanda, se atenderá, y pagarás por ello. Al igual que el rendimiento, la seguridad y la escalabilidad, los costes son ahora un aspecto de calidad de tu código que debes conocer y que tú, como desarrollador, puedes controlar.
No dejes que este párrafo te asuste: puedes establecer límites al comportamiento de escalado y ajustar con precisión la cantidad de recursos de que disponen tus contenedores. También puedes realizar pruebas de carga para predecir el coste.
Hiperescalabilidad
Cloud Run puede escalar a muchas instancias de contenedor muy rápidamente. Esto puede causar problemas a los sistemas posteriores que no pueden aumentar su capacidad con la misma rapidez o que tienen problemas para servir una carga de trabajo altamente concurrente, como las bases de datos relacionales tradicionales y las API externas con límites de velocidad impuestos. En el Capítulo 4, investigaré cómo puedes proteger tu base de datos relacional de una concurrencia excesiva.
Cuando las cosas van realmente mal
Cuando ejecutas tu software sobre una plataforma que no posees ni controlas, estás a merced de tu proveedor cuando las cosas van realmente mal. No me refiero a cuando tu código tiene un fallo cotidiano que puedes detectar y solucionar fácilmente. Con "realmente mal" me refiero a cuando, por ejemplo, tu software se rompe en producción y no tienes forma de reproducir el fallo cuando lo ejecutas localmente porque el error está realmente en la plataforma controlada por el proveedor.
En una infraestructura tradicional basada en servidores, cuando te enfrentas a un error o a un problema de rendimiento que no puedes explicar, puedes echar un vistazo bajo el capó porque controlas toda la pila. Hay abundancia de herramientas que pueden ayudarte a averiguar qué está pasando, incluso en producción. En una plataforma controlada por un proveedor, todo lo que puedes hacer es presentar un ticket de soporte.
Separación de cálculo y almacenamiento
Si utilizas Cloud Run, deberás almacenar los datos que deban persistir externamente en una base de datos o en almacenamiento blob. Esto se denomina separación de cálculo y almacenamiento, y es la forma en que Cloud Run realiza la escalabilidad. Sin embargo, para las cargas de trabajo que se benefician de un acceso rápido y aleatorio a muchos datos (que no caben en la RAM), esto puede añadir latencia al procesamiento de solicitudes. Esto se mitiga en parte por la red interna dentro de un centro de datos de Google Cloud, que suele ser muy rápida con baja latencia.
Compatibilidad con el código abierto
La portabilidad es importante: quieres poder migrar tu aplicación de un proveedor a otro, sin enfrentarte a grandes desafíos. Mientras escribía este capítulo, los directores de sistemas de información de un centenar de grandes empresas de Holanda dieron la voz de alarma porque sus proveedores de software cambiaban unilateralmente los términos y condiciones, y luego les imponían auditorías y considerables recargos. Creo que esto ilustra perfectamente por qué es importante "tener una salida" y asegurarse de que un proveedor nunca consiga ese tipo de influencia. Aunque hoy confíes en Google, nunca sabes lo que te depara el futuro.
Hay dos razones por las que Cloud Run es portátil. En primer lugar, está basado en contenedores. Si un contenedor se ejecuta en Cloud Run, puede ejecutarse en cualquier motor de contenedores, en cualquier lugar. En segundo lugar, si has creado una aplicación distribuida compleja con muchos servicios Cloud Run que funcionan juntos, puede que te preocupe la portabilidad de la propia plataforma. Cloud Run es compatible con la API del producto de código abierto Knative. Esto significa que puedes migrar de Cloud Run a un clúster autoalojado de Kubernetes (la plataforma de contenedores de código abierto) con Knative instalado con un esfuerzo limitado.2 Kubernetes es el estándar de facto cuando quieres implementar contenedores en un clúster de servidores.
En tu propio centro de datos, tienes el control total de tu infraestructura, pero tus desarrolladores siguen teniendo una experiencia de desarrollador "sin servidor" si ejecutas Knative. En el Capítulo 10 exploro Knative con más detalle.
Resumen
En este primer capítulo, aprendiste lo que significa realmente sin servidor y cuáles son sus características clave. También has obtenido una visión general de Google Cloud y has visto que la tecnología sin servidor no se limita a las aplicaciones que gestionan solicitudes HTTPS. Las bases de datos y las colas de tareas también pueden funcionar sin servidor.
La tecnología sin servidor es genial para ti si valoras una experiencia de desarrollador sencilla y rápida, y cuando no quieres construir y mantener una infraestructura de servidores tradicional. Los servidores siguen ahí, sólo que ya no tienes que gestionarlos.
Tu aplicación seguirá siendo portátil si eliges Cloud Run. Está basada en contenedores, y la propia plataforma Cloud Run se basa en la especificación abierta Knative.
Puede que aún tengas muchas preguntas después de leer este primer capítulo. ¡Eso es bueno! Cuando te unas a mí en este viaje sin servidor, te animo a que olvides todo lo que hayas aprendido sobre la gestión de la infraestructura de servidores.
1 Verma Abhishek y otros, "Gestión de clústeres a gran escala en Google con Borg", Actas de EuroSys (2015).
2 Ten cuidado de no vincular demasiado el código fuente de tu aplicación a los servicios de Google Cloud sin alternativas OSS, o podrías perder la ventaja de la portabilidad.
Get Construir aplicaciones sin servidor con Google Cloud Run now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
