… entonces ¿Clouds Privadas o Clouds Públicas?

Estos días pasados hemos comentado las características técnicas de las Clouds Privadas y de las Clouds Públicas (28-feb-2012) así como las razones de negocio (ayer y antes-de-ayer): y a la luz de lo expuesto, creo que cada una de ella responden mejor a un tipo de necesidades: en las Nubes Públicas los servicios de la Cloud está disponible al público en general. En ellas, la infraestructura pertenece a la organización que vende sus servicios de Cloud Computing. Por tanto es la solución más adecuada para todas aquellas empresas que para su negocio (o parte de su negocio) precise de que no existan costes de capital y todo sea OPEX, o las que necesiten agilidad y ajustar en todo momento sus costes TIC a las fluctuaciones de sus procesos de negocio (que se pueden en resumir en pagar por lo que realmente usa, solo por el tiempo que lo usa, y en el momento que lo necesita) y a las que nos les importe o no les afecte los problemas de seguridad, regulación de datos, prestaciones, etc. Frente a ello, en las Nubes Privadas, la infraestructura cloud pertenece a la propia empresa, por lo que en principio puede resolver los problemas que plantean las Nubes Públicas, pero implica que todo es CAPEX. De esta forma, de una forma muy generalista y a grandes rasgos (recordando que cada caso necesita de un análisis particular que puede conducir a conclusiones muy diferentes en función del tipo de empresa, de las características del servicio TIC necesitado, y del modelo de negocio) se podría decir que las Nubes Publicas suelen ser más adecuadas para las PYMEs, autónomos y ciudadanos, mientras que las Cloud Privadas son más adecuadas para las grandes empresas.

Y entre estos dos extremos existen otras soluciones como ya se ha mencionado antes, las Nubes Comunitarias y las Nubes Híbridas. En el mundo de las grandes empresas, muchos expertos les dan mejores expectativa a estas últimas dado que permiten a una empresa mantener los servicios TIC críticos, estratégicos o no externalizables por razones de regulación en su propia Cloud, y externalizar el resto de sus necesidades de recursos y servicios TIC, combinando las ventajas de ambas …

En nuestra opinión, en el mercado de las PYME españolas también puede tener cierto éxito las Nubes Comunitarias de la mano del cooperativismo o de las asociaciones empresariales establecidas en algunos sectores.

Tissat, además de estar colaborado y siendo catalizador de la creación de redes de este tipo, también ha sacado al mercado el servicio de ”Cloud Privada Alquilada” (con 2 modalidades básicas: “Hosting de Cloud Privada” o “Cloud Dedicada” y “Clouds Privadas Virtuales”) que añade otra opción en este campo, para las empresas que precisando de las características de las Cloud Privadas no pueden o quieren hacer frente a las necesidades de inversión en capital que precisan.

To cloud or not to cloud?: una perspectiva de negocio (caso de las Cloud Privadas)

Bajo el lema de To cloud, or not to cloud, that is a business question, ayer revisamos los razones de negocio que pueden impulsar a una entidad (empresa u organismo) a usar los Servicios de una Cloud Pública y adelantábamos que los dos principales no se dan (estrictamente hablando) en una Cloud Privada, es decir, si una empresa decide montar su propia Cloud Privada no transforma sus costes de capital en costes operativos, ni tampoco “parece” que claramente (en el sentido allí expuesto) esté sincronizando sus gastos TIC con la evolución de su negocio (flexibilidad de negocio), entonces ¿qué razones de negocio pueden motivar a una empresa a montar su propia Cloud Privada?. Estas son las que yo veo:

1. El principal motivo de negocio, en caso de Cloud Privada, es la mejora de su competitividad derivada del ahorro de costes tanto de capital como operativos que, en general, aportan las tecnologías subyacentes en una cloud auténtica: virtualización de servidores, abaratamiento del almacenamiento, automatización de procesos, eficiencia energética, etc. De forma somera:
   • El mejor aprovechamiento de los servidores y del almacenamiento reducen tanto los gastos de capital (pues se precisan menos equipos) como los gastos de operación (menos coste de mantenimiento de hardware y menos máquinas a las que atender).
   • La automatización de procesos (necesaria paras las características de elasticidad y de autoservicio) que precisa una cloud para ser considerada como tal, reduce los costes operativos.
   • Y, en general (sin entrar en casos particulares), la reducción de equipos, permite ahorrar costes de consumo de energía (costes operativos) y en compra de equipos para instalaciones auxiliares (menos SAIs, menos o menores grupos electrógenos, equipos de A/C de menor potencia) que reduce los costes de capital.
   
   
2. Otro motivo de peso es la mejora en la flexibilidad de negocio, pero ahora es un sentido distinto al que se comentaba en las Cloud Públicas (y se recordaba en el primer párrafo del comentario de hoy): en este caso la Cloud está formada por los recursos TIC que la empresa ha destinado a tal efecto, y no puede incorporar ágil y elásticamente más, debido al proceso de adquisición y puesta en marcha, además de que la inversión queda hecha aunqeu la cabo de un tiempo no se siga precisando. (Nota: recuérdese que estamos hablando de una Cloud Privada pura, y no una Cloud Híbrida, de hecho estas últimas surgen precisamente para resolver el caso que se acaba de exponer). En este caso, la mejora en la flexibilidad radica principalmente en 3 aspectos:
   • el primero es que la empresa puede priorizar en todo momento qué procesos de negocios son críticos o más importantes en cada momento y dotar a los mismos de más recursos TIC en detrimento de otros menos importantes para el negocio en esos momentos, pudiendo volver a cambiar la situación de uan forma ágil y rápida cuando la prioridad de los procesos de negocio vuelva cambiar.
   • el segundo aspecto se basa en el hecho de que generalmente en muchos negocios existen procesos (como las nóminas) que solo precisan recursos en determinados momentos (generalmente periódicos y previsibles) permitiendo los recursos que usan se puedan aprovechar fácil y cómodamente para otros procesos.
   • y, por último, siempre suele haber un ligero sobredimensionamiento que se aprovecha para que la reasignación de recursos no sea tan dura para los procesos menos importantes en ese momento.
3. Otra razón de negocio por la que una empresa despliega una Cloud Privada (en general es un motivo adicional a los dos anteriores, y no buscado por sí solo) es el poder dar a sus departamentos, áreas u otras unidades organizativas un modelo de servicio por el que las mismas se auto-gestionan el consumo que hacen de los recurso TIC, consumo por el que le repercuten la parte de costes correspondientes.
4. Por último, un caso particular es cuando eres una empresa del sector TIC y tus clientes te demandan bien servicios Cloud o bien un modelo de negocio donde el Cloud es la mejor respuesta.

Por otra parte las razones de negocio para recurrir a una Cloud Comunitaria, se pueden extrapolar a partir de las razones para una Cloud Privada, teniendo en cuenta en este caso que el dueño e inversor es una cooperativa (o agrupación de empresas, o figuras similares) y que los departamentos u áreas son las entidades integrantes de la cooperativa, etc.

Por último, los motivos de negocio para desplegar una Cloud Híbrida suelen quedar en un segundo plano frente a los tecnológicos, pero en cualquier caso son una combinación de los motivos de los modelos básicos (Públicas, Privadas o Comunitarias) que la integren.

“Lo-que-sea as a Service” (XaaS) y CaaS (Communications as a Service)

Si hay una palabra que esté aún más de moda que Cloud Computing es el estribillo “… as a Service”. Y, como han pronosticado los expertos, nos queda oír muchas veces “Lo-que-sea as a Service”, con sus consiguientes siglas XaaS. Una lista de lo que ya se está oyendo es la siguiente:

• Security as a Service (SaaS que colisiona en sus siglas con las mucho más populares de Software as a Service, y en algunos caso conduce a equívocos)
• Data as a Service (DaaS)
• DataBase as a Service (DBaaS)
• Disaster Recovery as a Service (DRaaS)
• DataCentre as a Service (DCaaS)
• Unified Communications as a Service (UCaaS)
• HelpDesk as a Service (HDaaS)
• Etc.

Estos vocablos en algunos casos se mezclan con otros conceptos que apuntan al uso de las Cloud para resolver un problema, pero no a que la tecnología se ofrezca como un servicio, por ejemplo: Cloud-Based Contact Center, Cloud-Based Help Desk, etc. En realidad todo depende en donde se focaliza y enfatiza el uso de la Cloud, si para resolver un problema interno (lo que sería una Cloud Privada) o para ofrecer servicios a terceros (Cloud Pública). En este último caso es cuando se habla, siguiendo con el ejemplo anterior, de HelpDesk as a Service (HDaaS), ContactCenter as a Service (CCaaS), UnifiedComms as a Services (UCaaS), es decir, del uso en modelo Cloud (compartido, autoservicio, elástico, etc.) de “centralitas virtuales”, “puestos de operador virtuales”, etc. destinados a empresas que no quieren o pueden invertir en capital para disponer de su propias infraestructuras de este tipo y en el software (de operador de HelpDesk o de ContactCenter) asociados a su operación (gestión de incidencias, gestión del conocimiento, etc.) y deciden usar las de un proveedor de Servicios Cloud (CCSP).

Muchos de estos vocablos creemos que han sido lanzados al mercado con la idea de convertirse en palabra de moda (buzzworld), pero no creemos que “creen escuela”, aunque lo que sí es cierto es que recogen la tendencia actual de llevarlo todo a la “nube” y por eso lo hemos tratado en el comentario de hoy.

Es más, en estos momentos los ejemplos anteriores están empezando a ser recogidos bajo, dependiendo de los medios que se lea, como CNS (Cloud Networking Services) o CaaS (Communications as a Service) y que mientras unos consideran un nicho de SaaS, otros lo sitúan una extensión del IaaS. Como se ha comentado, bajo ese concepto se recogen de forma aislada o en conjunto los servicios cloud de comunicaciones que hemos usado antes, así como otros próximos a ellos, fundamentalmente por su necesidad para montar una solución completa de servicios de alto nivel como HPaaS, o CCaaS: desde “centralitas virtuales” y “puestos de operador virtuales” hasta “comunicaciones unificadas”, añadiendo el software de gestión de incidencias, y completándolo con servicios de “escritorio en la nube” (“cloud desktop”) que no se debe confundir con “escritorios virtuales” o virtualización del desktop (como ya analizaremos otro día), etc., y que algunos CCSP (Proveedores de Servicios Cloud) ofertan como un paquete y otros individualmente.

Me gustaría destacar que esta área de CaaS (Communications as a Service), a caballo entre el IaaS y el SaaS, también está siendo recogida por algunos autores como un nuevo modelo (o nivel) de servicio (a añadir a los ya definidos de IaaS, PaaS y SaaS). Al margen de lo acertada, o no, de esa clasificación, lo que sí es importante es no confundir dichos servicios CaaS con el concepto de “Cloud Networking”: estos últimos se pueden definir como todo lo que tiene que tener una red y la gestión de la misma para dar soporte al Cloud Computing; esto afecta tanto a la WAN como a la LAN, como a cualquier otro tipo de comunicaciones. Aunque es un tema al que quiero dedicar más tiempo otro día, por realizar una primera aproximación que lo clarifique, lo que pretende el CloudNetworking es resolver problemáticas del siguiente tipo: en la actualidad una máquina virtual no se puede mover fácilmente a una máquina física en un segmento diferente, por problemas en las direcciones IP, en las reglas de firewall, etc., o el aumento de ancho de banda a una máquina física en función del número de máquinas virtuales que soporta, etc. (para los cuales en algunos casos existen soluciones, pero o no son estándares, o no soportan la automatización, o…).