Muchos usuarios ven el cloud como algo infalible, donde sus datos nunca van a desaparecer y su servicio siempre va a estar en línea, pero realmente es cierto?

En contra de muchas opiniones, el termino «servicios cloud»  no esta relacionado en absoluto con el término garantía de servicio, la calidad y garantía de servicio, no depende del nombre del mismo, depende directamente de la calidad, conocimiento e inversión del proveedor que lo ofrece.

Hace unos minutos he recibido un correo de uno de nuestros proveedores :

SLC-F Troubles I can’t apologize enough to the clients located on our SLC-F Cloud. We experienced an internal network outage limited to the cloud, and as a result the SANs needed to do a re-synchronization. While this re-sync is going on, the disk I/O remains tremendously high, causing performance substantially lower than our clients are used to. We have come up with a solution for this in the future. Due to the size of the SANs, we have worked with our SAN vendor to modify the normal behaviour of the SANs during a data sync to sync by volume rather than doing it as one large sync. We’ve also upgraded the iSCSI adapter in all SANs to prevent any future failures. We are very sorry for the SLC-F slowness and outages, and can assure you we’ve taken the action to prevent it from happening again.

A los pocos días se hizo público que Gmail había perdido el contenido de 150,000 cuentas por un error de software, lo curioso es que se puede leer una nota en su sitio que dice:

3:20 PM Google Mail service has already been restored for some users, and we expect a resolution for all users in the near future. Please note this time frame is an estimate and may change.
Update: Data for the remaining 0.012% of affected users has been successfully restored from tapes and is now being processed. We plan to begin moving data into mailboxes in 2 hours, and in the hours that follow users will regain access to their data. Accounts with more mail will take more time. For more information about what has happened, see the Gmail Blog. Thanks for bearing with us.

11:10 AM Google Mail service has already been restored for some users, and we expect a resolution for all users in the near future. Please note this time frame is an estimate and may change.

Es decir que hicieron lo que buenamente pudieron, pero al final su respuesta es que  se le ha restaurado a «algunos» usuarios y para el resto esperan poder dar una solución en el futuro próximo, es decir que no tienen ni idea de donde están, ni si lo encontrarán y lo están buscando, precisamente entre las nubes….

Después vino Amazon con una caída de varios días y para rematarlo Google Blogger ha estado con problemas durante más de 20 horas

Un sistema cloud, no es el milagro que muchos intentar vender, hablando sin tecnicismos, es simplemente un conjunto de servidores, que virtualizados junto con sus recursos se vende en pequeñas partes independientes con distintos nombres, como por ejemplo instancias, pero que no dejan de ser VPS individuales no administrados que normalmente, están especializados a atender un tipo de servicio, servidor web, correo, base de datos, etc…

Estas instancias pueden ser desde un servidor simple con todos sus servicios y panel de control, hasta una compleja configuración para un sitio de alta disponibilidad, con balanceo de carga, múltiples servidores web que funcionan en paralelo y conectados a un sistema de almacenamiento de mucha capacidad, por supuesto compartido por el resto de instancias, es decir un VPS.

Se puede montar «todo un cloud» con 4 servidores, suficiente para utilizarlo para un único proyecto, pero totalmente inadecuado para venderlo como un servicio cloud comercial a múltiples clientes, no tiene las características básicas de duplicidad de datos y ofrece un pobre rendimiento de I/O en situaciones críticas, por ejemplo cuando hay cientos de DDBB concurrentes.

Un SDC Virtualizado es mucho más sencillo de administrar, tiene mucho mejor desempeño, es mas seguro, es mas estable y ofrece mucho mejor rendimiento como Plataforma Virtualizada, que si la misma estructura se monta como «Cloud», a pesar de que estaría compuesto por los mismos elementos de hardware.

Un SDC virtualizado bien estructurado, tiene menos probabilidades de fallos que montado como cloud y en caso de problemas las caídas son mucho menos graves, fáciles y rápidas de solventar, los costos del servicio en «cloud» para el servicio de hosting compartido y normalmente por el mismo precio, obtienes menos recursos y rendimiento que con un VPS.

El cloud se diseño para ser utilizado por un solo cliente con necesidades de recursos muy altas, concretamente plataformas de investigación y cálculo, los Cray, con su sistema operativo UNICOS eran un prácticamente cloud hace muchos años, no para compartirlo y salvo muy raras (y caras) excepciones estamos delante de una nueva modalidad de sobrevender equipos y recursos bajo un nuevo concepto de márqueting.

El no tener una forma de acceder a tus datos de forma rápida y directa impide en el 99% de los casos hacer nada ante una caída seria, la duplicación no es parte del cloud, es parte de un buen diseño de SDC, si se muere un nodo en una plataforma virtualizada, incluso en el diseño más simple, puedes recuperar sus VPS inmediatamente en otro nodo, si se cae algo de la parte de control del cloud todo se cae y no puedes hacer absolutamente nada para solucionarlo, excepto esperar a que algún técnico de tu proveedor lo solucione.

La duplicidad de datos y la distribución de recursos no funciona ni con hosting estandar ni con DDBB, excepto si el diseño está especialmente preparado para ello, en hosting compartido, nada esta preparado para hacerlo, eso es igual para cloud que para cualquier otro sistema. Si quieres tener un nivel de alta disponibilidad en una DDBB, por ejemplo MySQl, debes hacerlo con replicas (esclavo) o con cluster, es exactamente lo mismo en cloud que en una plataforma virtualizada.

En mi opinión, el cloud es una nueva forma de vendernos una gran «máquina» en muchas partes, muy pequeñas que al final saturarán el proceso de I/O por bueno que sea, ejemplo VPS.net, tienen una muy buen infraestructura, duplicada, pero igual tienen problemas de I/O a cada rato.

Si consultas con cualquier especialista con experiencia te responderá que el cloud compartido no es apto para procesos que tienen gran cantidad de I/O, como por ejemplo uso simultáneo, dentro de un mismo «Cloud» de disco, DDBB de millones de registros, porque es muy lento.

Una de las principales ventajas del cloud es el poder «levantar instancias» que funcionen en paralelo cuando hay necesidad de atender un gran consumo de recursos, por ejemplo si hay muchas visitas a un sitio web, puedes levantar 10 o 30 procesos WWW en paralelo, la teoría es muy bonita, pero si hablamos de hosting estandar, con las aplicaciones y paneles de control que usan el 99% de los clientes, ninguna está preparada para utilizar esa técnica, es decir no se puede utilizar, volvemos al uso del «Cloud» por un único proyecto, porque para poder hacerlo, necesitas que tu aplicación este diseñada para trabajar en una plataforma distribuida, con los recursos ordenados y segmentados, es decir para hosting compartido el cloud no significa ninguna diferencia sobre un VPS.

Es decir volvemos a los mismo, el cloud es aplicable para aplicaciones pensadas y diseñadas desde el principio para funcionar en el, el usar Plesk o cPanel en un cloud es tener un VPS perdido en la nube, no tener una plataforma en cloud.

Como empresa tienes que saber donde están tus datos, tener acceso directo a ellos, aún en caso de una caída grave y sobre todo, lo que es más importante, poder trasladar tu aplicación a otro proveedor cuando quieras, sin complicaciones y con garantía de que tus servicios van a funcionar al 100%.

En conclusión, mis datos los almaceno yo, gracias….