vClouden – Sobre servicios IaaS y arquitectura

Un tiempo ha pasado ya desde la primera implementación de vClouden donde después de mirar y mirar proveedores de servidores me decante por AWS y su conjunto de servicios de almacenamiento y computación; y aunque fue una decisión tomada ello no implica que no siguiera revisando otros proveedores y modelos de virtualización por mero interés, lo que terminó cambiando mi forma de ver los recursos que necesita vClouden para funcionar y escalar.

Cambio de concepción: para vClouden no es necesario un cloud o IaaS complejo

Después de leer, re-leer, hacer pruebas y free trials, la conclusión es muy simple: el vServer es un solo servicio con una sola forma de conexión y por consiguiente no requiere de arquitecturas complejas para sus despliegue (load balancers, private networks, clusters, Queues, AutoScaling, Caching, etc.) así que proveedores como AWS, RackSpace, SendgGrid, Azure, etc. están sobrecalificados si solo vamos a usar sus recursos de computación, en otras palabras: no justifica usar un gran proveedor de IaaS como si fuese un proveedor de VPS, tal como puede verse en sus costos, las maquinas de AWS o RackSpace no son precisamente las más económicas si se les compara con servicios enfocados al vps únicamente como Linode.com (uno de los mas antiguos y respetados) y la razón no son las maquinas en si, es lo que esas maquinas pueden hacer dentro de su ecosistema y la gran cantidad de opciones en arquitectura que nos abren y por su puesto esas posibilidades se reflejan en sus precios, así que si estas usando uno de estos grandes proveedores de infraestructura como un mero VPS tal ves estas pagando demás por una cantidad de posibilidades que no estas usando.

Entonces que tipo de proveedor necesita vClouden ?

Dada su arquitectura vClouden solo requiere de unos puntos estratégicos, básicamente se requiere de un proveedor que:

  1. Tenga un API y pueda generar servers al vuelo.
  2. Que provea un SLA.
  3. Backups automáticos y snapshots de las maquinas creadas.

Se requiere un API dado que vClouden escala horizontalmente, es decir llena un servidor con vServers y automáticamente va añadiendo más para ir creciendo, esto con el fin de que el escalamiento sea automático y predecible, en cuanto al SLA al ofrecer servicios empresariales la estabilidad y disponibilidad es requisito SI o SI y los backups por obvias razones de control de riesgos además que son la base de la estrategia de escalamiento de vClouden.

digitavslinode

Con estos requerimientos y después de revisar varios proveedores quede entre 2 alternativas Linode o DigitalOcean, y despues de jugar con ambos servicios, revisar cuanto post y blog para hacerme una idea de sus reputaciones y problemas, me termine decantando por DigitalOcean dado sus costos, rapidísimo crecimiento en los últimos 2 años, su gran reputación por servicio al cliente y por su puesto su oferta de discos SSD, los cuales el vServer aprovecha en gran medida, simplemente vuelan !!!.

Impensada mejora en la arquitectura:

En ocasiones las mejores soluciones nacen sin pensarlas, como consecuencia de la evaluación de varios proveedores cloud y la definición de la estrategia de backups para la data de los vServers,  vClouden terminó con una arquitectura que es “Cloud  agnostic”, es decir podemos pasar de un cloud a otro sin muchas complicaciones, pues ahora todos los recursos de computo dentro del modelo son “descartables” y dadas las nuevas funcionalidades de LXC la creación de vms toma un par de segundos, por lo que es perfectamente viable pasar un servidor corriendo vClouden con 50 instancias en servidor de DigitalOcean a una maquina de Amazon EC2 en menos de 10 minutos, con lo que de ahora en adelante no estamos atados a ningún proveedor cloud en particular, siempre y cuando un proveedor tenga disponibles las 3 características arriba mencionadas será posible pasar todas las maquinas de vClouden.

Conclusión:

El resultado final de todo este proceso es el traslado a un servicio cloud que se enfoca en lo que vClouden necesita que son servidores puros, permitiendo costos mucho más bajos, discos muuuuuucho más rápidos, preservando las funcionalidades que de por si teníamos con Aws/EC2.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s