Usar servicios de clouds

Los servicios de clouds ofrecen varias cosas, IaaS, PaaS, etc. En principio una migración estándar que "tiene" que funcionar es migrar lo que corre un servidor físico directo a una instancia en una cloud IaaS (Infraestructura como Servicio), y la "instancia" sería básicamente un server virtual en algun proveedor de cloud services, y migramos ahí nuestro server físico. No es nada diferente de migrar a servers virtualizados hosteados localmente o migrarlos a un VPS, un server virtualizado en un proveedor de hosting. Hasta ahí son parecidos los viejos proveedores a los servicios de cloud, pero solo hasta ahí (luego vemos más diferencias importantes).

Hay muchos escenarios donde se puede utilizar clouds, pero la idea base es esta: servicios - una aplicación X  que corre en servers físicos - que no es necesario correr con frecuencia.

Es decir, usaríamos clouds si necesitamos de vez en cuando correr esa aplicación X que requeriría un servidor físico muy potente para correr, pero, no tenemos suficientes servers físicos para dejar uno dedicado y prenderlo cuando haga falta.

Si hablamos de infra virtualizada, es lo mismo, puede que tengamos 6 servidores virtualizados en un server físico, y que no haya la posibilidad de usar los recursos virtualizados en el momento en que haga falta correr nuestra aplicación X. (un ejemplo, es que la aplicación X necesite correr indefectiblemente a las 11 de la mañana, cuando los demás 6 servidores virtualizados están usando todos los recursos del host físico).

Así que una alternativa sería rentar un host virtualizado en una cloud, disponer de los servicios básicos: el mínimo espacio de disco necesario para alojar los datos, la mínima cantidad de ram necesaria para que bootee el server y así sucesivamente, todos los mínimos.

¿Por qué mínimos? Porque la razón de usar servicios en clouds es poder ampliar y reducir a voluntad los recursos de servidor que contratamos (y pagando más o de dejando de pagar por ello). Así que se se puede tener - dependiendo del proveedor de cloud - incluso el server apagado todo el tiempo, por un mínimo costo, y solo arrancarlo cuando haga falta, luego ampliar el "pack" de servicios (+ CPU, +RAM, +placas de red, etc.), por el tiempo que nos haga falta (4 horas por ejemplo), utilizar esos recursos y luego, al terminar, ya nos facturaron el uso que hicimos de lo contratado, y podemos reducir nuestro "pack" a lo mínimo de vuelta, y así sucesivamente podemos llegar a tener disponible recursos físicos para nuestro server en la cloud, que no estarían disponibles en nuestra infraestructura local.

Como pueden ver, contratar más servicio, subir requerimientos de RAM, CPU, storage, etc. es un trabajo de administración importante, y más aún si consideramos todo el trabajo de arrancar/rearrancar el servidor, y luego las tareas internas de administración en nuestra app (que es el motivo por el cual se hace todo este trabajo). Ok, acá es donde empezamos a considerar otras diferencias entre un proveedor tradicional y una cloud: en clouds tenemos una API y herramientas que nos permiten interactuar con la infraestructura de cloud, enviando ordenes a las instancias. No tengo noticias puntuales de que ningun proveedor de cloud ofrezca mecanismos de manejo de capacidad desde su API, por ej. adquirir 20 GB extra de storage, pero es posible que alguno lo tenga disponible.