Probablemente acercarse a Azure después de haber leído sobre sus capacidades y servicios, y pretender empezar a construir servicios o migrar cargas de trabajo debe ser algo parecido a lo que le ocurre a los escritores cuando se enfrentan al intento de iniciar un libro, el síndrome del folio en blanco.
Creo que lo más interesante para comenzar es imaginar Azure como un datacenter vacío en el que, de momento, no tienes nada, pero que, sin tener que comprar, alquilando, puedes disponer de casi cualquier tecnología, con distintos niveles de gestión.
Hay distintas formas de utilizar el Cloud, la más «primitiva» es provisionar máquinas virtuales como harías en un centro de datos OnPremise (utilizando VMware o Hyper-V, por ejemplo) e instalar en esas máquinas virtuales las aplicaciones y servicios tal y como se hacía tradicionalmente. En este caso de uso las ventajas no son tan significativas como en otros modelos: no tienes que invertir en hierro, pagas por uso (si apagas entornos no productivos cuando no están en uso, por ejemplo), lo te permite hacer pruebas y experimentar sin invertir…
Un caso de uso extendido en los primeros pasos de muchas empresas con el Cloud es utilizarlo como centro de contingencia, para poder prestar servicio en caso de caída del centro de datos principal.
Otro catalizador o motivo para emprender la migración al la nube es el hecho de tener que actualizar infraestructuras o versiones de software obsoletas. Antes de acometer la compra de Hardware, o puesto que hay que actualizar las versiones de software que soportan una aplicación, surge la oportunidad de evitar la inversión y acometer la migración cambiando el modelo, o incluso la aplicación. Es posible consumir la aplicación ofrecida por un proveedor en un modelo SaaS (Software as a Service), cambiar a aplicación, reescribir el código o, sencillamente, migrarla a infraestructura virtualizada en la nube utilizando versiones soportadas.
Pero la verdadera potencia del Cloud viene derivada del uso de servicios gestionados o PaaS (Paltform as a Service) e, incluso, Serverless, en los que no hay máquinas virtuales, e incluso ni siquiera instancias que gestionar. En ciertos casos dar el paso a este tipo de consumo requiere de aplicaciones diseñadas para funcionar bajo estos patrones de utilización, deben estar diseñadas para ello.
A la hora de emprender el viaje a la nube es importante analizar la nube a elegir, es posible y cada vez más habitual utilizar estrategias multinube, ubicando distintos servicios en las nubes públicas de distintos proveedores. Es importante considerar que, si se empiezan a utilizar tecnologías propias del fabricante empezamos a depender de la nube, hay un bloqueo o dependencia de ese proveedor.
Otro punto a considerar es lo que ya tenemos avanzado. Hay nubes en las que es necesario partir de cero. La plataforma de Microsoft está diseñada para permitir aprovechar el esfuerzo empleado en la definición de un servicio de directorio y proveedor de identidades como Active Directory, por ejemplo, en la estrategia de consumo de servicios en su nube pública Azure, además de la integración con servicios como Office 365, por ejemplo.
En cualquier caso, sea cual sea el modelo a elegir, e incluso la nube elegida, hay ciertos cimientos o andamios que es necesario establecer. Que los cimientos sean sólidos permitirá crecer con robustez, sin problemas a medio camino. Es importante invertir en una buena definición del modelo de gobierno, diseño de red y seguridad, estructura organizativa, nomenclatura, gestión de permisos.
Iremos revisando en este blog las opciones y patrones de diseño que nos permitirán hacer un uso exitoso de Azure. Espero que os resulte interesante.