La nube ha cambiado nuestras arquitecturas de software

La nube aporta nuevos servicios

Los proveedores de nube ofrecen un gran número de servicios ya preparados, como bases de datos, gestión de usuarios, intermediarios de mensajes y mucho más. Esto hace que el entorno operativo de nuestro software en la nube sea muy diferente del entorno que encontramos en el centro de datos clásico.

On-Premises Centro de Datos

Cuando creamos software en el entorno Java que se va a ejecutar en el centro de datos del cliente (on-premises), el entorno suele ser un servidor de aplicaciones o un entorno Docker, así como una base de datos relacional. Otros servicios como:

• Bases de datos NoSQL,
• Servidores de cola o
• Administración de usuarios externos

son poco frecuentes. Si el nuevo software no es exactamente el sistema principal del cliente, tampoco es posible ponerlo en producción. Para ello, habría que abordar al menos las siguientes cuestiones:

• Alta disponibilidad
• Gestión de parches
• Autenticación
• Cifrado de datos
• Copia de seguridad y restauración

Sin embargo, a menudo faltan los conocimientos necesarios para los nuevos servicios. Los costes y el riesgo de interrupción de las operaciones asociadas al nuevo servicio suelen ser demasiado elevados.

Servicios gestionados con proveedores de nube

Para los proveedores de nube, los servicios no son costes y riesgos, sino un producto que genera dinero. En consecuencia, aquí se invierte de forma diferente y de repente se dispone de servicios que no se podían prestar en el centro de datos local.

En esta entrada de blog, recurro a Amazon Web Services (AWS) como ejemplo. Google Cloud y Microsoft Azure ofrecen servicios similares, pero personalmente estoy especializado en AWS.

En la nube, podemos ejecutar un servicio, como una base de datos, nosotros mismos en una máquina virtual. Pero esto no ofrece ninguna ventaja sobre nuestro propio centro de datos. Si en cambio elegimos una base de datos operada por AWS, AWS se encarga de las cuestiones operativas mencionadas anteriormente.

En el ámbito de las bases de datos, AWS ofrece no solo bases de datos SQL, sino también bases de datos clave-valor, de documentos y de gráficos, motores de búsqueda de texto completo y servicios más exóticos, como bases de datos de blockchain. En total, AWS ofrece más de 200 servicios.

El impacto en la arquitectura

Cuando queremos introducir un nuevo servicio, como una base de datos, utilizando un servicio gestionado de un proveedor en la nube, estamos construyendo sobre una infraestructura existente con puntos fuertes y débiles conocidos. Esto reduce significativamente el riesgo de introducir el servicio. Al introducir un servicio autoalimentado e integrarlo en su propio entorno, siempre hay imponderables que pueden provocar retrasos y mayores costes. Cuando se eliminan estos riesgos, uno puede concentrarse mejor en el desarrollo real de la aplicación y atreverse a desarrollar software más innovador. Con la posibilidad de utilizar nuevos servicios aparte de las bases de datos SQL y los servidores de aplicaciones, podemos seleccionar e integrar los servicios que mejor se adapten a nuestro software. Por ejemplo, en el pasado, debido a la falta de alternativas, a menudo aplicaba

• administraciones de usuarios implantadas,
• que gestiona gráficos de estructuras organizativas en una base de datos relacional,
• imágenes y documentos almacenados en una base de datos relacional y
• eventos asíncronos simulados en una base de datos.

Con los servicios adecuados, todo esto ya no es necesario. El software se simplifica, contiene menos errores y se termina antes.

Modelo de costes

Los costes basados en el consumo en la nube requieren un enfoque diferente de los costes operativos.

On-Premise Centro de Datos

En un proyecto de software clásico, los costes de explotación sólo desempeñan un papel al principio del proyecto. A continuación se solicita el hardware y las licencias necesarias. Una vez que el software está en funcionamiento, los costes de explotación apenas influyen. Si los cambios se ordenan para reducir los costes de licencia -por ejemplo, sustituir un sistema de base de datos caro por otro más barato-, apenas tiene repercusión. Dado que la infraestructura está instalada y se ha pagado por adelantado, un software más eficiente no supone un ahorro a posteriori. Los costes operativos no se desglosan en componentes de software individuales y, desde la perspectiva del desarrollo de software, los costes operativos se consideran costes ya existentes.

En la nube

En la nube se pueden encontrar diferentes modelos de costes basados en el consumo. Un software más eficiente puede suponer un ahorro inmediato, al generar menos llamadas facturables, utilizar menos memoria o requerir menos máquinas virtuales o de menor tamaño.

El etiquetado puede utilizarse para asignar costes operativos a componentes de software individuales. Esto permite a veces incluso calcular el coste de una sola transacción o el coste por usuario.

Efectos en la arquitectura

Los modelos de costes de la nube ofrecen nuevas perspectivas sobre las decisiones arquitectónicas. Se puede calcular el impacto de un cambio de arquitectura en los costes de explotación y relacionarlo con el coste del cambio. Una reducción de costes que merezca la pena puede ser entonces la única razón para cambiar un programa informático. Un requisito previo para realizar un cálculo es disponer de datos suficientes de la operación anterior del software.

A la hora de seleccionar la tecnología, los costes de funcionamiento pueden desempeñar de repente un papel decisivo. Para las aplicaciones en la nube, por ejemplo, habría que comprobar si es realmente necesaria una base de datos SQL o si también es suficiente una base de datos clave-valor más barata.

Funciones sin servidor

Las funciones sin servidor son una verdadera innovación en la nube para la que no hay equivalente en los centros de datos locales. En AWS, las funciones sin servidor se denominan "Lambda Functions" y permiten que los artefactos de código -por ejemplo, JavaScript, scripts Python o archivos Java Jar- se ejecuten en la nube sin su propio servidor. La facturación se basa en el número de llamadas, el consumo de tiempo y el uso de memoria. En el caso de pausas entre llamadas a funciones Lambda, ocurre que el entorno de ejecución se desmonta y se reconstruye con la siguiente llamada. Un entorno de ejecución que se inicie rápidamente es, por tanto, importante para un buen rendimiento.

Efectos en la arquitectura

El modelo de costes y el comportamiento de arranque de las funciones Lambda desaconsejan el uso de frameworks con una elevada sobrecarga de memoria y arranque, como Spring Boot o Java EE. Los gastos generales se reflejan directamente en los costes de explotación. Los marcos de arranque lento provocan latencias elevadas durante la llamada inicial. En Java, esto condujo a la aparición de frameworks más ágiles y eficientes como Quarkus, así como de entornos de arranque más rápidos como GraalVM.

El comportamiento de arranque hace que sea inconveniente utilizar recursos con elevados gastos generales de inicialización, como las conexiones a bases de datos SQL. Por lo tanto, una capa de persistencia basada en bases de datos SQL es desfavorable para las funciones Lambda.

Mientras tanto, vemos cada vez con más frecuencia que se desarrollan aplicaciones completas sobre la base de Lambda Functions. Para aplicaciones con poca carga, esto supone una ventaja económica.

Conclusión

En la nube, podemos crear aplicaciones personalizadas e innovadoras con menos riesgos seleccionando los servicios gestionados adecuados. Los modelos de costes de la nube añaden un factor adicional a las decisiones arquitectónicas. Y con las funciones sin servidor, están surgiendo nuevos enfoques arquitectónicos más ágiles.

Encontrará más temas apasionantes del mundo de adesso en los artículos de nuestro blog publicados hasta ahora.