Desarrollo nativo en la nube con Google Cloud

Capítulo 1. ¿Por qué nube nativa y no sólo nube?

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

A finales de los 90, cuando empecé mi carrera, el panorama digital estaba en las primeras fases de transformación. Las empresas estaban introduciendo servidores de correo electrónico por primera vez, a medida que los empleados empezaban a familiarizarse con los PC que tenían en sus mesas. Como técnico práctico, mi trabajo consistía en configurar estos ordenadores e instalar servidores de correo electrónico en salas de servidores, conectándolos a Internet mediante módems de acceso telefónico o líneas RDSI.

Por aquel entonces, una sala de ordenadores no era más que un armario con aire acondicionado que albergaba toda la infraestructura informática de la empresa. Recuerdo perfectamente haber instalado un servidor junto a un DEC VAX del tamaño de una lavadora, una reliquia informática de los años 80, que seguía funcionando tal y como aparecía en mis libros de informática.

Con el auge de las puntocom a principios de la década de 2000, una presencia sólida e ininterrumpida en Internet se convirtió en algo fundamental para las empresas. Las grandes empresas respondieron invirtiendo en centros de datos locales, instalaciones especializadas equipadas para albergar equipos informáticos con múltiples conexiones a Internet y fuentes de alimentación redundantes.

Sin embargo, construir un centro de datos dedicado no era factible para las empresas más pequeñas. En su lugar, podían alquilar espacio en centros de datos de colocación compartidos, o "CoLos". Pero esto planteaba un reto importante para las empresas emergentes de Internet: ¿Qué ocurre si te conviertes en un éxito de la noche a la mañana? ¿Y si tu base de usuarios pasa de mil a un millón de usuarios de la noche a la mañana?

¿Sería más sensato empezar con servidores que puedan dar cabida a mil usuarios y arriesgarte a que tu sitio web se caiga si no puedes escalar con suficiente rapidez? ¿O deberías invertir preventivamente en la capacidad de dar servicio a millones de usuarios, en caso de crecimiento rápido? Esta última opción requeriría una financiación significativa, posiblemente dependiente de un inversor de capital riesgo con los bolsillos llenos. Equilibrar este riesgo y el crecimiento potencial se convirtió en una cuestión acuciante para muchas empresas durante este tiempo.

Aparición de la era de la nube

La llegada de la nube pública marcó un importante punto de inflexión. Lanzada en 2006, Amazon Web Services (AWS) empezó a ofrecer servidores EC2 bajo demanda, y en 2008, cualquiera con una tarjeta de crédito podía configurar virtualmente un servidor en un instante. La posibilidad de ampliar sin problemas la capacidad de los servidores a medida que aumentaba la demanda cambió las reglas del juego. Las startups podían empezar con una infraestructura modesta y luego ampliarla a medida que fueran más rentables, minimizando así las inversiones iniciales y reduciendo el coste de la innovación.

En 2008, Google hizo lo propio con Google App Engine (GAE) , pionera de una de las primeras plataformas como servicio (PaaS). Con GAE, los desarrolladores podían escribir una aplicación web en PHP o Python e implementarla en la nube pública de Google, todo ello sin necesidad de gestionar la infraestructura del servidor. A pesar del potencial de GAE, presentaba retos para los desarrolladores como yo, acostumbrados a trabajar con aplicaciones tradicionales y bases de datos relacionales, debido a sus restricciones desconocidas.

A medida que avanzaba la década de 2010 y aumentaba la popularidad de la computación en nube, las empresas con costosos centros de datos locales empezaron a mirar con envidia a sus competidores nativos digitales. Empresas como Netflix, Airbnb y Slack. Estas nuevas entidades, nacidas en la nube y que desplegaban software en plataformas como AWS, Google Cloud y Microsoft Azure, lanzaban rápidamente productos competitivos sin tener que soportar los onerosos costes de mantener un centro de datos. También estaban aprovechando servicios adicionales en la nube bajo demanda, como el aprendizaje automático y la IA, que ofrecían capacidades sin precedentes.

Las empresas establecidas, arraigadas en las operaciones tradicionales de los centros de datos, encontraron irresistible el atractivo de la nube por varias razones, como se muestra en la Figura 1-1.

Figura 1-1. Ve más rápido, ahorra dinero y haz más

Estos eran típicamente:

Ve más rápido

Mejora la productividad de los desarrolladores aprovechando los recursos escalables bajo demanda de la nube y una amplia gama de servicios preconstruidos. Esto permite a los desarrolladores centrarse en la lógica central de la aplicación en lugar de en la gestión de la infraestructura.

Ahorra dinero

Disminuye los costes operativos o de infraestructura pasando de los gastos de capital (CapEx) para hardware y mantenimiento a los gastos operativos (OpEx) para servicios a la carta, mejorando el flujo de caja y reduciendo las inversiones iniciales.

Haz más

Accede a recursos y servicios poco prácticos en una configuración local, como amplias opciones de almacenamiento escalable, potentes herramientas de análisis de datos, plataformas de aprendizaje automático y servicios avanzados de IA.

El paso en falso crítico que suelen dar estas organizaciones es migrar a la nube sin comprender su naturaleza única, la complejidad añadida y cómo exige cambios en las prácticas de desarrollo de software. Como resultado, en lugar de mejorar la eficiencia y reducir los costes, la nube puede a veces introducir complicaciones y gastos adicionales, ralentizando así el progreso y aumentando los gastos. Por lo tanto, el beneficio frecuentemente prometido de "hacer funcionar tu lío por menos" rara vez se materializa, lo que subraya la importancia de un enfoque bien informado y estratégico de la migración a la nube.

Navegar por la migración a la nube

Soy una gran admiradora de Marie Kondo, la consultora organizadora japonesa que alegra los hogares transformando los espacios desordenados en reinos de tranquilidad yeficacia.

Imagínate un armario rebosante de dos décadas de posesiones acumuladas: una mezcla de objetos obsoletos, rotos y sin abrir. Entre ellos hay objetos que has comprado por duplicado, ignorando su existencia en lo más profundo de los desordenados confines. En medio del caos, algunos objetos útiles aguardan a ser descubiertos. Sin embargo, intentar excavarlos podría provocar una avalancha catastrófica. Créeme, yo poseo un armario así.

Este escenario representa adecuadamente un típico centro de datos local, un laberinto de aplicaciones sin discernimiento de su importancia.

En la búsqueda de los beneficios de la nube, se instó a las empresas a ejecutar una estrategia de "levantar y cambiar", trasladando sus aplicaciones existentes a la nube al por mayor. Esta estrategia a menudo se parece a trasladar tu armario desordenado a un garaje alquilado en otra parte de la ciudad. Sigues lidiando con la misma cantidad de cosas; sólo que es más incómodo acceder a ellas y asegurarlas. Por no mencionar que el garaje conlleva un coste adicional de alquiler.

Como alternativa a "levantar y cambiar", también se recomendó a las empresas que "contengan" sus aplicaciones antes de migrar a la nube. Utilizando la analogía del armario, esto equivaldría a empaquetar tus pertenencias en cajas de plástico antes de trasladarlas al garaje. La contenedorización simplifica el transporte y la gestión de las aplicaciones y facilita futuros traslados entre distintas unidades de almacenamiento. No obstante, hereda los inconvenientes del almacenamiento en garajes, junto con el gasto añadido de los contenedores. Esta estrategia de "mover y mejorar" parece atractiva, pero la motivación para ordenar el desorden a menudo disminuye una vez que está fuera de la vista.

Las trampas de un viaje no planificado

Lo ideal es desordenar el armario por completo. Los objetos rotos deben repararse o desecharse, las pertenencias obsoletas deben eliminarse y las duplicadas o no utilizadas deben donarse. Siguiendo el mantra de Marie Kondo, deberías conservar sólo los objetos que "despierten alegría". Una vez completada esta selección, puedes plantearte si exponer estos objetos preciados en un lugar destacado o guardarlos de forma ordenada y segura.

En el ámbito de la tecnología en la nube, este enfoque se traduce en la modernización de la nube: una revisión y reestructuración exhaustivas de las aplicaciones para un rendimiento óptimo en la nube. Este tema, sin embargo, queda fuera del alcance de este libro. Como han descubierto muchas empresas, la modernización de la nube puede ser un proceso largo y costoso. Muchas empresas han recurrido a las estrategias lift and shift o de contenedorización, sólo para descubrir que sus aplicaciones son más difíciles de gestionar y seguras, y más caras de ejecutar en la nube.

Las experiencias menos que óptimas con la migración a la nube han provocado escepticismo y decepción en torno a la nube. Se ha recordado a las empresas que no existe una solución única ni una solución rápida. A pesar de esta desilusión, los competidores nativos digitales siguen aprovechando las ventajas de la nube, lo que justifica una exploración más profunda de lo que diferencia a estas empresas en su estrategia en la nube.

Más que un centro de datos en línea

Los nativos digitales entienden que el verdadero poder de los servicios de nube pública reside en sus centros de datos masivos, distribuidos globalmente, compartidos y altamente automatizados. Estas características permiten ofrecer una facturación de pago por uso, una escalabilidad prácticamente ilimitada y un modelo de consumo de autoservicio, como se muestra en la Figura 1-2.

Figura 1-2. Ventajas de la nube

Sin embargo, las nubes públicas se construyen a partir de hardware básico conectado por redes que se han seleccionado para minimizar el coste total de propiedad. El hardware lo gestiona un proveedor externo y lo comparten varios clientes. Es crucial comprender que la computación en nube no es intrínsecamente más fiable, rentable o segura que gestionar tu propio centro de datos:

• El hardware de los centros de datos se construye a menudo para la redundancia y la optimización de tareas específicas, mientras que en la nube, el hardware es genérico, comoditizado y diseñado con la expectativa de un fallo ocasional.

• En un centro de datos, eres propietario del hardware y es difícil cambiarlo. En cambio, la nube proporciona hardware alquilado minuto a minuto, lo que permite cambiar fácilmente, pero a un precio superior al de tu hardware.

• Un centro de datos físico tiene un muro eficaz a su alrededor, que engendra un nivel de confianza implícito en la infraestructura de su interior. En la nube, sin embargo, debe adoptarse un enfoque de no confianza.

La transición a la nube no es simplemente una cuestión de transferir las operaciones tradicionales de tu centro de datos a Internet. Representa una oportunidad para aprovechar una potente tecnología que puede remodelar fundamentalmente las operaciones empresariales. Sin embargo, esto requiere el enfoque correcto. Limitarse a replicar tu configuración local en la nube sin adaptar tus métodos puede dar lugar a costes más elevados, mayores riesgos de seguridad y una fiabilidad potencialmente reducida, como se muestra en la Figura 1-3. Esto no aprovecha todo el potencial de la nube y puede ser contraproducente.

Figura 1-3. La realidad de tratar la nube como otro centro de datos

En cambio, reconocer las características y requisitos únicos de la nube y adoptarlos plenamente puede ser verdaderamente transformador. Aprovechar las características de elasticidad, escalabilidad y seguridad avanzada de la nube puede conducir a niveles de eficacia operativa, rentabilidad e innovación que superan lo que pueden ofrecer los entornos tradicionales de centros de datos.

La nube no es sólo una variante en línea de tu actual centro de datos. Es un paradigma diferente que exige un enfoque distinto. Cuando se maneja con habilidad, puede desbloquear un mundo de oportunidades que superan con creces las que ofrece la infraestructura tradicional. Acepta las diferencias, y todo el potencial de la nube será inmenso.

Adoptar la nube como sistema distribuido

La verdad esencial de la nube es que funciona como un sistema distribuido. Esta característica clave dejaobsoletos muchos supuestos inherentes al desarrollo tradicional.

Estos conceptos erróneos, denominados falacias de la informática distribuida, fueron identificados por primera vez por L Peter Deutsch y sus colegas de Sun Microsystems:

• La red es fiable.

• La latencia es cero.

• El ancho de banda es infinito.

• La red es segura.

• La topología no cambia.

• Hay un administrador.

• El coste de transporte es cero.

• La red es homogénea.

Cada uno de estos puntos representa un obstáculo que hay que superar cuando se intenta construir una nube desde cero. Afortunadamente, los proveedores de la nube han dedicado importantes recursos de ingeniería en las dos últimas décadas para construir abstracciones de más alto nivel a través de API, abordando eficazmente estos problemas. Esta es precisamente la razón por la que los nativos digitales tienen un perímetro de ventaja: están en sintonía con el desarrollo nativo de la nube, una metodología que aprovecha este trabajo de base.

El desarrollo nativo de la nube reconoce las características distintivas de la nube y aprovecha las abstracciones de alto nivel que proporcionan las API de los proveedores de la nube. Es un estilo de desarrollo en sintonía con las realidades de la nube, que abraza sus idiosincrasias y las aprovecha en todo su potencial.

Distinguir la nube alojada de la nube nativa

Comprender la diferencia entre las aplicaciones alojadas en la nube y las aplicaciones nativas de la nube es fundamental. En pocas palabras, la primera tiene que ver con el dónde, y la segunda con el cómo.

Las aplicaciones pueden alojarse en la nube, ejecutándose en la infraestructura proporcionada por un proveedor de nube pública, pero con una arquitectura tradicional, como si funcionaran en un centro de datos local. A la inversa, las aplicaciones pueden diseñarse de forma nativa en la nube y seguir alojadas en un centro de datos local, como se muestra en la Figura 1-4.

Figura 1-4. La nube alojada es dónde, la nube nativa es cómo

Cuando me refiero a la nube nativa, hablo del estilo de desarrollo, la arquitectura de la aplicación y la abstracción que proporcionan las API de la nube, más que de la ubicación del alojamiento.

Este libro explora principalmente la construcción de aplicaciones nativas de la nube utilizando Google Cloud, que abarca tanto los principios de la nube alojada como los de la nube nativa, la parte inferior derecha de la Figura 1-4. Sin embargo, ten en cuenta que gran parte de la información que aquí se comparte también es aplicable a las nubes privadas e híbridas locales, en particular las construidas en torno a contenedores y Kubernetes, como Red Hat OpenShift, VMWare Tanzu y Google Anthos, abajo a la izquierda en la Figura 1-4.

Desentrañar el concepto de nube nativa

El término "nativo de la nube" solía darme escalofríos, pues sentía que su significado se había diluido porque los vendedores de software lo utilizaban simplemente como un sello de aprobación para indicar que sus aplicaciones eran compatibles con la nube y modernas. Me recordaba a otras palabras de moda como "ágil" o "DevOps", que han sido reformuladas con el tiempo por empresas con algo que vender.

Sin embargo, la Fundación para la Computación Nativa en la Nube (CNCF), un proyecto de la Fundación Linux creado para impulsar los esfuerzos de la industria tecnológica hacia el avance de las tecnologías nativas de la nube, ofrece una definición concisa:

Las tecnologías nativas de la nube permiten a las organizaciones crear y ejecutar aplicaciones escalables en entornos modernos y dinámicos, como nubes públicas, privadas e híbridas. Los contenedores, las mallas de servicios, los microservicios, la infraestructura inmutable y las API declarativas ejemplifican este enfoque.

Estas técnicas permiten que los sistemas poco acoplados sean resistentes, manejables y observables. Combinadas con una automatización robusta, permiten a los ingenieros realizar cambios de gran impacto de forma frecuente y predecible con un esfuerzo mínimo.

En mi primera defensa de la tecnología nativa de la nube, solía caracterizarla como un conjunto de microservicios, contenedores, automatización y orquestación. Sin embargo, esto fue un paso en falso; aunque estos son componentes vitales de una solución nativa de la nube, son sólo los aspectos tecnológicos a los que se hace referencia en la primera parte de la definición de la CNCF. Confundir la nube nativa con un cambio puramente tecnológico es una de las razones clave por las que fracasan muchas iniciativas de nube nativa.

Introducir tecnologías como Kubernetes puede ser bastante perturbador debido a la pronunciada curva de aprendizaje y a la complejidad añadida que presentan para los desarrolladores. Si a los desarrolladores simplemente se les entrega un clúster de Kubernetes y se espera que lo gestionen, es inevitable que surjan problemas. Un error común es pensar que la nube nativa empieza y termina con los contenedores o Kubernetes, pero esto está muy lejos de la realidad.

También hay cuestiones relacionadas con el coste y la seguridad. Ambos aspectos sufren cambios significativos con la nube, especialmente en un escenario nativo de nube. Los desarrolladores tienen que trabajar dentro de unos límites adecuados para evitar errores costosos o fallos de seguridad que podrían comprometer la reputación de una organización.

Lo que es más crucial en la definición del CNCF es la segunda parte: las técnicas. Éstas reflejan un estilo de desarrollo que aprovecha los puntos fuertes de la nube al tiempo que reconoce sus limitaciones.

La nube nativa consiste en reconocer que el hardware fallará, las redes pueden ser poco fiables y la demanda de los usuarios fluctuará. Además, las aplicaciones modernas necesitan adaptarse continuamente a las necesidades de los usuarios y, por tanto, deben diseñarse teniendo en cuenta esta flexibilidad. El concepto de nube nativa se extiende a considerar las limitaciones de la nube tanto como a utilizar sus ventajas.

Adoptar la nube nativa significa un cambio mental hacia el diseño de aplicaciones para aprovechar al máximo las abstracciones expuestas por las API de los proveedores de la nube. Esto implica pasar de pensar en términos de elementos de hardware como servidores, discos y redes a abstracciones superiores como unidades de cálculo, almacenamiento y ancho de banda.

Es importante destacar que la nube nativa está orientada a resolver problemas clave:

• Desarrollar aplicaciones fáciles de modificar

• Crear aplicaciones más eficaces y fiables que la infraestructura en la que se ejecutan

• Establecer medidas de seguridad basadas en un modelo de confianza cero

El objetivo final de la nube nativa es conseguir ciclos de respuesta cortos, tiempo de inactividad cero y una seguridad robusta.

Por tanto, "nativo de la nube" ya no me da escalofríos; encapsula y comunica un estilo de desarrollo que supera las limitaciones de la nube y libera todo su potencial.

En esencia, la nube nativa actúa como catalizador, haciendo realidad la promesa inicial de la computación en nube: desarrollo acelerado, ahorro de costes y capacidades mejoradas.

Adoptar la arquitectura nativa de la nube

La arquitectura nativa de la nube adopta un conjunto de principios rectores diseñados para explotar los puntos fuertes y eludir las limitaciones de la nube. A diferencia de la arquitectura tradicional, que trataba los cambios, fallos y amenazas a la seguridad como excepciones, la arquitectura nativa de la nube los anticipa como normas inevitables.

Los conceptos clave de la Figura 1-5 sustentan la arquitectura nativa de la nube.

Figura 1-5. Principios de la arquitectura nativa de la nube

Exploremos cada uno de estos conceptos:

Independencia de los componentes

Una arquitectura está débilmente acoplada cuando sus componentes individuales del sistema se diseñan y modifican independientemente. Esta disposición permite que distintos equipos desarrollen componentes separados sin retrasos causados por interdependencias. Cuando se implementan, los componentes pueden escalarse individualmente. Si falla un componente, el sistema global sigue funcionando.

Resistencia incorporada

Un sistema resistente funciona sin problemas y se recupera automáticamente en medio de cambios en la infraestructura subyacente o fallos de componentes individuales. Los sistemas nativos de la nube están diseñados intrínsecamente para adaptarse a los fallos. Esta resiliencia puede lograrse mediante la ejecución de múltiples instancias de un componente, la recuperación automática de componentes fallidos o una combinación de ambas estrategias.

Observabilidad transparente

Dado que un sistema nativo de la nube abarca múltiples componentes, comprender el comportamiento del sistema y depurar los problemas puede ser complejo. Por tanto, es crucial que el sistema esté diseñado para permitir una clara comprensión de su estado a partir de sus salidas externas. Esta observabilidad puede facilitarse mediante un registro exhaustivo, métricas detalladas, herramientas de visualización eficaces y sistemas de alerta proactivos.

Gestión declarativa

En un entorno nativo de la nube, el hardware subyacente lo gestiona otra persona, con capas de abstracción construidas encima para simplificar las operaciones. Los sistemas nativos de la nube prefieren un enfoque declarativo a la gestión, priorizando el resultado deseado(qué) sobre los pasos específicos para conseguirlo(cómo). Este estilo de gestión permite a los desarrolladores centrarse más en abordar los retos empresariales.

Seguridad de confianza cero

Dado que todo en la nube pública es compartido, es esencial una postura predeterminada de confianza cero. Los sistemas nativos de la nube cifran los datos tanto en reposo como en tránsito y verifican rigurosamente cada interacción entre componentes.

A medida que explore estos principios en capítulos posteriores, examinaré cómo diversas herramientas, tecnologías y técnicas pueden facilitar estos conceptos.

Construir una plataforma nativa en la nube

Los proveedores de la nube ofrecen una amplia gama de herramientas y tecnologías. Para que la arquitectura nativa de la nube prospere, es crucial sinergizar estas herramientas y aplicarlas utilizando técnicas nativas de la nube. Este enfoque sentará las bases de una plataforma propicia para el desarrollo eficiente de aplicaciones nativas de la nube.

Laboratorio, Fábrica, Ciudadela y Observatorio

Cuando conceptualices una plataforma nativa de la nube, imagina la construcción de cuatro "instalaciones" clave sobre la nube: el laboratorio, la fábrica, la ciudadela y el observatorio, como se muestra en la Figura 1-6. Cada una sirve a un propósito específico para promover la productividad, la eficiencia y la seguridad:

Laboratorio

El laboratorio maximiza la productividad de los desarrolladores proporcionándoles un entorno sin fricciones, equipado con las herramientas y recursos necesarios para la innovación y el desarrollo de aplicaciones. Debe fomentar un entorno seguro que propicie la experimentación y la retroalimentación rápida.

Fábrica

La fábrica da prioridad a la eficacia. Procesa la aplicación -creada originalmente en el laboratorio- a través de varias etapas de montaje y pruebas rigurosas. El resultado es una aplicación segura, escalable y de bajo mantenimiento, lista para suimplementación.

Ciudadela

La ciudadela es un entorno fortificado diseñado para ejecutar la aplicación de forma segura y eficaz, protegiéndola de posibles ataques.

Observatorio

El observatorio sirve como centro de supervisión de todos los servicios y aplicaciones que se ejecutan en la nube.

Figura 1-6. Desarrollar instalaciones en la nube eficaces

Es fundamental garantizar una transición fluida de las aplicaciones desde el laboratorio, pasando por la fábrica, hasta la ciudadela. El mismo código inmutable debe transportarse automáticamente entre las distintas instalaciones.

La necesidad de algo más que una fábrica

En los años 90, cuando pensaba qué estudiar en la universidad, encontré la inspiración en un episodio del programa de televisión de la BBC Troubleshooter. El imponente Sir John Harvey-Jones visitaba la empresa de coches clásicos Morgan, en apuros, y les sugería que sustituyeran sus anticuados métodos de fabricación por una fábrica moderna para mejorar la producción y la consistencia del producto. Desde entonces, me cautivó la idea de mejorar la eficacia de las empresas.

Sin embargo, una década más tarde, un episodio de seguimiento reveló que Morgan había desafiado por completo el consejo de Sir John, capitalizando en cambio su artesanía única como argumento de venta. Sorprendentemente, el propio programa de televisión acabó promocionando su artesanía y atrayendo a nuevos clientes.

Para muchas empresas, la perspectiva de establecer una fábrica presenta unasolución tentadora para racionalizar lo que a menudo se percibe como el caótico paisaje de la nube. Como ingeniero, naturalmente gravito hacia ese orden sistemático. Sin embargo, confinar y regular el desarrollo únicamente dentro de una línea de producción automatizada entraña el riesgo de sacrificar la innovación y la artesanía, atributos que a menudo distinguen a un producto. Un enfoqueexclusivamente fabril podría socavar la libertad creativa facilitada por la nube pública bajo demanda, que los nativos digitales aprovechan hábilmente.

Para aprovechar todo el potencial de la nube, no basta con tener una fábrica para automatizar las pruebas y garantizar la coherencia de la calidad; un laboratorio es igualmente crucial. En este espacio, los desarrolladores pueden elaborar e innovar rápidamente un producto en un entorno seguro, con una amplia gama de herramientas a su disposición, antes de pasar sin problemas a la fábrica.

Una vez que la fábrica ha producido aplicaciones probadas a fondo y de confianza, es necesaria una tercera instalación, la ciudadela, donde la aplicación pueda funcionar con seguridad en un entorno de producción.

El potencial para los promotores

A lo largo de mi carrera como desarrollador, he experimentado obstáculos tanto técnicos como burocráticos que han dificultado mi productividad y, con el tiempo, han minado mi moral. Un ejemplo clásico podría ser la penosa espera de semanas para que se apruebe o aprovisione una nueva máquina virtual, o simplemente esperar a que se concedan permisos.

Hace varios años, cuando empecé a utilizar la nube pública para mis proyectos personales, me sorprendió la diferencia. Era como correr sin obstáculos en lugar de vadear el fango. A medida que las plataformas en la nube han ido madurando en los últimos años, esta experiencia no ha hecho sino mejorar.

Marie Kondo, conocida por abogar por el orden, también subraya la importancia de la alegría. Para los desarrolladores, la alegría no es una mera quimera; puede hacerse realidad en un entorno sin fricciones que permita a los desarrolladores trabajar en un estado de flujo. Con una plataforma nativa en la nube que ponga la experiencia del desarrollador en primer plano, tú también podrás disfrutar de esta experiencia.

Equipado con el apoyo de un laboratorio, una fábrica, una ciudadela y un observatorio, un individuo sentado en una cafetería con sólo un portátil y una conexión a Internet tiene el poder de diseñar e implementar una aplicación que puede escalar a millones de usuarios, igual que la organización multinacional más extensa. Para aumentar la emoción, numerosos gigantes de la nube compiten para facilitarte aún más esta tarea.

Como individuo nativo digital, no estás atado a un centro de datos ni a las aplicaciones tradicionales. Puedes empezar a desarrollar en un estilo nativo de la nube de inmediato. A medida que disfrutes de las ventajas de ser un nativo digital, puedes continuar por este camino o prestar tu experiencia a una organización que pretenda adoptar un estilo de desarrollo nativo de la nube. En cualquier caso, tus habilidades serán muy buscadas y valiosas.

Recuerdo las palabras de un conferenciante de finales de la década de 2000, cuando los smartphones empezaban a dominar el mercado. Describían a los fabricantes de teléfonos móviles y a los operadores de redes como enfrascados en una guerra, en la que los desarrolladores de aplicaciones móviles eran la munición. Hoy, cuando las organizaciones se esfuerzan por explotar todo el potencial de la nube, los desarrolladores nativos de la nube se han convertido en la nueva munición.

Este libro consolida mis aprendizajes a lo largo de los años para ayudarte a experimentar la misma alegría -un término que utilizo con la mayor sinceridad- que yo he obtenido como desarrollador nativo en la nube. Su objetivo es ofrecerte una ruta accesible y de bajo coste para experimentar la productividad del desarrollo nativo en la nube como individuo, mediante la elaboración de una experiencia de desarrollador (DX) que realmente funcione para ti.

Además, ofrece una visión suficiente de las preocupaciones empresariales para introducir con éxito el desarrollo nativo en la nube en un entorno a escala. Alcanzar el mismo nivel de productividad en el trabajo que en tus proyectos personales puede ayudarte a experimentar esta alegría también en el lugar de trabajo.

Resumen

La nube nativa representa un enfoque arquitectónico y una metodología de desarrollo que aprovecha plenamente el potencial de la nube. Se caracteriza por técnicas, herramientas y tecnologías específicas diseñadas para potenciar los puntos fuertes y mitigar los puntos débiles inherentes a la computación en nube. Es importante destacar que el alcance de la nube nativa no se limita a Google Cloud o incluso a la nube pública. Abarca un amplio espectro de metodologías aplicables allí donde estén presentes abstracciones similares a la nube.

Para prosperar en el ecosistema nativo de la nube, los desarrolladores necesitan aprovechar el potencial de cuatro instalaciones distintas pero interdependientes: un laboratorio para la exploración innovadora, una fábrica para la automatización racionalizada de la producción, una ciudadela para la defensa robusta de las aplicaciones activas y un observatorio para la supervisión exhaustiva del sistema.

El resto de este libro te guiará a través de estas metodologías nativas de la nube, demostrándote cómo crear y optimizar un laboratorio, una fábrica, una ciudadela y un observatorio utilizando Google Cloud. El objetivo es equiparte con los conocimientos y estrategias que maximicen tus posibilidades de alcanzar el éxito nativo de la nube. Antes de embarcarte en este viaje, examinemos primero por qué Google Cloud, entre otras, ofrece un entorno especialmente propicio para el desarrollo nativo en la nube.