Construir aplicaciones sin servidor en Knative

Prefacio

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: [e-mail]

La tecnología sin servidor se ha convertido en uno de los principales argumentos de venta de los proveedores de servicios en la nube. En los últimos cuatro años, cientos de servicios, tanto de los principales proveedores de la nube como de ofertas de servicios más pequeñas, se han denominado o rebautizado como "sin servidor". Está claro que "sin servidor" tiene algo que ver con los servicios prestados a través de una red, pero ¿qué es "sin servidor" y por qué es importante? ¿En qué se diferencia de los contenedores, las funciones o las tecnologías nativas de la nube? Aunque la terminología y las definiciones evolucionan constantemente, este libro pretende destacar los atributos esenciales de las tecnologías sin servidor y explicar por qué el apelativo "sin servidor" está ganando popularidad.

Este libro se centra principalmente en los sistemas informáticos sin servidor; es decir, sistemas que ejecutan software definido por el usuario, en lugar de realizar un sistema de función fija como el almacenamiento, la indexación o la cola de mensajes. (También existen sistemas de almacenamiento sin servidor, pero no son el objetivo principal de este libro). Dicho esto, la línea divisoria entre el almacenamiento de función fija y la informática de propósito general nunca es tan nítida y clara como la teoría desearía: por ejemplo, los sistemas de bases de datos que admiten la sintaxis de consulta SQL combinan el almacenamiento, la indexación y la ejecución de programas de consulta declarativos escritos en SQL. Aunque la arquitectura de los sistemas de función fija puede ser fascinante e importante de entender para ajustar el rendimiento, este libro se centra principalmente en la computación sin servidor porque es la interfaz con más grados de libertad para los autores de aplicaciones, y el sistema con el que es más probable que interactúen a diario.

Si todavía no estás muy seguro de lo que es la tecnología sin servidor, no te preocupes. Dada la cantidad de productos diferentes que hay en el mercado, está claro que la mayoría de la gente está en el mismo barco. Trazaremos la evolución del término "sin servidor" enlos "Antecedentes" del Prefacio y luego expondremos una definición precisa en el Capítulo 1.

¿A quién va dirigido este libro?

El público principal de este libro son los ingenieros de software¹ y tecnólogos que, o bien no están familiarizados con la arquitectura sin servidor, o bien desean profundizar en los principios y buenas prácticas asociados a dicha arquitectura.

Los nuevos profesionales que quieran sumergirse de inmediato en la escritura de aplicaciones sin servidor pueden empezar en el Capítulo 2, aunque yo recomendaría el Capítulo 1 para obtener una orientación adicional sobre lo que está pasando y por qué es importante la tecnología sin servidor.El Capítulo 3 proporciona material práctico adicional para desarrollar una comprensión más profunda de la arquitectura de la plataforma Knative utilizada en los ejemplos.

El orden de los capítulos debería resultar natural para los lectores familiarizados con la tecnología sin servidor. Los Capítulos 5 y 6 ofrecen una lista de patrones estándar para aplicar la tecnología sin servidor, mientras que el Capítulo 8 y siguientes proporcionan una especie de "tarjeta de bingo" de señales de advertencia de la tecnología sin servidor y esbozos de soluciones que pueden ser útiles en el día a día. El contexto histórico del Capítulo 11también proporciona un mapa de comunidades tecnológicas anteriores que examinar en busca de patrones y soluciones.

Para los lectores que estén más interesados en captar las ideas generales de la tecnología sin servidor, los Capítulos 1, 4 y 7 contienen algunas joyas interesantes para inspirar una comprensión más profunda y nuevas ideas. El contexto histórico y las predicciones futuras del Capítulo11 también pueden ser de interés para comprender el arco de los sistemas de software que condujeron a las implementaciones actuales de las ofertas sin servidor de escalabilidad horizontal.

Para los lectores que sean nuevos no sólo en la computación sin servidor, sino también en el backend o en el desarrollo nativo en la nube, el resto de este prefacio proporcionará algunos antecedentes que ayudarán a preparar el terreno. Como gran parte de la ingeniería de software, estas áreas se mueven rápidamente, por lo que las definiciones que proporciono aquí pueden haber cambiado algo para cuando leas este libro. En caso de duda, estas palabras clave y descripciones pueden ahorrarte tiempo a la hora de buscar servicios equivalentes en el entorno que elijas.

Antecedentes

En los últimos seis años, los términos "nativo de la nube", "sin servidor" y "contenedores" han sido objeto de sucesivas rondas de exageraciones y redefiniciones, hasta el punto de que incluso a muchos profesionales les cuesta mantenerse al día o ponerse totalmente de acuerdo sobre las definiciones de estos términos. Las siguientes secciones pretenden proporcionar definiciones de algunos puntos de referencia importantes en el resto del libro, pero muchas de estas definiciones probablemente seguirán evolucionando: tómalas como contexto de referencia general para el resto de este libro, pero no como el único y verdadero evangelio de la informática sin servidor. Las definiciones cambian a medida que las ideas germinan y crecen, y los jardines de la computación nativa en la nube y sin servidor de los últimos seis años se han llenado de nuevos crecimientos.

Ten en cuenta también que estos antecedentes están organizados de forma que tengan sentido cuando se leen de principio a fin, no como un registro histórico de lo que vino primero. Muchas de estas áreas se desarrollaron independientemente unas de otras y luego se encontraron y combinaron tras su florecimiento inicial (replantando ideas de un jardín a otro por el camino).

Contenedores

Los contenedores -enformato Docker u Open Container Initiative (OCI)- proporcionan un mecanismo para subdividir una máquina anfitriona en múltiples entornos de ejecución independientes. A diferencia de las máquinas virtuales (VM), los entornos de contenedores comparten un único núcleo de sistema operativo, lo que proporciona algunas ventajas:

Reducción de la sobrecarga del SO, porque sólo se ejecuta un SO

Esto limita los contenedores a ejecutar el mismo sistema operativo que el anfitrión, normalmente Linux. (También existen contenedores Windows, pero se utilizan mucho menos).

Paquetes de aplicaciones simplificados que se ejecutan independientemente de los controladores del SO y del hardware

Estos paquetes son suficientes para ejecutar distintas distribuciones de Linux en el mismo núcleo con un comportamiento coherente en todas las versiones de Linux.

Mayor visibilidad de la aplicación

El núcleo compartido permite monitorizar detalles de la aplicación, como los gestores de archivos abiertos, que serían difíciles de extraer de una máquina virtual completa.

Un mecanismo de distribución estándar para almacenar un contenedor en un registro OCI

Parte de la especificación del contenedor describe cómo almacenar y recuperar un contenedor de un registro: el contenedor se almacena como una serie de capas del sistema de archivos almacenadas como un TAR (archivo de cinta) comprimido, de forma que las nuevas capas puedan añadir y eliminar archivos de las capas inmutables subyacentes.

A diferencia de cualquiera de las siguientes tecnologías, las tecnologías de contenedores por sí solas benefician la ejecución de aplicaciones en una sola máquina, pero no abordan la distribución de una aplicación en más de una máquina. En el contexto de este libro, los contenedores actúan como un sustrato común que permite distribuir fácilmente una aplicación que puede ejecutarse de forma coherente en uno o varios ordenadores.

Proveedores de la nube

Proveedores en la nube son empresas que venden acceso remoto a servicios informáticos y de almacenamiento. Algunos ejemplos populares son Amazon Web Services (AWS), Microsoft Azure y Google Cloud Platform (GCP). Los servicios informáticos y de almacenamiento incluyen máquinas virtuales, almacenamiento blob, bases de datos, colas de mensajes y más servicios personalizados. Estas empresas alquilan el acceso a los servicios por horas o incluso de forma más detallada, lo que facilita a las empresas el acceso a la potencia informática cuando la necesitan, sin tener que invertir y planificar por adelantado el espacio del centro de datos, el hardware y las inversiones en redes.

Economía del proveedor de la nube

Los principales proveedores de la nube ganan mucho dinero vendiendo o multiplexando el acceso al hardware físico subyacente: por ejemplo, pueden comprar un servidor a 5.000 $/año (amortizados), pero luego dividirlo en 20 slots, que venden a 0,05 $/hora. Para una empresa que quiera alquilar medio servidor para realizar pruebas durante unas horas, esto significa acceder a más de 2.500 $ de hardware por menos de 1 $.

Por tanto, los proveedores de la nube resultan atractivos para muchos tipos de empresas en las que la demanda no es constante de un día para otro o de una hora para otra, y en las que el acceso a través de Internet es aceptable. Si el proveedor de la nube puede vender tres cuartas partes de la máquina (15 franjas horarias × 0,05 $ = 0,75 $/hora de ingresos), puede obtener 0,75 $ × 24 × 365 = 6.570 $/año de ingresos: no es un mal rendimiento de la inversión.

Aunque algunos servicios de computación en nube son básicamente "alquilar un trozo de hardware", los proveedores de la nube también han competido en el desarrollo de servicios gestionadosmás complejos , ya sea alojados en máquinas virtuales individuales por cliente o utilizando un enfoquemultiusuario en el que los propios servidores son capaces de separar el trabajo y los recursos consumidos por diferentes clientes dentro de un único proceso de aplicación. Es más difícil crear una aplicación o servicio multiusuario, pero la ventaja es que resulta mucho más fácil gestionar y compartir los recursos del servidor entre los clientes, y reducir el coste de ejecución del servicio significa mejores márgenes para los proveedores de la nube.

Los patrones de computación sin servidor que se describen en este libro fueron desarrollados en gran medida por los propios proveedores de la nube o por clientes que proporcionaron orientación y comentarios sobre lo que haría que los servicios fueran aún más atractivos (y, por tanto, merecieran una prima de precio más alta). Independientemente de si utilizas un servicio propietario de nube única o si autoalojas una solución (para más detalles, consulta las siguientes secciones, así como el Capítulo 3), los proveedores de nube pueden ofrecer un entorno atractivo para aprovisionar y ejecutar aplicaciones sin servidor.

Kubernetes y Nube Nativa

Aunque los proveedores de la nube empezaron ofreciendo computación como versiones virtualizadas de hardware físico (la llamada infraestructura como servicio, o IaaS), pronto quedó claro que gran parte del trabajo de asegurar y mantener las redes y los sistemas operativos era repetitivo y muy adecuado para la automatización. Una solución ideal utilizaría contenedores como forma repetible de implementación de software, que se ejecutarían en sistemas operativos Linux gestionados en bloque con la red "justa" para conectar los contenedores de forma privada sin exponerlos a Internet en general. Exploro los requisitos de este tipo de sistema con más detalle en"Supuestos de infraestructura".

Diversas startups intentaron construir soluciones en este espacio con un éxito moderado: Docker Swarm, Apache Mesos y otros. Al final, se impuso una tecnología introducida por Google y a la que contribuyeron Red Hat, IBM y otros: Kubernetes. Aunque Kubernetes puede haber tenido algunas ventajas técnicas sobre los sistemas competidores, gran parte de su éxito puede atribuirse al ecosistema que surgió en torno al proyecto.

Kubernetes no sólo se donó a una fundación neutral (la Cloud Native Computing Foundation, o CNCF), sino que pronto se le unieron otros proyectos fundacionales, como los marcos gRPC y de observabilidad, el empaquetado de contenedores, la base de datos, el proxy inverso y los proyectos de malla de servicios. A pesar de ser una fundación neutral en cuanto a proveedores, la CNCF y sus miembros anunciaron y comercializaron este conjunto de tecnologías con eficacia para ganar la atención y la atención de los desarrolladores, y en 2019, estaba muy claro que la combinación Kubernetes + Linux sería la plataforma de infraestructura de contenedores preferida por muchas organizaciones.

Desde entonces, Kubernetes ha evolucionado para actuar como un sistema de uso general para controlar sistemas de infraestructura mediante un modelo de API estandarizado y extensible. El modelo de API de Kubernetes se basa en definiciones de recursos personalizadas(CRD) y controladores de infraestructura, que observan el estado del mundo e intentan ajustarlo para que coincida con un estado deseado almacenado en la API de Kubernetes. Este proceso se conoce como reconciliación, y cuando se implementa correctamente, puede dar lugar a sistemas resistentes y autorreparables que son más sencillos de implementar que un modelo orquestado centralmente.

Las tecnologías relacionadas con Kubernetes y otros proyectos del CNCF se denominan tecnologías "nativas de la nube", tanto si se implementan en máquinas virtuales de un proveedor de la nube como en hardware físico o virtual dentro de la propia organización de un usuario. Las características clave de estas tecnologías son que están diseñadas explícitamente para ejecutarse en clústeres de ordenadores y redes semiconfiables, y para gestionar con elegancia los fallos de hardware individuales sin dejar de estar disponibles para los usuarios. Por el contrario, muchas tecnologías anteriores a la nube nativa se construyeron sobre la premisa de nodos de hardware individuales altamente disponibles y redundantes, en los que el mantenimiento provocaría generalmente un tiempo de inactividad planificado o una interrupción.

Sin servidor alojado en la nube

Aunque en los últimos cinco años se ha producido una avalancha de para renombrar muchas tecnologías de proveedores en la nube como "sin servidor", el término se refería originalmente a un conjunto de tecnologías alojadas en la nube que simplificaban la implementación de servicios para los desarrolladores. En concreto, "sin servidor" permitía a los desarrolladores centrados en aplicaciones móviles o web implementar una pequeña cantidad de lógica del lado del servidor sin necesidad de comprender, gestionar o implementar servidores de aplicaciones (de ahí el nombre). Estas tecnologías se dividieron en dos bandos principales:

Backend como servicio (BaaS)

Servicios de almacenamiento estructurados con una API rica y configurable para gestionar el estado almacenado en un cliente. Por lo general, esta API incluía un mecanismo para almacenar objetos de pequeño a mediano tamaño en JavaScript Object Notation (JSON) en un almacén de valores clave, con capacidad para enviar notificaciones push al dispositivo cuando se modificaba un objeto en el servidor. Las API también permitían definir la validación de objetos en el servidor, la autenticación automática y la gestión de usuarios, así como reglas de seguridad adaptadas al cliente móvil. Los ejemplos más populares fueron Parse (adquirida por Facebook, ahora Meta, en 2013 y convertida en código abierto en 2017) y Firebase (adquirida por Google en 2014).

Aunque resultaba útil para poner en marcha un proyecto con un equipo pequeño, el BaaS acabó encontrándose con algunos problemas que le hicieron perder popularidad:

• La mayoría de las aplicaciones acabaron superando la funcionalidad fija. Aunque adoptar BaaS podía proporcionar un impulso inicial de productividad, casi con toda seguridad garantizaba una futura migración y reescritura del almacenamiento si la aplicación se hacía popular.

• Comparado con otras opciones de almacenamiento, era caro y tenía un escalado limitado. Aunque los desarrolladores de aplicaciones no necesitaban gestionar servidores, muchas de las arquitecturas de implementación requerían un único servidor frontend para evitar complejos modelos de bloqueo de objetos.

Función como servicio (FaaS)

En este modelo de , los desarrolladores de aplicaciones escribían funciones individuales que se invocarían (llamarían) cuando se cumplieran determinadas condiciones. En algunos casos, esto se combinó con BaaS para resolver algunos de los problemas de las funciones fijas, pero también podría combinarse con servicios escalables de almacenamiento en la nube para conseguir arquitecturas mucho más escalables. En el modelo FaaS, cada invocación de función es independiente y puede producirse en paralelo, incluso en distintos ordenadores. La coordinación entre invocaciones de funciones debe gestionarse explícitamente mediante transacciones o bloqueos, en lugar de ser gestionada implícitamente por la API de almacenamiento, como en BaaS. La primera implementación ampliamente popular de FaaS fue AWS Lambda, lanzada en 2014. Al cabo de unos años, la mayoría de los proveedores de la nube ofrecían servicios competidores similares, aunque sin ningún tipo de API estándar.

A diferencia de la IaaS, las ofertas de FaaS del proveedor de la nube suelen facturarse por invocación o por segundo de ejecución de la función, con una duración máxima de 5 a 15 minutos por invocación. La facturación por invocación puede dar lugar a costes muy bajos para funciones utilizadas con poca frecuencia, así como a una facturación favorable para cargas de trabajo en ráfaga que reciben miles de peticiones y luego están inactivas durante minutos u horas. Para permitir este modelo de facturación, los proveedores de la nube operan plataformas multiusuario que aíslan las funciones de cada usuario entre sí, a pesar de ejecutarse en el mismo hardware físico con pocos segundos de diferencia.

Alrededor de 2019, el término "sin servidor" se asociaba principalmente a la FaaS, ya que la BaaS había caído en desgracia. A partir de ese momento, el apelativo "sin servidor" empezó a utilizarse para servicios no informáticos, que funcionaban bien con el modelo de facturación FaaS: cobrar sólo por las llamadas de acceso y el almacenamiento utilizados, en lugar de por unidades de servidor de larga duración. En el Capítulo 1 hablaremos de las diferencias entre la informática tradicional con servidor y sin servidor, pero esta nueva definición permite ampliar la noción de sin servidor a los sistemas de almacenamiento y servicios especializados como la transcodificación de vídeo o el reconocimiento de imágenes por IA.

Aunque las definiciones de "proveedor de la nube" o "software nativo de la nube" mencionadas han sido algo fluidas a lo largo del tiempo, el apelativo "sin servidor" ha sido especialmente fluido: un entusiasta de los servicios sin servidor de 2014 estaría bastante confundido por la mayoría de los servicios ofrecidos bajo ese nombre ocho años después.

Una nota final de desambiguación en : Las redes de telecomunicaciones 5G han introducido el confuso término "función de red como servicio", que es la idea de que el comportamiento de enrutamiento de red de larga duración, como los cortafuegos, podría ejecutarse como un servicio en una plataforma virtualizada que no está asociada a ninguna máquina física concreta. En este caso, el término "función de red" implica una arquitectura sustancialmente diferente, con servidores de larga vida pero móviles, en lugar de una arquitectura distribuida sin servidores .

Cómo está organizado este libro

Este libro se divide en cuatro partes principales.² Tiendo a aprender desarrollando un modelo mental de lo que ocurre, luego probando cosas para ver dónde mi modelo mental no es del todo correcto y, finalmente, desarrollando una pericia profunda tras un uso prolongado. Las partes corresponden a este modelo: las del Cuadro P-1.

Tabla P-1. Partes del libro

Pieza	Capítulo	Descripción
Parte I, "La Teoría del Sin Servidor"	Capítulo 1	Definiciones y descripciones de lo que ofrecen las plataformas sin servidor.
	Capítulo 2	Construir aprendiendo: una aplicación sin estado en Knative.
	Capítulo 3	Una inmersión profunda en la implementación de Knative, un sistema de computación sin servidor.
	Capítulo 4	Este capítulo enmarca el movimiento sin servidor en términos de valor empresarial.
Parte II, "Diseñar sin servidor"	Capítulo 5	Una vez adquiridos los conocimientos sobre la tecnología sin servidor, este capítulo explica cómo aplicar los patrones del Capítulo 2 a las aplicaciones existentes.
	Capítulo 6	Los eventos son un patrón común para orquestar aplicaciones sin estado. Este capítulo explica varios patrones de arquitectura basada en eventos.
	Capítulo 7	Aunque el Capítulo 6 trata de la conexión de eventos a una aplicación, este capítulo se centra específicamente en la creación de una aplicación sin servidor que aproveche los eventos de forma nativa.
	Capítulo 8	Tras cuatro capítulos de vítores a la arquitectura sin servidor, este capítulo se centra en los patrones que pueden frustrar la arquitectura de una aplicación sin servidor.
Parte III, "Vivir sin servidor"	Capítulo 9	Tras las advertencias del Capítulo 8sobre los antipatrones sin servidor, este capítulo relata los obstáculos operativos al nirvana sin servidor.
	Capítulo 10	Mientras que el Capítulo 9 se centra en los colapsos espectaculares, este capítulo trata de las herramientas de depuración necesarias para resolver los fallos habituales y cotidianos de las aplicaciones.
Parte IV, "Breve historia de Serverless"	Capítulo 11	Contexto histórico del desarrollo de las abstracciones informáticas sin servidor.

Convenciones utilizadas en este libro

En este libro se utilizan las siguientes convenciones tipográficas:

Cursiva

Indica nuevos términos, URL, direcciones de correo electrónico, nombres de archivo y extensiones de archivo.

Constant width

Se utiliza en los listados de programas, así como dentro de los párrafos para referirse a elementos del programa como nombres de variables o funciones, bases de datos, tipos de datos, variables de entorno, sentencias y palabras clave.

Constant width bold

Muestra comandos u otros textos que deben ser tecleados literalmente por el usuario.

Constant width italic

Muestra el texto que debe sustituirse por valores proporcionados por el usuario o por valores determinados por el contexto.

Consejo

Este elemento significa un consejo o sugerencia.

Nota

Este elemento significa una nota general.

Advertencia

Este elemento indica una advertencia o precaución.

Utilizar ejemplos de código

El material complementario (ejemplos de código, ejercicios, etc.) se puede descargar en https://oreil.ly/BSAK-supp.

Este libro está aquí para ayudarte a hacer tu trabajo. En general, si se ofrece código de ejemplo con este libro, puedes utilizarlo en tus programas y documentación. No es necesario que te pongas en contacto con nosotros para pedirnos permiso, a menos que estés reproduciendo una parte importante del código. Por ejemplo, escribir un programa que utilice varios trozos de código de este libro no requiere permiso. Vender o distribuir ejemplos de los libros de O'Reilly sí requiere permiso. Responder a una pregunta citando este libro y el código de ejemplo no requiere permiso. Incorporar una cantidad significativa de código de ejemplo de este libro en la documentación de tu producto sí requierepermiso.

Agradecemos, pero generalmente no exigimos, la atribución. Una atribución suele incluir el título, el autor, la editorial y el ISBN. Por ejemplo "Building Serverless Applications on Knative por Evan Anderson (O'Reilly). Copyright 2024 Evan Anderson, 978-1-098-14207-0".

Si crees que el uso que haces de los ejemplos de código no se ajusta al uso legítimo o al permiso concedido anteriormente, no dudes en ponerte en contacto con nosotros en [e-mail].

Aprendizaje en línea O'Reilly

Nota

Durante más de 40 años, O'Reilly Media ha proporcionado formación tecnológica y empresarial, conocimientos y perspectivas para ayudar a las empresas a alcanzar el éxito.

Nuestra red única de expertos e innovadores comparten sus conocimientos y experiencia a través de libros, artículos y nuestra plataforma de aprendizaje online. La plataforma de aprendizaje en línea de O'Reilly te ofrece acceso bajo demanda a cursos de formación en directo, rutas de aprendizaje en profundidad, entornos de codificación interactivos y una amplia colección de textos y vídeos de O'Reilly y de más de 200 editoriales. Para más información, visitahttps://oreilly.com.

Cómo contactar con nosotros

Dirige tus comentarios y preguntas sobre este libro a la editorial:

• O'Reilly Media, Inc.
• 1005 Gravenstein Highway Norte
• Sebastopol, CA 95472
• 800-889-8969 (en Estados Unidos o Canadá)
• 707-829-7019 (internacional o local)
• 707-829-0104 (fax)
• [e-mail]
• https://www.oreilly.com/about/contact.html

Tenemos una página web para este libro, donde se enumeran erratas, ejemplos y cualquier información adicional. Accede a esta página en https://oreil.ly/BuildingServerlessAppsKnative.

Para obtener noticias e información sobre nuestros libros y cursos, visita https://oreilly.com.

Encuéntranos en LinkedIn: https://linkedin.com/company/oreilly-media.

Síguenos en Twitter: https://twitter.com/oreillymedia.

Míranos en YouTube: https://youtube.com/oreillymedia.

Agradecimientos

Este libro se ha estado gestando durante al menos tres años.³ En muchos sentidos, también es el resultado de mis interacciones con usuarios y constructores de serverless, incluidos autores demúltiplesplataformas serverless, así como de la amplia y acogedora comunidad Knative. Este es el pueblo del que brotó este libro. Este libro aún sería un brote sin la ayuda de las muchas personas que han contribuido a este producto final.

En primer lugar están mis editores de O'Reilly, que me ayudaron en el proceso de publicar realmente un libro. John Devins se puso en contacto conmigo por primera vez en abril de 2022 para hablarme de la posibilidad de escribir un libro y me ayudó durante el proceso inicial de redacción y pulido de la propuesta inicial. Shira Evans fue una compañera paciente y persistente como editora de desarrollo: me ayudó a encontrar la motivación para escribir y a desatascarme cuando me retrasaba en el calendario, me recomendó contenido adicional incluso cuando eso retrasaba el calendario, y me proporcionó un optimismo constante de que este libro se haría. Por último, Clare Laylock fue mi editora de producción, y me ayudó a ver el libro terminado incluso después de haberlo leído una docena de veces.

Mis revisores técnicos proporcionaron comentarios incisivos (¡y amables!) sobre los primeros borradores de este libro. Sin sus perspectivas, este libro sería más tedioso y menos preciso. Incluso cuando la perspicacia significaba que tenía que escribir otra sección, tenía la confianza de que eran palabras que importaban. Celeste Stinger puso de relieve una serie de ideas sobre seguridad a las que había dado poca importancia en mi redacción inicial. Jess Males aportó un fuerte sentido de la urgencia y un pensamiento de fiabilidad práctica para perfeccionar mis primeros borradores. Y este libro tiene una inmensa deuda con Joe Beda, tanto por haberme puesto en el camino de la nube nativa que me ha traído hasta aquí, como por obligarme a explicar más claramente las ventajas y desventajas de una serie de ideas interesantes y destacar las partes que necesitaban más celebración.

Aunque los colaboradores nombrados ayudaron a mejorar este libro, mi familia me proporcionó el apoyo y la motivación necesarios para seguir adelante con este esfuerzo. La idea de escribir un libro a partir de mi propia experiencia surgió en mi imaginación a raíz del trabajo de mi padre escribiendo un libro de texto de álgebra lineal con el que pudiera disfrutar enseñando. Mi hijo, Erik, y mi hija, Eleanor, han sido excepcionalmente pacientes a la hora de encontrar su propio entretenimiento mientras yo me sentaba en espacios comunes a teclear en el portátil "trabajando en el libro", y han hecho ruidos de agradecimiento por lo bien que se ven los PDF de previsualización cuando los reviso. Sobre todo, este libro no habría sido posible sin Emily, mi mujer y compañera, que ha sido mi primera caja de resonancia, una distracción útil para los niños cuando necesitaba tiempo para concentrarme y una evaluadora realista de lo que puedo hacer cuando digo que quiero hacerlo todo. Y he aquí otra cosa que he conseguido hacer.

¹ Incluidos los ingenieros centrados en las operaciones, como los ingenieros de fiabilidad del sitio (SRE) o los profesionales de DevOps.

² La última parte es un capítulo porque no pude resistirme a añadir algunas notas históricas a pie de página en el capítulo 11.

³ O seis años si contamos el inicio de mi trabajo en Knative. O catorce si contamos mi primer uso de Google App Engine con ira.