Migrando a la Nube

Este es un blog que publique hace casi 2 años en otra pagina, pero me parece que aun es actual.

Estudios recientes indican que es una tendencia el uso o adopción de computación en la nube (cloud computing) ha venido creciendo, si bien es cierto que muchas cosas las utilizamos desde la nube, como escuchar música (spotify), ver televisión (Netflix), almacenar documentos (google drive), hacer llamadas (skype), compartir mensajes (WhatsApp), no quiere decir que todo los servicios de Tecnología Informática (T.I.) deban ir a la nube.

Muchos de los proveedores de tecnología nos intentan vender servicios de nube y nos hacen ver a los que aun no estamos en la nube, que ya hacemos parte de los "late majority", ya que no aprovechamos a tiempo esta tecnología y no estamos alineados con los cambios tecnológicos.

Nuestro reto en las organizaciones es, no ir con todos y con todo a la nube, nuestro reto realmente es tomar ventaja de las oportunidades que proveen las nuevas tecnologías y adaptar la estructura organizacional a estas tecnologías. Cuando nos movemos a una nueva forma de trabajo, desde la perspectiva de la nube, es necesario re-construir una arquitectura empresarial que soporte esta nueva forma de trabajo, hacer re-ingeniería a los procesos y no menos importante revisar las estructuras de gobierno corporativo, de tal forma que podamos estar seguros de qué es lo que vamos hacer y sobre todo que es lo que vamos a mover a la nube.

Antes de movernos , necesitamos entender los principales modelos de nube, definir claramente los requerimientos para movernos a la nube, seleccionar cuidadosamente el proveedor y tener claro el contrato a firmar, recordemos que será un contrato por mucho tiempo.

El término de nube vino a usarse hacia 2006, compañías como Amazon y Google fueron las primeras en usar el término Cloud Computing. Hacia 2011 NIST (National Institute of Standard and Technology) desarrolló al definición completa de Cloud computing.

NIST ha definido -hasta ahora- los tres principales modelos de trabajo en la nube. Infraestructure as a Service (Iaas) , esto es básicamente el uso de una máquina virtual ubicada en la infraestructura del proveedor, en la máquina virtual puede instalar lo que se desee, obviamente con las restricciones del contrato.

El otro modelo es Platform as a Service (PaaS), esto es un IaaS más aplicaciones para desarrollo, incluye sistema operativo, un framework para un lenguaje de programación y base de datos, así; se desarrolla software en la infraestructura del proveedor para luego exponerlo ahí mismo. Este modelo tiene un gran inconveniente que se denomina el "Cerco del proveedor", ya que que es muy difícil trasladar las aplicaciones desarrolladas desde un proveedor de PaaS a otro proveedor de PaaS, La gran noticia, es que se puede desarrollar rápidamente si necesidad de comprar hardware y software.

Finalmente tenemos Software as a Service (SaaS) , en donde se paga por tener acceso a aplicaciones y bases de datos. Podemos tener tener acceso a las ultimas versiones del software de aplicación, últimos parches a nivel de sistema operativo y de bases de datos, con la tranquilad de que habrá el menor impacto en el servicio, solo que existe la dificultad de mover los datos de un proveedor a otro o, al querer finalizar el contrato de servicio en la nube y trasladar los datos nuevamente a infraestructura "on premise"

En resumen, estos son los 3 mas grandes modelos, pero existen muchos otros modelos menos conocidos, como CaaS - Communications as a Service, BaaS - Backup as a Service, DBaaS - Database as a Service, MaaS - Monitoring as a Service, DaaS - Desktops as a Service.

Aunque es probable que debamos ir a la nube y que la tendencia según una encuesta de LogicsMonitor, para el 2020 es que el 43% de las empresas prestarán sus servicios desde la nube pública (Amazon AWS, Google Cloud Platform, Microstf Azure, IBM Cloud y otras), la real pregunta es: Realmente la nube es para todos o para todos los servicios de T.I?

Veamos algunas consideraciones a tener en cuenta para movernos a la Nube y tratar de deducir si es lo mejor para cada uno:

CONTRATO DE SERVICIOS

No voy a entrar en detalles sobre lo que debe ir en el contrato, solo voy a dar un algunos TIPS a tener en cuenta:

Primero: algunos de los contratos de proveedores de servicios en la nube tienen una cláusula, en la cual el nivel de calidad del servicio puede ser cambiado en forma unilateral por parte del proveedor y el cliente solo será informado por la pagina web del servicio o a través de un aviso dirigido desde el proveedor, por ejemplo la que vemos a continuación.

" El proveedor podrá efectuar modificaciones o actualizaciones a los Servicios (tales como infraestructura, seguridad, configuraciones técnicas, características de las aplicaciones, etc.) durante el Período de Servicios, incluidas aquellas destinadas a reflejar cambios en la tecnología, prácticas de la industria, pautas de uso del sistema, y disponibilidad de Contenido de Terceros. Las Especificaciones del Servicio están sujetas a modificaciones a discreción del proveedor; no obstante, las modificaciones que el proveedor efectúe a las Especificaciones del Servicio no tendrán como consecuencia una reducción significativa del nivel de rendimiento o disponibilidad de los Servicios respectivos que se le presten durante la vigencia del Período de Servicios"

Segundo, las nubes dan la posibilidad a los proveedores de habilitar o denegar servicios a discreción o disminuir su rendimiento, o lo que deseen, cualquiera que sea la situación el proveedor puede hacer eso con o sin aviso para el cliente. Veamos un ejemplo

" El proveedor podrá suspender en forma temporal Su contraseña, cuenta y acceso a los Servicios y uso de los mismos si según el criterio razonable del proveedor, los Servicios o cualquiera de sus componentes estuvieran por sufrir una amenaza significativa a la seguridad o funcionalidad. El proveedor le notificará con anticipación tal suspensión a discreción razonable de el proveedor en función de la naturaleza de las circunstancias que dan origen a la suspensión. El proveedor empleará esfuerzos razonables para restablecer los Servicios afectados sin demora una vez que el proveedor determine, a su discreción razonable, que la situación que dio origen a la suspensión ha sido subsanada"

Existen otros elementos que deben leerse y negociarse detalladamente en los contratos como son: Los acuerdos de confidencialidad y el manejo que eventualmente le podrán dar los proveedores a los datos, los respaldos (backups), la operación a nivel de infraestructura (aplicación de parches que puedan afectar la operación de la organización) , la seguridad, un esquema de recuperación ante desastres (Disaster Recovery), las indemnizaciones, las responsabilidades de las partes y las causas por las cuales se pueden finalizar los contratos

Dentro del contrato existen muchas renuncias por parte del proveedor, ante lo cual no lo hace menos responsable al servicio ofrecido y es mejor tomar buenas decisiones, mas allá de esperar que se puedan aplicar las cláusulas de exigencia del servicio. No pretendo decir que no es viable mover los servicios a la nube por que los proveedores nos "amarran", solo quiero decir que hay que negociar el contrato muy tranquilamente y decidir que tan crítico es el servicio a mover a la nube como para dejar a discreción del proveedor la suspensión del servicio; aun si no se está afectando el SLA de disponibilidad contratado.

LOS SLAs y KPIs

Los SLA (Service Level agreements) en resumen y hablando de servicios en la nube, son los términos mínimos del contrato. Los KPI (Key Performance Indicators) son los indicadores que miden en detalle un buen SLA, por ejemplo el Indicador de disponibilidad, generalmente es el único KPI de este SLA . Los proveedores se no entran en detalles para una definición mas detallada de este SLA, por ejemplo , no existe un KPI para el tiempo de respuesta de los servicios (ni en una infraestructura "on premise"). La nube esta disponible siempre, así que no se esta incumpliendo el SLA de disponibilidad, solo está lenta, y para los proveedores de nube, existen muchas causas por la cuales su tiempo de respuesta se puede ver afectado.

Puede el proveedor entonces ofrecer un mejor tiempo de respuesta en su nube? Es muy probable , aunque la mayoría de los contratos indicarán que el proveedor hará su mejor esfuerzo para responder en los tiempos de atención pactados.

Los SLA permiten definir las expectativas del servicio y las compensaciones económicas en caso de falla del mismo, limitan la responsabilidad de los proveedores "castigándolos", cuando hay demasiadas fallas y solo no más.

Los SLAs y los KPIs, no van a ayudar mucho en que caso que el proveedor no pueda prestar el servicio por un "CASO DE FUERZA MAYOR", es responsabilidad de la organización (gobierno de T.I.) que contrata los servicios minimizar -lamentablemente con dinero-, el impacto de un evento no controlable ni atribuible al proveedor bien sea en la reducción de los tiempos de respuesta o en un incidente de disponibilidad.

EL COSTO DEL SERVICIO

El costo del servicio por supuesto es un asunto a tener muy en cuenta y por cada tipo de nube existe esquemas de valores diferenciadores, por ejemplo para IaaS, existe pago por demanda o pago por suscripción y estos son configurados por máquina virtual usada.

El pago por demanda es mas alto, pero tiene la ventaja de disminuir los recursos o apagar las maquinas virtuales cuando tienen baja carga de trabajo, en cambio el pago por suscripción es mas bajo, pero se corre el mismo riesgo de la compra o arriendo de infraestructura "on premise", y es que se gasta dinero en algo que no se está aprovechando y que finalmente se verá reflejado en el valor de la factura mensual.

En cuanto al soporte no debemos olvidar el que el servicio que ofrecen muchos proveedores de nube es el estándar o básico y este no cuesta igual que uno 24/7 y que el tiempo de solución de un problema en 8 horas no vale lo mismo de uno de 15 minutos.

El costo siempre estará asociado a las opciones y beneficios que el proveedor ofrece y que la organización desea manejar, si algún proveedor no tiene u ofrece los beneficios, recursos, modelos de precios que la organización necesita, entonces es bueno buscar otro proveedor.

Pueden ver mas información en : https://www.omg.org/cloud/index.htm

Uno de los principales elementos a tener en cuenta durante el análisis es el impacto en la arquitectura actual, identificar cuales componentes se van a retirar, cuales necesitan renovación y cuales son realmente importantes.

Se puede tomar cualquier metodología de gestión de procesos, personalmente considero que el Framework de arquitectura empresarial de Zachman podría aplicar aquí para realizar el inventario, una fórmula fácil de recordar este framework es a través de las 5W-H por:

WHY(MOTIVACIÓN): Cuales son las razones para el cambio?, cuales son los objetivos de negocio?, cual es la estrategia?.

WHAT (DATOS): Que vamos a mover? ,cuales procesos se mueven? , cuales aplicaciones? , cuales son los datos que se van a mantener en uso?

WHO (PERSONAS): Quienes se van a ver afectados?, Cual será el proceso para el flujo de trabajo dentro de la organización?, Que tanto van a cambiar las funciones de los afectados?

WHEN: (TIEMPO) Cuando necesitaremos el servicio al 100%, Están identificados los picos de productividad?, como se van a manejar estos picos?

WHERE (REDES Y COMUNICACIONES): Donde van a estar ubicados nuestros datos?, como nos vamos a conectar?, que va a pasar con las aplicaciones heredadas(legacy)?

HOW: (PROCESOS) Cómo vamos hacer la transición a la nube?, cual será el nuevo modelo de trabajo?, En caso de no funcionar como se esperaba, cómo vamos devolvernos?

Hay que recordar que en la nube, T.I no estaría administrando los recursos, no quiero decir que aun no sería responsable en términos de gobierno, nosotros como parte de T.I, debemos desarrollar nuevos procesos para acomodarnos al ambiente en la nube. Por ejemplo, si hay problemas; como vamos a manejar estos problemas, hasta donde el proveedor de Nube debe participar en la solución de estos problemas, si hay que escalarlos , quien los escala?. En fin si vamos a trabajar en la nube para obtener los beneficios entonces hay que repensar las cosas que veníamos haciendo.

LA PLANEACIÓN.

La planeación no por ser la ultima en este artículo es la menos importante. Es el proceso clave en el proyecto para movernos a la nube, ya que a través de esta etapa veremos lo que hay que re-prensar a nivel de procesos de T.I, procesos empresariales y, finalmente, identificar las necesidades de capacitación de los actores que directa o indirectamente vayan a participar dentro del proyecto con el fin tengan las habilidades correctas y puedan soportar los nuevos procesos. No olvidemos que "Fallar en Planificar es Planificar el Fallo"

Yo estoy completamente convencido que en un futuro no muy lejano debemos migrar hacia la nube, pero también estoy convencido que es un proceso que no a todos les funciona, es un proceso que no debe tomarse tan ligeramente solo por que la tendencia lo impone.