En los últimos años ha habido un fenómeno, sutil, pero no por ello menos real, la convergencia entre lo que conocemos como la nube pública y el “viejo mundo” del on premise. Es que la verdad sea dicha, a menos que seas una startup, es muy probable que tengas una buena cantidad de aplicaciones desarrolladas para el on premise, con sus servidores, centros de computo y todo eso, algunas muy bien hechas y bien optimizada, otras legados que están de mirar y no tocar, y claro el viejo que se resiste a morir, el mainframe.
El caso es que con la penetración progresiva de la nube, algunas cosas empezaron a ocurrir en las organizaciones cuando pasaron de la prueba de concepto:
- Adoptar una política de Cloud First para las nuevas iniciativas
- Darse cuenta de cuán conveniente es el “estilo cloud” de provisionar y desplegar aplicaciones
- Descubrir las potencialidades del Serverless para desarrollar nuevos tipos de aplicaciones
- Percatarse que por muy en la nube que esten tus apps, van a tener que consultarle información a aplicaciones que (aún) no se migraran a la nube
- Tropezar con el hecho de que comprar servicios en la nube requiere un reaprendizaje
- Considerar el “cloud native” (con o sin contenedores) como parte de tu estrategia
Entonces casi por inercia empezaron a darse soluciones a dos problemas: ¿como llevar las ventajas de las tecnologías cloud al on premise? y ¿como mejorar la integración entre ambos mundos?
Dos caminos empezaron a surgir, por un lado el crear una plataforma de hardware que permita tener servicios nube con los que ya esta familiarizado, pero que se despliegue en tu centro de datos, así tenemos Azure Stack y AWS Outposts, el detalle es que aun con toda la potencia que estos servicios pueden ofrecer, la inversión y complejidad física de aprovisionamiento puede alejar esto de la mayoría de las empresas, las cuales en nuestros paises tendrían que hacer una importación ad hoc.
Y por otro lado está el uso de contenedores, que como recordamos se volvieron (erróneamente) en sinónimo de cloud native, los cuales fueron vistos como una opción tecnológica válida para acercar prácticas de despliegue de aplicaciones que prendieron rápidamente en la nube (*), en ese sentido tenemos plataformas como Red Hat OpenShift, Google Anthos, Azure Arc y AWS EKS/ECS Anywhere, que ofrecen la promesa de desplegar un orquestador de contenedores en cualquier lugar (on premise o una nube de la competencia) con el valor agregado de que los últimos tres permiten la administración de la plataforma de la misma forma que el resto de los servicios cloud que tengas en el proveedor respectivo, p. ej, gestionar tu Azure Arc en el on premise, desde el mismo portal donde se gestionan tus subscripciones de Azure.
De igual manera surgen servicios (basados en contenedores) que extienden el brazo de la nube hasta el on premise como el API Self-hosted gateway, que permite “delegar” parte de las tareas del Azure API Management, pero gestionando todo desde un único centro de mando, esto permite colocar la interfaz de exposición de las APIs más “cerca” del backend que las está emitiendo, simplificando los saltos para poner disponible el API de sus usuarios.
Es lógico que con este modelo de acercar el “estilo cloud” al on premise debemos sacrificar en parte la facilidad para el escalamiento al que nos hemos acostumbrado en la nube, pues claro… el “colchon” para alojar tus servicios corre por tu cuenta, y ya no por un proveedor de nube que puede jugar con las economías de escala, para que le salga rentable comprar hardware “de mas” a fin de atender holgadamente los requerimientos variables de sus usuarios.
Pero lo que si intentan estos servicios, es tratar de proveer la facilidad de despliegue, ya inherente de los servicios en la nube, aunque hasta hace poco estábamos limitados a “tan solo” desplegar contenedores en la mayoría de estas plataformas.
Esta situación ha cambiado desde el día de ayer, cuando en el Microsoft Build se anuncio que populares servicios PaaS como Azure App Service, Functions, Logica Apps, entre otros ahora podrían ser desplegados en cualquier lugar (Run your apps, anywhere) mediante el ya mencionado Azure Arc basado en Kubernetes.
Esto decididamente abre nuevas opciones, como la posibilidad de tener desarrollo serverless orientado a eventos, mas cerca a los componentes on premise, utilizando patrones de trabajo que ya han demostrado su productividad en la industria, mas aun, este servicio ha sido diseñado de tal forma que tu despliegue en Arc sea visto como una “región” desde el portal de Azure, abstracción total para simplificar la administración.
Es seguro que otros proveedores saltaran a esta opción muy pronto, por lo que ya no solo bastara con la facilidad de desplegar contenedores en el on premise (o en la nube de la competencia), sino también el que los servicios que ellos habiliten para el enfoque híbrido sean lo suficientemente atractivos para los usuarios, vamos… igual que en la nube publica!
Y si, nuevas tecnologías y nuevas opciones, significan nuevos retos: definir adecuadamente nuestras arquitecturas de despliegue, definir la estrategia de seguridad, las políticas para controlar el escalamiento, escoger adecuadamente que se desarrollara con los nuevos patrones y cuales todavía seguirán con el modelo tradicional…..
(*) Si, ya se, que siempre se ha podido desplegar Docker y Kubernetes en el on premise, pero la verdad es que su uso mayoritario ha sido en la nube, especialmente porque los proveedores de manera temprana facilitaron servicios que reducen notablemente la complejidad de la administración de plataformas de orquestación.