Cinco errores frecuentes en el cloud computing

Buenas,

Una vez mas excusarme por la irregularidad en la escritura, pero entre viajes, visitas y los 9,95 euros que me ha costado en el Media markt un pack que además del Battlefield 1942 trae las extensiones «Road to Rome» y «Secret Weapons of WWII» tienen la culpa de que no actualice el blog con la regularidad deseable :)

Pero esto tiene su lado bueno. Me he dado cuenta de que cuanto mas tiempo transcurre entre post y post, aglutino una mayor cantidad de ideas para intentar escribir cosas más elaboradas, menos aburridas y más interesantes para el personal. Otro tema es que lo consiga :)

Hoy voy a hablar de la nube. Sobre la nube se ha escrito en abundancia, y probablemente, se seguira escribiendo. Es un concepto de moda, y las modas son así: nube hasta en la sopa. Tenemos Twitter hasta en la sopa, Facebook hasta en la sopa, la Web 2.0 en general hasta en la sopa … y la nube no podía ser menos.

Hace tiempo que vengo observando referencias un tanto vagas a los estereotipos manidos que rodean al cloud computing: todo el mundo habla de flexibilidad, escalabilidad, de poder trabajar desde donde queramos … y poco más. Algunos se atreven con reflexiones estrategicas, se mojan en el tema de costes o hablan del ROI, pero vagamente. Menos frecuentes son los que escriben sobre la resiliencia de los negocios, y luego estan los grandes olvidados, la seguridad y el cumplimiento regulatorio, temas que pasan absolutamente desapercibidos, por norma general, en muchas discusiones sobre tecnología y que tampoco iban a ser una excepcion cuando hablamos de la nube.

El resultado de todo lo anterior es un sentimiento generalizado de «la nube mola», criterio que en el barrio 2.0 han promulgado diversos participantes basándose solamente en aspectos elementales como los que hemos citado. No obstante, a poco que se excave en el concepto, es más o menos fácil darse cuenta de que en la corriente de opinión hay mucho concepto generalista repetido, y que encontrar material diferenciado es más complicado de lo que parece. Pero aquí no acaba todo: Como consecuecia de la generalización conceptual también se simplifica en exceso, y eso lleva a errores de diversa índole.

Seria injusto que con estas lineas tire la piedra y esconda la mano. En este caso me estaría comportando como los críticos/seguidores de la nube que la ponen a parir/ensalzan pero sin indicar claramente por qué. Es facil opinar, pero no es tan fácil hacerlo aportando una crítica razonada, que puede ser mejor, peor, correcta o incorrecta, pero que siempre es de recibo cuando se ofrece un punto de vista.

Voy a intentarlo. Voy a tratar de traer a la palestra algunos conceptos que o bien suelen crear confusión, o son continuamente obviados o simplicifados cuando se habla de la nube. Es más que probable que me deje en el tintero muchos conceptos, así que los comentarios son bien recibidos. Seguro que no soy el único que ha observado que a la nube la acompañan ocasionalmente también tormentas.

Error 1. La nube y la simplicidad de conceptos

Con sólo tratar de definir la nube tenemos la primera en la frente. En la literatura es frecuente encontrar referencias asociadas al concepto como granjas, Grid computing, sistemas virtualizados, clústeres, fabric computing, volunteer computing, servicios descentralizados … eso sin entrar en la jungla de los as a service (SaaS, IaaS, PaaS…) y en otros conceptos como la arquitectura orientada a servicios (SOA). Resulta por tanto obvio que querer aglutinar en dos palabras (cloud, computing) todo lo anterior y todo lo que está por venir no es una tarea banal.

El resultado inmediato de la cantidad de elementos que pueden ser asociados al concepto de nube es tal que al final cada cual acaba teniendo su idea particular de lo que es cloud computing, y al igual que muchos aciertan con su visión, otros muchos se equivocan estrepitosamente o simplifican en exceso la idea.

Al menos para mí, por poner un ejemplo, la nube no es tener un sistema operativo distribuido en porciones por los cinco continentes al que accedo desde mi flamante ultraportátil para poder hacer Twitter, Facebook y Google Docs. Ese escenario es plausible, y a buen seguro en un futuro lo veremos firmemente instaurado, pero eso no es hacer cloud computing. Es una contextualización concreta que lleva a pensar que al final todo se trata de tener Chrome OS en un netbook para hacer el chorra en Facebook y guardar documentos en Google Docs. Evitemos ser simples al pensar en estos modelos.

Cloud computing es una manera de entregar servicios basados en tecnologias de la informacion, usualmente a traves de redes (sean públicas como Internet o no) y generalmente sometidos a criterios contractuales. A partir de aquí, que cada cual haga sus particularizaciones, pero creo que es una buena manera de establecer un punto de partida. La palabra clave a grabarse a fuego es SERVICIOS, y la idea que hay que retener es que un servicio puede entregarse de muchas maneras. Tan servicio es ofrecer almacenamiento distribuido profesional mediante fibre channel como ofrecer correo electrónico a un usuario final, con lo que creo que asociar un concepto general a una particularización determinada conducirá siempre a ofrecer una visión incompleta.

Moraleja 1: No convirtamos ni propaguemos abstracciones simplistas de conceptos generales en definiciones.

Error 2. La nube lo revolucionará absolutamente todo

Un servicio TI puede estar ligado a la actividad empresarial o no. Tambien es posible ofrecer servicios a los usuarios finales, ya que los servicios no son patrimonio exclusivo de las corporaciones, así que la nube, en caso de revolucionar algo, probablemente lo hará en los dos segmentos. Es importante desterrar el mito de que la nube lo posibilitará absolutamente todo: no. Hoy en día hay servicios que por su criticidad o complejidad no pueden ser transportados a la nube, y no hay garantias de que algun día sea rentable hacerlo. Tratemos de pensar que no todo es tan aparentemente sencillo como montar un servidor de aplicaciones en el que pueden concurrir usuarios que editan colaborativa o privadamente un documento.

Cuando se selecciona una manera de operar es frecuente encontrarse con un sinfín de limitaciones. Para ilustrar esta idea podemos apoyarnos en el libro La Meta, de Goldratt. Es uno de los materiales de referencia en muchas escuelas de negocios, y contiene una joya que se llama la Teoría de las Limitaciones (Theory of Constraints, TOC). Esta teoría viene a decir que siempre existe al menos una limitación a la hora de gestionar un sistema (Goldratt habla de sistemas productivos, pero nosotros podemos aprovechar el concepto para hablar de sistemas de información). La idea de la TOC es identificar claramente las limitaciones, y construir las estrategias alrededor de la limitaciones más constrictivas para ir mejorando los objetivos de la empresa al reducirse las mismas.

De lo anterior se deduce que, por obvio que parezca, siempre existirán limitaciones para que la nube sea siempre un modelo de éxito, y por tanto no parece tenaz aseverar que en todos los casos será la revolución empresarial por excelencia, ya que siempre existirán negocios limitados por los costes, la seguridad, el cumplimiento normativo, la calidad de servicio, las obligaciones contractuales, la estaticidad de las infraestructuras… Demasiados factores para asegurar un éxito empresarial en el 100% de los casos.

Moraleja 2: No creamos que la nube, por definición, es aplicable con plenas garantías de éxito el 100% de los casos de negocio.

Error 3. Pequeñas variaciones con grandes colaterales

Aunque es un error más concreto, y que posiblemente podríamos haber incluido en el siguiente, he querido mencionarlo de manera expresa. El enfoque erróneo consiste en este caso en no advertir que la variación de un sólo factor en la entrega de servicios puede resultar, en ciertas situaciones, determinante para convertir lo que aparentemente es lo mismo en algo radicalmente opuesto.

Un ejemplo clásico es la ubicación geográfica. Es el caso de las nubes privadas, donde la idea es la misma, pero existiendo una limitación muy importante en la localización de los elementos de la infraestructura y los datos. En vez de tener una porción de la base de datos de clientes en EEUU, otra en Noruega y una tercera en Australia, tenemos las tres porciones en uno o varios racks situados en uno o varios centros de proceso de datos concreto subicados en una única demarcación territorial para la cual existe una regulación común.

Esto juega un papel fundamental en el cumplimiento normativo, como veremos a continuación. En un modelo de nube puro y duro no tiene por que ser así: existen muchos proveedores que tienen numerosos centros de proceso de datos (CPD) y son capaces de distribuir el procesamiento en su red de CPDs con la única condición de que los datos esten disponibles para el cliente cuando sean necesarios, sin importar si los mismos circulan por la geografía mundial o no.

Moraleja 3: La entrega de un servicio generalmente es multivariante, y la más mínima alteración de las condiciones puede tener implicaciones severas en el resultado final.

Error 4. Obviar el cumplimiento normativo

El primer gran olvidado. A algunos les puede parecer estupendo y/o les puede dar igual que sus fotos, contactos, vídeos y demas datos personales estén repartidos a lo largo y ancho del planeta sin tener opción de saber donde están esos datos. Algunos usuarios se conformarán con que sus derechos relacionados con la privacidad y la protección de datos personales esten salvaguardados, sin importarles la ubicacion física de los datos mientras ésta no vulnere sus derechos básicos. Otros usuarios, por desgracia, ni conocen ni se plantean estos temas.

Estas posturas, válidas a priori para servicios orientados a usuarios finales, son a menudo inaceptables en el mundo corporativo, donde hay que respetar la regulación. Muchos reguladores tienen directrices expresas en las que se obliga al propietario de los ficheros a saber en todo momento donde están los datos, ya que es frecuente vincular la permisividad del tratamiento a que los datos esten geográficamente localizados allí donde el regulador estime que es oportuno..

En un modelo puro de computación distribuida con dispersión internacional no es posible garantizar el cumplimiento normativo. Desde la óptica del cumplimiento, la nube tiene en los conflictos legales transfronterizos a su peor enemigo, ya que por desgracia, cada país y cada regulador hace las cosas a su manera, y aunque hay esfuerzos notorios para la convergencia, creo que es sensato pensar que disponer de una legislación mundial única en la que deje de importar si mis logs están en Rusia, Canadá o Angola es un pensamiento en extremo utópico.

Moraleja 4: En sectores regulados, las nubes privadas con limtiación en relación a la dispersión son probablemente la mejor opción.

Error 5. Generalizar sobre la seguridad

Dado que las nubes como tales no han explotado al 100%, y con esto me refiero a que no es algo que usen a día de hoy todas las compañías y usuarios de manera intensiva, es arriesgado calificar taxativamente a las nubes como seguras o no. Tampoco pare lógico pasar por alto que estos modelos están en continua evolución, con lo que lo único que podemos hacer es mirar atrás y ver que incidentes de seguridad han tenido a la nube de protagonista, y hacer una valoracion hasta (n-1), siendo n el dia de hoy.

Por tanto, recelo mucho de las cábalas (n+1) y subsiguientes, especialmente cuando vienen de personas que sólo entienden a la nube como la suma de netbook+chormeOS+facebook+twitter. Tampoco creo que la seguridad dependa únicamente de los incidentes que hayan pasado con anterioridad, dado que la potencialidad de materialización de un riesgo depende también de los factores presentes y futuros. Aunque sea un tópico también manido, la seguridad es un proceso continuo.

Los incidentes en servicios distribuidos no es que hayan sido precisamente pequeños. Si tenéis curiosidad, asomaos por The Breach Blog, e indagad un poco. Pensad un poco también en la cantidad de dependencias tecnológicas que suele tener un servicio y que cada eslabón puede ser un punto de fallo. Demasiadas condiciones de contorno para poder generalizar.

Cada despliegue es un mundo, y en función del tipo de servicio que se esté entregando, me puede preocupar más o menos la seguridad, pero en ningún caso podemos obviarla o acudir a postulados generales para afrontar la necesidad de ofrecer servicios robustos. No me preocupa en exceso la seguridad de las nubes privadas, ya que si desde mi ordenador accedo a unos servicios ubicados en un centro de datos protegido, no sólo por la seguridad física y lógica de un CPD, sino avalado también por una conexión privada (por ejemplo, LAN2LAN) pues convendremos todos en que los riesgos son a priori mucho menores que los que derivan de acceder a mi información personal a través de servicios de gestión documental vía Internet.

Aunque es perfectamente externalizable y confiable a terceras personas, la seguridad requiere que al menos retengamos un elemento, y ese no es otro que el control. Aunque mi proveedor de servicios tenga tokens, firewalls, IDS, IPS y a un equipo de hackers en plantilla para diseñar una estrategia que cubra la mínima probabilidad de sufrir un problema de seguridad, yo quiero seguir teniendo el control. Al menos quiero poder decidir.

No caigamos en el error de pensar que mantener el control es sólo una cuestión técnica, ya que también es una cuestión procedimental. Aunque el barco sea de otra persona, se trata de tener nosotros el timón en nuestras manos y dirigir el barco allá donde nosotros queramos que vaya, y eso conlleva tener muy claro que cuando buscamos seguridad no podemos evadir responsabilidad. Evitemos caer en la tentación de firmar contratos de exención de responsabilidades o delegar absolutamente todo en nuestros proveedores como las mejores maneras de gestionar la seguridad y afrontar nuestras responsabilidades.

Moraleja 5: Cada caso es diferente. Construyamos la seguridad contemplando, como mínimo, nuestra responsabilidad y el nivel mínimo de control deseable.

Un saludo,