Algunas ‘mejores prácticas’ de TI para el fracaso –y algunas ‘mejores prácticas’ para evitarlo

Así es, una mejor práctica no es una receta de cocina. La preparación que hagamos de un ‘platillo’ y su resultado depende de muchos factores referidos a las herramientas, nosotros mismos como çocineros’, de los ‘comensales’ y su entorno.

Una real mejor práctica es considerar la preparación del ‘platillo’ para garantizar su resultado. Así, intervienen el ecosistema tecnológico en operación –moderno, vigente, legacy, integrado, interconectado- plataforma tecnológica e infraestructura de soporte, la cantidad necesaria de especialistas con el perfil apropiado, la experiencia, competencias (conocimientos, aptitudes, actitudes), orientación técnica o de gestión, requisitos del negocio, apetito de riesgo, intereses personales, los recursos para la producción del servicio (en adición al ecosistema tecnológico y el personal de apoyo, se necesita información, aplicaciones, recursos financieros) y capacidades para asegurar el rendimiento esperado (modelo de gestión, organización implementada, procesos establecidos, conocimiento gestionado), ambos activos de servicio necesarios para entregar el servicio con el valor esperado (con la utilidad y la garantía de rendimiento esperada), aparte claro del presupuesto, coyuntura socio-económica, entorno regulatorio y legal, mercado (cultura, exigencias, demografía, restricciones, gobierno, importación/exportación).

Estamos propensos a decir sí o no a todo y esto varia como buena práctica de acuerdo a la cultura y clima organizacional, buscando no quedar mal –aunque esto es lo que ocurre al no cumplir si accedemos o no entregar si era posible y alguien después nos lo hizo ver.

Una real buena práctica es explicar qué debe hacer para satisfacer las solicitudes, luego de realizar el análisis previo correspondiente. Lo que sigue será una conversación más que una excusa.

Tampoco es una buena práctica blandir que se cumple con el acuerdo de nivel de servicio (SLA) aceptado por el cliente, o con el nivel de servicio organizacional (OLA) requerido y comprometido por las áreas internas de la empresa, cuando es evidente la existencia de reclamaciones al respecto, y tratamos de minimizar el impacto haciendo bromas a costa de clientes, usuarios –o peor, de nuestro soporte- ‘inexperto’. Puede haber un contrato en ambos casos, pero no es bueno mantener las relaciones a distancia.

Una real buena práctica es identificar y enfrentar cambios –incluso sustanciales, investiguemos con transparencia. Recuerde que las relaciones requieren confianza, que la confianza no sucede a menos que reconozca a los colegas y clientes como personas reales que, si les gusta, trabajarán con usted para arreglar lo que falla y que el propósito de los contratos no es definir las relaciones -es definir lo que sucede cuando no hay confianza y algo va seriamente mal.

Tomamos como buena práctica poner nombre a nuestros proyectos, desde hace poco incluso, no siempre ha sido así. Pero esta buena práctica de la dirección de proyectos la utilizamos para nombrar el proyecto como una implementación de software (y nos preocupamos de que el producto software funcione) y no como los resultados esperados por el negocio (no establecemos los requisitos y criterios de validación necesarios para el entregable). El trabajo de TI se realiza cuando el software satisface los requisitos y cumple con las especificaciones –se ha hecho el aseguramiento y control de calidad apropiados al producto software, su verificación. Entonces sabemos quién es culpable de no alcanzar los resultados esperados por el negocio ¿verdad?

Una real buena práctica implica identificar al real sponsor del proyecto. Me refiero no al que ha sido nombrado (otra ‘buena práctica’), sino al que le interesa el éxito del proyecto porque su reputación está en juego y actúa en beneficio del negocio, y no asume el encargo sólo por intereses personales. Otra es designar correctamente a alguien realmente encargado de realizar las validaciones oportunas, correctas y apropiadas.

Insistir en un retorno de inversión de la plataforma actual al instaurar la buena práctica del gobierno de TI es también una perjudicial para los proyectos donde la tecnología puede ayudar a los departamentos de negocios a ofrecer mejores resultados más rápido, o para aquellos proyectos que buscan ayudar a impulsar la satisfacción del cliente.

No podemos discutir que estos proyectos son críticos, por lo que una real buena práctica es que se necesita establecer correctamente los casos de negocio oportunos, necesarios y apropiados, y la organización debe implementar los cambios que sean identificados con prontitud.

El aumento de la eficacia de la misión y la eficiencia operativa son beneficios clave que se pueden lograr con el cloud computing. Recordemos la definición del NIST. Pero aplicar una estrategia al respecto es otra cosa, considerando por supuesto la seguridad en la nube. Tomamos como buena práctica la mera adopción de una solución comercial enfocada en IaaS, PaaS o SaaS. Sí hay orientaciones al respecto, pero dependerá de cada organización su definición y el éxito de su implementación ya que se deberá mantener las evaluaciones tecnológicas y las inversiones alineadas con las estrategias empresariales. Es una buena práctica reutilizar el recurso humano (exigirle más, por decirlo amablemente), pero debemos considerar que, probablemente, se requiera una reorganización de la organización de TI para ofrecer mayor agilidad empresarial y soporte a iniciativas empresariales clave.

Es una real buena práctica recordar que el ser humano es adaptable pero no es una máquina multitarea y tiene dignidad. Entonces conviene planificar –una buena práctica que muchas veces olvidamos por las presiones del mercado. Una buena planificación es muy importante porque en ella establecemos roles, responsabilidades, alcance del modelo de despliegue y servicios a emplear o entregar, controles, aspectos de diseño y de operación (que seguramente será necesario afinar), cumplimiento regulatorio y legal, integración de tecnología legacy con la nueva, cargas de trabajo, procesos establecidos, exposición al riesgo o apetito de riesgo, sponsor (real), ámbito de influencia, gobernabilidad, plazos, presupuestos, valor real para el negocio considerando las inversiones con base en su estrategia de negocio digital, entre otros muchos factores a considerar.  Otra real buena práctica es que todos los proyectos que se lancen deberían estar totalmente equipados, con “personal completo”, lo que significa que el proyecto nunca esperará a que un miembro del equipo esté disponible para trabajar en él.

Una buena práctica es emplear métodos ágiles, pero el pretender combinarla con la premisa de abaratar costos ya no lo es. La combinación es factible pero complicada en su control y gestión, y hasta contraproducente en cuanto a resultados esperados. Esto sólo si hablamos de contar con recursos y capacidades internas al país (on-shore); sin hablar de los recursos y capacidades que podrían verse interesantes fuera del país (off-shore).

Una real buena práctica es realizar una apropiada planificación tras reconocer que están implicados diferentes aspectos, no sólo el costo del recurso humano con el perfil adecuado, sino los costos de la tecnología a emplear y los mecanismos de seguridad necesarios, así como aspectos de locación, demográficos, culturares, idiomáticos, entre muchos otros.

¿Quién desea una TI Bimodal?

¿Quién desea una TI Bimodal?

Según Gartner, bimodal es la práctica de la gestión de dos estilos distintos pero coherentes de trabajo: uno centrado en la previsibilidad; la otra en la exploración.

Revisemos:

  • El Modo 1 (más gobierno, menos cambio) está optimizado para las áreas que son más predecibles y son bien entendidas. Lidiamos aquí con, pero no limitados a, estabilidad, robustez, estándares, planificación cuidadosa, cumplimiento, gobierno, riesgos, eficiencia, seguridad, precisión, disponibilidad, presupuestos, niveles de servicio y requisitos.
  • El Modo 2 (menos gobierno, más cambio) es exploratorio [pero requiere un enfoque riguroso y disciplinado -para que las cosas no se escapen de las manos], experimentando para resolver nuevos problemas, agilidad centrada en el tiempo de lanzamiento al mercado [velocidad], la rápida evolución de la aplicación y, en particular, la estrecha alineación con las unidades de negocio.

En la siguiente figura Gartner gráfica lo anterior:

Estas iniciativas a menudo comienzan con una hipótesis que se prueba y se adapta durante un proceso que implica iteraciones cortas, adoptando potencialmente un enfoque de producto viable mínimo (MVP) -experimentación.

Tengamos presente que un equipo de TI exploratorio no es fácil porque tienes que desafiar el pensamiento convencional [de las personas, claro], aceptar los riesgos [la empresa] y sentirte cómodo con un ritmo de cambio [motivación de todos] que es muy diferente de la forma actual en que opera TI.

Ninguna iniciativa es igual a otra, dadas las particularidades de cada negocio, mercado, o empresa. Cada empresa debe conocer su ecosistema, para adaptarse conforme convenga, e innovar rápidamente para responder a las amenazas y oportunidades.

Sabemos que, en el contexto empresarial, el estilo de trabajo, el modelo de decisión y la gobernanza, son los que hacen la diferencia; por tanto, cada empresa debe evaluar -a través de prueba y error- cómo enfrenta este paradigma, porque seguramente requerirá equipos multidisciplinarios [manpower], consultorías, nuevos contratos de soporte, nuevas negociaciones, nuevas herramientas, nuevos procesos, nuevas competencias, nuevas habilidades, nuevos conocimientos, nuevos recursos, y nuevas capacidades. No dejemos de lado el costo total de propiedad y los niveles de servicio acordados.

Seguramente deberemos considerar incluir cosas como aplicaciones móviles y su desarrollo, experiencia para el lado del cliente, IoT [Internet de las cosas] para obtener cierta experiencia en la captura de grandes flujos de datos y analizarlos desde diferentes dispositivos, ya sean estos dispositivos de consumo, dispositivos industriales, lo que se tenga a mano. Podría acabar ocurriendo que los ingenieros recién entrenados quieren usar nuevas técnicas en sistemas antiguos, y crear silenciosamente work-arounds en lo que se ha conocido como “shadow IT“. Trataríamos entonces de incorporar y estandarizar esta shadow IT y permitir a los innovadores innovar, pero dentro de la estructura corporativa. Esto implicaría una reingeniería de la gestión tecnológica y del papel de la empresa en su implementación.

Pero, tengamos presente que no por utilizar métodos ágiles o DevOps ya somos bimodales. La organización también está involucrada, no solo es un asunto de pura tecnología. Tampoco significa dedicarse a producir código porque se arriesga una mayor complejidad arquitectónica y de aplicación, lo que reduce la agilidad de la empresa. Recordemos que la cadena se rompe por el eslabón más débil, ¿o será que avanzaremos siempre al paso del más lento? [el impacto en los clientes, específicamente, es parte del segundo efecto secundario].

Ambos modos son esenciales, según Gartner, [tienen una relación simbiótica] para crear un valor sustancial, e impulsar un cambio organizativo importante, ninguno es estático y, probablemente, para el futuro tampoco sean suficientes. Combinar [y balancear] una evolución más predecible de productos y tecnologías (Modo 1) con lo nuevo e innovador (Modo 2) es la esencia de una capacidad bimodal empresarial. Ambos modos juegan un papel esencial en la transformación digital.

Sin embargo, el Modo 1 podría erróneamente considerarse negativo [¿desmotivación por creer que debe mantenerse con lo legacy (islamiento), con el día a día, aunque exista la nube?]. Y no vemos que se debería centrar en la explotación de lo que se conoce, pero renovando a la vez el entorno heredado a un estado que es apto para un mundo digital –renovar el core es la clave. De igual modo, el Modo 2 podría considerarse erróneamente positivo, (siempre iterando / ¿arriesgando, sobre simplificando, sin normas, con prácticas no lineales?), y siempre debería siempre estar ¿planeando para el futuro? [¿flexibilidad?, ¿motivación por mantenerse en lo nuevo?]. Capacidad de respuesta frente a estabilidad.

¿Y si cambiamos el ejemplo de los corredores a las velocidades de una bicicleta de carrera? ¿o de blanco y negro al espectro de colores? ¿cuán segregada/dividida/segmentada podrían estar TI? Esto sugiere que este modelo bimodal podría ser una sobre simplificación de lo realmente requerido. Por ejemplo, una mejor alternativa, según John C. McCarthy, analista de Forrester, es que las organizaciones trabajen más para entender sus desafíos y hacer “los cambios necesarios para conducir la simplicidad”. El enfoque en los clientes, más que la velocidad o una disciplina en particular, es el diferenciador crítico en las empresas que están teniendo éxito.

También debemos tener cuidado y considerar que los modos podrían competir inevitablemente por los fondos, recursos, habilidades y la atención de la dirección, sin dejar de lado estándares, disciplina, reducir complejidad, gestionar riesgos, en todo momento. Ambos conceptos pueden funcionar mejor cuando son compartidos por los elementos front-end y back-end del ecosistema de TI. Iterar es bueno, pero con la verificación y la metodología de las TI tradicionales de back-end.

Internet de las cosas -IoT

Según Gartner, el “Internet de las cosas (IoT) es la red de objetos físicos que contienen tecnología incorporada para comunicarse y detectar o interactuar con sus estados internos o con el entorno externo”[1]; y añade que “el valor real del Internet de las cosas va más allá de los dispositivos interconectados”[2][3].

La interacción crea más datos (más complejidad en su tratamiento, más aplicaciones, mejores y más seguras que los traten, mayor necesidad de almacenamiento y procesamiento); la comunicación acarrea más riesgos que deben ser apropiadamente gobernados, una necesidad de mayor y mejor gestión de servicios (decisiones de toda índole más difíciles, para usuarios y operadores); las condiciones actuales y posibilidades futuras requieren recursos y capacidades diferenciados para asegurar que se mantiene el valor de los servicios (que promulga ITIL®) que entregamos –la sostenibilidad operativa.

Todos estamos involucrados y somos responsables del buen o mal uso que hagamos del IoT, en todo nivel. Además, debemos considerar que hay muchas cosas que considerar[4]: capacitación, público objetivo, requisitos de construcción, servicios incorporados, dispositivos (tipos, compromiso de seguridad, manipulación no autorizada[5], otros), disponibilidad, aplicaciones, redes, conectividad, plataforma tecnológica, ecosistema, riesgos directos e indirectos, actualizaciones de firmware o de software, aplicaciones que incorporen la seguridad desde el diseño, la arquitectura de las aplicaciones a este respecto, cifrado de datos, protección de datos personales, categorización de datos, datos sensibles en general, control de acceso, normativas, regulaciones, estándares, metadatos de los dispositivos, sistemas de monitorización y de protección contra intrusiones y ataques, tanto a nivel individual como colectivo[6], monitoreo continuo, localización de los datos porque lo que es delito informático en un país puede no serlo en otro, resiliencia[7], confidencialidad, integridad y disponibilidad, entre muchas otras posibilidades.

IoT no es una cosa; es la integración de varias cosas en una solución de negocio, es el corazón del negocio digital –bueno, cuando ya no sea una buzzword y realmente se de una transformación digital y contemos con tecnología concreta utilizable hasta en nuestros hogares[8] y por todos (refrigeradoras que podrán avisar a sus dueños cuando no haya alimento en ellos[9] es la promesa ¿recuerdan?). Sería bueno saber cuántos y cuáles dispositivos están accediendo a nuestra red local, y algo ‘raro’ como deshabilitar el bluetooth y las funciones que los dispositivos no usan todo el tiempo[10]. No queremos que “alguien” nos haga “gastar” más electricidad de lo habitual. Ya conocemos las deficiencias de seguridad existentes, que no nos pesquen desprevenidos, por ellas al menos[11].

[1]       Fuente: http://www.gartner.com/it-glossary/internet-of-things/; disponible en marzo/2017

[2]       Fuente: http://www.gartner.com/technology/research/internet-of-things/?s=1; disponible en marzo/2017

[3]       Fuente: http://view.ceros.com/gartner/iot/p/1; disponible en marzo/2017

[4]       Fuente: https://ricveal.com/blog/10-retos-seguridad-iot/; disponible en marzo/2017

[5]       Fuente: http://aunclicdelastic.blogthinkbig.com/el-reto-de-la-seguridad-en-iot/; disponible en marzo/2017

[6]       Fuente: http://www.csuc.cat/es/internet-of-things-un-reto-para-la-seguridad; disponible en marzo/2017

[7]       Fuente: http://www.ibm.com/developerworks/ssa/library/iot-trs-secure-iot-solutions1/index.html; disponible en marzo/2017

[8]       Fuente: http://techcetera.co/el-reto-para-la-seguridad-para-el-internet-de-las-cosas/; disponible en marzo/2017

[9]       Fuente: http://www.nacion.com/tecnologia/informatica/Seguridad-principal-reto-Internet-Cosas_0_1571442852.html; disponible en marzo/2017

[10]     Fuente: http://techcetera.co/tiene-el-internet-de-las-cosas-iot-algun-riesgo-para-su-hogar/; disponible en marzo/2017

[11]     Fuente: http://www.symantec.com/content/en/us/enterprise/media/security_response/whitepapers/insecurity-in-the-internet-of-things.pdf; disponible en marzo/2017

Más sobre el marco de la computación en nube -cloudcomputing -Parte 2

La computación en nube es un acontecimiento disruptivo en TI[1]no es novedad, así como la movilidad, la seguridad, Big Data y las redes sociales (mayor cobertura con los smartphones y sus cada vez mayores funcionalidades) son factores disruptivos para los actuales modelos de negocio.

Como suele ser el caso, lo que debe hacerse en primer lugar como factor competitivo diferenciador [mayor conocimiento, mejor organización del conocimiento, mejores decisiones, mejor gestión de riesgos, entre otros beneficios], es establecer un fuerte enfoque de liderazgo en el cultivo de una cultura centrada en los datos (articulados claro con los objetivos del negocio) [implica tecnología, herramientas, experiencia, talento, cultura organizacional y, claro, liderazgo –nada nuevo ¿verdad?] pero esto casi siempre sucede en último lugar[2].

Además, [trabajar con, para y en] la nube requiere un conjunto único de habilidades del personal responsable de TI[3] -tampoco es novedad, si está esto bien enfocado.

¿Un ejemplo de enfoque? Como vi en una convocatoria CAS hace unos días, solicitaban un abogado especializado en planes de contingencia, con maestría en gestión pública, y experiencia en el cargo de más de cinco años en empresas extranjeras –por S/.4,500 Nuevos Soles mensuales. Dieron en el clavo los que señalaron que esta convocatoria quedó desierta –y no creo equivocarme que fue por el monto a pagar (nadie se presentó) más que por cumplimiento del perfil. No sería de extrañar que contraten un extranjero que “dice” cumple con los requisitos y pagándole más de lo presupuestado, utilizando alguna argucia legal porque: no se encuentra el profesional “calificado” en Perú [uno al que [podamos baratear exprimiendo su necesidad para] pagarle lo “presupuestado” por realizar las “funciones del cargo” [lo que deberían hacer varios profesionales y no uno] que [no] han pasado apropiadamente por los filtros correspondientes para efectuar la definición funcional correspondiente] –y después nos quejamos de los resultados. ¿O será que se requiere en realidad un servicio de consultoría y no debe entonces canalizarse como CAS? ¿Aspectos presupuestales o Pepe el vivo?

O el caso –que seguramente todos conocen y hasta vivido (yo sí pero fue descubierto a tiempo –de por medio, monitorización y trazabilidad ¿mencioné auditoría?, análisis del entorno económico-político [hacia dónde se dirigen las cosas], conocimiento del ecosistema, ¿ya planteé riesgos?)- de un administrador de sistemas “motivado” para “impactar negativamente” en la organización[4].

Y en el contexto de nube privada, seguramente [espero] los CIO no estarán pensando en [sugiero que no] reducir personal, por lo menos no bajo la ‘perspectiva’ de “verse” más [hum, digamos] eficientes [paraguas usualmente mal utilizado]. Antes seguramente han pensado en cómo proteger [y asegurar claro] la propiedad intelectual empresarial del servicio que se entrega ¿verdad que primero ya implementaron un buen sistema de gestión del conocimiento que funciona en toda la organización [me refiero a que es operado, actualizado, utilizado, optimizado], que está interiorizado y está sujeto a mejora continua con base en procedimientos documentados?

Flexibilidad, agilidad y ahorros económicos son los principales motivos –en adición a “sentirse en” control de la seguridad o justificar la “soberanía” de la información, independiente de su localización geográfica, lo que limita la adopción de este paradigma. Estos son viejos desafíos para las empresas y “bussiness as usual [el día a día]” para los equipos de TI [el proveedor interno]. Viejas historias.

No olvidamos el planeamiento previo, profundo y concienzudo que debemos hacer –para evitar errores [¡hey!, ¿no somos humanos?]. Sí, lo reconocemos [y no hay forma de olvidarlo] y algunos dirán que es mejor pensar conforme avanzamos [haciendo… bueno… depende de -o teniendo que aceptar- lo que resulte…]. Al respecto nuestras experiencias son variadas –por ponerlo amable. El diseño, implementación, gestión y mantenimiento de una nube privada es algo complejo –e intimidante para algunos. Sí, sí, cuento con algunas certificaciones al respecto [por lo que puedo hablar del tema] pero igual me intimido por supuesto, por las expectativas puestas en los proyectos –sobre todo si no contamos [o resulta “difícil” contar] con los recursos suficientes y apropiados, tanto humanos como materiales, pasando por plazos, factores externos, apoyo interno [la organización en su conjunto] y externo [proveedores, otras organizaciones], difusión y comunicación apropiada del proyecto [a TODOS los INTERESADOS], entre otros pero no únicos factores a considerar.

Sí, están las nuevas operaciones –propias del nuevo entorno de servicio entregado [suena bien y estamos ansiosos por trabajar en lo nuevo ¿verdad?]- y las legacy –propias del día a día [claro, las ahora aburridas (pero que no descuidamos ¿verdad? aun cuando somos humanos ¿cierto?) cuando tenemos a la vista algo nuevo], y tan habituales como la función de mesa de ayuda. Hay [hoy] normas y estándares internacionales que deberíamos seguir –y, claro, cada vez estamos más obligados [considerando lo apropiado caso por caso –es decir, con el sustento claro y completo por supuesto]. Cumplamos pero, con y por convicción, no sólo para la foto [¿el Mercado?].

Hace varias semanas estuve conversando con un cliente [una entidad pública] y su requerimiento era más tecnología, nueva tecnología, mejor tecnología. ¿Por qué y para qué? “Para operar mejor” fue prácticamente la respuesta [una horrible y muy lamentable similitud con el cuento de Perrault que escuchamos de niños]. No en balde los proveedores siempre preguntan primero si se cuenta con presupuesto y a cuánto asciende. A pesar de la redundancia y contingencia desplegada de la que hacía gala este cliente (centros de datos en activo-activo, y otras sutilezas), ocurrió un percance y ninguna redundancia o contingencia implementada lo salvó de ver sus servicios desplegados a nivel nacional paralizados –varias horas, en horario laboral. Pasado esto, ante las mismas preguntas de antes, la respuesta seguía siendo la misma.

¿Ya hablé de sostenibilidad [continuidad de operaciones sin menoscabo de la capacidad de desarrollo futuro] y sustentabilidad [las razones por las cuales invertir en la sostenibilidad o en la plataforma tecnológica para el caso]?[5] No olviden a Murphy. ¿Habrán por lo menos considerado la tercerización o externalización [claro, para aprovechar el know-how, alinear capacidades, suplir carencias, facilitar el acceso a especializaciones, economía de escala, acceder a más servicios –o mejor provistos, ampliar la oferta de servicios, optimizar costos, reducir el CAPEX [las inversiones] y optimizar el OPEX [el recurrente], mejorar la competitividad, adoptar el modelo de servicio, proporcionar continuidad al negocio, obtener resultados, entre otros motivos], o el formar un ecosistema bien balanceado con los proveedores? ¿[Aún] no? Pero seguramente ya lo están considerando ¿verdad?

Mucho que pensar ¿verdad? Y eso que falta considerar cumplimiento normativo y legal –ups, olvidé las relacionadas con certificaciones alcanzadas, cargas de trabajo a elegir entre ser procesadas localmente [nube privada] o en la nube [pública], ¿alguien dijo aplicaciones móviles?, el lidiar con la uniformidad de las plataformas en nube, o la complejidad de trabajar con nubes híbridas [qué va en dónde, cómo, cuánto y hasta cuándo], entre otros muchos factores. La mezcla correcta, por supuesto, puede variar de un cliente a otro en función de las necesidades específicas, tales como la disponibilidad, costos, el rendimiento de cada servicio en la cartera de la organización.

Gartner definió en 2012 una plataforma de gestión de nube como las capas superiores de la solución en nube e indica que se debe considerar lo siguiente:

  • Una arquitectura empresarial deservicio en nubetiene cinco nivelesde funcionalidad: gestión de acceso (auto servicio, subscripción, identidad y acceso, entre otros aspectos a considerar), gestión de servicios (proveedores, contratos, catálogo de servicio, modelo de servicio, configuración, provisión, nivel de servicio, disponibilidad, rendimiento, demanda, capacidad, finanzas, mediciones, facturación, entre otros aspectos a considerar), optimización de servicios (gobierno, orquestación, federación, entre otros aspectos a considerar), gestión de recursos (gobierno, estado, rendimiento, seguridad, entre otros aspectos a considerar), yla capasubyacente de recursos (APIs, recursos físicos y virtuales tanto internos como externos, entre otros aspectos a considerar).
  • Idealmente, las capas de servicios en nubedebenser lógicamenteindependientes entre sí, deben maximizar laflexibilidad de implementacióny debenpermitir que elpotencial de sustituciónde variosproveedores –recordemos que la arquitectura de nube no es monolítica.
  • Los servicios en nubepueden haber reducidolos requerimientosparauna capa degestión de servicios-por ejemplo,en pre-producción, donde generalmente se aplican menos procesosformalesde gestión de TI [pero debemos tener cuidado en no “aligerar” demasiado el control necesario].
  • Las empresas tienen la posibilidad de acabarcon muchosconjuntos derecursos de nube que probablemente tengan repartidos entre recursosinternos yexternos, y deberían evitar obstaculizar el desplazamiento eficiente de los recursos [diseñando y aplicando procedimientos apropiados, adecuados y optimizados].
  • Se debe evitar la dependencia de proveedores únicos, pero tener [MUCHO] cuidado de que seleccionar los componentes significa para la organización de TI que debe [asumir los riesgos de] convertirse en su propio integrador de sistemas. Seguramente ya tiene una estrategia de computación en nube a seguir ¿o no?
  • Se debe elegir una plataforma de gestión de nube que permita la gestión de los recursos y servicios híbridos, los que operan tanto a nivel interno como externo.

No olvidemos la tecnología –pero a la inteligencia artificial aún le falta para ser “humana” (para bien o mal) –en un par de siglos tal vez. La aplicación del concepto de “TI debe funcionar como un negocio” será obligatoria en este entorno, ya que las organizaciones de TI tendrán que aprender y perfeccionar áreas tales como el catálogo de productos [ok, ok, servicios], gestión de la capacidad, gestión del rendimiento, gestión de la configuración, gestión de la demanda [ITIL/ISO20000], aseguramiento de la continuidad [ISO27000], la gestión financiera, optimización y gobierno del servicio [COBIT/Kaplan y Norton] y, en general, la orientación al servicio [inherentemente calidad de servicio (conociendo al cliente y su entorno), innovación, ISO9000]. Esto requerirá nuevas habilidades y transformación [inteligencia emocional] porque los diferentes servicios probablemente requerirán diferentes modelos de gestión.

El tema es que hoy por hoy todos los acontecimientos disruptivos han impactado la forma en que se compran y consumen los bienes y servicios, la forma en que las empresas se conectan con sus clientes, la forma en que los gobiernos interactúan con sus ciudadanos [¿podremos finalmente utilizar eficientemente la Plataforma de interoperabilidad del estado -PIDE?], e incluso la forma en que colaboran a diario [la agenda digital peruana[6] [7]]. En consecuencia, las empresas y los gobiernos deben centrarse menos en commodities [hardware y software], y más en la forma en que TI ayuda a resolver problemas de negocios –un poco más de inteligencia en las políticas de empleo de los recursos –incluso a nivel gobierno con el Sistema Nacional de Inversión Pública (SNIP) tenemos ya importantes inclusiones de recomendaciones y mejores prácticas como la gestión de proyectos en el marco del PMI.

[1]      Fuente: http://docs.media.bitpipe.com/io_11x/io_111063/item_741189/HP_Gartner%20Newsletter_Cloud.pdf, febrero/2016

[2]      Fuente: http://resources.idgenterprise.com/original/AST-0143462_EIU_Teradata_The_Virtuous_Circle_of_Data_briefing_paper_1_.PDF, febrero/2016

[3]      Fuente: http://searchcloudcomputing.techtarget.com/answer/Should-I-build-a-dedicated-private-cloud-staff?utm_medium=EM&asrc=EM_NLN_51771055&utm_campaign=20151229_Google%20cloud%20grows%20up%20in%202015,%20but%20work%20remains_kcasey&utm_source=NLN&track=NL-1814&ad=904943&src=904943, diciembre/2015

[4]      Fuente: http://community.spiceworks.com/topic/334270-how-to-fire-a-sys-admin-when-it-pros-go-rogue?utm_campaign=digest&utm_medium=email&utm_source=digest&utme=topic+featured, febrero/2016

[5]      Cáceres Meza, Jack Daniel. Propuesta para la implementación de normas de calidad que apoyen la gestión de clientes en una empresa proveedora de Internet. Lima, 2013. viii, 293 h. : il. ; 30 cm. Tesis (Mg. en Dirección Estratégica de las Telecomunicaciones) -Universidad Nacional Mayor de San Marcos. Facultad de Ingeniería Electrónica y Eléctrica. Escuela de Post-Grado, 2013

[6]      Fuente: http://www.codesi.gob.pe/, febrero/2016

[7]      Fuente: http://www.codesi.gob.pe/docs/AgendaDigital20_28julio_2011.pdf, febrero/2016

Más sobre el marco de la computación en nube -cloudcomputing -Parte 1

Sabemos que cuando las organizaciones se ven impulsadas a invertir se preguntan primero ¿cuáles son los objetivos de negocio que la organización espera alcanzar?, ¿cómo encajan estos objetivos dentro de la estrategia global de la organización?

Lo anterior funciona bien para tecnología convencional [claro, si queremos mantener la estadística de que días después de que algo entra en funcionamiento, ya está desactualizado, aparecen nuevas soluciones, nuevos parches, nuevas actualizaciones y así, como gerentes de TI, sólo nos mantenemos persiguiendo la curva de valor todo el tiempo –no muy buen porvenir ¿verdad?] pero, en cuanto a la nube, ¿sabemos si nuestra estrategia de negocio está lista para la nube?[1] –claro, y todas las demás preguntas.

¿Nos hemos preguntado si estamos pensando en la nube para ahorrar o para crecer, por un aspecto táctico o por una solución expresa y personalizada, está la infraestructura “completamente” o “en gran medida” optimizada para la estrategia de [nuestro] negocio? ¿Hemos definido los criterios para evaluar lo anterior? ¿No? bueno, deberíamos. Tengamos presente también que cuando existe una relación con uno o más proveedores externos, la transición a la nube [o de la nube] suele complicarse.

Sería bueno encontrar maneras en que las tecnologías de nube se ajusten a las necesidades y capacidades únicas de su organización [sincerando -alineando- la infraestructura de TI con los requerimientos del negocio y asegurando que la estrategia en nube evoluciona en consonancia]. Así, conviene adoptar la tecnología en nube con la misma seriedad que se aplica a los mecanismos de despliegue de TI más tradicionales. Atención, la madurez en la nube no significa abandonar las nubes privadas, sino el uso de la herramienta adecuada para la tarea y, en última instancia, el alineamiento de la estrategia en infraestructura y la gobernanza.

No olvidemos a los “nativos digitales” y su continua ansia por la nueva y menor tecnología que puedan comprar -¿alguien ha explotado todo lo que esta nueva tecnología puede hacer? ¿Recuerdan cuando La gente estaba acostumbrada a tener una mejor tecnología en el trabajo de la que tenía en casa [y estaban menos propensos a cuestionar el hecho]? Claro, BYOD –flexibilidad, agilidad, adaptabilidad, rendimiento, escalabilidad, rapidez[2], libertad… fomentando una cultura que hace uso seguro de la tecnología digital[3] [pero asegúrese de que la seguridad, la privacidad y el cumplimiento legal se abordan desde el principio –no olvide desarrollar las estructuras de gobierno exigidas por la nube, y adaptar o remodelar los procesos de gobierno para implicar más a los líderes]. La leyenda urbana dice que para ampliar el uso de la nube con responsabilidad y cosechar sus beneficios, las empresas deben ser capaces de utilizar la nube de forma segura.

Preparémonos para invertir más tiempo y esfuerzo en evaluar un número creciente de proveedores de nube (IaaS, PaaS, SaaS, XaaS para el caso) y soluciones puntuales –ojo con las soluciones “llave en mano” ya sean propietarias (Amazon y Microsoft entre otras) o de código abierto[4] (OpenStack). El entorno se complica cuando se involucra a otros grupos de interés internos como responsables de la conformidad (la aceptación de la implantación y la migración podría ser complicada por lo que debemos asegurar el cumplimiento legal y normativo), y líderes de negocio –seguramente habrán dudas en cuanto a la seguridad de la información. En última instancia, todos debemos prepararnos para la transición. Acuerde los detalles con sus proveedores actuales –no se olvide de exigir garantías, y aproveche toda su experiencia –hasta puede obtener orientación estratégica, busquemos socios que estén preparados para mantener una relación de colaboración y aprendizaje constantes (sería ideal compartir ideas sobre mejoras en la tecnología y la plataforma –y hasta tener la posibilidad de influir de forma innovadora en la del proveedor).

Apuesto que creían que olvido al integrador. No es así. Debemos elegir un integrador, alguien que se haga cargo de la integración de los servicio de nube, ya sea un empleado o un consultor técnico de confianza[5]. Debemos asegurar que se orqueste adecuadamente nuestra red de [los mejores] proveedores –¿o considera sabio poner todos los huevos en la misma canasta?, sin olvidar el intercambio de datos y las diferencias entre los procesos de los distintos centros de datos. Como somos entendidos en la materia nos habremos dado cuenta que para garantizar el éxito de la adopción de la nube debemos establecer un plan de ruta para esta integración‑migración y que debemos gestionar este plan [apropiadamente] como un proyecto.

Además, en la vida diaria cosas malas suceden, y nos ocurrirán cuando y donde más nos afecte -¿recuerdan a Murphy? Las necesidades del negocio cambian y más vendedores aparecen (con ofertas más atractivas) o los actuales vendedores salen del mercado (local, lo que nos deja sin soporte apropiado, o simplemente quiebran y quedamos desamparados), a veces las relaciones de nube no duran (porque no obtuvimos del proveedor los servicios –funcionalidad y soporte- como nos ofreció, porque ¿la nube no estuvo a la altura de nuestras necesidades? –y no obtuvimos las ganancias financieras esperadas[6] [en parte quizá porque en primer lugar no estuvimos “preparados” para la nube], porque hubo pérdida de datos –improbable dicen algunos pero sin embargo posible, porque el proveedor está atrasado tecnológicamente, porque se impactó negativamente en alguno de los factores CID de la seguridad de la información, porque ocurrieron apagones de la nube y permanecen en la oscuridad la gravedad y el estado exacto de los trabajos de restauración[7] -y este oscurantismo medioeval no nos gusta, entre otros aspectos a considerar).

En fin, a veces tenemos que hacer un cambio, y a veces hay eventos fuera de nuestro control que lo hacen por nosotros; así, no podemos o logramos permanecer en un servicio que es “el más adecuado”. Bien pensado, tampoco queremos vernos “atados” a un proveedor. Cuando eso sucede, tener un plan [¿sería mejor considerar una estrategia de salida?] puede significar la diferencia entre un ligero contratiempo del cual la organización puede recuperarse rápidamente, o enfrentar caos, tiempo de inactividad y una interrupción importante para el negocio.

En otras palabras, la estrategia de salida de nube [“migración en reversa” o “uncloud”[8] o “de-cloud” si nos ponemos al día con la terminología –ajá, ¿cuántos hemos reconocido estos términos?] es la elaboración de un plan de acción para asegurar que cualesquiera sean los servicios de nube que apoyan las actividades actuales del negocio, estos [servicios de nube] se pueden reemplazar [se puede realizar la transición] sin una interrupción grave[9]. El objetivo es realizar la transición en el plazo más breve posible[10] así que, entre otras cosas, no olvidemos considerar herramientas, personal calificado, niveles de servicio acordados con terceros [¿nuestros clientes?], otras responsabilidades adquiridas, mapeo de dependencias, mapeo de aplicaciones con la plataforma tecnológica, las propias aplicaciones, pruebas.

Así, tengamos presente qué servicios en nube reemplazamos e igualmente importante, con qué servicios en nube los reemplazamos –las alternativas tecnológicas pueden ser hasta iguales, pero centrémonos en lo que el negocio requiere (seguramente hemos realizado o deberemos realizar un BIA para un BCP[11] por ejemplo); así también es importante el cómo estamos utilizando los [actuales] servicios en nube (costos, rendimiento, jugadores clave, características del servicio, tratamiento de datos, niveles de servicio, soporte, aspectos legales y de cumplimiento, gobierno, no olvidemos las necesidades de privacidad y trazabilidad[12], entre otros aspectos a considerar –¿ya mencioné los factores CID de la seguridad de la información?).

Un análisis de impacto en el negocio (BIA) es un proceso sistemático mediante el cual una organización reúne y analiza información sobre sus funciones esenciales [y sus prioridades] y procesos (aplicaciones, datos, redes, sistemas de información, instalaciones, etc.). Esta información se utiliza para determinar cómo se vería afectada la organización (impacto potencial y costos en casos de desastre/acontecimiento/suceso) si estas funciones y procesos fueron interrumpidos por un desastre[13]/acontecimiento/suceso. En otras palabras, es fundamental analizar cuál es la tolerancia de su negocio a la no disponibilidad de sus funciones críticas[14]. ITIL®[15] nos dice que el BIA define los requisitos de recuperación de los servicios de TI. Estos requisitos incluyen tiempos de recuperación objetivos, puntos de recuperación objetivos y los objetivos mínimos de nivel de servicio para cada servicio de TI.

En la actualidad garantizar la operación no es una opción. Los clientes, proveedores y accionistas esperan respuesta sin importar lo que suceda en el exterior [sin importar las circunstancias que se presenten en el ecosistema donde se desarrolla la organización, sea ésta del tamaño que sea, pública, privada o entidad gubernamental]. La continuidad del negocio (BC) describe los procesos y procedimientos que una organización pone en marcha para garantizar que las funciones esenciales puedan continuar durante y después de un desastre/acontecimiento/suceso –esto no sólo involucra a TI y su Plan de recuperación ante desastres o DRP (¿alguno lo tiene? Como procedimiento documentado[16] quiero decir). La Planificación de la Continuidad del Negocio (BCP) trata de evitar la interrupción de los servicios de misión crítica (seguramente más de una vez caeremos) y restablecer el pleno funcionamiento de la forma más rápida y fácil que sea posible[17] (lo importante es levantarnos, cada vez). Usualmente los procesos críticos de negocio mantienen una íntima interdependencia con la tecnología; así, no consideremos que esto es un gasto sino más bien una inversión.

No esperamos –o deseamos- que nuestra relación con el o los proveedores de nube se vea interrumpida o falle. Pero prestemos atención al refrán: “cuando el río suena es porque piedras trae”. Otro refrán dice más o menos así: “esperamos lo mejor preparándonos para lo peor” –o que Dios nos coja confesados.

[1]      Fuente: http://whitepapers.siliconweek.es/wp-content/uploads/2015/05/CIOs-Mapping-the-cloud-maturity-curve-The-fundamental-five.pdf, mayo/2015

[2]      Fuente: http://whitepapers.siliconweek.es/wp-content/uploads/2015/02/CIOs-Cloud-Bound.pdf, febrero/2015

[3]      Fuente: http://whitepapers.siliconweek.es/wp-content/uploads/2015/05/CIOs-Mapping-the-Cloud-Maturity-Curve.pdf, mayo/2015

[4]      Fuente: http://www.channelbiz.es/2014/09/25/openstack-un-repaso-esta-alternativa-cloud-en-codigo-abierto/, setiembre/2014

[5]      Término acuñado, a mi mejor entender, por Garcerán Rojas de PQC.es

[6]      Fuente: http://searchcloudprovider.techtarget.com/tip/How-to-uncloud-Best-practices-for-exiting-the-public-cloud, noviembre/2015

[7]      Fuente: http://cioperu.pe/articulo/17264/como-utilizar-openstack/, noviembre/2014

[8]      Fuente: http://searchcloudprovider.techtarget.com/definition/uncloud-de-cloud, setiembre/2015

[9]      Fuente: http://searchcloudsecurity.techtarget.com/tip/Create-a-cloud-exit-strategy-to-prepare-for-the-unknown?utm_medium=EM&asrc=EM_NLN_49188871&utm_campaign=20151028_Dridex%20banking%20Trojan,%20botnets%20wreaking%20havoc%20again%20despite%20DOJ%20takedown_oeckerson&utm_source=NLN&track=NL-1820&ad=903816&src=903816, octubre/2015

[10]    Fuente: http://blogs.gartner.com/kyle-hilgendorf/2013/09/18/cloud-exit-strategies-you-do-need-them/, setiembre/2013

[11]    Fuente: http://searchdisasterrecovery.techtarget.com/essentialguide/Essential-guide-to-business-continuity-and-disaster-recovery-plans, 2015

[12]    Fuente: http://www.bbb.org/blog/2013/08/6-steps-for-de-clouding-yourself/, agosto/2013

[13]    Fuente: http://searchsecurity.techtarget.com/feature/Conducting-an-effective-business-impact-analysis, febrero/2003

[14]    Fuente: http://searchdatacenter.techtarget.com/es/opinion/BCP-y-DRP-El-arte-de-levantar-un-negocio-caido, noviembre/2013

[15]    Fuente: http://wiki.servicenow.com/index.php?title=File:ITIL_2011_Spanish_%28Latin_American%29_Glossary_v1.0.pdf#gsc.tab=0, junio/2012

[16]    Fuente: http://iso9001calidad.com/procedimientos-documentados-exigidos-por-la-norma-151.html, 2013

[17]    Fuente: http://searchdatacenter.techtarget.com/es/definicion/Continuidad-de-negocios-BC, setiembre/2013

Cumplimiento en el marco de la computación en nube -cloudcomputing

Cumplimiento ¿palabra de moda?

En términos generales, el cumplimiento es el proceso de adherirse a un conjunto de reglas que un organismo de la industria o agencia de gobierno piensa que usted necesita cumplir. El negocio tiene que cumplir con X, Y y Z requisitos o de lo contrario[1]… [bueno, ya conocemos los eventos apocalípticos que se desatarían]. El proceso es doloroso opinan algunos incluso sin haberlo intentado –por el status quo y otros considerandos; que hay poca área gris o espacio para la flexibilidad opinan otros. Habría que actualizarnos continuamente con el fin de establecer si aún prevalece lo malo anteriormente expuesto.

Cumplimiento es algo más que un aspecto adicional relacionado con la seguridad[2]; y es que no se puede externalizar la responsabilidad de la seguridad –una alta prioridad sobre todo por la inherente complejidad, siempre creciente[3] -no olvidemos el gobierno en sus diferentes formas y alcances para gestionar apropiadamente los riesgos. Asegurar el cumplimiento y proporcionar seguridad a los datos en la nube son cosas complicadas, no es fácil, pero se puede lograr[4].

De hecho, definir una estrategia de seguridad en la nube debería ser la mayor preocupación, tanto para el negocio como para TI, desde el mismo inicio de cualquier despliegue en la nube[5]; así es, una estrategia de seguridad NO puede esperar –a nadie y por nada- y debe mantenerse viva.

Con respecto a la seguridad, entre otras inquietudes todos tenemos las siguientes[6]:

  • ¿Qué informaciónse almacenaen un sistema? –lo sabe ¿verdad?
  • ¿Dóndese almacenala información? –el asunto en cuestión, y todas las demás interrogantes relacionadas.
  • ¿Quiénpuede acceder al sistema? –y ¿mantenemos vigente la lista como parte de un procedimiento documentado que involucra a todas las partes involucradas (proveedor, cliente, terceros)? –sin olvidar los niveles administrador/usuario, como mínimo.
  • ¿Cuál es el riesgo para los datos? -¿Están los controles en el lugar adecuado para mitigar el riesgo? ¿Cómo se lidia con los criterios de confidencialidad, integridad y disponibilidad (CID)? Recordemos que para asegurar los datos debemos empezar por su identificación, clasificación y tratamiento. No olvidemos la seguridad de nuestros datos cuando son transportados y almacenados, pensando que nuestros datos son menos seguros en la nube [¿utilizamos cifrado de datos?[7] ¿Y validamos que se mantenga su efectividad?[8]] –claro, también cuando son procesados; el tema es nuevamente la responsabilidad compartida. Probar periódicamente la funcionalidad de exportación de datos le ayuda a entender el proceso de exportación en la práctica (no sólo en teoría). Esto da claridad sobre algunos diversos aspectos operativos de esta manera: cuánto tiempo va a tomar, quién tiene que estar involucrado en el lado del proveedor de servicios, los costos adicionales que pueden ser requeridos, en qué formato llegan los datos en última instancia, entre otros aspectos[9] –seguridad de la información/cumplimiento/SLA, o deseamos depender de solo un proveedor de servicios en nube.
  • ¿A quépuedenacceder? –seguramente tenemos un procedimiento documentado para esto, además de las relaciones necesarias en el sistema y a qué partes de la plataforma (hipervisor, aplicación por ejemplo).
  • ¿Es elacceso adecuado? –es decir, ¿sabemos el porqué es adecuado? El acceso debe basarse en roles de trabajo, y debe proporcionarse una descripción clara del nivel de acceso necesario.
  • ¿Operaciones de seguridad? ¿Tenemos o existe disponibilidad para acceder a las trazas de seguridad, detección de anomalías, notificaciones de brechas de seguridad u otras notificaciones, APIs, procedimientos de respuesta a incidentes, derecho a realizar auditorías, otros? ¿Son las medidas de seguridad tradicionales aplicables en la nube? –de hecho hay un alto riesgo, y tampoco cometamos el error deconfiar demasiado enlas capas de seguridaddel proveedor deIaaS (o de ningún otro modelo) ¿Siguen siendo válidos “viejos” paradigmas como prevenir es mejor que curar, los seres humanos son el eslabón más débil, y el acceso debe limitarse a sólo a lo que un empleado necesita para hacer su trabajo[10]?
  • Obviamente no todas las aplicaciones son creadas iguales y la funcionalidad de la aplicación, el tipo de datos que se accede, la criticidad de negocios, los accesos/roles de los usuarios, la autenticación y así sucesivamente todos influyen en el perfil de seguridad de cualquier aplicación -¿ya mencioné que esto debe vigilarse en el tiempo?

Sabremos seguramente lo primero pero, ¿qué hay del resto de las incógnitas? -sobre todo cuando se trata de una nube pública y sobre todo por su naturaleza multi-cliente[11]. El reto es saber dónde están los datos [o dónde deberían estar] y cómo están protegidos -cuán privados permanecen [cuál es nuestro nivel de propiedad de los datos], porque pasar a la nube puede afectar la capacidad de una organización para cumplir con normas, regulaciones y estándares.

Si bien el proveedor podría técnicamente identificar dónde almacena sus [tus] datos, no está obligado a hacerlo. Bueno, parte del negocio es ese, el proveedor distribuye lo mejor que puede los recursos de la plataforma para entregar un servicio razonablemente “apropiado” para las cargas de trabajo que le serán exigidas. Aquí lo usual como clientes es preocuparnos de cuán persistentes son estos almacenamientos.

En buena cuenta, asegúrese de que su proveedor es capaz y está dispuesto a demostrar que utiliza separación de funciones para las funciones administrativas, y que tienen la capacidad de “probar” quién tuvo acceso a un sistema de información y cuándo tuvo este acceso. Tenga en cuenta que este último requisito requeriría desplegar una solución robusta y estado del arte para el registro relacionado con la seguridad. Es importante un cierto nivel de madurez[12] en el cumplimiento de estándares. Gran parte del cumplimiento se trata de garantizar los controles adecuados sobre quién tiene acceso a los bienes, qué nivel de acceso que tienen y cómo se mantienen esos niveles. La manera en que esas cosas suelen garantizarse es a través de la auditoría, en el que hay que decir lo que estamos haciendo y demostrar que lo estamos haciendo.

Mike Chapple de la Universidad de Notre Dame implica la posibilidad de un cambio en nuestro enfoque [de nuestros equipos de trabajo] en la seguridad y el cumplimiento. En los centros de datos convencionales [o legados] un equipo es el que lleva la responsabilidad final por el mantenimiento de un ambiente de TI seguro y conforme.

Este enfoque de extremo a extremo, simplemente no se aplica en un mundo de computación en nube donde las empresas suelen compartir las cargas de cumplimiento con uno o más proveedores de servicios que puedan estar proporcionando infraestructura, plataformas o servicios alojados. En este modelo de responsabilidad compartida, tanto los proveedores de servicios como sus clientes deben precisar lo que se requiere de cada lado, en términos de responsabilidades de cumplimiento.

Así, es crítico identificar quién es responsable de la ejecución de cada objetivo de control en cada etapa del modelo de nube. Entonces deberá trabajar con sus proveedores de servicios en forma regular para revisar y actualizar la división de responsabilidades. A medida que cambian las necesidades del negocio y las capacidades técnicas evolucionan, el peso del cumplimiento puede desplazarse en una dirección u otra. Mantenerse al tanto de estos desplazamientos de responsabilidades es un componente clave de la gestión del cumplimiento.

Muchas regulaciones de cumplimiento de TI contienen una redacción que especifica las ubicaciones geográficas donde entidades financieras o de salud, por ejemplo, pueden almacenar datos. Reglamentos de control de exportaciones de Estados Unidos prohíben el almacenamiento o la transmisión de algunos datos regulados fuera de los Estados Unidos. Del mismo modo, las regulaciones de privacidad de la Unión Europea prohíben la transferencia de información personal fuera de la UE sin la implementación de controles de privacidad adecuadas alrededor de esos datos; no hablemos de los canadienses.

Por esta razón, debemos considerar cuidadosamente los procesos de notificación de incidentes de seguridad antes de contratar los proveedores. Los contratos con los proveedores de servicios deben exigir que el proveedor nos notifique inmediatamente de los incidentes de seguridad conocidos o sospechosos que afectan a los datos en la nube. No olvidemos asegurar estas condiciones.

La adopción de servicios de cloud computing aumenta la complejidad de cuestiones relativas al cumplimiento y la importancia de documentar los controles. Cuanto más fácil nos sea demostrar claramente el cumplimiento de las leyes y reglamentos de TI, más tranquilas irán las cosas cuando los auditores nos visiten. No olvidemos que los contratos deben explicar los detalles del modelo de responsabilidad compartida negociado entre la organización y sus proveedores de servicios –y tampoco olvidemos los acuerdos de nivel de servicio.

También debemos conservar el derecho de auditar –periódicamente- el desempeño de los proveedores contra cualquier normativa de seguridad aplicable –un proveedor de la nube certificado [aunque parezca interesante y liberador que al utilizar sus servicios “heredemos” las certificaciones] no garantiza la protección [continua] así, siempre valide las demandas de cumplimiento que su proveedor le entregue –y asegúrese que se mantienen vigentes porque recordemos que la seguridad no es un acto único. Los vendedores son sin duda responsables de la gestión de sus servicios enfocados en el cumplimiento, pero este cumplimiento no se traduce automáticamente al cumplimiento completo del cliente[13]; alcanzar los estándares cumplimiento y regulatorios es predominantemente responsabilidad del cliente, no del proveedor de la nube[14].

Los proveedores de nube deben ofrecer transparencia de su infraestructura a los clientes. Por ejemplo, aunque Microsoft realiza sus propias pruebas de Azure[15], los usuarios finales tienen la responsabilidad de asegurarse de que sus sistemas cumplen los requisitos de seguridad de la empresa[16]. El cumplimiento de los estándares de seguridad del centro de datos son una cosa, pero fallas de servidores y aplicaciones son otra muy distinta.

Así, es necesario tomar medidas para garantizar que los proveedores de servicios implementan sus servicios en la nube de manera tal que conservan el cumplimiento de todas las regulaciones aplicables a nuestros requerimientos –recordemos, entre otros, aspectos de exportación, requerimientos de privacidad. Nunca debemos depender exclusivamente de nuestro [menos de uno] proveedor de la nube[17] ‑recordemos, la responsabilidad debe ser compartida, y el monitoreo continuo.

No olvidemos los contratos de confidencialidad y seguros contra daños ocasionados por terceros –recordemos que el diablo está en los detalles[18]; la documentación referida a las responsabilidades compartidas; responsabilidades por la seguridad de los datos, como tampoco las categorías de servicio en nube que son ofrecidas o con las que desee trabajar –los requerimientos de cumplimiento en cada caso; los dispositivos móviles[19] que podamos utilizar para el control (según el Barómetro 2013 Riesgo/Recompensa de ISACA, 50% de las empresas ya permiten explícitamente BYOD[20]); los hipervisores y contenedores (dockers como alternativa a los hipervisores[21], que tienen tanto de proceso como de gobierno y tecnología y que los expertos instan a las organizaciones sólo utilizar contenedores de aplicaciones con permisos fuertemente custodiados, y para controlar el sistema operativo subyacente[22]), virtualización; control de los proveedores en nube que contratamos para la empresa –o que nuestros usuarios utilizan [incluso sin nuestro conocimiento o autorización]; entre otros puntos a considerar para un efectivo matrimonio cumplimiento-seguridad.

A estas alturas ya se habrán dado cuenta porqué hemos hablado poco de tecnología. De hecho, la seguridad en la nube no es sólo una pregunta [retórica] de TI[23].

[1]      Fuente: http://searchcompliance.techtarget.com/tip/Cloud-compliance-legal-issues-take-center-stage-as-cloud-use-expands,febrero/2011

[2]      Fuente: https://www.youtube.com/watch?v=1SruE7Tr7iw, enero/2015

[3]      Fuente: http://searchcloudsecurity.techtarget.com/feature/The-ups-and-downs-of-cloud-compliance?utm_medium=EM&asrc=EM_NLN_48466586&utm_campaign=20151009_NEW%20IN%20INFORMATION%20SECURITY%20MAGAZINE:%20Regaining%20control%20of%20cloud%20compliance,%20CISO%27s%20role%20from%20IT%20security%20to%20policy%20wonk,%20Corporate%20investments%20in%20cybersecurity%20startups%20%20_oeckerson&utm_source=NLN&track=NL-1836&ad=903432&src=903432#, octubre/2015

[4]      Fuente: http://searchcloudsecurity.techtarget.com/feature/Securing-data-and-ensuring-compliance-in-cloud-based-services, octubre/2015

[5]      Fuente: http://searchcloudcomputing.techtarget.com/news/4500247879/Four-cloud-security-myths-debunked, junio/2015

[6]      Fuente: http://viewer.media.bitpipe.com/1103740304_372/1280167431_218/CA_sCompliance_SO-O31222-E-Guide_7-22.pdf, octubre/2015

[7]      Fuente: http://searchcompliance.techtarget.com/video/Cloud-compliance-data-protection-top-reasons-for-encryption, abril/2015

[8]      Fuente: http://searchcloudcomputing.techtarget.com/photostory/4500246165/Seven-cloud-security-risks-that-will-ruin-your-day/2/Overlooking-cloud-data-encryption, octubre/2015

[9]      Fuente: http://searchcloudsecurity.techtarget.com/tip/Three-practices-to-prevent-cloud-vendor-lock-in, junio/2013

[10]    Fuente: http://www.cio.com/article/2989206/security/when-it-comes-to-security-trust-but-verify.html?phint=newt%3Dcio_security&phint=idg_eid%3D0f3e0907b81179ebb4f3b209b6424bae#tk.CIONLE_nlt_infosec_2015-10-09, octubre/2015

[11]    Fuente: http://searchcloudcomputing.techtarget.com/photostory/4500246164/Seven-cloud-security-risks-that-will-ruin-your-day/1/The-risky-business-of-securing-data-in-the-cloud, octubre/2015

[12]    Fuente: http://www.bitpipe.com/data/demandEngage.action?resId=1329422213_586, 2012

[13]    Fuente: http://searchcloudsecurity.techtarget.com/tip/Who-does-what-Uncover-the-key-to-cloud-security-compliance, octubre/2015

[14]    Fuente: http://searchcloudprovider.techtarget.com/news/2240149306/Achieving-cloud-compliance-Customer-not-cloud-provider-responsible, abril/2012

[15]    Fuente: https://azure.microsoft.com/en-us/support/trust-center/compliance/, octubre/2015

[16]    Fuente: http://searchwindowsserver.techtarget.com/tip/What-admins-should-know-about-Microsoft-Azure-security, setiembre/2015

[17]    Fuente: http://searchcloudcomputing.techtarget.com/news/4500256467/Cloud-security-requires-shared-responsibility-model, octubre/2015

[18]    Fuente: http://searchcloudsecurity.techtarget.com/news/2240186102/Gartner-Negotiate-cloud-contracts-with-detailed-security-control, junio/2013

[19]    Fuente: http://searchcloudcomputing.techtarget.com/photostory/4500246167/Seven-cloud-security-risks-that-will-ruin-your-day/4/Skipping-the-BYOD-security-policy, octubre/2015

[20]    Fuente: http://searchcloudsecurity.techtarget.com/tip/Cloud-and-BYOD-A-combo-that-can-improve-enterprise-security, abril/2014

[21]    Fuente: http://searchcloudsecurity.techtarget.com/answer/How-can-AWS-EC2-Container-Service-improve-Docker-security, julio/2015

[22]    Fuente: http://searchcloudcomputing.techtarget.com/photostory/4500246169/Seven-cloud-security-risks-that-will-ruin-your-day/5/Rushing-your-Docker-container-security-strategy, octubre/2015

[23]    Fuente: http://docs.media.bitpipe.com/io_11x/io_111063/item_745697/HP_CloudSecurityGuide_Final1%20Approved.pdf, 2015

SLA en el marco de la computación en nube -cloudcomputing

La mayoría de las transiciones a una solución de cloud computing implican un cambio de una solución gestionada técnicamente (“yo lo construyo, yo lo mantengo”) a una solución administrada por contrato (“alguien más está haciendo esto por mí, ¿cómo puedo asegurarme de que están haciendo lo que se supone deben hacer? “).

Este cambio requiere una mayor capacidad de negociación del contrato de TI para establecer los términos de la relación (“¿Qué obtengo?”) Y habilidades de gestión de proveedores para mantener la relación (“¿Cómo puedo asegurarme de que lo obtenga?”)[1]. Esto implica identificar primero los requerimientos del negocio y establecer los indicadores clave de rendimiento esperados[2]. No olvidemos que hablamos de un servicio –y lo necesitamos para proveer servicios.

Por un lado, Kristin Knapp, editor del sitio de SearchCloudComputing, nos recuerda que los acuerdos de nivel de servicio (SLA) establecen confianza; los usuarios quieren seguridad de que su proveedor le garantiza un cierto nivel de servicio.

Tenemos que ser capaces de articular nuestras expectativas cuando se está negociando el acuerdo con el proveedor –y no es sólo mirarlo a los ojos cuando buscamos una respuesta, ni conviene acelerar su proceso. Un SLA no es una solución de una sola parte[3] [sabemos que en todo SLA existen dos partes]. Una de las partes -el proveedor de servicio en la nube, por ejemplo- no debe imponer decisiones acerca de cómo deben hacerse las cosas, sobre todo cuando la otra parte -el cliente de servicios de nube, por ejemplo- tiene diferentes expectativas sobre cómo debería formularse el SLA. Existe un impacto tecnológico y legal, especialmente cuando buscamos utilizar una nube pública[4].

Ninguno de nosotros desea que un proveedor simplemente reconozca el problema –luego que nosotros como usuarios asentamos la reclamación correspondiente primero. Debe haber un vínculo con la cura – como un tiempo de respuesta de una media hora para los problemas de servicio de mayor gravedad.

También es importante entender lo que el SLA cubre en términos de lo que recibirás y cómo va a recibirlo si el proveedor incumple el acuerdo. Así, igual de importante, deseamos la seguridad de que nuestro proveedor deberá pagar (o reembolsar) si no se cumplen las garantías acordadas[5] -pero no sólo con crédito, que los usuarios en general podríamos aplicar a nuestra factura de nube o para la compra de otro servicio en la nube, ya que rara vez se compensa la pérdida financiera o de negocio que puede ocurrir después de una interrupción (o degradación) en el servicio.

De hecho, no [siempre] se trata de dinero, se trata de la capacidad de ofrecer un servicio. No es de extrañar que los precios de los servicios en nube bajen con el tiempo y así, la elección de un proveedor se va a centrar todo sobre la prestación del servicio y el mayor tiempo de actividad que ofrezca.

Por otro lado, los clientes deben estar a la altura, por sanidad. Y una de las mejores maneras de hacerlo es construir aplicaciones en la nube que son resistentes, tolerante a fallos y diseñadas específicamente para la nube. Y realmente se necesita diseñar contra fallos por cuanto los proveedores cuentan con [se apoyan en] esto para proporcionar sus servicios “diferenciados”. No olvidemos que ya existe la ISO/IEC 27017 aplicada a la seguridad en nube, y que la CSA está tras este punto.

Un SLA de nube debe incluir términos más granulares alrededor de la respuesta del proveedor y el tiempo de recuperación. En concreto, los SLA de nube deben incluir términos que abarcan el “ciclo de gestión de fallos” completo de un servicio en la nube, sugirió Jason Andersen de Stratus Technologies. Esto incluye cinco fases clave de fallo de un servicio en la nube:

  1. Darse cuenta de que hay un hecho/problema ocurrido
  2. Localizar el hecho/problema
  3. Aislar el hecho/problema
  4. Recuperación del hecho/problema
  5. Recuperación completa del hecho/problema

Muchos términos del SLA sólo hablan de la disponibilidad en nube en términos de un servicio que está “operativo” o “caído” –lo que hace atemorizante y confusa la tarea de establecer un SLA, y no tienen en cuenta los distintos niveles de desempeño que siempre existen entre ambos. ¿Cuánta degradación es requerida para que un servicio se considere ‘caído’? ¿Cuál es el tiempo de resolución ofrecido (el tiempo que tarda un proveedor de nube para resolver completamente un problema con su servicio)? En la granularidad de los términos utilizados está el asunto –el diablo está en los detalles (definiciones y terminología entre otros).

Por lo anterior, Tom Nolle de CIMI Corporation[6] nos sugiere establecer un SLA en nube como un pequeño proyecto.

Uno de los desafíos de establecer un SLA en la nube es que la experiencia entregada por una aplicación en nube depende de varios aspectos o zonas de servicio por lo que la primera tarea es desarrollar un mapa de entidades que muestre quién provee qué porción del servicio en nube y cómo esta porción transita entre estas entidades.

Por ejemplo, las comunicaciones empleadas, si son accesos locales o remotos, los dispositivos empleados, las cargas de trabajo exigidas, los flujos de trabajo generados –que son en última instancia la base de los SLA.

Para una buena gestión del SLA y decisiones de su política, es necesario medir el comportamiento de cada uno de los proveedores de las diferentes zonas que componen el servicio en nube. Podemos comenzar con mecanismos para medir el tiempo de respuesta y pasar de eso a las condiciones de medición en los puntos de frontera de estas diferentes zonas. Un buen inicio es medir en el punto de conexión del usuario. Para la observación de la zona frontera alguna forma de supervisión de tráfico o protocolo es difícil de superar.

Sin la consideración y herramientas adecuadas, incluso un buen SLA probablemente fallará porque no se sabrá que está siendo violado ni por qué. Recopile datos en un repositorio de forma natural. Esta recopilación de datos le permite ejecutar consultas para analizar el rendimiento y las condiciones en el tiempo y establecer líneas de base para un comportamiento normal, así como los umbrales de lo que se considera que son violaciones al SLA. La analítica de red puede ser una base sólida para basar las decisiones alrededor de los acuerdos de nivel de servicio de computación en nube.

Para que el SLA de computación en nube y los servicios que ofrece tengan éxito es fundamental tomar un enfoque organizado para el SLA y las decisiones que surgen de su cumplimiento.

Así que la pregunta es, entonces, ¿Qué estás haciendo para monitorear el servicio [de tu proveedor en nube] y qué estás haciendo para asegurarte de que estás [el servicio que ofreces está] disponible?

Dan Sullivan[7] nos recuerda que si bien no existe precisamente una plantilla [proporciono un ejemplito[8]], hay puntos que no debemos olvidar –aunque nos parezcan obvios ahora pueden escapársenos en el momento:

  • Suacuerdo de nivel deservicio en la nube(SLA) debe especificar los nivelesmínimos derendimiento paracada servicio, codificadocon parámetros específicos –insisto, debemos ser específicos, y no aceptar generalidades[9].
  • Tenga en cuenta losrequisitospara documentaruna interrupcióny el tiempo quetiene para presentaruna reclamación.
  • Esvital entenderlos procedimientos de documentaciónde interrupciónantes de usar cualquierservicio en la nube.
  • Sobre la transferencia de datos utilizando procedimientos establecidos y protocolos seguros –y que nuestros datos permanezcan siendo nuestros [o definir a priori la manera de recuperarlos].
  • Seguridad de los datos en la nube –lo que es una responsabilidad compartida: proveedor-usuario[10]; todos esperan que alguien [usted] sea responsable.
  • Gobierno de la nube -de probar procesos internos a comprobar el cumplimiento de su proveedor con las regulaciones.
  • Contratos firmados –locales e internacionales (buen viaje).
  • Tarifas y costos ocultos.
  • Dependencias con terceros.
  • Retención de datos.
  • Servicios de datos –controles de seguridad por ejemplo.
  • Versiones, versiones, versiones –de todo y para todo.
  • Licencias, licencias, licencias –de todo y para todo.
  • Estándares empleados –porque heredamos las certificaciones.
  • No olviden lo básico[11]:
    • Codifica losparámetros específicosy los nivelesmínimos requeridospara cada elementodel servicio [y busquemos utilizar las mejores prácticas que encontremos para que no olvidemos ninguno, ITIL® por ejemplo], así como los recursospor incumplimiento deesos requisitos.
    • Sobre la transferencia de datos utilizando procedimientos establecidos y protocolos seguros, afirmar la propiedad de nuestra institución de sus datos almacenados en el sistema del proveedor de servicios [y que nuestros datos permanezcan siendo nuestros], y especifica sus derechos para recuperarla [definiendo a priori la manera de recuperarlos].
    • Detalles dela infraestructura del sistemay las normasde seguridadque deben mantenersepor elproveedor de servicios, junto con sus derechospara auditarsu cumplimiento o al menos teneracceso a susinformes de auditoríaescritos porun tercero de confianza –de verdad, no es broma.
    • Especificasus derechos ycosto paraseguirydejar de utilizar el
  • Ni tampoco olvidar que debe existir un balance entre seguridad y riesgos[12] [redundancia, disponibilidad, continuidad, resiliencia, y otros términos relacionados], comprender la noción de niveles “aceptables” de riesgo[13], y los riesgos de firmar un contrato estándar[14] porque importa:
    • Tiempo de actividad / inactividad.
    • Periodo de tiempo de inactividad (inactividad recurrente en un periodo pre-establecido).
    • Rendimiento y tiempo de respuesta –niveles máximos de latencia aceptados, QoS, entre otros aspectos.
    • Tiempo de inactividad programado.
    • Tiempo de corrección de errores.
    • Infraestructura /

Para garantizar un modelo de responsabilidad compartida en nube -o un enfoque por el que tanto el proveedor de la nube y sus clientes son responsables de ciertos aspectos de la seguridad- las empresas deben definir claramente sus propias responsabilidades, junto con las del proveedor de la nube. Por tanto, debe establecerse una línea clara [que podría llegar a ser muy delgada] que indique cuál de las partes es responsable no sólo de ciertos aspectos de la seguridad de los datos, sino además de la seguridad de las aplicaciones, máquinas virtuales, interfaces, configuraciones de servicio y más en la nube. “La infraestructura de nube ofrece la capacidad de escalar una aplicación horizontalmente, pero sólo si la aplicación posee una arquitectura para aprovechar esa capacidad”, dijo Ed Featherston, Senior Enterprise Architect and Director en Collaborative Consulting. Si la aplicación no escala debido a un defecto de diseño, el proveedor puede seguir cumpliendo con los requisitos del SLA[15]. De ahí que convenga separar la nube de la aplicación; TI debe ser capaz de distinguir los problemas potenciales de infraestructura de problemas de la aplicación.

“Va a ser dependiente del contrato, pero está en nosotros como empresa, asegurar de que está muy claramente indicado en el contrato dónde está dicha línea”, dijo Peter Keenan, Director de Seguridad de la Información en Lazard, una firma de asesoría y gestión de activos financieros en Nueva York. “Creo que se va a realizar caso por caso y servicio por servicio”.

No olvide asegurarse de tener un seguimiento continuo del ecosistema de su proveedor porque las cosas cambian diariamente. Claro, es aconsejable utilizar herramientas especializadas e integradas lo mejor posible para nuestro ecosistema de nube.

De igual forma, cuanta más supervisión regulatoria enfrente tu empresa, más tienes que preocuparte por cuestiones de jurisdicción de datos. Consulta con tus propios auditores de gobierno, asegúrate de saber si existen regulaciones estatales o locales que podrían aplicarse a los datos almacenados en la nube, y asegúrate de que sabes dónde almacenará los datos tu proveedor de nube[16].

Probablemente si aplicamos la herramienta 6W-2H nos ayude a determinar cosas importantes como: estado, acceso, tiempo de respuesta, tiempo de caducación, versionamiento, fallo, entre otros. ¿Cuántos nueves deseamos de disponibilidad? ¿Quién es culpable de qué, cuándo y por qué?…

Sugiero al lector [si aún está interesado] revisar la exhaustiva información de la Comisión Europea sobre Acuerdos de Nivel de Servicio en Cloud Computing[17].

[1]      Fuente: http://er.educause.edu/articles/2010/6/if-its-in-the-cloud-get-it-on-paper-cloud-computing-contract-issues, junio/2010

[2]      Fuente: http://searchcloudcomputing.techtarget.com/tip/Defining-the-right-cloud-SLA-requirements-up-front, junio/2012

[3]      Fuente: http://www.ibm.com/developerworks/cloud/library/cl-slastandards/, enero/2013

[4]      Fuente: http://searchcloudcomputing.techtarget.com/tip/Embrace-these-cloud-service-level-agreement-best-practices, setiembre/2015

[5]     Fuente: http://searchcloudcomputing.techtarget.com/news/4500252585/IT-pros-crave-a-new-kind-of-cloud-SLA, agosto/2015

[6]     Fuente: http://searchcloudapplications.techtarget.com/tip/Avoid-the-cloud-computing-SLA-trap?utm_medium=EM&asrc=EM_NLN_48206904&utm_campaign=20151002_How%20will%20microservices%20impact%20the%20cloud?_fchurchville&utm_source=NLN&track=NL-1806&ad=903291&src=903291, setiembre/2015

[7]      Fuente: http://searchcloudcomputing.techtarget.com/answer/Sidestep-problems-be-your-own-cloud-SLA-watchdog, julio/2014

[8]      Fuente: http://clkrep.lacity.org/onlinecontracts/2009/C-116359_c_11-20-09.pdf, noviembre/2009

[9]      Fuente: http://searchcloudapplications.techtarget.com/answer/When-cloud-providers-fail-Recovering-from-an-SLA-violation, octubre/2013

[10]    Fuente: http://searchcloudcomputing.techtarget.com/news/4500256467/Cloud-security-requires-shared-responsibility-model, octubre/2015

[11]    Fuente: http://er.educause.edu/articles/2010/6/if-its-in-the-cloud-get-it-on-paper-cloud-computing-contract-issues, junio/2010

[12]    Fuente: http://lts.lehigh.edu/services/explanation/guide-evaluating-service-security-cloud-service-providers, 2015

[13]    Fuente: http://searchcloudcomputing.techtarget.com/tip/Cloud-data-security-outside-the-vacuum-Find-acceptable-levels-of-risk, noviembre/2013

[14]    Igual que Nota 1.

[15]    Igual que Nota 4.

[16]    Fuente: http://searchcloudcomputing.techtarget.com/tip/Dont-let-governance-methods-die-after-a-cloud-migration, enero/2014

[17]    Fuentes (entre otras):
https://ec.europa.eu/digital-agenda/en/cloud-select-industry-group-service-level-agreements
https://ec.europa.eu/digital-agenda/en/news/cloud-service-level-agreement-standardisation-guidelines
https://ec.europa.eu/digital-agenda/en/news/cloud-computing-service-level-agreements-exploitation-research-results
https://ec.europa.eu/digital-agenda/en/news/study-report-standards-terms-and-performances-criteria-service-level-agreements-cloud-computing , octubre/2015

Cargas de trabajo en el marco de la computación en nube -cloudcomputing

Antes de entrar de lleno al tema, definamos someramente el concepto de nube.

Según NIST[1], es un modelo que permite, convenientemente y bajo demanda, el acceso por red a un conjunto compartido de recursos informáticos configurables (por ejemplo, redes, servidores, almacenamiento, aplicaciones y servicios) que pueden ser rápidamente aprovisionados y desplegados con mínimo esfuerzo de administración o de interacción con el proveedor de servicios.

Uno de estos tres métodos de entrega de servicios en la nube según NIST satisface las necesidades de procesamiento de diferentes cargas de trabajo y de diferentes maneras: (íconos e imágenes de Chou[2])

chu

Se sabe que el modelo de computación en nube propugna el uso racional y eficiente de los recursos informáticos para minimizar el impacto negativo de la tecnología sobre el medio ambiente y maximizar su viabilidad económica mediante la reducción del costo total de propiedad (TCO), así como velar por la responsabilidad social.

Interesante pero, antes de elegir debemos comprobar que el modelo de servicio de nube elegido (privado, público o híbrido) cuente con todas las funciones que necesita para sus aplicaciones, por ejemplo, niveles de servicio, recuperación de desastres (DR), prevención de desastres (DA), alta disponibilidad, compatibilidad de la infraestructura del modelo elegido con la existente o con la que deba coexistir ahora y en el futuro, para mantener el control y asegurar portabilidad, flexibilidad, adaptabilidad y elasticidad, entre otros aspectos de importancia.

Ahora, en esencia, una carga de trabajo son todas las capacidades individuales y unidades de trabajo que componen una aplicación discreta, como las aplicaciones distribuidas (Bloomberg[3]); es la clase de trabajo que una organización necesita cumplir.

Esto hace del concepto carga de trabajo una abstracción que implica portabilidad: la capacidad o cantidad de trabajo (alojar un sitio web) que puede ejecutarse en ambientes físicos diferentes pero con configuraciones adecuadas para el trabajo en cuestión (por ejemplo, versiones específicas de los productos o herramientas empleadas, con la cantidad de memoria [de acceso aleatorio] RAM y rendimiento específicos necesarios).

En otras palabras, cada carga de trabajo tiene características que la hacen funcionar más eficientemente en ciertos tipos de hardware y software, y en ciertos entornos mejor que en otros; así, se facilitará la implementación de las políticas de seguridad necesarias en la nube. Además, IBM[4] señala en un estudio de ámbito mundial que habrían otras consideraciones de por medio, como las siguientes:

  • ¿Se tratarán datos sensibles (registros sobre pacientes con SIDA)?
  • ¿Existen transacciones dependientes entre sí (transacciones en línea de alto rendimiento o de misión crítica)?
  • ¿Existen transacciones que necesitan un alto nivel de contabilidad y auditabilidad (por ejemplo, SOX)?
  • ¿Se trabajará con software de terceros que no es cloud-aware [preparado para trabajar en nube]?
  • ¿Qué hay si se requiere medición de aplicación de costos (planificación de la capacidad) o de la utilización (facturación a nivel departamental)?
  • ¿Se necesita adaptación del ERP?

PricewaterhouseCoopers LLP[5] reporta que, por varias razones técnicas, la mayoría de las cargas de trabajo de misión crítica todavía no están preparadas para la infraestructura informática en nube. Y añade que “… no estarán listas hasta que se realicen esfuerzos mayores en el rediseño de la arquitectura y re-codificación, cuyo costo puede llegar a ser un factor importante para mantener estas aplicaciones por muchos años en los centros de datos tradicionales”.

En el artículo de PricewaterhouseCoopers LLP, Ali Shadman, jefe de tecnología de Hewlett-Packard, añade que esto se debe a que los motores de bases de datos no tienen buen rendimiento en un ambiente altamente virtualizado; por la latencia que demandan las aplicaciones de alto rendimiento en cuanto a cantidad de IOPS -y el rendimiento de la red (Geyer[6]). David Stuckey, líder de PwC en las prácticas para la [implementación de la] infraestructura del centro de datos, dice que antes de volver a alojar partes principales de la cartera de aplicaciones en la nube, la empresa haría bien en revisar el ajuste estratégico entre la arquitectura empresarial cambiante y la [arquitectura] de las tecnologías de la información.

También es un buen momento, añade Shadman, para comprometerse con disciplinas como ITSM (IT gestión de servicios), ya que la infraestructura de nube adapta de forma natural en el paradigma de ITSM.

Sylvia & Peterson[7] de IBM señala que son seis las cargas de trabajo de TI fundamentales: desarrollo y prueba, data analytics, almacenamiento, colaboración, escritorio, y cargas de trabajo de aplicaciones.

Es claro entonces que mover algunas cargas de trabajo requiere un análisis cuidadoso ya que se gana más con unas que con otras y esto depende de cuán fácil se puedan mover a la nube. Por ejemplo, los autores señalan que el correo web, los sistemas colaborativos y los de desarrollo y prueba son los más fáciles de migrar. El hecho es que, continúan los autores, ninguna carga de trabajo es la misma en términos de su importancia y costo para la organización, y esto puede afectar su resultado en la nube.

Surge entonces el concepto de política de umbral que, en un entorno en nube, es un atributo importante y necesario — se utiliza para controlar y gestionar los recursos cuando las demandas de carga de trabajo necesitan equilibrarse de forma dinámica después de alcanzar un nivel de umbral predeterminado. La política le solicita al sistema crear instancias de los recursos necesarios según en qué medida la cantidad de demandas de carga de trabajo exceda el nivel del umbral[8]. La información que debería incluirse en una política de umbral se ve influenciada por:

  • El tipo de servicio en la nube que alquile el consumidor.
  • Qué control tiene el consumidor sobre los sistemas operativos, el hardware y el software.
  • El tipo de industria en la que se encuentra el consumidor (por ejemplo, venta mayorista o minorista, energía y servicios, mercados financieros, telecomunicaciones, atención médica, químicos y petróleo, seguros, gobierno, construcción, educación, automotor, entre otros).

En un artículo de VMware[9] se establece que los casos de uso de una nube privada caen en tres categorías:

  • Temporal (de uso poco frecuente -o de uso único).
  • Altamente elástico (crece y se reduce conforme se ejecuta -o necesita).
  • De infraestructura (con un comportamiento estable todo el tiempo –o la mayoría).

Además, agrega el artículo que la nube privada es muy adecuada para demostraciones de ventas, capacitar al personal y socios en software, y permite un fácil acceso a las configuraciones predefinidas de paquetes de aplicaciones complejos. Para agregar variabibilidad, por ejemplo, en un estudio que realizó IBM Market Insights, Cloud Computing Strategy Research en 2009, se consideraron para el estudio las cargas de trabajo mostradas en la siguiente tabla.

cargas

El estudio puso de manifiesto que los responsables de la toma de decisiones manifiestan estar abiertos a nubes tanto públicas como privadas, aunque los índices de adopción y consideración del modelo de prestación de nube privada eran superiores.

Algunas de las cargas de trabajo más críticas son tan costosas para la organización, financiera y operacionalmente, que la migración a la nube tiene el potencial de proporcionar un beneficio considerable. Otras cargas de trabajo pueden estar ya tan altamente optimizadas, que hay poco que ganar de esa migración.

Obsérvese las condiciones y características de las siguientes cargas de trabajo propuestas en un artículo de IBM/Redbooks (Naphade, Prewitt, & Yocom[10]), las que corren sobre una máquina virtual del mainframe [sujeto de estudio en el artículo], que proporciona una nube privada:

  • Un CRM que procesa transacciones tales como la creación de nuevas cuentas de clientes, la actualización de las políticas de los clientes, y desactivar cuentas de clientes.
  • Estas operaciones se ejecutan en el horario de trabajo de 08:00 a 20:00 horas, los siete días de la semana.
  • Después de las 20:00 horas, los empleados de las compañías de seguros utilizan la misma aplicación para procesar reclamaciones de seguros.
  • Un proceso por lotes para archivar e imprimir datos de reclamaciones que está programado para comenzar a la medianoche cada noche y completa todos los días a las 10:00 horas.

Control, monitoreo, gestión, gobierno, todos necesarios. ¿Ya encontró –todos- los riesgos inherentes?

[1]     NIST. (2012). National Institute of Standards and Technology -NIST. Recuperado el 09 de Setiembre de 2015, de sitio web de National Institute of Standards and Technology: http://www.nist.gov/

[2]     Yung Chou. Chou’s Theories of Cloud Computing: The 5-3-2 Principle. Recuperado el 09 de Setiembre de 2015 de sitio web: http://blogs.technet.com/b/yungchou/archive/2011/03/03/chou-s-theories-of-cloud-computing-the-5-3-2-principle.aspx#sthash.08lfGBWy.dpuf

[3]     Bloomberg, J. (08 de Noviembre de 2012). Workloads in Cloud Computing: A Twist on an Old Concept. Recuperado el 09 de Setiembre de 2015, de sitio web de Quinstreet Enterprise: http://www.devx.com/blog/understanding-cloud-workloads.html

[4]     IBM. (Enero de 2010). Disipando la niebla alrededor de cloud computing. Recuperado el 11 de Febrero de 2013, de sitio web de IBM Smart Business: ftp://ftp.software.ibm.com/common/ssi/ecm/es/ciw03062eses/CIW03062ESES.PDF

[5]     PwC_LLP. (2011). Big cloud hurdle: Workload readiness is the key to accelerating cloud adoption. Recuperado el 10 de Febrero de 2013, de sitio web de Price Waterhouse Coopers LLP: http://www.pwc.com/gx/en/technology/cloud-computing/assets/Article_5_Big_Cloud_Hurdle.pdf

[6]     Geyer, R. J. (23 de Mayo de 2012). Identifying Workloads for the Cloud. Recuperado el 09 de Setiembre de 2015, de sitio web de RightScale Blog: http://blog.rightscale.com/2012/05/23/identifying-workloads-for-the-cloud/

[7]     Sylvia, M., & Peterson, B. (Marzo de 2012). Success in the cloud: Why workload matters. Recuperado el 10 de Febrero de 2013, de sitio web de IBM Global Services: ftp://public.dhe.ibm.com/common/ssi/ecm/en/ciw03082usen/CIW03082USEN.PDF

[8]     M. Myerson, Judith. Equilibre la carga de trabajo en un entorno en la nube, 2012. Recuperado el 09 de Setiembre de 2015, de sitio web de IBM: http://www.ibm.com/developerworks/ssa/cloud/library/cl-cloudthresholdpolicy/

[9]     VMware. (2010). Service Definition for Private Cloud. Recuperado el 09 de Setiembre de 2015, de sitio web de VMware: http://www.vmware.com/files/pdf/VMware-Service-Definition-Private-Cloud.pdf

[10]    Naphade, D., Prewitt, R. D., & Yocom, P. (23 de Enero de 2013). Managing Workload Processor Resources on Cloud. Recuperado el 09 de Setiembre de 2015, de sitio web de IBM Redbooks: http://www.redbooks.ibm.com/redpapers/pdfs/redp4940.pdf

Cinco razones para capitalizar en la computación en la nube

Cinco razones para capitalizar en la computación en la nube

(Artículo preparado para difusión interna en la Red Científica Peruana -RCP)

Cinco razones por las que los proveedores de servicio de telecomunicaciones deben capitalizar en la computación en la nube para sus negocios y clientes:

La competencia, presiones de costo, y demanda por servicios y aplicaciones en todo momento y lugar y con cualquier dispositivo están forzando a los proveedores de servicios de telecomunicaciones a considerar modelos alternativos de provisión para adquirir y proporcionar los servicios de TI que demandan los clientes.

El término nube puede ser solo un término de mercadeo para los portadores y no una oferta real de producto. El la palabrita de moda utilizada en el mercadeo actual. Podremos terminar llamando a la computación en la nube de otra forma. Continue reading