Transformación nativa en la nube

Capítulo 1. ¿Qué es la Nube Nativa? ¿Qué es la nube nativa?

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

Nativo de la nube es más que un conjunto de herramientas. Es una arquitectura completa, un enfoque filosófico para crear aplicaciones que aprovechen al máximo la computación en nube. También es compleja, tanto conceptualmente como en la práctica.

En este capítulo echaremos un vistazo a los principales componentes de un sistema nativo de la nube -los cinco principios- y cómo funcionan juntos. Comprender estos conceptos básicos ayuda a los recién llegados a ver cómo el verdadero valor de la nube nativa reside en aprovechar el ecosistema de servicios extraordinariamente sofisticados que ahora está a disposición de todas las empresas, no sólo de los gigantes tecnológicos.

La nube nativa no es "la nube"

Aunque los términos se confunden a menudo, la computación en nube y la nube nativa son dos entidades totalmente distintas.

La computación en nube -a menudodenominada simplemente "la nube" en - es la entrega bajo demanda de infraestructura (hardware/servidores), almacenamiento, bases de datos y todo tipo de servicios de aplicaciones a través de Internet. A menudo los proporciona una plataforma de servicios en la nube como Amazon Web Services, Google Cloud o Microsoft Azure, con precios medidos para que pagues sólo por los recursos que realmente consumes.

Nube nativa es una arquitectura para ensamblar todos los componentes anteriores basados en la nube de forma optimizada para el entorno de la nube. No se trata de los servidores, sino de los servicios. Así pues, la nube nativa es también un destino organizativo: el objetivo actual de las empresas que buscan modernizar su infraestructura y sus procesos, e incluso su cultura organizativa, eligiendo cuidadosamente las tecnologías en la nube que mejor se adapten a su caso concreto (al menos, el objetivo por ahora; con el tiempo, incluso muy pronto, la nube nativa será sustituida por otro paradigma que vuelva a cambiar por completo nuestra forma de hacer las cosas).

Ya está. Ha sido fácil.

Quizá demasiado fácil, en realidad. Después de todo, hay innumerables caminos para llegar a tu destino de migración nativa a la nube. Identificar, aprovisionar y luego implementar la combinación justa de servicios para aprovechar mejor este nuevo mundo en rápida evolución entre las nubes puede adoptar formas muy diferentes, según las necesidades de una organización concreta. Es fácil perderse.

Para las empresas dispuestas a emprender su propia migración a la nube, mantenerse en el buen camino significa centrarse en la arquitectura: comprender y priorizar el diseño antes de lanzarse de lleno a la implementación y el despliegue.

A lo largo de los cinco años que han pasado guiando a las empresas hacia la nube, los ingenieros de Container Solutions han aprendido un par de cosas (o tres) sobre cómo ayudar a cada empresa a encontrar su propio camino óptimo. Definitivamente, no estamos prescribiendo ninguna solución "de arriba abajo" que sirva para todos. Sin embargo, a estas alturas, mediante la observación y la experiencia, hemos recopilado suficientes datos para identificar algunos puntos de referencia necesarios para trazar esa ruta.

Desarrollar un lenguaje de patrones nativos de la nube es el siguiente paso para trazar una hoja de ruta útil y reutilizable. Un lenguaje compartido para identificar contextos comunes y debatir sobre herramientas, técnicas y métodos es esencial para que los desarrolladores puedan debatir, aprender y aplicar las buenas prácticas en la nube nativa, incluso mientras siguen surgiendo.

Pero primero echemos un vistazo rápido y básico a cómo funciona la nube nativa.

Introducción a la nube nativa

Empecemos por lo más parecido a una definición oficial de "nativo de la nube":

La computación nativa en la nube utiliza una pila de software de código abierto para desplegar aplicaciones como microservicios, empaquetando cada parte en su propio contenedor y orquestando dinámicamente esos contenedores para optimizar la utilización de los recursos.

Este procede de la Cloud Native Computing Foundation (CNCF), la entidad que supervisa y coordina la aparición de tecnologías de código abierto que apoyan el desarrollo de software nativo de la nube. La CNCF hace hincapié en las tecnologías de código abierto, pero también existen importantes herramientas nativas de la nube ofrecidas por proveedores comerciales.

Esencialmente, nube nativa es el nombre de un enfoque particular para diseñar, construir y ejecutar aplicaciones informáticas. La arquitectura se basa en la Infraestructura como Servicio, combinada con nuevas herramientas y servicios operativos como la integración continua, los motores de contenedores y los orquestadores. El objetivo, normalmente, es mejorar la velocidad. Empresas de todos los tamaños ven ahora una ventaja estratégica en poder moverse con rapidez y llegar rápido al mercado: poner una nueva idea en producción en cuestión de días o incluso horas, en lugar de meses.

De hecho, la mayoría de las empresas que migran a la nube nativa en la actualidad citan la velocidad como su principal motivo.

¿Cómo reconozco una nube nativa cuando la veo?

Los fundamentos de la nube nativa se describen más a menudo como empaquetamiento de contenedores, gestión dinámica y una arquitectura modular distribuida.

Nosotros, sin embargo, creemos que la nube nativa consiste en realidad en adoptar cinco principios arquitectónicos (que es difícil) más dos culturales (que es aún más difícil):

• Containerización: Encapsular las aplicaciones de junto con sus dependencias/entorno operativo, todo en un único paquete. Esto facilita su prueba, traslado e implementación.

• Gestión dinámica: Utilizando servidores basados en la nube que pueden aprovisionarse de forma flexible bajo demanda; si es en una nube pública, que es lo habitual, las empresas sólo pagan por los recursos cuando realmente se utilizan.

• Microservicios: Diseñar aplicaciones como una colección de pequeños servicios de componentes desacoplados. Cada microservicio puede desplegarse, actualizarse, escalarse y reiniciarse independientemente de los demás servicios de la aplicación, y sin afectar al usuario final. Los microservicios aumentan la velocidad al permitir que los equipos desarrollen en paralelo, trabajando en sus componentes de forma simultánea pero independiente, gracias a la eliminación de dependencias y los esfuerzos de coordinación que conllevan.

• Automatización: Sustituir las tareas manuales de, como el mantenimiento y la actualización, por scripts o código para que se realicen sin problemas y de forma fiable.

• Orquestación: Uniendo todo mediante la automatización de la implementación, el escalado y la gestión de aplicaciones en contenedores. En concreto, utilizando Kubernetes (u otra herramienta de orquestación de ) para controlar y automatizar tareas como la disponibilidad, el aprovisionamiento y la implementación de contenedores, el equilibrio de carga de contenedores en la infraestructura y el aumento/reducción de escala añadiendo/eliminando contenedores según sea necesario.

Los dos principios culturales son:

• Delegar: Ofrecer a las personas de las herramientas, la formación y la discreción que necesitan para realizar cambios con seguridad, y luego implementarlos y monitorizarlos de la forma más autónoma posible (es decir, sin necesidad de delegar en otros equipos o pedir permiso a través de un lento proceso de aprobación de la dirección).

• Estrategia dinámica: Comunicando la estrategia de a los equipos, pero permitiéndoles modificar esa estrategia en respuesta a sus resultados. Ese es el fin último de la implementación rápida y experimental que proporciona la nube nativa: no tiene sentido hacer experimentos si no aprovechas lo que aprendes.

En última instancia, la nube nativa trata de cómo creamos y entregamos, no de dónde. Así que, cuando veas una aplicación creada y desplegada en iteraciones rápidas por un grupo de equipos de desarrollo de funciones independientes y compactos -y que esos equipos colaboran a través de una plataforma integrada que desacopla la infraestructura a la vez que proporciona monitoreo y pruebas automatizados-, entonces sabrás que estás viendo el enfoque nativo de la nube en acción.

Nosotros,, no estamos considerando el enfoque nativo de la nube porque sea la tecnología de moda (aunque esto es innegablemente cierto). Nuestra motivación es pragmática: la nube nativa funciona bien con métodos de entrega de software rápidos y modernos, como la entrega continua, para proporcionar un tiempo de creación de valor más rápido; escala horizontalmente y sin esfuerzo; y su funcionamiento puede ser muy eficiente. La arquitectura nativa de la nube también nos permite crear sistemas complejos dividiéndolos en componentes más pequeños construidos por equipos independientes. Esto difiere de la complejidad de las aplicaciones monolíticas tradicionales, que está limitada por la capacidad de los desarrolladores y arquitectos para comprenderla completamente, incluso cuando los encadena para entregar al unísono.

Y lo que es más importante, la nube nativa puede ayudar a reducir el riesgo de una forma nueva: yendo rápido pero en pequeño, limitando el radio de explosión en caso de que los cambios salgan mal, y revirtiéndolos al instante si lo hacen. Entonces, ¿cómo y dónde empezamos a construir?

Todo es cuestión de servicios

El corazón de la nube nativa son los servicios basados en la nube. Es la plataforma sobre la que construimos, lanzamos y operamos nuestro imperio de aplicaciones modulares distribuidas, en contenedores y automatizadas. Hay distintos tipos de servicios disponibles en los proveedores de nubes públicas:

• Infraestructura como servicio: Este es el más obvio, e incluye hardware, almacenamiento de datos y redes fuera de las instalaciones. Contratar la infraestructura en lugar de poseerla te permite maximizar la creatividad de cada equipo en lugar de limitarla a las capacidades de un equipo de arquitectura central.

• Plataforma como servicio: Este puede utilizarse para gestionar y mantener toda esa infraestructura virtualizada, reduciendo enormemente la carga de tu equipo de Operaciones (o Plataforma).

• Software como servicio: Esto permite a elegir las aplicaciones que lo componen, desde software empresarial tradicional (piensa en MS Office 365 o Adobe Creative Cloud) hasta herramientas de gestión de infraestructuras virtuales, todo ello suministrado a través de la web y operado por ella. El proveedor garantiza la seguridad, la disponibilidad y el rendimiento.

• Contenedor como servicio: Esto permite a entregar motores de contenedores, orquestación y todos los recursos informáticos subyacentes para su entrega a los usuarios como un servicio de tu proveedor de la nube.

• *-as-a-Service: Si puedes soñarlo, si tu negocio lo requiere, probablemente exista un servicio para ello. Si no existe ahora mismo, espera uno o dos meses. Backend-as-a-Service, Functions-as-a-Service: estos servicios, que antes eran una quimera, están cruzando el abismo hacia la plena introducción en la empresa, incluso mientras escribimos este libro.

Todos los servicios en la nube llegan preconstruidos y listos para conectarse con cualquier otro servicio, por lo que puedes ponerte a trabajar más o menos al instante. Sin embargo, para utilizarlos eficazmente, debes emplear la arquitectura adecuada.

Comprender los principios

La nube nativa es mucho en lo que pensar: es una arquitectura, una pila tecnológica, un enfoque del desarrollo y la entrega de software, ¡y un cambio de paradigma completo, todo en uno! Para confundir aún más las cosas, las implementaciones nativas de la nube varían mucho entre empresas gracias al gran número de herramientas disponibles, así como a la complejidad que ofrecen. Sin embargo, la simple comprensión de estos cinco principios fundamentales de la arquitectura nativa de la nube -y, lo que es aún más importante, cómo se interrelacionan y apoyan entre sí- te da las claves del reino nativo de la nube, por muy complicado que se ponga.

Para reiterar, los cinco principios consisten en:

• Contenedorización

• Gestión dinámica

• Microservicios

• Automatización

• Orquestación

Contenedorización

Una vez que has definido tu arquitectura basada en servicios, sólo tiene sentido (para casi todo el mundo, en todas partes) contenerizar las cosas. Los contenedores son paquetes de software ejecutables, ligeros e independientes que incluyen todo lo necesario para ejecutar una aplicación: código, tiempo de ejecución, herramientas del sistema, bibliotecas y configuraciones. Son una especie de "unidad estándar" de software que empaqueta el código con todas sus dependencias para que pueda ejecutarse en cualquier lugar, en cualquier entorno informático. Puedes enlazar contenedores, establecer políticas de seguridad, limitar el uso de recursos, etc.

Piensa en ellos como máquinas virtuales escalables y aisladas en las que ejecutas tus aplicaciones. (Sabemos que esta afirmación ha desencadenado históricamente mil guerras de llamas, así que al menos convengamos en que los contenedores son simplemente mucho más rápidos, ¿de acuerdo?) Los contenedores aíslan una aplicación y sus dependencias, incluso su propio sistema operativo, en una unidad autónoma que puede ejecutarse en cualquier plataforma, en cualquier lugar. Esto significa que puedes alojar e implementar contenedores duplicados en todo el mundo (¡gracias a tu Infraestructura como Servicio!) para que tus operaciones sean flexibles, fiables y rápidas.

Gestión dinámica

En este es donde brilla absolutamente tu nuevo sistema. En resumen, la gestión dinámica significa hacer un uso óptimo de las ventajas que confiere tu nueva plataforma en la nube. Los recursos informáticos, de red y de almacenamiento se aprovisionan bajo demanda, utilizando API estandarizadas, sin costes iniciales y en respuesta en tiempo real a las necesidades reales de la empresa.

La gestión dinámica elimina los costes que suelen conllevar la planificación de la capacidad y el aprovisionamiento de recursos de hardware. En su lugar, un equipo de ingenieros puede empezar a implementar valor en la producción en cuestión de horas. Los recursos también pueden desasignarse con la misma rapidez, reflejando fielmente los cambios en la demanda de los clientes.

El funcionamiento de los recursos informáticos, de red y de almacenamiento es tradicionalmente una tarea difícil que requiere conocimientos especializados. Obtener estas habilidades suele llevar mucho tiempo y ser caro. Pero aún más importante es la velocidad: los humanos nunca van a poder responder tan rápidamente a los ciclos de subida y bajada según suba o baje la demanda. Dejar que la plataforma en nube que elijas gestione las cosas dinámicamente significa que los ciclos de vida de los recursos se gestionan automáticamente y de acuerdo con unos estándares de disponibilidad, fiabilidad y seguridad inquebrantablemente altos.

Microservicios

Microservicios (arquitectura de microservicios) es un enfoque del desarrollo de aplicaciones en el que una aplicación grande se construye como un conjunto de componentes modulares o servicios. Cada servicio ejecuta un proceso único y a menudo gestiona su propia base de datos. Un servicio puede generar alertas, registrar datos, soportar interfaces de usuario y autenticación, y realizar otras tareas diversas. Los microservicios se comunican mediante API y permiten aislar, reconstruir, reimplantar y gestionar cada servicio de forma independiente.

También permiten a los equipos de desarrollo adoptar un enfoque más descentralizado (no jerárquico) e interfuncional para crear software. Al utilizar microservicios para dividir una entidad monolítica en piezas distintas más pequeñas, cada equipo puede apropiarse de una parte del proceso y entregarla de forma independiente. En el mejor de los casos, algunas de estas piezas pueden incluso adquirirse como un *-as-a-Service bajo demanda desde la nube.

Piensa en las empresas que ponen el listón para todos los demás en términos de rendimiento, disponibilidad y experiencia de usuario: Netflix, Amazon, la plataforma de mensajería instantánea WhatsApp, la aplicación de gestión de relaciones con los clientes Salesforce, incluso la principal aplicación de búsqueda de Google. Cada uno de estos sistemas requiere de todo, desde funcionalidad de inicio de sesión, perfiles de usuario, motores de recomendación, personalización, bases de datos relacionales, bases de datos de objetos, redes de distribución de contenidos y muchos otros componentes, todo ello servido de forma cohesionada al usuario. Al dividir toda esta funcionalidad en piezas modulares y entregar cada servicio por separado e independientemente, aumentas la agilidad. Cada microservicio puede escribirse en el lenguaje más apropiado para su propósito concreto, gestionarse por su propio equipo dedicado y ampliarse o reducirse de forma independiente según sea necesario. Y, al contrario que en una aplicación monolítica estrechamente acoplada, el radio de explosión de cualquier cambio está contenido dentro de la huella de ese microservicio.

Automatización

Las tareas manuales se sustituyen por pasos automatizados en scripts o código. Algunos ejemplos son los marcos de pruebas automatizados, la gestión de la configuración, la integración continua y las herramientas de implementación continua. La automatización mejora la fiabilidad del sistema al limitar los errores humanos en las tareas repetitivas y los procedimientos operativamente intensivos. A su vez, esto libera a las personas y los recursos para que se centren en el negocio principal en lugar de en interminables tareas de mantenimiento.

En pocas palabras, si intentas pasar a la nube nativa pero no tienes automatización, te meterás rápidamente en un lío. Las empresas acuden a la nube para realizar implementaciones más rápidas y frecuentes. Si no has automatizado por completo tus procesos de implementación, de repente tus empleados de operaciones dedicarán todo el tiempo que ahorran al no tener que gestionar los servidores locales a implementar manualmente tu nuevo ciclo de producción acelerado. Implementaciones más frecuentes también significan más oportunidades de meter la pata cada semana; poner las cosas en producción más rápido y escalarlas más rápido también significa generar errores más rápido. La Implementación automatizada elimina el trabajo pesado de la implementación constante, mientras que las pruebas automatizadas detectan los problemas antes de que se conviertan en crisis.

Orquestación

Una vez que una arquitectura de microservicios está en su sitio y en contenedores, es hora de orquestar las piezas. Una verdadera aplicación de nivel empresarial abarcará varios contenedores, que deben desplegarse en varios servidores anfitriones que formen una infraestructura de contenedores completa, que incluya seguridad, redes, almacenamiento y otros servicios. Un motor de orquestación despliega los contenedores, a escala, para las cargas de trabajo requeridas, al tiempo que los programa en un clúster mientras los escala y los mantiene, todo ello integrando al mismo tiempo todo con la infraestructura de contenedores.

La orquestación fomenta el uso de patrones comunes al planificar la arquitectura de servicios y aplicaciones, lo que mejora la fiabilidad y reduce los esfuerzos de ingeniería. Los desarrolladores se liberan de resolver abstracciones de nivel inferior y pueden centrarse en la arquitectura general de la aplicación.

Aquí es donde entra en juego Kubernetes, y es una de las últimas cosas que hay que hacer en una migración nativa a la nube. Si implementas primero un orquestador, estás librando una batalla en frentes simultáneos. Utilizar un orquestador con eficacia es una tarea muy compleja; hacerlo bien depende a menudo de la flexibilidad, velocidad y capacidad de iterar que hayas puesto en marcha primero. Otros principios nativos de la nube -la infraestructura en la nube, la gestión dinámica y la automatización- deben estar implantados antes. Muy a menudo, cuando se llama a los expertos para que trabajen con una empresa cuya migración a la nube ha salido mal, lo que encontramos es que han puesto un orquestador antes de que las cosas estuvieran en su sitio.

Utiliza tu plataforma para construir tu plataforma, ¡antes de empezar a preocuparte por orquestar todas las piezas!

Encajar todo

Los cinco principios (técnicos) de, construidos en el orden adecuado, son todos soportes esenciales en una arquitectura nativa de la nube. Uno, sin embargo, puede ser incluso más importante que todos los demás: los microservicios.

Los microservicios ocupan un papel central entre los cinco principios. Para que los microservicios funcionen bien, debes tener un enfoque maduro de los otros cuatro principios. Al mismo tiempo, los contenedores, la gestión dinámica, la automatización y la orquestación sólo son verdaderamente potentes cuando se combinan con la arquitectura de microservicios. La Figura 1-1 muestra cómo encaja todo.

Por ejemplo, una de las principales ventajas de la contenedorización es que permite empaquetar aplicaciones heterogéneas de forma estandarizada. Esto no es muy convincente si toda tu lógica empresarial está construida dentro de un monolito. Del mismo modo, podrías aplicar la gestión dinámica a una aplicación empresarial homogénea clásica de este tipo en una infraestructura pública o en un proveedor de Plataforma como Servicio en la nube. Hacerlo, sin embargo, significa desperdiciar la capacidad de escalar hacia arriba y hacia abajo en respuesta a tus necesidades empresariales.

Figura 1-1. Diagrama de relación entre los cinco principios de la arquitectura nativa de la nube

Y, sí, aunque es cierto que la automatización aún puede aplicarse a la arquitectura monolítica, al menos hasta cierto punto, el nivel de automatización alcanzable con los microservicios es enormemente superior, dada su naturaleza autónoma e independiente. Por último, las plataformas de orquestación modernas asumen que las aplicaciones se compondrán de servicios más pequeños, en contenedores. Es posible una migración a la nube "lift and shift" de una aplicación tradicional para que se ejecute en contenedores sobre orquestadores modernos. Sin embargo, requiere una gran adaptación e inversión, y no permite aprovechar las importantes ventajas de la arquitectura de microservicios.

Hay casos en los que hacer un lifting and shift de una aplicación monolítica existente para ejecutarla en una plataforma nativa de la nube es una opción razonable. Las empresas con experiencia nativa en la nube pueden encontrar ventajas en trasladar primero una aplicación a la nube, antes de rediseñarla para optimizarla para que funcione allí. Esto no te lleva a la nube nativa completa, sino que inicia tu viaje en dos de las cinco áreas como punto de partida para una mayor transformación. Así que, en las circunstancias adecuadas, este enfoque puede tener cierto valor.

Sin embargo, la experiencia es esencial: si vas a utilizar un socio experimentado para guiar tu transformación nativa de la nube, puede que aciertes. Pero el riesgo de hacerlo por tu cuenta es demasiado alto para el valor que aporta. Con demasiada frecuencia vemos empresas con conocimientos limitados sobre la nube que intentan simplemente trasladar su monolito existente a la nube como objetivo final y no como punto de partida. Esto requiere una gran inversión de tiempo y recursos con beneficios limitados, momento en el que muchas empresas se desaniman y retrasan, o incluso cancelan, sus esfuerzos de transformación.

El argumento más convincente para situar los microservicios en el centro de los principios nativos de la nube es el hecho de que encapsulan la lógica empresarial, el factor diferenciador de cualquier empresa. Los microservicios son capaces de representar los procesos mediante los cuales una empresa ofrece valor a sus clientes. En última instancia, esto acorta la distancia entre la definición de la estrategia y la ejecución, satisfaciendo la necesidad de velocidad que lleva a la mayoría de las empresas a la nube nativa en primer lugar.

Independientemente de cómo se implementen, estos cinco principios cuentan ahora con técnicas y herramientas que se acercan a su plena madurez y comoditización. La facilidad de uso y la robustez de las herramientas que ofrecen los contenedores y las plataformas de orquestación actuales son realmente impresionantes. Érase una vez (hace cuatro años) que las tecnologías más avanzadas del mundo sólo eran alcanzables a verdadera escala de producción por las grandes empresas que podían mantener equipos informáticos internos dedicados al desarrollo, cuidado y alimentación de innovaciones potentes pero aún inmaduras como los contenedores y los microservicios. Ahora, las ventajas competitivas que confieren estas tecnologías están a disposición del público, comoditizadas y al alcance de cualquiera con una conexión a Internet y una tarjeta de crédito.

¿Qué podría salir mal?

Así que, sí, es realmente asombroso que cualquiera con una idea pueda ir a Amazon, Microsoft o Google, contratar una Plataforma como Servicio totalmente aprovisionada, y estar funcionando en cuestión de minutos. La competencia es feroz, y los precios bajan, mientras que las funciones se amplían exponencialmente. La nube parece estar trastornando ahora todos los sectores que toca, y es comprensible que las empresas estén ansiosas por migrar las operaciones y adoptar la nube nativa tan rápido como puedan.

¿Qué puede salir mal? En realidad, muchas cosas. Pero las razones por las que las transformaciones nativas en la nube salen mal suelen pertenecer a una de estas tres categorías principales:

• Dificultades debidas a la complejidad de los sistemas distribuidos

• La relativa inmadurez del ecosistema nativo de la nube, con su paisaje del salvaje oeste de herramientas y plataformas.

• La incapacidad de adaptar y hacer evolucionar la cultura organizativa para seguir el ritmo de los cambios tecnológicos y las expectativas de entrega

Choque de sistemas (distribuidos)

Nosotros vivimos ahora en un mundo altamente móvil en el que se accede a las aplicaciones y se utilizan a través de una plétora de plataformas y dispositivos. Los usuarios esperan una experiencia rápida, fluida y siempre activa. Para cumplir estas expectativas y mantener contentos a los usuarios, hemos desarrollado sistemas distribuidos para gestionar las inevitables fluctuaciones y fallos de los complejos servicios entre bastidores necesarios para que todo funcione. Muchas de las superpotencias de la nube nativa se deben al mérito de su arquitectura de sistemas distribuidos.

Una forma sencilla de pensar en los sistemas distribuidos es como múltiples funciones independientes unidas para presentarse al usuario final como una experiencia única y unificada. Incluso una aplicación monolítica que se comunica con una base de datos es un sistema distribuido, aunque muy simple. La principal ventaja de un sistema distribuido es la fiabilidad; cuando los procesos informáticos se extienden por toda una red de máquinas, ocurren independientemente unos de otros. Si uno falla, el proceso sigue funcionando.

Asimismo, la distribución facilita la adición de nodos y funcionalidad según sea necesario: la tan cacareada escalabilidad de los sistemas nativos de la nube. Los sistemas distribuidos también son capaces de ofrecer el rendimiento que los usuarios esperan ahora de cada interacción, gracias a que empresas como Google y Amazon han subido el listón de la experiencia del usuario online. Las peticiones y cargas de trabajo se dividen en trozos y se reparten entre varios ordenadores, de modo que el trabajo se completa en paralelo y se devuelve muy rápidamente.

Todas estas ventajas, sin embargo, tienen un importante efecto secundario: la complejidad. Cuando los sistemas distribuidos se vuelven complejos, el diseño, la construcción y la depuración se hacen mucho, mucho más difíciles. Los fallos son prácticamente inevitables, y los equipos de ingeniería tienen que aceptarlo y elaborar planes de contingencia para los fallos, de modo que los usuarios finales apenas se den cuenta cuando se produzcan. Sin embargo, asomarse al interior de una pila tecnológica de sistemas distribuidos para comprender esos fallos es un reto enorme, por lo que la observabilidad sofisticada es esencial. Las herramientas y los conocimientos necesarios para detectar esos puntos de fallo -como el rastreo distribuido, la ingeniería del caos, la revisión de incidentes y la comprensión de las complejidades de las dependencias ascendentes y descendentes- son extremadamente avanzados. Pocas empresas tienen la capacidad de hacerlo por sí mismas.

Inmadurez chocante

Eso nos lleva al segundo punto en el que las cosas van mal durante las migraciones a la nube: la relativa inmadurez del ecosistema nativo de la nube. Las plataformas de nube pública como Amazon Web Services y Azure se presentan como soluciones completas de extremo a extremo, pero están lejos de ser plug and play. Las empresas acostumbradas a la funcionalidad completa de las máquinas virtuales, o a cualquier otra solución tecnológica totalmente madura, se llevan la desagradable sorpresa de que la configuración es manual, y ni siquiera están presentes todas las piezas necesarias.

Imagina que compras un televisor, lo llevas a casa y al abrir la caja descubres que no hay cables, ni cable de alimentación, ni mando a distancia. Ninguno de los periféricos que esperamos encontrar y que son esenciales para el funcionamiento del televisor. Literalmente, es sólo una pantalla. El fabricante te dice: "Ahora vete a comprar esta pieza aquí, aquella pieza allá, y monta tu televisor: ¡al final funcionará bien!". Lo mismo ocurre con los proveedores de la nube: dicen ser soluciones completas, pero les falta la mitad de lo necesario. Como creíste a tu proveedor que su plataforma era una solución completa, no has asignado personas ni presupuesto ni tiempo para construir o comprar las piezas que faltan o están incompletas. Y, de todos modos, es muy poco probable que tengas gente dentro de tu empresa que pueda encargarse de montarlo todo.

Dado que la nube nativa es aún tan nueva, el panorama actual de las tecnologías de nube y las ofertas de los proveedores está en constante evolución. El CNCF mantiene una lista de las tecnologías en constante proliferación en el panorama de la nube nativa. Probarlas todas está probablemente fuera de lugar: mientras escribimos este libro, el CNCF cuenta con más de 1.200 tecnologías, proveedores y proyectos entre los que elegir a la hora de trazar una migración a la nube.

Muchos de los patrones que presentamos más adelante en este libro están directamente relacionados con la gestión de las complejidades de los sistemas distribuidos. También hay patrones para reducir el intimidante abanico de opciones de herramientas y plataformas nativas de la nube, por mucho que cambien, con el fin de elegir la más eficaz para tu contexto específico.

Resumen ejecutivo

En resumiendo, para obtener lo mejor de la nube, utiliza arquitectura nativa de la nube: microservicios, contenedores, orquestación, automatización. Dado que los tres primeros pueden introducir nuevos problemas, la automatización debe ser una de las primeras cosas que se pongan en marcha: quieres que el sistema de saneamiento esté establecido antes de construir tu ciudad en las nubes.

Los microservicios y los servicios en la nube son la clave para aprovechar realmente el poder de las operaciones en la nube. A primera vista, la victoria puede parecer deshacerse de las máquinas físicas. La verdadera victoria, sin embargo, es acceder a todos los servicios extraordinariamente sofisticados: todo tipo de software especializado como servicio, llave en mano y listo para engancharse a tu aplicación. Con la nube y los microservicios en su sitio, estarás preparado para iterar e implementar rápidamente y con más frecuencia, que es donde entran en juego la automatización y la orquestación. Puede ser complejo, sí, pero existen orquestadores para optimizar todo esto, y hoy en día también puedes contratarlos como servicio.

El minorista europeo de moda online ASOS es un buen ejemplo de cómo reunir el conjunto perfecto de servicios. Su gran triunfo en la nube fue la posibilidad de elegir una base de datos distinta para cada dato que tenían, desde las existencias hasta los envíos o la información de los clientes, todo ello sin necesidad de gestionar las complejidades de distintas bases de datos. Con los microservicios, ASOS podía hacer sus aplicaciones más pequeñas y vinculadas específicamente a una base de datos concreta optimizada para ese caso de uso exacto. Una base de datos relacional para algunos, un almacén de claves/valores para algo muy rápido, pero en todos los casos se trataba de State-as-a-Service. Y lo que es mejor, podían comprarlo del proveedor, sin necesidad de especialistas que lo gestionaran todo. No un monolito gigante que se comunica con una base de datos relacional gigante, sino muchos microservicios más pequeños, cada uno de los cuales se comunica con su base de datos correspondiente. Este ejemplo muestra lo lejos y lo rápido que hemos llegado: en los "viejos" tiempos, hace cinco años, si querías, por ejemplo, una base de datos Cassandra, también necesitabas un experto en bases de datos realmente caro para ejecutarla. Ahora puedes obtener ambas cosas bajo demanda de tu proveedor de nube pública.

La nube nativa es una tecnología potente, prometedora (y, sí, muy publicitada). Es comprensible que las empresas estén ansiosas por llegar a ella lo antes posible. Pero aprovechar todas las ventajas de la nube significa, en primer lugar, ir más allá del bombo publicitario para construir unos cimientos sólidos, basados en los principios de la arquitectura nativa de la nube. Y, mientras tanto, hacer evolucionar la cultura de tu organización, su estructura y sus procesos, hacia una forma de trabajar igualmente nueva. Exploraremos cómo lograr estos cambios centrados en el ser humano a continuación, en el Capítulo 2.