Llegamos a ustedes gracias a:



Reportajes y análisis

Seleccione y provisione sus propios servicios de nube

Cómo seleccionar y preparar aplicaciones para la nube

Con sus propios servicios de nube podrá añadir valor para los clientes y empleados, e incluso establecer nuevas fuentes de ingresos. A continuación, cómo encontrar posibles servicios entre sus aplicaciones existentes, y tenerlos listos para desplegarlos
[29/05/2012] Gracias al éxito de Amazon EC2, Salesforce, y otros servicios de nube pública, la mayoría de las empresas entienden el valor de la computación en la nube. De hecho, un creciente número de empresas están explorando la idea de ingresar al negocio de la computación en la nube. Y ¿por qué no? Lanzar un servicio de nube pública podría  generar un nuevo flujo de ingresos -un autoservicio para clientes, por ejemplo- con mínimas adiciones a la infraestructura existente.
Pero el camino hacia el lanzamiento de un servicio de nube no es necesariamente recto. Los gerentes TI de las empresas necesitan seleccionar cuáles aplicaciones deberían ser preparadas para la nube en base a un riguroso conjunto de criterios. Más aún, deben establecer o modificar las API o interfases de los servicios y enfrentar los nuevos desafíos en gobierno y seguridad, entre los que se encuentra la capacidad de registrar el uso, tanto para la facturación como para las devoluciones.
¿Está listo para el negocio de la nube? ¿Cuáles de sus servicios están a punto para convertirse en un servicio de nube? ¿Cómo establece un convincente caso de negocios? ¿Cómo crea servicios de nube exitosos, simples o complejos?
El texto a continuación proporciona algunas pautas generales para establecer servicios de nube, entre las que se incluye identificar, justificar, migrar y validar la transformación de nuevos y existentes servicios de aplicaciones en verdaderos servicios de nube. Con esta información, tendrá una idea general de cómo establecer servicios resilientes dentro o fuera de la empresa.
Paso 1: Seleccione la(s) aplicación(es) correcta(s) para la nube
Todas las organizaciones tienen una aplicación de la que todos creen que podría ser un buen servicio de nube. Generalmente, el análisis demuestra lo contrario.
Necesita construir un caso de negocios para justificar la creación de un servicio de nube a partir de una aplicación individual o conjunto de aplicaciones. Considere cómo será el servicio de nube. Considere la realidad técnica, incluyendo los costos de migración y desempeño. En otras palabras, ¿cuál será el verdadero ROI del servicio de nube?
Para determinar la viabilidad, comience ponderando el valor real de la aplicación. Entienda los casos de uso para los servicios de nube, como los siguientes, que son muy comunes:
1. Los consumidores externos pueden consumir información de órdenes, como el estado de una orden de revisión, demoras y actualizaciones.
2. La empresa puede generar ingresos adicionales alquilando servicios de nube de control de inventario a varias empresas externas.
3. Otras divisiones de la compañía pueden validar los datos usando un servicio de nube, ya sea humano a máquina o máquina a máquina, lo cual conduce a uns mejor calidad de los datos.
Defina el problema que los potenciales servicios de nube resolverán como primer paso para definir el valor que ofrece al negocio. Tenga en mente que, en algunos casos, tendrá que trasladar aplicaciones enteras. En otras palabras expondrá unos cuantos servicios simples a través de un protocolo de servicios web, por ejemplo.
Una vez que ha establecido el por qué y el qué para la provisión de un servicio de nube, necesitará determinar cómo lo hará -y, más importante aún, cuánto costaría. Los costos de migración dependen del estado de la aplicación existente y de su arquitectura -y la cantidad de trabajo que considera que le tomará exponer los aspectos de la aplicación, o la aplicación en su integridad, como servicio de nube.
Obviamente, la forma en que conduce esta evaluación depende en gran medida del tipo de aplicación y servicios que pretende exponer. Esta lista genérica de pasos de evaluación puede ayudarlo a comenzar:
* Evalúe el estado de la aplicación existente.
* Evalúe el actual diseño de la interfase de usuario.
* Evalúe el actual diseño de seguridad.
* Determine cómo se implementaría la contabilidad basada en el usuario.
* Estime el alcance de los cambios a la aplicación core y otras tareas de re desarrollo.
* Considere el número de clientes internos y externos que podrían usar el servicio y estime qué infraestructura adicional podría requerirse.
* Evalúe qué características de computación en la nube deben ser añadidas, como el autoprovisionamiento y el multitenancy.
* Estime el costo y el esfuerzo del desarrollo de la interfase del servicio.
* Determine el nivel de esfuerzo para integrarlo con los actuales sistemas de seguridad.
* Esboce los planes de testeo y montaje.
* Estime los costos de despliegue, incluyendo la futura infraestructura que se requerirá para crecer.
Como regla general, mientras mayor sea la edad y la complejidad de una aplicación, mayor serán los costos de migración, quizás hasta el punto en donde no es costo efectivo. También necesita tomar en consideración todas las realidades de la tecnología, como la pérdida de desempeño. Toda aplicación interna sufrirá pérdida de desempeño cuando se acceda a ella mediante Internet.
Cuando cree un caso de negocios para reestructurar una aplicación como servicio de nube considere lo siguiente:
* Costos de migración. Este es el costo de cambiar una aplicación para satisfacer los requerimientos de un servicio de computación en la nube. Incluye todo el hardware y software nuevo que se requiere, así como los cambios a la arquitectura y diseño, costos de desarrollo, recursos de testeo, costos de despliegue y cosas por el estilo.
* Costo del riesgo.En otras palabras, el dinero que se pierde si el cambio de la aplicación a un servicio de nube no resulta.
* Costo de mantenimiento. Cuánto va a necesitar gastar en mantenimiento del servicio de nube a lo largo del tiempo.
* Valor para el negocio. La ganancia potencial de tener una aplicación que se convierta en un verdadero servicio de nube va más allá de los ingresos predichos, pues incluye valores estratégicos, como la capacidad de mejorar el servicio para la base actual de clientes y retener mejor a estos clientes.
Puesto de manera simple: Valor del Servicio de Nube = Valor para el Negocio - (Costo del Riesgo + Costos de Migración + Costos de Mantenimiento). Generalmente, esto cubre un horizonte de tres años.
Entonces, si una aplicación se encuentra expuesta como un servicio de nube con un valor de 20 millones de dólares para el negocio, con un costo del riesgo de cinco millones de dólares, un costo de migración de 4,5 millones de dólares y un costo de mantenimiento de dos millones de dólares:
Valor/ROI del Servicio de Nube = 20 – (5 + 4,5 + 2) millones de dólares
Por tanto, el valor del servicio de nube es de aproximadamente 8,5 millones de dólares. Queda claro que este ejemplo justifica así mismo con precisión, dado que ha capturado los costos en forma correcta.
Paso 2: Evalúe su actual arquitectura de aplicaciones
Una vez que ha estimado un ROI viable para justificar su servicio de nube, es el momento de observar la actual arquitectura de aplicaciones, es decir:
* Datos
* Servicios
* Procesos
* Redes
* Interfases de usuario y API
* Seguridad
* Gobierno
* Capacidad de crecer
Mucho depende en la edad de la aplicación y la forma en que ésta fue diseñada. En muchos casos, las aplicaciones más nuevas fueron construidas usando API tanto para comportamiento como para datos. Las aplicaciones más antiguas podrían incluso no tener API, en cuyo caso se requerirá de tiempo y esfuerzo adicional para convertirlas en servicios de nube.
Por supuesto, siempre hay forma para comunicarse con las aplicaciones antiguas, tales como las interfases transaccionales, accesos directos a datos o incluso screen scraping. Pero generalmente hay problemas con estos enfoques -principalmente, desempeño y escalabilidad. Considere la efectividad de usar estas interfases versus hacer una reingeniería más invasiva.
Cuando tenga un buen entendimiento de la arquitectura de las aplicaciones, tendrá una buena visión de la mejor forma para convertir los servicios de las aplicaciones core en servicios de nube. Esto incluye saber la estructura y funcionamiento de la base de datos, la forma en la que se accede a la base de datos, el uso y la ejecución de la lógica del negocio, la integración con las interfases de usuario, y muchos otros elementos del proceso core del negocio.
Comience deconstruyendo la aplicación en sus elementos funcionales como los datos, servicios, procesos, interfases de usuario, y cosas por el estilo. Una vez que conozca estos elementos, podrá recrear una arquitectura lógica para la aplicación que satisfaga de la mejor manera las necesidades del servicio de nube propuesto. Luego es cuestión de mapear la nueva arquitectura lógica a una arquitectura física y determinar el trabajo requerido para crear esa arquitectura física.
Paso 3: Seleccione el mejor enfoque para crear su servicio de nube
Tenga en mente que los sistemas objetivo deben ser verdaderos sistemas de computación en la nube. En otras palabras, deben proveer nuevas características que generalmente no existen en la aplicación actual como:
* Machine addressability. La capacidad de acceder, asignar y usar el servicio de nube, máquina a máquina, sin tener que tratar con un humano.
* Multitenancy. La capacidad de soportar muchos usuarios externos del servicio de nube al mismo tiempo y asegurar a la vez un desempeño consistente; y asegurarse que los tenants no interfieran unos con otros.
* Contabilidad basada en el uso.La capacidad para monitorear el uso del servicio de nube por parte de usuarios autorizados, y hacer los cobros o llevar la contabilidad de tal uso.
* Seguridad avanzada. Esto incluye la capacidad de administrar la seguridad usando un enfoque basado en la identidad.
Hay tres enfoques básicos para crear servicios de nube a partir de aplicaciones nuevas o existentes. Llamémoslos pequeños, medianos y grandes.
En el escenario de habilitación de un servicio de nube pequeño solo externalizamos una pequeña parte de la aplicación, generalmente unos cuantos servicios que realizan operaciones como la validación de datos. Hay poco que hacer más que crear un servicio web que tenga a una interfase bien definida para aceptar los datos del consumidor del servicio de nube, validar los datos contra la base de datos conectada a la aplicación, y luego retornar el estado al consumidor. Un ejemplo podría ser un consumidor que valida una orden usando un servicio web sobre la Internet abierta.
Para ilustrar, creemos un servicio llamado Validate_Order(), el cual hace lo siguiente:
* Abre el servicio
* Registra el uso del servicio y el consumidor
* Registra el tiempo
* Acepta el número de la orden
* Valida el número de la orden
* Busca el número de la orden en la base de datos
* Retorna el estado, válido o no
* Registra el tiempo
* Cierra el servicio
Por supuesto, uno tiene que asegurarse que uno puede hacer esto con un enfoque multiusuario/multitenancy, lo cual significa que uno tiene que asignar recursos equitativamente a todos los usuarios y proteger los procesos de los usuarios. Más aún, uno tiene que aprovechar la contabilidad basada en el uso para rastrear el uso, sin importar si cobra o factura por el servicio o no.
Uno puede aprovechar muchos diferentes tipos de tecnología al tomar el enfoque pequeño, incluyendo programas externos que corren en espacios de procesos separados -los cuales se separan de la aplicación core y pueden requerir poca o ninguna modificación. O el servicio puede encontrarse fuertemente unido dentro de la aplicación y requiere de alguna modificación en el programa core. No hay un enfoque de conjunto o mejor práctica. Uno tiene que considerar cada servicio de nube caso por caso.
Una vez que ha construido el servicio, conecte el WSDL y seleccione un método de comunicaciones, el cual generalmente es REST (Representational State Transfer). El consumidor del servicio podrá estar en capacidad de acceder al servicio usando una URL, así que debe entender como invocar los servicios mediante la lectura del WSDL, y luego usar REST para invocar el servicio.
En el escenario de habilitación de un servicio de nube medio generalmente tratamos con muchos y diferentes servicios de nube que proporcionan muchos diferentes tipos de funciones. Uno puede considerar esto como el caso anterior pero multiplicado por cinco o 10. Existen muchos más servicios de nube concurrentes que son accesibles por el consumidor de los servicios de nube, lo cual significa que uno necesita tratar con más problemas de concurrencia y multitenancy.
En el escenario de habilitación de un servicio de nube grande generalmente tratamos con cientos y, algunas veces, miles de servicios de nube que son externalizados y administrados. Estos tipos de servicios de nube podrían ser consumidos por miles de clientes todos los días, todos accediendo a estos servicios de formas diferentes y con propósitos diferentes. El desafío aquí no es con la externalización del servicio sino con la administración concurrente de estos servicios en un estado operativo exitoso por largos periodos de tiempo. En otras palabras, el objetivo central es tanto la escalabilidad como la estabilidad.
Tanto en el escenario medio como grande, uno generalmente trata con una rearquitectura más sistémica de la aplicación core, esto incluye cambios a la base de datos y servicios de cómputo core. Esto se hace de dos maneras:
1. El software add on habilita la nube. En esencia, el middleware convierte los servicios de aplicaciones nativas en servicios de nube y administra estos servicios usando funciones preconstruidas dentro del producto. Este software está comenzando a aparecer en el mercado, generalmente se vende como software de habilitación de nube (cloud enablement).
2. Una reescritura completa de la aplicación desde cero. Rehacer la aplicación se acomoda a las necesidades de los servicios de nube, como el soporte del multitenancy. Esto en realidad puede ser una oportunidad para recrear la aplicación -quizás usando nuevos lenguajes de programación o tecnología de bases de datos- lo cual generalmente es más económico que construir sobre el código antiguo.
Finalmente, al considerar la arquitectura de la aplicación y la externalización y administración de los servicios de nube, uno necesita considerar los estándares. La mayoría de los estándares que son relevantes aquí se encuentran relacionados con los servicios web, tales como WSDL, SOAP y REST. Por supuesto, algunos estándares están emergiendo en el espacio de la computación en la nube, como los estándares para la seguridad y el gobierno. Se debe de tomar en consideración cuáles son los mejores estándares y enfoques para su servicio de nube antes de que se inicie el proyecto.
Paso 4: Evalúe los temas de seguridad
La seguridad es lo primero y más importante para las implementaciones de computación en la nube. El establecimiento de los servicios de nube, públicos o privados, requiere que piense su enfoque basado en la seguridad. Esto incluye crear un modelo de seguridad, seleccionar la tecnología de seguridad adecuada y entender los riesgos.
El tema principal es que se encuentra a punto de exponer como servicio de nube un sistema que fue diseñado solo para uso interno. Los modelos de seguridad aprovechados en los servicios de nube son generalmente más sofisticados y actuales, y usan tecnologías como el encriptamiento avanzado y la seguridad basada en la identidad.
La seguridad basada en la identidad implica que uno rastree la identidad de los usuarios humanos, de las máquinas usuarias, los servicios, los datos y similares, de tal forma que pueda administrar la seguridad de manera muy granular, y determinar quién puede acceder a servicios específicos y qué pueden hacer con estos servicios. Por ejemplo, sabemos que una máquina con una identidad específica puede invocar un servicio, porque esa máquina fue validada antes de que se le permitiera invocar al servicio. Los sistemas de seguridad de la administración de la identidad generalmente requieren de un repositorio que registre las identidades y de una capacidad de validar credenciales de todos los involucrados.
El encriptamiento es otro mecanismo de seguridad estándar de los servicios de nube. Tanto el consumidor como el proveedor de servicio deben estar en capacidad de activar el encriptamiento cuando se requiera, de tal forma que la sesión entre el proveedor de servicio y el consumidor sea privada. Cuando los datos encriptados se trasladan de un sistema a otro a esto se llama encriptamiento al vuelo (encryption in flight).
Más aún, uno necesita considerar la protección de los datos en reposo. Esta protección adicional sirve para que las partes externas no puedan tocar su aplicación core o acceder a la base de datos. Los datos se encuentran encriptados cuando descansan en el disco, y desencriptados cuando lo requiera alguna aplicación o servicio de nube.
Paso 5: Decida los modelos de costo y la contabilidad basada en el uso
El último paso es pensar cómo registrar el uso de su servicio de nube, y quizás facturar ese uso.
Muchos paquetes comerciales registran el uso de los servicios de nube por usted. Ellos funcionan como otra aplicación externa que se encuentra acoplada a su aplicación core y a los servicios de nube. Algunos de ellos son software licenciado de manera convencional; otros son servicios de nube de proveedores de nubes públicas. Lo que escoja depende de su modelo de costo preferido y de la naturaleza de su servicio de nube, pero la tecnología ya se encuentra disponible, así que no hay razón para que lo construya por sí mismo.
Siguiente, decida cómo quiere facturar el servicio. Algunos de éstos pueden ser servicios de cloud computing públicos que son facturados a otras organizaciones de la misma forma en que una empresa de telefonía móvil factura su servicio. Por otro lado, muchos de estos servicios serán facturados como cobros dentro de la misma empresa. Hay muchos modelos para escoger, como:
* Todo lo que pueda comer
* Facturación por tiempo
* Facturación por asiento
* Facturación por cantidad
La facturación todo lo que pueda comer registra el uso del servicio, pero los consumidores pueden usar todo lo que quieran del servicio. Generalmente esto es aplicable si conoce al consumidor del servicio, y proporciona el servicio como un beneficio añadido.
Cuando factura por tiempo, un sistema de contabilidad basado en el uso reportará el uso y creará la factura. Las facturas pueden ser transmitidas de manera automática en intervalos predeterminados.
Cuando factura por asiento, el total podría ser un pago mensual plano multiplicado por el número de cuentas de usuario, o podría querer medir el uso de cada usuario, y facturar de acuerdo a ello. Si opta por el último modelo, asegúrese que el paquete tenga la granularidad que necesita.
Cuando factura por cantidad, factura por la cantidad de datos transmitidos al consumidor, generalmente por megabytes. Nuevamente, el uso de los datos se registrará, y se transmitirá automáticamente una factura al consumidor del servicio de nube.
¿Y ahora qué?
La externalización de los datos de la aplicación y sus comportamientos como servicios de nube públicos o privados solo se va a incrementar. De hecho, la creación de servicios de nube conduce a nuevas oportunidades de generación de ingresos para algunas empresas, y ofrece una forma relativamente sencilla de explotar el valor de las aplicaciones empresariales core fuera y dentro de la empresa.
Sin embargo, recuerde observar bien su cartera de aplicaciones antes de comenzar. Las aplicaciones que parecen fáciles de transformar a servicios de nube podrían convertirse en algo completamente impráctico por razones no obvias. Por otro lado, si cava profundo en su cartera podría encontrar aplicaciones de las que nunca pensó que podrían provisionarse como servicios de nube, y que incluso podrían ser relativamente fáciles de provisionar.
Todo depende de usted. Hay suficiente espacio para crear valor, especialmente cuando uno escoge desplegar servicios que reflejan algún aspecto único de lo que hace su empresa.
David S. Linthicum, InfoWorld (EE.UU.)