La redundancia del cloud computing en duda

No hace ni una semana de la tan sonada caída de los servicios de cloud computing de Amazon Elastic Compute Cloud (Amazon EC2), una plataforma utilizada por grandes proyectos como Foursquare, Reddit, Hootsuite, Quota y otras tantas empresas a nivel mundial que confían de forma ciega en una única solución de cloud hosting.

Y es que los servicios de cloud también pueden fallar, de hecho quien puede asegurar que cualquier sistemas sin redundar esté libre de fallos. Si tienes un servicio crítico, o que no quieres que falle nunca la solución no es una única nube computacional.

Amazon tiene independencia entre sus sistemas, dispones de varios centros de datos por todo el mundo (EEUU, Europa y Asia), pero esta garantía de redundancia y estabilidad no sirvió de nada ante, según las noticias, a  un fallo en el procedimiento de copia de seguridad descontrolado que hizo alguna que otras copias de sí mismo, un bucle que consumió todo el espacio disponible creando un «cloudgate» o «cloudpocalipsis«. Un fallo que podríamos decir que nunca debió suceder, y más cuando el grado de madurez de Amazon Cloud es elevado. Aunque nadie está libre de cometer errores, y de los errores se puede aprender.

Mi pregunta es sencilla, ¿por qué confiamos ciegamente una única empresa para nuestros servicios de cloud? ¿y por qué confiamos en una única ubicación para nuestros sistemas y datos?.

Si lo que necesitas es garantía de redundancia de datos, estabilidad en el servicio, replicación de datos en múltiples localizaciones, que el fallo en un centro de datos no afecte a tu proyecto o sitio web,… siempre pienso que las soluciones pueden ser varias según lo crítico que consideres tu proyecto. Aquí os dejo algunas soluciones y espero vuestros comentarios:

  • Cloud Federation. Una federación de nubes es lo que necesitamos. Poder desplegar nuestros servicios con una plataforma común de cloud hosting en Amazon, Rackspace, Stackscale Cloud, … y otros proveedores de forma sencilla, levantando copias e instancias en varios proveedores de un mismo proyecto de forma que aseguramos mucho más la continuidad de nuestro servicios. A día de hoy esto es una gran utopía.
  • Cloud privado combinado con un cloud público. Un cloud híbrido como solución para aislar nuestra base en una plataforma en la nube basada en hardware que solo alberga nuestros sistemas de forma que podemos aislar y controlar mucho más los posibles errores, combinando con una cloud público para necesidades de escalar, picos de carga, picos de tráfico, …
  • Y si lo que quieres es Amazon, Azure, Google, … si o si, no has pensando en montar el núcleo de tu proyecto fuera de la nube propietaria de Amazon. Monta tu núcleo en servidores dedicados propios, en otra nube alojada en tu país preferiblemente, y crea una capa para escalar desde tu propia estructura hacia cualquier servicio en la nube según las necesidades de cada momento.

Ante todo evalúa los costes de que tu proyecto no esté online, y también los riesgos que supone depender de un cloud hosting que no está en tu país, donde además no sabes ni donde están tus datos, … yo siempre apuesto por hosting en España como una garantía adicional, aunque después tengas como apoyo una nube internacional.

Scroll al inicio