Llegamos a ustedes gracias a:



Reportajes y análisis

Estrategia de Salida

Antes de que le confíe sus negocios a la nube, asegúrese de saber cómo salir

[05/07/2009] Cuando el mundo de TI mire hacia el 2008, ciertamente recordará la crisis financiera global. Pero también seguramente vinculará ese marco de tiempo con el despegue del cómputo en la nube -el motor detrás de más conferencias, conversaciones y márketing colateral que al parecer cualquier otra tecnología en desarrollo actualmente-. Pero entre todo el bullicio sobre si entrar o cómo entrar a la nube, hay una preocupación creciente sobre cómo salir.

El encierro de proveedor (vendor lock-in) es uno de los miedos primarios expresados por los líderes de ITI que consideran moverse hacia la nube. Y el reciente anuncio de que Coghead Inc., fabricante de un sistema de desarrollo de aplicaciones empresariales basadas en la nube, está cerrando ha exacerbado ese miedo.
El cómputo en la nube es una arquitectura en la cual las compañías consumen recursos de tecnología como un servicio de Internet, en lugar de un como un sistema propio. Gran parte del temor al encierro de proveedor es causado por conceptos erróneos, señaló John Willis, un consultor de administración de sistemas que bloguea sobre administración de TI y cómputo en la nube. Cuando la gente habla sobre encierro o lock-in, generalmente no distinguen entre los distintos tipos de nube que existen, cada uno de los cuales requiere niveles variados de compromiso.
Además, señala, el grado de encierro necesita ser contrarrestado con las ventajas de usar el sistema. La gente concluye diciendo cosas como la nube está muerta debido al encierro. Bueno, ¿de qué nube estamos hablando? Puedo darles cinco escenarios donde el encierro es un problema, y cinco otros donde no lo es, señaló Willis.
Mientras algunos proveedores debaten si el encierro existe, la mayoría concuerda en que hay razones técnicas para preocuparse.
Una falta de estándares pone trabas a la portabilidad de los datos y a las aplicaciones entre sistemas, señala James Staten, un analista de Forrester Research Inc. Y aunque la exageración popular sugiere que moverse a la nube no requiere ninguna carga pesada, eso no es verdad para algunas formas de cómputo en la nube.
Particularmente con software y plataforma como servicio, los proveedores usan interfases de usuario, interfases de programación de las aplicaciones (API) y bases de datos únicas y propietarias. Para aprovechar totalmente un sistema, los usuarios o los desarrolladores independientes, necesitan programar a esas especificaciones en grados diversos. Si están cada vez más insatisfechos con el servicio o el proveedor se hunde, los datos y/o las aplicaciones necesitarán ser reformateadas para ser removidas, lo cual sería complejo y costoso.
Si despliegas a cualquier nube por allí, algún grado de su despliegue está vinculado al proveedor, a través de la única máquina virtual o API para los que escriba, o la configuración o composición única de la aplicación, señala Staten.
Ha tomado una decisión de estar involucrado en un cierto ecosistema, anotó Michael Crandell, CEO de RightScale Inc., un proveedor de infraestructura en la nube. "Hay API y plataformas en el mundo de la nube que crean un jardín tapiado. Obtienes los beneficios del jardín, pero también estás restringido.
Dejado los problemas técnicos a un lado, el encierro también es un problema emocional, señaló René Bonvanie, vicepresidente senior de Serena Software Inc., que provee un sistema de administración del ciclo de vida de aplicaciones basado en la nube, y corre la mayoría de su propio negocio en la nube. Él argumenta que los datos hospedados en sistemas tradicionales como los de SAP, Oracle o Microsoft, están tan encerrados como los datos en cualquier sistema en la nube, pero la gente está más preocupada sobre el cómputo en la nube porque los sistemas no están en sus propios locales.
La percepción errónea común es que como los datos están al alcance, de alguna manera son más accesibles que cuando es remoto, señaló Bonvanie. Pero la realidad es, que es como el dinero: si está en una bóveda, no importa dónde está la bóveda. A pesar de todo, está encerrado.
Exacerbando este miedo está la inmadurez del mercado de la nube, señaló Staten, añadiendo que los líderes de TI no pueden evitar preguntar: Cuando venga la recesión, ¿logrará pasarla este proveedor?.
Ese es el caso de Christopher Barron, CIO de CPS Energy. "Estamos muy preocupados por estar encerrados con un proveedor por un período de tiempo de muchos años, sin saber si tienen la capacidad de servirnos apropiadamente, indicó.
Por esa razón, Barron se está moviendo hacia el cómputo en la nube lentamente, escogiendo ciertos procesos que encajan en esta arquitectura, sin que le exijan comprometer a la empresa entera en la nube. Tomándolo por piezas, podemos experimentar, afinar y ajustar mientras mitigamos un enorme riesgo de compromiso financiero, señaló.
La viabilidad de los proveedores es menos preocupante si lo estás usando para un proyecto de corto plazo, como un servicio promocional o una aplicación que quiera probar, añadió Staten.
Manteniéndose fuera de la bóveda
Otra forma de aproximarse al enigma del encierro es usar la regla Willis del pulgar: Cuanto más alto vaya en la taxonomía de la nube, más alto será el riesgo de encierro.
Con el almacenamiento en la nube, por ejemplo, los datos son fácilmente transportables porque están almacenados en servidores Linux, señaló, pero software y plataformas en la nube vienen con API y requerimientos de sistema que no son estándares, así como otras tecnologías propietarias.
Un ejemplo concreto es la Plataforma de Servicios Azure de Microsoft, que provee un sistema operativo y un juego de servicios de desarrollador para construir aplicaciones basadas en la nube.
Como Staten señaló, con Azure los usuarios escriben para un juego de servicios de la nube en una forma que es diferente a escribir para los mismos servicios desplegados en sus propios ambientes. Los requerimientos de la base de datos SQL, explicó, son diferentes de los requerimientos en Azure. Para moverse a un proveedor diferente, los usuarios tendrían que entender cómo traducir esos requerimientos de API a requerimientos de SQL Server, indicó.
Para minimizar la complejidad y el costo de hacer esto, señaló Staten, los usuarios de la nube deben tratar de tocar elementos propietarios y no estándares lo más ligeramente posible. Eso es lo que RightScale afirma que lleva a cabo con sus herramientas de administración, las cuales funcionan con una variedad de proveedores de infraestructura en la nube, tales como FlexiScale, GoGrid y Amazon.com.
Como Crandell explicó, las herramientas de RightScale crean una capa de abstracción encima de estos servicios, lo cual efectivamente minimiza la dependencia en tecnología propietaria de los usuarios, y hace a sus herramientas portátiles entre proveedores. Nosotros protegemos a las compañías de tener que escribir una solución específica para, digamos, Amazon, y luego tener que reescribirla otra vez para cada nube, señaló. Lo que es mejor, añadió Crandell, el código fuente de RightScale está disponible para los usuarios, así que si quieren alejarse de RightScale, pueden hacerlo.
Christian Taylor, CEO de MeDeploy, señaló que él aprecia la flexibilidad del enfoque de RightScale. Basado en Hamden, Connectitud, MeDeploy ofrece una infraestructura que permite a los distribuidores de películas construir ecosistemas en línea para distribuir y vender películas. El sistema está basado en la EC2 (Nube de Cómputo Elástico) de Amazon, y está administrado con herramientas de RightScale.
Si acaso, [alejarse de EC2] sería más fácil que [salir] de un sistema instalado en el local, señaló Taylor. Utiliza hardware estándar, así que si un competidor nos hizo pensar en cambiarnos a una nube diferente, podemos simplemente configurar un sistema de nube completamente distinto, cargarlo y luego hacer el cambio.
La danza del riesgo-beneficio
Evitar los aspectos propietarios del sistema de un proveedor realmente se reduce a un intercambio de riesgo-beneficio, señaló Staten. Necesita contrarrestar las ventajas de usar tecnología específica de un proveedor contra las vulnerabilidades del fabricante.
Tome Salesforce.com Inc., el cual utiliza un lenguaje propietario de programación y sus propias API, indicó. Hace años, nadie estaba escribiendo aplicaciones personalizadas en Salesforce o impulsando sus API, porque ellos no sabían si estarían por aquí, explicóa Staten. Ahora que han estado aquí por 10 años y que están bien capitalizados, esas cosas están en alto uso.
Para determinar la viabilidad de un fabricante, Staten sugiere que los compradores hagan una investigación en profundidad y le pida al fabricante que le brinde, bajo un acuerdo de no divulgación, información tal como su posición de efectivo. También recomienda hablar a los capitalistas de inversión que respaldan la compañía sobre su compromiso con ella. Adicionalmente, Staten señaló, pida referencias de si solo están metiendo las puntas de los dedos en el agua con el fabricante, o si están tomando un mayor compromiso.
Bonvanie de Serena Software también recomienda a las compañías especificar una estrategia de salida en sus contratos. El imperativo es que accedes con tu proveedor a cuáles son los procedimientos para abandonar su aplicación, si fuera necesario, señaló. Por ejemplo, ¿cómo salen los datos, y cuál es la participación del fabricante en hacer que eso suceda? ¿Cuánto tiempo tienes para sacar los datos después de que no renueve el servicio?
En muchos de sus contratos, Serena inserta acuerdos para regular lo que le pasa al código fuente de sus proveedores de software en la nube si ellos suspenden operaciones. Bonvanie ha encontrado que muchos proveedores en la nube están más dispuestos a esto, que la mayoría de proveedores tradicionales.
También es esencial aplicar normas tempranas sobre cómo su compañía va a utilizar la nube y bajo qué circunstancias, señaló Staten. Esto es especialmente importante cuando se refiere a asegurar los datos en la nube, lo cual generalmente requiere personalización por el usuario. Tienes que hacer algunas cosas sobre y más allá de lo que el proveedor de la nube ofrece para ser seguro o cumplir las regulaciones, indicó.
Así que si quieres usar cinco diferentes proveedores en la nube, por ejemplo, necesitas estar seguro de antemano de que puedes personalizar todas las cinco plataformas.
Crear estos tipos de normas no es algo que muchas compañías están haciendo todavía, debido a que el uso de la nube ahora mismo es un poco como el Salvaje Oeste, indicó Staten.
Con el tiempo se desarrollarán estándares, probablemente dirigidos por la demanda de los clientes, indicó. Esto no sucederá sin tensión, porque la demanda de los clientes será contrarrestada por las ventajas que los proveedores ven en el encierro. Por esa razón, los usuarios necesitan ser inflexibles sobre cuáles estándares desean y dónde son más importantes. Un área crucial está en usar servicios web abiertos en la comunicación de aplicación a aplicación, apuntó Staten.
El analista de Gartner Inc., Richard Ni, sostiene que los líderes deTI pueden fomentar el desarrollo de estándares asegurando que sus equipos consideren un amplio rango de proveedores y tecnologías, más allá de los líderes de mercado obvios. Alentaremos el encierro si cerramos nuestros ojos a otros proveedores en la industria, señaló. El CIO tiene un rol que jugar al asegurar que varios proveedores están involucrados en los procesos de evaluación, selección y auditoría.
En tanto la exagerada promoción del cómputo en la nube se asienta, la esperanza es que las preocupaciones sobre el encierro crezcan más mesuradas. Eso sería un desarrollo bienvenido para Bonvanie, quien ve igual cantidad de riesgo con los sistemas de cómputo tradicionales. De hecho, su uso del software de negocios basado en web de NetSuite Inc. y el software ERP basado en web de IntAcct Corp. lo ha convencido de que sus interfases y procedimientos para recuperar y descargar datos son más fáciles de usar que los de SAP AG.
Lo que me vuelve loco es que la misma gente que está preocupada por el encierro en la nube no está preocupada por el encierro detrás del firewall o en los sistemas instalados en su local, donde la gente corre normalmente mezclas de tres o cuatro diferentes clases de Unix, anotó Willis. Es mucho más difícil moverse de AIX a Sun, que de Amazon a FlexiScale.
Willis espera el día en que la gente le deje de preguntar si la nube causa encierro. Es la pregunta equivocada, señaló. La nube son solo los muebles. En cambio, indicó Willis, quite la palabra nube y pregunte ¿Hay encierro en las opciones que estoy considerando?.
Mary Brandel, Computerworld (US)