El dilema de los datos en la nube

La información es el activo más importante de una empresa, y es normal que cuando alguien haga referencia a los datos, estemos sensibles. Me gustaría animaros a no cerraros en banda, dar una oportunidad para evaluar los servicios que comienzan a estar disponibles y ver si os pueden ser de ayuda.

Existe la posibilidad de que no se adecúen a vuestras necesidades, pero al menos tomaréis la decisión de no utilizarlos con conocimiento de causa y no por el mero “No y punto” 🙂

En este post, cuando hablo de información/datos… me refiero a la información/datos que puede utilizar una aplicación desarrollada por nosotros. No me refiero a contratar servicios de email, comunicaciones… en la nube, estoy hablando de alojar los datos con los que trabajan nuestras aplicaciones.

Al lío….¿Por qué podría interesarme mover datos a la nube? A continuación os planteo una serie de escenarios posibles

1) Porque excepcionalmente vamos a tener un pico de trabajo y necesitamos teras para procesar esa información –> Comprar almacenamiento para usarlo 4 veces al año es un lujo innecesario :)  http://open.blogs.nytimes.com/2008/05/21/the-new-york-times-archives-amazon-web-services-timesmachine/

2) Porque, por su naturaleza, no es información vital y nos sale más barato contratar almacenamiento –> Por ejemplo… las fotos de perfil de twitter no están en los servidores de twitter, están en un servicio de almacenamiento en la nube. O un  Backup baratito 🙂 Hay empresas que te dan backup ilimitado por 50$ al año!

3) Porque quiero hacer disponible mi contenido a través de una CDN –> Así, estará accesible en un tiempo mínimo en todo e mundo.

4) Por escalabilidad, los servicios de almacenamiento de datos están preparados para la máxima escalabilidad, si nuestra aplicación la necesita, puede ser una opción interesante el subcontratarla.´

5) …

Una vez hemos visto que nos interesa alojar información en un servicio en la nube, tenemos que considerar qué información vamos a poner en manos del proveedor, no es lo mismo subir a la nube unos documentos para procesar, que unas imágenes de perfil o de productos de un catálogo, que los datos de contacto de mis clientes, o las cuentas bancarias con las que trabajamos 🙂

La naturaleza de la información es vital a la hora de tomar una decisión,  de todos modos, por romper una lanza sobre subir información sensible a la nube… recordad que el cifrado es una opción viable  y que si estás preocupado por la seguridad del datacenter…. pues no es por menospreciar, pero posiblemente estén tus datos más seguros en el datacenter de X proveedor que en el tuyo 😉

Y aún teniendo claro que el escenario es apropiado, y que la información a subir a la nube se puede subir sin causar una catástrofe interna… queda algo muy importante, qué pasa con la información una vez está en el proveedor? Qué legislación se aplica sobre esos datos? Si un cliente en un país A, visita una web alojada en un país B que consume datos alojados en un país C… ¿ qué legislación aplica ?

Este es un reto que cada proveedor resuelve de una forma diferente, en el caso de Microsoft, existe la geolocalización de los datos, podemos escoger el área geográfica donde se despliega la aplicación ( por ahora solo hay 2 … pero es que seguimos en beta 😉 )  de todos modos, tenemos que esperar a verano de este año para que se aclare el modelo de negocio de Azure, en ese momento veremos cuáles son los términos que arropan a Azure Services Platform.

Como siempre… cada caso es un mundo!! pero no descartéis opciones sin haber profundizado mínimamente en ellas, la nube no deja de ser otro canal más… pero puede ser muy ventajoso si se adecúa a nuestras necesidades.

 

Happy hacking

~ds

Publicado por

10 comentarios en “El dilema de los datos en la nube”

  1. En concreto, en la legislación española, aquellos datos notariales (1954), registrales, catastrales o similares, pasan por cumplir normas muy antiguas y hace poco renovadas para adecuarlas al almacenamiento digital. Estas nuevas normas son una mera continuación de aquellas antiguas en la que dejan bien claro que los datos acontecidos en esos documentos no pueden salir físicamente del sitio en el que se intervienen. En nuestro caso y como empresa proveedera de soluciones informáticas (JPA,sl), no tenemos otra opción que la que no sea de almacenar esos datos en el mismo lugar dónde se intervienen los documentos. Para conseguir tal propósito y la vez acceso a datos relevantes a favor de organismos como son los de Hacienda, CC.AA., Ayto. etc. se creo una plataforma llamada SIGNO compartida por una intrared llamada RENO (en el caso notarial), que se compone de unos 2000 servidores que se alojan en cada una de las notarías existentes en España. En este caso, “la nube”, no puede cumplir su función tal y como la describes.

    Un saludo
    Oscar (2Flores).

  2. ¡Cómo cambian los tiempos!

    Cuando era joven, eso de “estar en las nubes” se castigaba con deberes extra o con quedarte castigado una hora más después de la hora oficial de salida… 😛

  3. Es interesante que se avance en el tema de la localización de los datos y su relación con la legislación. A nosotros se nos ha caído un proyecto que podría beneficiarse de Azure precisamente por eso.

    Es dificil desentrañar las implicaciones que ese infierno de la LOPD tiene para las aplicaciones en la nube, sobre todo si manejan datos sensibles como pueden ser datos médicos.

    Es el problema de que las leyes las redacten los mismos que luego viven de usarlas para litigar, cuanto más complejas y oscuras sean, más tendremos que depender de sus servicios profesionales y más caras serán sus facturas…

    En las leyes como en el software la complejidad es un enemigo a batir.

    ¡Saludos titán!

  4. Hola a todos:

    Rodrigo ha dado en el clavo con la LOPD. De hecho esa ley dice que no podemos almacenar los datos en servidores de países cuya legislación no se equipare a la nuestra en cuanto a los niveles de seguridad y auditoría exigidos. Y eso influye en cosas tan tontas como, por ejemplo, en dónde están tus servidores de correo. Ya hay precedentes. tengo este archivado, por ejemplo, aunque es algo antiguo sigue vigente:

    http://www.elpais.com/articulo/red/Multado/ISP/espanol/alojar/datos/Estados/Unidos/elpeputeccib/20020829elpcibenr_2/Tes

    Con albergar los datos en Europa sería suficiente, pero en EEUU, por ejemplo, sólo se pueden albergar en ISPs y proveedores que hayan firmado con la UE un tratado de Safe Harbor: http://web.ita.doc.gov/safeharbor/shlist.nsf/webPages/safe+harbor+list

    ¡Saludos y a ver si nos vemos!

    JM

  5. Ves… si cuando nos tocan los datos…. 😀 menos mal que el alojamiento de datos no es lo único que nos ofrece la nube!

    @Oscar Gracias por los datos!! Es lo que decía de la naturaleza de los datos… algunos no podrán siquiera contemplar la opción de la nube

    @Alfredo Hay algo parecido a un SQL en la nube, los SQL Services. Pero todo depende de lo que estés buscando

    Ciao!

  6. David, tengo entendido que los SQL Services aun no están listos.

    Yo necesito consultas SQL, CTEs, vistas, procedimientos almacenados, triggers, checks, etc, etc. Es decir, lo que te da un servidor dedicado con SQL Server desde hace bastantes años.

    Si tengo eso y además es muy escalable pues estupendo, pero si no tengo todo eso no me sirve por muy escalable que sea.

    Saludos

  7. se me acaba de ocurrir… dada la dependencia geográfica de los datos españoles… poco tardará algún avispado en ofrecer este servicio localmente 😀

    ciao!

  8. Mmm… David, por lo que me parecen los SQL Services permiten una gran escalabilidad, pero que tal se llevan con la sincronización? es decir, se basan en distribuir una información a lo largo de diferentes servidores del globo, pero si estos se actualizan (glups) cuanto tiempo se tardaría en que todas estas copias esten actualizadas?
    Si esto es así (no lo he probado) este modelo solo serviría para datos que no varíen en exceso y cuya desactualización no pueda provocar problemas…
    no?

  9. La sincronización entre los servidores de SQL Services es ‘instantánea’, siguiendo un modelo lazy, de sincronización de las actualizaciones de forma inmediata a unos 2 servidores y al resto de servidores un poco después. Todo este sistema de sicronización inmediata es completamente nuevo y por lo que habrá muchas cosas de SQL Server que no saldrán en esta primera versión, como Reporting, DataWarehouse, DataMining, etc. Pero tendremos los principal, Bases de datos normales de SQL Server, acceso por TCP y en definitiva que una app que te funciona contra SQL Server/Express en desarrollo, te funcione en la nube cambiando solo el nombre del servidor del string de conexión a un nombre DNS. Incluso es util para hacer debugging en local pero accediendo a datos en la nube. 🙂
    Esper que este verano lo podais empezar a probar, todavía no hay betas públicas.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *