¿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

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

Ah!, el factor FUD (miedo, incertidumbre, duda, por sus siglas en inglés).

secure-cloud-computing¿Utilizo la nube para mis datos sensibles o confidenciales? ¿En qué parte de la nube residen mis datos? ¿Qué pasa si el proveedor sufre un desastre? ¿Cómo sus planes de continuidad afectan mis datos [servicios]? ¿Qué tanto control debo ceder[1]? ¿Cómo se alteran mis procedimientos y periodicidad para el respaldo de datos? ¿Puedo migrar fácilmente hacia [y desde] el proveedor de servicios en nube? ¿Cuál es la política de privacidad del proveedor de servicios en nube[2]?

Bueno, estas y más eran algunas de las preguntas que nos hacíamos hace unos cuantos años. Hemos escuchado noticias de alguna brecha de seguridad en alguno de los grandes proveedores de cloud –y frenábamos nuestra decisión. ¿Están las leyes ya optimizadas [existen siquiera] para trabajar en la nube? ¿Cuál es su alcance, global o local, apoyan al proveedor o al consumidor? ¿Está regulada la cesión de datos (a gobiernos extranjeros por ejemplo) por aspectos legales, fraude, terrorismo, o de cumplimiento normativo, qué tan transparentes son las acciones correspondientes de privacidad, qué tanto los proveedores nos dejan solos ante estos casos?

Pero, aún queda pendiente resolver dudas más interesantes como ¿quién es en última instancia el principal responsable de la protección de los datos: el proveedor o el dueño de los datos?[3] ¿Qué acuerdos existen para el almacenamiento de datos en la nube? ¿Qué acuerdos hay vigentes para el respaldo y restauración de datos? ¿Tenemos conocimiento de las medidas de seguridad que los proveedores han puesto en marcha para proteger los datos? ¿Debo preocuparme de la protección de mis datos y uso de autenticación y autorización [la Cloud Security Alliance se preocupa baste por estos temas[4] relacionados con cuentas de usuario] tan igual y con las mismas medidas como en mi centro de datos[5]? ¿Funcionan en la nube las herramientas que actualmente utilizo en mi centro de datos o necesito nuevas versiones de ellas o incluso nuevos y diferentes productos que “hablen” cloud –y todo lo que esto signifique para el costo total de propiedad?

Recordemos que en la nube está centrada en la provisión de servicios; así, los controles de la seguridad seguramente se moverán cada vez más hacia los objetos que se desean proteger[6] (firewall virtual, políticas de control de acceso basadas en roles, derechos de acceso a la red, entre otras opciones). ¿Y estamos seguros que el proveedor ha configurado de forma correcta las bases de datos, sistemas operativos y middleware que ha desplegado[7]? –evaluemos los riesgos, no olvidemos esto.

Hoy en día, rara vez enviamos fotos por correo electrónico, y ya no usamos unidades flash USB para llevar documentos. La nube se ha convertido en un lugar donde todo el mundo se reúne e intercambia información. Por otra parte, la nube se ha convertido en un lugar donde los datos se mantienen de forma permanente[8] -¿un cierto nivel de seguridad o confort? Seguramente no nos preocupamos en estos casos de cifrar los datos personales [porque pensamos que son de propósito general, de distracción o que su contenido y contexto no es tan valioso [interesante] para nosotros –hasta cierto punto claro- pero tenga en cuenta que si tienen un valor por su contenido y contexto para quienes los buscan[9] –y tal vez sus intenciones no son buenas]. Recuerde que si usted no está pagando por un servicio, usted es el producto, no el cliente[10]. Obvio, el nivel de riesgo aumenta lo que exige un nuevo conjunto de mejores prácticas de seguridad[11]. Pero sí deberíamos cifrar los datos corporativos –o asegurar [no confiar] que el proveedor de servicios en nube proporcione tal servicio [asegúrese de que usted controle este aspecto, controlando las llaves de cifrado[12]]. No exagere, mantenga en equilibrio la seguridad requerida y la rapidez del proceso de cifrado.

Los expertos dicen que simplemente no hay manera de alguna vez estar completamente seguros de que sus datos permanecerán a buen recaudo una vez que los haya movido a la nube[13]. Más aún por el usual oscurantismo[14] que envuelve cómo se aseguran los servicios en nube. ¿Muevo mis datos o no los muevo? Antes de decidirse, lo primero que se debe hacer es identificar sus activos de información, definir el nivel de privacidad que éstos necesitan y así planear un nivel de protección adecuado para ellos.

No olvide evaluar sus debilidades y el marco normativo y legal que debe cumplir, y del monitoreo y seguimiento continuos a la actividad de los usuarios[15]. El monitoreo, seguimiento y la gestión son importantes para cualquier centro de datos, ya sea en la nube o no. Estas herramientas reaccionan a los datos en tiempo real [importante la automatización para reducir en la ecuación la implicancia del factor humano[16]] obtenidos de las operaciones del sistema (almacenamiento, computadora, aplicaciones, bases de datos, otros), así como responder a las tendencias en los datos[17]. El mayor beneficio de la supervisión y gestión de la nube es la posibilidad de ver las tendencias. Esto significa reunir muchos puntos de datos a través del tiempo y sacar conclusiones en cuanto a lo que significan –y vaticinan [un poco de analítica aquí no hace daño ¿verdad?]. ¿Estamos considerando todo esto en nuestro modelo de seguridad y en el presupuesto? No se olviden de los volúmenes de datos que deberemos manejar.

Sin embargo, parece que la seguridad en la nube sí está mejorando, se está volviendo más proactiva, ya que hoy por hoy hay más noticias de centros de datos corporativos vulnerados -¿por antigüedad tal vez -legacy? ¿Menos “factor humano” –mejores profesionales o mejor distribución de funciones? ¿Mayor o mejor adopción de tecnología moderna –economía de escala[18]? ¿Mejor enfoque de gestión procesos—tecnología—personas? ¿Deben someterse continuamente a diferentes tests -pentesting?

La seguridad a largo plazo debe ser diseñada y desarrollada especialmente para la nube y realmente ser un pilar para las operaciones de la nube, apoyando la forma en que las aplicaciones en la nube están siendo construidas y entregadas hoy[19]. Los sistemas construidos sin un adecuado rigor en torno a la seguridad no serán tan seguros, estén o no en nube[20]. Sin la cantidad adecuada de planificación y una buena tecnología para controlar el acceso a los datos u adopción de otras medidas preventivas para evitar filtraciones de datos en la nube[21], las plataformas basadas en la nube pueden llegar a ser un riesgo. Por lo tanto, la mejor práctica es centrarse en una estrategia de seguridad bien definida y ejecutada con la correcta tecnología habilitadora (APIs, DevOps[22] [23], otros).

Gartner[24] nos dice que evitar servicios en la nube puede incluso dar lugar a riesgos innecesarios de seguridad, ya que las organizaciones siguen confiando en sistemas internos mal gestionados que a menudo tienen más vulnerabilidades de seguridad que sus equivalentes de nube pública. Además, la renuencia para tomar ventaja de la computación en nube puede dejar a una organización en una situación insegura, inflexible o de incompetencia. Así, es evidente que toda iniciativa en nube debe regirse mediante la planificación, procesos y políticas apropiadas.

OK, un poco de nube puede ser bueno entonces, ¿cuándo moveré mis datos a la nube? podría ser finalmente LA pregunta, y una relacionada, ¿por dónde empiezo, pública o privada? Para responder la pregunta diagnostiquemos el negocio, aterricemos sus necesidades, sinceremos la sensibilidad de nuestros datos, exploremos en nuestra base de datos de conocimientos, agreguemos nuestras lecciones aprendidas, adoptemos mejores prácticas en la industria, incorporemos estándares de gestión de servicios, de seguridad de la información, de riesgos, de gobierno corporativo de TI, identifiquemos e incorporemos el monitoreo y trazabilidad requeridos, no olvidemos incluir políticas sobre la responsabilidad de uso y los procesos de aceptación del riesgo en la nube, y propongamos una alternativa que incorpore en su diseño la seguridad correcta, necesaria y suficiente, y aseguremos que esta alternativa esté alineada con los objetivos del negocio.

[1]      Fuente: http://www.information-age.com/technology/security/123459135/great-it-myth-cloud-really-less-secure-premise; marzo/2016

[2]      Fuente: http://lifehacker.com/the-best-cloud-storage-services-that-protect-your-priva-729639300; marzo/2016

[3]      Fuente: http://www.technewsworld.com/story/76019.html; marzo/2016

[4]      Fuente: http://www.informationweek.com/cloud/infrastructure-as-a-service/9-worst-cloud-security-threats/d/d-id/1114085; marzo/2016

[5]      Fuente: http://computer.howstuffworks.com/cloud-computing/5-ways-to-keep-your-information-secure-in-the-cloud.htm; marzo/2016

[6]      Fuente: http://www.information-age.com/technology/cloud-and-virtualisation/123458895/6-predictions-cloud-security-2015; marzo/2016

[7]      Fuente: http://www.forbes.com/sites/cdw/2014/09/17/how-secure-is-your-cloud-service-provider/#240af4c576db; marzo/2016

[8]      Fuente: http://www.cio.com/article/2380182/cloud-security/5-tips-to-keep-your-data-secure-on-the-cloud.html; marzo/2016

[9]      Fuente: http://lifehacker.com/5904966/why-you-should-care-about-and-defend-your-privacy; marzo/2016

[10]    Fuente: http://lifehacker.com/5887140/everyones-trying-to-track-what-you-do-on-the-web-heres-how-to-stop-them; marzo/2016

[11]    Fuente: http://www.infoworld.com/resources/16334/cloud-security/digital-spotlight-cloud-security#tk.ifw-infsb; marzo/2016

[12]    Fuente: http://www.trendmicro.com/cloud-content/us/pdfs/business/datasheets/ds_securecloud.pdf; marzo/2016

[13]    Fuente: http://www.computerworld.com/article/2483552/cloud-security/no–your-data-isn-t-secure-in-the-cloud.html; marzo/2016

[14]    Fuente: http://www.infoworld.com/article/3010006/data-security/sorry-it-the-public-cloud-is-more-secure-than-your-data-center.html; marzo/2016

[15]    Fuente: http://www.imagineiti.com/the-cloud/is-the-cloud-secure/; marzo/2016

[16]    Fuente: http://www.cio.com/article/3045532/cloud-computing/it-is-getting-cloud-storage-security-all-wrong.html?token=%23tk.CIONLE_nlt_cio_insider_2016-03-18&idg_eid=0f3e0907b81179ebb4f3b209b6424bae&utm_source=Sailthru&utm_medium=email&utm_campaign=CIO%20Daily%202016-03-18&utm_term=cio_insider#tk.CIO_nlt_cio_insider_2016-03-18; marzo/2016

[17]    Fuente: http://www.infoworld.com/article/3044153/cloud-computing/the-clouds-missing-link-monitoring-and-management.html?token=%23tk.IFWNLE_nlt_infoworld_cloud_computing_2016-03-17&idg_eid=0f3e0907b81179ebb4f3b209b6424bae&utm_source=Sailthru&utm_medium=email&utm_campaign=Infoworld%20Cloud%20Computing%202016-03-17&utm_term=infoworld_cloud_computing#tk.IFW_nlt_infoworld_cloud_computing_2016-03-17; marzo/2016

[18]    Fuente: http://zapthink.com/2012/02/07/why-public-clouds-are-more-secure-than-private-clouds/; marzo/2016

[19]    Fuente: http://www.information-age.com/technology/cloud-and-virtualisation/123459009/3-dominant-trends-will-drive-cloud-security-coming-years; marzo/2016

[20]    Fuente: http://searchcloudcomputing.techtarget.com/opinion/Clouds-are-more-secure-than-traditional-IT-systems-and-heres-why; marzo/2016

[21]    Fuente: https://pando.com/2013/11/20/if-you-think-the-cloud-isnt-secure-youre-dead-wrong/; marzo/2016

[22]    Fuente: http://blogs.unir.net/4542-devops-el-catalizador-de-los-beneficios-de-la-nube; marzo/2016

[23]    Fuente: http://www.csc.com/es/publications/121877/121953-acelerar_la_actividad_empresarial_con_devops_en_la_nube; marzo/2016

[24]    Fuente: https://www.gartner.com/doc/reprints?id=1-2RNO28T&ct=151106&st=sg; marzo/2016

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

Planear un Centro de Datos –parte 2

En lugar de sólo alinearse con el negocio, los CIO pueden llegar a ser fuerzas disruptivas estratégicas que impulsan el cambio y crecimiento del negocio[1]. Ya no se trata sólo de mantener las luces encendidas en un centro de datos; eso ya no agrega valor a la organización –no caigamos en la trampa.

Los proveedores inteligentes de centros de datos y servicios en nube aprenden a usar lo que tienen y aprovechan al máximo todos los recursos[2] -¿trillado verdad? De hecho, casi todas las nuevas tecnologías están desplegando hoy en día requieren un lugar donde residir. Evidentemente la nube vive en el centro de datos. No es de sorprender que al emplear tecnologías avanzadas de centro de datos su organización, literalmente, tendrá una rebanada segura de la nube que gestionar y controlar[3]. Ubicación, componentes, comunicaciones, eficiencia, densidad, soporte, seguridad, riesgos, diversos modelos de confinamiento[4] [5] [6], nos vienen a la mente.

En muchos casos, la creación de una mayor eficiencia y un centro de datos más competitivo gira en torno a la consolidación de los recursos del centro de datos –nada nuevo aún, la variación estaría en la protección medioambiental o los centros de datos verdes[7]. Con esto en mente, nos fijamos en tres áreas clave que los gerentes deben mirar cuando se trata de la consolidación del centro de datos. Esto incluye:

  • El hardware (los diferentes niveles de virtualización, ya conocidos –no olvidemos los agentes y recursos necesarios para la seguridad lo cual seguramente impactará negativamente en el rendimiento[8] -todo un desafío la seguridad[9]),
  • El software (de gestión como BMS o DCIM –ajá, una variación a lo estándar que es contar con una aplicación o sistemas de información preparados para la nube), y
  • Los usuarios (los servicios que entregamos hoy y entregaremos mañana, entre otros, a los nativos digitales [y sus gadgets] –así es, lo veíamos venir).

No es noticia que una gran fuente de derroche de energía es la refrigeración del centro de datos ni es un secreto que un sistema de enfriamiento puede engullir hasta la mitad de todo el consumo energético de un centro de datos. Otra, también importante causa de derroche de energía son los servidores que están encendidos pero ociosos[10]. ¿Seguiremos consumiendo [cada vez más] agua como refrigerante o buscaremos utilizar alguna de las alternativas existentes como evaporación, refrigerantes especiales, aire exterior, entre otras?[11] Dependerá claro de los recursos, presupuestos, metas, objetivos, cumplimientos, y otros más, digamos, incentivos.

La tendencia es todavía el enfriamiento excesivo de los centros de datos –a pesar de que la ASHRAE especifica ciertos rangos de temperatura no tan “fríos” como antes. La tecnología (¿fabricantes comprometidos?) y su obsolescencia (¿el hardware resistirá?) -ellos, y la inadecuada gestión del aire [¿existe una adecuada separación entre aire frío y aire caliente?] al interior del centro de datos [¿cuántos puntos calientes tenemos?] que refleje las necesidades reales de refrigeración –nosotros- tienen mucho que ver en esto.

Y hablamos de centros de datos de diversos tamaños de diversas empresas –no precisamente de los centros de datos de gigantes como Microsoft, Yahoo, Google, entre otros, que sí son controlados -reciben bastante publicidad ¿verdad? Los motivos son varios: presupuesto; recursos; conocimiento. Claro, la carencia de estos.

También debemos tomar en cuenta zonas estratégicas para la provisión de servicios -¿qué modelo deseamos proveer o utilizar? Luxemburgo aloja el Hub de Datos de Europa[12] con su centro de datos categoría TIER IV totalmente subterráneo, con instalaciones independientes del operador de primera calidad y avanzados servicios gestionados por demanda. O, para tal efecto, la interconexión de centros de datos[13] para asegurar la disponibilidad de los servicios –y cumplimiento de los niveles de servicio contratados. Esto permite ofrecer a los clientes un único interlocutor para sus necesidades, desde la infraestructura básica hasta las aplicaciones que utilizan los usuarios. Podría ser un beneficio no depender de los operadores regulares –lo que significa contar con los propios recursos pero nos hacemos de la administración y gestión de un servicio propio, algo que cada empresa debe analizar.

Y no pensemos sólo en construir si podemos adaptar bunkers anti-nucleares, iglesias, castillos y otros[14] [15]. Sí, claro, hay cosas que funcionan para otras latitudes –la geografía aprovechada[16] -¿qué podríamos hacer en nuestra geografía, y con cuánto (dinero y sentido común)?[17] Por tanto, debemos tener en cuenta las regulaciones locales y regionales para la provisión de un servicio como un centro de datos (hasta dónde llega la disponibilidad de tecnología de vanguardia –no para el terrorismo por supuesto), o para utilizar los servicios de un determinado centro de datos (dónde estarán nuestros datos). Démonos cuenta que las preocupaciones de unos [proveedores] son diferentes a los de otros (arquitectura de la solución a proveer, servicios a proveer o utilizar, plataforma tecnológica a desplegar –no olvidemos que, poco a poco, encontramos cada vez más una integración Microsoft-Linux[18] [agua y aceite una vez, ¿hasta cuándo?][19], gestión de la infraestructura y de la plataforma, distancias a cubrir, capacidad de las comunicaciones, espacio físico, entre otros aspectos a considerar).

Podemos adoptar una metodología[20] de cuatro fases para asegurar la disponibilidad en un centro de datos [así es, en algún momento debíamos explicitar en este artículo la seguridad de la información –si es que no se habían dado cuenta que tiene mucho que ver]:

  1. La primera de estas fases es la de valoración y evaluación [preguntas como qué tengo, qué no tengo, porqué lo necesito, entre otras, son interesantes –e importantes de responder], que dará paso a
  2. La fase de planificación y diseño[21] [no olvidemos los cambios –probablemente inevitables durante el proyecto por diversas razones y el apoyo que una herramienta BMS o DCIM podría proporcionar, la gobernabilidad[22] y la seguridad de la información], seguida de
  3. La fase de implementación y pruebas [¿recordamos el commissioning[23] [24] [25][26] [27]?, materia para otro artículo ¿verdad? -aunque la mayoría de las compañías tienen planes de recuperación de desastres (DR) establecidos (al menos para las aplicaciones críticas o de lo contrario invitamos al desastre), estas no tienen absoluta confianza en sus pruebas de recuperación de desastres en caso de emergencia[28]] y, por último,
  4. La fase de administración y mantenimiento [la sostenibilidad, sustentabilidad] –no olvidemos el carácter circular o espiral en el tiempo de esta metodología ya que nunca podemos declarar que hemos terminado o que la disponibilidad es máxima y no hay más que hacer.

No olvidemos considerar los equipos de soporte como UPS[29]:

  • ¿Tendremos que reemplazarlos luego de su vida útil?,
  • ¿Podremos prolongar de alguna manera esta vida útil?,
  • ¿Le damos mantenimiento hasta que ya no se pueda –externalizando incluso el servicio?

Todo dependerá de [cuándo no] los costos en cada caso y los presupuestos disponibles, si la carga se mantiene [o aumentará], la eficiencia energética requerida, si hay posibilidad de reutilizarlos [o cuál será su “nueva” utilización], la criticidad del equipamiento que es [o será] protegido, la arquitectura de la que forma [o formará] parte, su impacto [positivo o negativo] en el ecosistema [o para la protección medioambiental], la estandarización de sus componentes, entre otros factores a considerar.

Una pregunta interesante –recordemos que el UPS brinda energía al servidor físico: si un UPS necesita reiniciar un servidor virtual, ¿qué ocurre en nuestro centro de datos?[30], o mejor dicho, ¿cuántas cargas de trabajo se ven afectadas?; ¿está el hiper visor al tanto del comportamiento o de cómo manejar esta situación?, ¿cuál es la configuración de la plataforma virtualizada para asegurar el menor tiempo sin servicio (espacio, rendimiento, comunicaciones, redundancia, clusters, orden, prioridad, entre otros puntos a considerar)?

Así es, hay riesgos. Para poder identificar de forma adecuada los riesgos de negocio asociados al uso de las TI, las organizaciones necesitan adoptar una visión más amplia del riesgo TI que vaya más allá de los estándares tradicionales y que alinee las TI con la dirección estratégica del negocio[31]. Ya no se trata sólo del impacto financiero sobre los servicios. Con la solución de centro de datos que se proponga, deberíamos considerar los servicios que se proveerán. Entre otros aspectos deberíamos considerar: agilidad e idoneidad [adaptación y transformación con rapidez, eficacia y rentabilidad]; escalabilidad y rendimiento [adaptando la capacidad y el rendimiento TI ante las fluctuaciones de las necesidades del negocio –por ende, del mercado]; seguridad y protección de datos [¿procedimientos documentados?, claro que sí; ¿seguridad de la información?, ciertamente]; exactitud y puntualidad [calidad, criterios, indicadores, oportunidad]; disponibilidad y recuperabilidad [respuesta a incidencias, problemas y cortes de servicio, mejora continua].

Cierto, finalmente dependerá del grado de confiabilidad, resiliencia que deseamos –o requiramos[32].

[1]      Fuente: http://www.cio.com/article/3017195/leadership-management/secrets-of-disruptive-cios-investing-in-tomorrow-has-little-to-do-with-keeping-the-lights-on.html?token=%23tk.CIONLE_nlt_cio_insider_2015-12-29&idg_eid=0f3e0907b81179ebb4f3b209b6424bae&utm_source=Sailthru&utm_medium=email&utm_campaign=CIO%20Daily%202015-12-29&utm_term=cio_insider#tk.CIO_nlt_cio_insider_2015-12-29, diciembre/2015

[2]      Fuente: http://www.datacenterknowledge.com/archives/2015/09/03/data-center-consolidation-a-managers-checklist/?mkt_tok=3RkMMJWWfF9wsRokuKvLce%2FhmjTEU5z16egtUaWzgIkz2EFye%2BLIHETpodcMTcJmNL3YDBceEJhqyQJxPr3FLNQN2MFvRhXkC33rhbLOWYxceLV9yOhlovnwjQ%3D%3D, setiembre/2015

[3]      Fuente: http://www.datacenterknowledge.com/archives/2015/09/07/how-data-center-providers-have-become-cloud-leaders/?mkt_tok=3RkMMJWWfF9wsRokuKvLce%2FhmjTEU5z16egtUaWzgIkz2EFye%2BLIHETpodcMTcJmNL3YDBceEJhqyQJxPr3FLNQN2MFvRhXkC33rhbLOWYxceLV9yOhlovnwjQ%3D%3D, setiembre/2015

[4]      Fuente: http://www.datacenterknowledge.com/archives/2015/03/10/startup-challenges-concept-of-aisle-for-edge-data-centers/, marzo/2015

[5]      Fuente: http://www.datacenterdynamics.es/focus/archive/2015/02/gz-ingenier%C3%ADa-presenta-un-sistema-de-confinamiento-con-apertura-autom%C3%A1tica, febrero/2015

[6]      Fuente: http://www.emersonnetworkpower.com/es-CALA/Products/RacksAndIntegratedCabinets/Pages/default.aspx, 2015

[7]      Fuente: http://es.slideshare.net/mundocontact/5-b-lmejia, mayo/2011

[8]      Fuente: http://resources.idgenterprise.com/original/AST-0157915_CIOInsight_Executive_Brief.pdf, 2014

[9]      Fuente: http://searchdatacenter.techtarget.com/news/4500260725/Eight-emerging-data-center-trends-to-follow-in-2016?utm_medium=EM&asrc=EM_ERU_51309322&utm_campaign=20151218_ERU%20Transmission%20for%2012/18/2015%20%28UserUniverse:%201891297%[email protected]&utm_source=ERU&src=5462781, diciembre/2015

[10]    Fuente: http://www.datacenterknowledge.com/archives/2015/12/04/the-problem-of-inefficient-cooling-in-smaller-data-centers/?utm_source=feedburner&utm_medium=email&utm_campaign=487&sfvc4enews=42&Issue=DCK-01_20151205_DCK-01_762&utm_rid=CPNET000002790352&elq2=52cfef0c7bf645009d174f9745fac545&cl=article_1_b&NL=DCK-01, diciembre/2015

[11]    Fuente: http://searchdatacenter.techtarget.com/feature/Data-center-water-usage-whets-appetite-for-change?utm_medium=EM&asrc=EM_ERU_51693770&utm_campaign=20151228_ERU%20Transmission%20for%2012/28/2015%20%28UserUniverse:%201893991%[email protected]&utm_source=ERU&src=5465925, setiembre/2015

[12]    Fuente: http://www.europeandatahub.eu/, 2015

[13]    Fuente: http://www.interoute.es/centros-de-datos, 2015

[14]    Fuente: http://www.elconfidencial.com/tecnologia/2013-07-13/carceles-iglesias-bunkers-los-cinco-centros-de-datos-mas-excentricos_766321/, julio/2013

[15]    Fuente: http://listas.20minutos.es/lista/top-10-centros-de-datos-mas-increibles-en-la-tierra-378571/, marzo/2014

[16]    Fuente: http://www.datacenterdynamics.es/focus/archive/2015/08/el-mayor-centro-de-datos-europeo-abrir%C3%A1-sus-puertas-en-noruega, agosto/2015

[17]    Fuente: http://blog.aodbc.es/2013/02/15/cual-es-la-mejor-ubicacion-para-mi-centro-de-datos/, febrero/2013

[18]    Fuente: https://www.linux.com/news/software/applications/795366-what-does-microsofts-love-mean-for-linux/, noviembre/2014

[19]    Fuente: https://azure.microsoft.com/es-es/blog/azures-getting-bigger-faster-and-more-open/, octubre/2014

[20]    Fuente: http://whitepapers.siliconweek.es/wp-content/uploads/2015/11/asset-disponibilidad-continua-ES.pdf?tk=fdd0e39bcbe9cb85526ef41772cf6036&i=1858333,2015,12,29,20,19,39,1&to=1isfJdMdGXCxoOsGhiJA5gauGb9JTjz0egzR9GRyVtle+GW2NRVNG98ZoFk/RcA7qVJAiljKGYFyQeLQI3ry6WW7btWj12lK1vZ+BmlKlBqw==, junio/2015

[21]    Fuente: http://whitepapers.siliconweek.es/wp-content/uploads/2015/11/500-C%C3%B3mo-el-software-de-gesti%C3%B3n-de-la-infraestructura-f%C3%ADsica-de-centros-de-datos-mejora-la-planificaci%C3%B3n-y-reduce-los-costes-operativos.pdf?tk=85f7dd12ac9cb147e450fff73dedd38c&i=1829855,2015,10,26,03,14,08,1&to=gMmG7X5GdUMFP2Elk5KbyQs8iI+BzefwafMO81xmymKRty95Fq9ym6zt3gRdp9GPnpbq2hmhjD42YrvZEjOKB+myBeUhv7tH2vm3ln4iJUnQ==, noviembre/2015

[22]    Fuente: http://www.amperonline.com/biblioteca/novedades.pdf, 2015

[23]    Fuente: http://www.businessdictionary.com/definition/commissioning.html, 2015

[24]    Fuente: http://www.datacenterknowledge.com/archives/2013/05/20/understanding-data-center-commissioning-and-its-many-benefits/, mayo/2015

[25]    Fuente: http://www.primaryintegration.com/services/levels-of-commissioning-integrated-systems-testing/, 2015

[26]    Fuente: http://www.emersonnetworkpower.com/documentation/en-us/brands/liebert/documents/white%20papers/commissioning_your_data_center_sl-25673.pdf, 2015

[27]    Fuente: http://www.datacenterworld.com/spring2013/account/Uploader/uploader_files/show/151, 2015

[28]    Fuente: http://searchdisasterrecovery.techtarget.com/feature/DR-plans-are-common-but-disaster-recovery-tests-remain-uneven?utm_medium=EM&asrc=EM_ERU_51745967&utm_campaign=20151229_ERU%20Transmission%20for%2012/29/2015%20(UserUniverse:%201891632)[email protected]&utm_source=ERU&src=5466407, julio/2015

[29]    Fuente: http://whitepapers.siliconweek.es/wp-content/uploads/2015/11/50-Gu%C3%ADa-sobre-qu%C3%A9-hacer-con-un-UPS-antiguo.pdf?tk=bc4e958da70db63f75bff4ee5b1347d1&i=1829855,2015,10,26,03,14,08,1&to=1bRGt+lvPw3b0/oxUHE1fQOvpoo3hcG2c+wi8Et/JWRf7OvvmrTb8CO46esi6/zy9QXnANJNz0dacE0U1+w2PjJm5ANqCtZCY+LAVMocroXg==, noviembre/2015

[30]    Fuente: http://searchdisasterrecovery.techtarget.com/tip/How-UPS-devices-can-protect-a-virtualization-host?utm_medium=EM&asrc=EM_ERU_51745966&utm_campaign=20151229_ERU%20Transmission%20for%2012/29/2015%20(UserUniverse:%201891632)[email protected]&utm_source=ERU&src=5466407, julio/2015

[31]    Fuente: http://whitepapers.siliconweek.es/wp-content/uploads/2015/11/1.Alineaci%C3%B3n-de-las-TI-con-los-objetivos-estrat%C3%A9gicos-de-negocio.pdf?tk=bf79d0fc835dec23ebddf52fadd076bf&i=1829855,2015,10,26,03,14,08,1&to=mMH7XN9dEnGl0MY/l7/7HgPdtzfD43o6bYI1IP/H0NE3LZdIGwWtAxztXbNDcO549bAP0RbfihjcpdhNwFt1DGKs/MR7I7yoS2O117YLPPoA==, noviembre/2015

[32]    Fuente: http://searchdatacenter.techtarget.com/tip/A-data-center-design-guide-to-get-it-right-the-first-time?utm_medium=EM&asrc=EM_ERU_51309324&utm_campaign=20151218_ERU%20Transmission%20for%2012/18/2015%20%28UserUniverse:%201891297%[email protected]&utm_source=ERU&src=5462781, diciembre/2015

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

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

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

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

Otro interesante artículo sobre el tema del cloud computing donde Forbes, Líderes de Negocios del Mundo, como indican en su página Web, nos dice que el departamento de TI ha sido completamente puesto de lado en el ámbito de las tecnologías de automatización de mercadeo. Para el modelo SaaS, las necesidades de integración y cooperación entre diferentes soluciones, sin dejar de lado los hábitos de compra de los depaen el marco de la computación en nube -cloudcomputingrtamentos de mercadeo, son factores determinantes para esto. Aquí hablamos del intercambio fluido de datos entre las soluciones empleadas, de ida y vuelta, considerando los diferentes proveedores; bueno, entre algunos proveedores por el momento.

Según el artículo, todo lo anterior ocurre a tal punto que la tecnología se asemeja más la tecnología de consumo que a las tradicionales aplicaciones de negocio. Los usuarios de mercadeo que no son técnicos pueden hacer de forma fácil que el software haga lo que ellos desean que haga.

El problema será que, posiblemente, los departamentos de TI tengan que, en algún momento, entretejer diferentes soluciones para lograr los objetivos del negocio. Bueno, de hecho, en el artículo acompañante, Forbes nos dice en este artículo que por años los gerentes de informática han tenido que elegir entre las mejores aplicaciones de su clase que se enfocaban en resolver un problema y colecciones combinadas de muchas aplicaciones construidas para trabajar juntas. Lo anterior es cierto porque en los negocios existen muchas variaciones (producto, industria, tamaño de la empresa, cultura e idiosincrasia) y probablemente no se cuente con una única solución que satisfaga cada necesidad. Consideremos que cada solución puede, incluso, ser utilizada de forma diferente. ¿Cuál será el eje central? ese mismo, los datos; ¿cómo? esa es otra historia. No olvidemos que luego se tiene la responsabilidad de integrar el flujo de procesos a través de aplicaciones e integrar la funcionalidad entre aplicaciones, tales como gestión de identidades, la gestión del rendimiento empresarial y cumplimiento, en diferentes magnitudes, dependiendo de la solución elegida.