Informática y Sistemas (β)

2009/10/06 - 6 octubre 2009

Azure Storage Services: almacenando datos en la nube

almacenando datos en la nube

almacenando datos en la nube

Continuando la serie de pruebas en Azure, avancé sobre los servicios de almacenamiento de datos específicamente las tablas de datos (table service), incorporando la funcionalidad en el sitio público que creé para dichos efectos. Este servicio se implementa de manera completamente independiente a la aplicación o servicio web; y se accede a través de su API (REST API), lo que es prácticamente transparente para el desarrollador si se auxilia de las librerías .NET y ejemplos que introducen en su SDK. Las características de este servicio es la disponibilidad permanente, y redundancia asegurada; lo que no es poca cosa para quienes deben implementar algo similar con infraestructura propia.

Algo sumamente interesante que encontré de este servicio, es que al ser independiente de los servicios de aplicación web, se puede acceder desde aplicaciones web externas o aplicaciones Windows. Compartir un mismo repositorio de datos entre distintos tipos de aplicaciones es una alternativa que abre posibilidades de implementación y esquemas de solución diversos. En vista de ello, experimenté una arquitectura de tres capas, pudiendo la capa de presentación ser tanto de tipo web como una aplicación Windows de escritorio. En este sentido, y recordando mis observaciones sobre las arquitecturas n-capas, en esta plataforma de Azure no tiene sentido el hablar de capas en servidores físicos independientes; justificándose plenamente el comunicar las mismas por referencia directa de sus librerías, con todas las ventajas que mencioné en oportunidad de dicho artículo.

Azure Storage Services

Azure Storage Services

Los registros de la tabla se almacenan como entidades, y un tema tranquilizador es que modificaciones del esquema de datos de una entidad, agregando propiedades pero manteniendo compatibilidad con la versión previa, se implementa de manera totalmente transparente, lo que evita tratar con migraciones de datos preexistentes por cambios menores de tablas. El concepto es trabajar las entidades propiamente como objetos a nivel físico, en vez de registros de tablas; y el modelo relacional es inaplicable en este ámbito aunque a nivel de capa de datos o negocio se los trate de este modo por lo que no es excluyente a nivel lógico.

Los tiempos de respuesta para un conjunto acotados de registros son excelentes, aunque resultan un poco lentos para el acceso desde una aplicación por fuera de la plataforma Azure; lo que debe considerarse a efectos de limitar las prestaciones que se quieran otorgar a la capa de presentación externa. Otra limitación, especialmente importante, es la limitada gama de sentencias para obtener los registros o entidades; si bien la librería permite acceder los datos con instrucciones símil a LinQ, muy pocas instrucciones están disponibles para las consultas (de hecho, solo tres tipos de operadores:  from/where, take, y first o firstordefault). Esto genera cierta incomodidad al momento de tener que realizar consultas tan simples como el obtener el valor máximo de una propiedad, o paginar una consulta sin saber a ciencia cierta cuantos registros existen antes de obtenerlos todos (con el operador count por ejemplo). Las transacciones a su vez, solo están limitadas a operaciones tipo batch de un conjunto acotado de entidades pertenecientes a una misma tabla; por lo que su aplicación es de dudosa utilidad. De hecho generalmente una transacción es justificable y necesaria cuando se afectan varias tablas. Puede pensarse que se pueden implementar rutinas programadas que simulen las transacciones, u otras prestaciones como la de implementar campos autonuméricos (obviamente inexistentes es este contexto); pero lo engorroso de estos procedimientos y lo débiles que pueden resultar frente a una posible concurrencia masiva de usuarios es un fuerte condicionante para desechar esta iniciativa en aplicaciones comerciales o con implicaciones monetarias. En estos últimos casos seguramente deban recurrirse a los servicios Azure de SQL, que próximamente analizaré.

En definitiva, el host de Azure para aplicaciones web combinadas solo con los servicios de almacenamiento nativos es una buena alternativa para sitios modestos, donde no se deban manejar grandes volúmenes de datos por consulta, y sin implicaciones comerciales. Frente a los hosting ofrecidos por terceros tiene la ventaja adicional de contar con permanencia de servicio, redundancia de datos asegurada, y velocidades de acceso y gestión de datos difícilmente igualables; tres características que lo convierten en una opción más que atractiva.

(tiny)

Anuncios

Dejar un comentario »

Aún no hay comentarios.

RSS feed for comments on this post. TrackBack URI

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

Blog de WordPress.com.

A %d blogueros les gusta esto: