Category Archives: Cloud

Escalabilidad Infinita y tablas Memory-Optimized

Clock

 

 

En este post voy a analizar algunos escenarios de escalabilidad de aplicaciones, en particular, aquellos escenarios que pueden verse beneficiados con el uso de tablas memory-optimized.

Los puntos principales del post son los siguientes:

  • Rangos de escalabilidad de aplicaciones
  • Algunas restricciones a la escalabilidad infinita impuestas por la arquitectura tradicional de base de datos relacionales
  • Ventajas de las tablas memory-optimized para sistemas con escalabilidad infinita

Rangos de escalabilidad de aplicaciones

Cuando hablamos de escalabilidad de aplicaciones, nos referimos a la capacidad que tiene una aplicación dada de mantener el mismo nivel de performance ante cantidades crecientes de usuarios concurrentes que la utilizan.

La escalabilidad de aplicaciones puede agruparse en diversos rangos, según el punto de vista del análisis, pero una forma típica es la siguiente:

  • Escalabilidad básica
  • Escalabilidad intermedia
  • Escalabilidad ilimitada o infinita

Escalabilidad básica es el rango mínimo de escalabilidad, que abarca entre uno y unos pocos miles de usuarios concurrentes.

En este rango se ubican aplicaciones de PyMEs y aplicaciones departamentales de grandes empresas.

La edición Express de SQL Server puede atender este rango de escalabilidad.

Este rango no es el foco de este post.

Escalabilidad Intermedia es un rango que abarca entre unos pocos miles y varias decenas de miles a varios cientos de miles (para muchos escenarios) de usuarios concurrentes. Este es el rango de escalabilidad que las ediciones de SQL Server a partir de la Standard pueden proveer (con los recursos apropiados de hardware del server).

En este rango se ubican aplicaciones corporativas del estilo de ERP, portales corporativos, aplicaciones de Helpdesk y otras similares.

En este rango de escalabilidad, las ediciones de SQL Server mencionadas (con los recursos de hardware apropiados), son capaces de atender con alta performance a todo tipo de escenarios. También es importante destacar que a partir de este rango de escalabilidad, es imprescindible usar versiones 64 bits de SQL Server con múltiples procesadores de múltiples núcleos, y con un dimensionamiento adecuado de memoria.

Escalabilidad ilimitada o infinita es el rango que se corresponde con aplicaciones web de uso masivo, a partir de varias decenas de miles de usuarios concurrentes en adelante, sin cota superior definida.

Este rango puede ser atendido por las mismas ediciones ya mencionadas de SQL Server, con los adecuados recursos de hardware en el server, sin embargo, es importante destacar que con cantidades muy grandes de usuarios concurrentes, existen diversos escenarios donde puede aumentar la latencia en las transacciones hasta niveles no deseables: este es el tipo de escenarios que se puede beneficiar con las ventajas de las tablas memory-optimized.

Para poder analizar las ventajas que las tablas memory-optimized ofrecen para este tipo de requerimiento (escalabilidad infinita), es necesario analizar con más detalle algunas de las restricciones a la escalabilidad infinita que imponen algunos elementos de la arquitectura tradicional de los engines de bases de datos relacionales.

Algunas restricciones a la escalabilidad infinita impuestas por la arquitectura tradicional de base de datos relacionales

Vamos a repasar brevemente la secuencia de pasos que ocurren en un server de base de datos SQL Server desde que recibe una solicitud de ejecutar un proceso hasta que el resultado del proceso es retornado al proceso cliente en un contexto de escalabilidad infinita.

Para realizar este breve análisis, me focalizaré en un concepto que es útil para este propósito: el concepto de recurso limitante.

En un contexto de alta escalabilidad, el server de base de datos ha de recibir una cantidad muy alta de Remote Procedure Calls concurrentes, provenientes de procesos cliente.

Para poder atender a todos estas invocaciones concurrentes sin tener que encolarlas, es necesario que el server tenga multiples procesadores con múltiples núcleos.

Desde este punto de vista, el procesamiento paralelo es favorable para cubrir el requerimiento de escalabilidad infinita.

Para poder ejecutar el proceso solicitado, el server ha de verificar si los datos necesarios para dicho proceso están disponibles en el Data Caché.

Este es el primer recurso limitante relevante que se presenta en los diversos pasos a seguir para ejecutar el proceso solicitado.

Si en el Buffer Pool no están todos los datos necesarios, el server debe leer los datos faltantes en los files que los contienen y ubicarlos en el Data Caché para poder ejecutar el proceso solicitado.

Al querer leer los datos faltantes en los files que los contienen, aparece el segundo recurso limitante relevante: que el disco que contiene los files donde se alojan los datos requeridos esté ocupado realizando otra tarea previa.

Esto hace que se debe encolar la tarea de lectura y esperar su turno hasta que pueda ser realizada: esta espera es la causante de los wait types “infames” del tipo PageIOLatch*.

Es importante destacar que tener múltiples procesadores no ayuda para reducir ambos recursos limitantes: es más, cuantos más procesadores tenga el server, es más probable que múltiples invocaciones concurrentes estén “peleando” entre sí por los recursos limitantes mencionados.

También es importante destacar que el aumento de memoria permite tener un Data Caché más grande, y por lo tanto, bajar un poco la probabilidad que el server no encuentre los datos necesarios para ejecutar el proceso solicitado y por lo tanto, tenga que leer dichos datos de los files que los contienen.

En cuanto al recurso limitante que el disco esté ocupado con otra tarea previa, el elemento crucial es la velocidad del disco, y tener más procesadores o más memoria en el server no resuelve  en forma significativa este problema (toda vez que es necesario ir a leer los datos faltantes).

En resumen, las restricciones a la escalabilidad infinita surgen por el tiempo total necesario para ejecutar el proceso solicitado, y dicho tiempo se ve afectado por la espera para leer los datos faltantes, y esto ocurre porque dichos datos no están disponibles en el Data Caché al momento de ejecutar el proceso solicitado.

Por lo tanto, si se puede garantizar que los datos necesarios para un proceso en particular estén “siempre” en memoria, se eliminan las restricciones mencionadas a la escalabilidad infinita.

Justamente, esto es lo que aporta el uso de tablas memory-optimized a los escenarios de escalabilidad infinita.

Ventajas de las tablas memory-optimized para sistemas con escalabilidad infinita

Al eliminar la necesidad de tener que ir a leer al disco los datos faltantes para ejecutar un proceso en particular, el uso de tablas memory-optimized puede mejorar en forma significativa la performance de los procesos que operan con dichas tablas, donde el factor de mejora típicamente es por lo menos un orden de magnitud, y en muchos casos, dos órdenes de magnitud: justamente esto justificó que el codename de esta tecnología sea Hekaton, que literalmente es “cien” en griego.

Este nivel de mejora de performance es crucial para aplicaciones tanto Internet Facing como Cloud.

Para aplicaciones Web Internet Facing, se tiene disponible las tablas memory-optimized en SQL Server 2014 Enterprise (On Premises), mientras que para Cloud-based web applications, se tiene disponible tablas memory-optimized en SQL Azure.

Saludos, GEN

 

Advertisements

La tecnología nivela el campo: La Hora de los Más Chicos

umbrellaID-10023846

En el libro “El Arte de la Guerra” de Sun Tzu, el capítulo “Configuraciones de Terreno” contiene un párrafo muy relevador:

“Si podemos avanzar y el enemigo también puede avanzar, se llama ‘accesible’. En la configuración ‘accesible’, primero ocupa las alturas y el lado yang (soleado), y mejora las rutas para transportar provisiones. Luego, cuando nos trabemos en batalla, será ventajoso”.

Sun Tzu, en este párrafo, destaca a la vez que el terreno alto y soleado ofrece ventajas innegables al ejército que las ocupa, y que las posiciones niveladas no ofrecen ventajas diferenciales a ninguno de los contrincantes, y por lo tanto, el resultado de la batalla no está garantizado, sin la intervención de muchos otros factores cuyo orden de magnitud y combinación son tales que puedan desbalancear el resultado en favor del lado poseedor de los mismos.

Este párrafo es muy relevante respecto al panorama actual de tecnologías, redes sociales y software open source. Justamente, todas estos elementos dan lugar a un campo de batalla que presenta un terreno accesible, es más, totalmente nivelado, por lo tanto, el terreno es a la vez accesible y sin puntos elevados, por lo tanto, no hay lugares altos y a la vez, todos los sectores son lados yang (soleados).

En este contexto, la ventaja juega claramente a favor de los players más chicos, las PyMES, las empresas regionales, y definitivamente no juega a favor de las multinacionales, ni siquiera de las empresas nacionales más grandes.

Esta ventaja es concreta y posible, pero no puede realizarse si “los más chicos” no toman las medidas necesarias para hacer de estas ventajas una realidad.

Esas medidas necesarias implican un plan estratégico y una implementación de tal estrategia.

Tanto el plan estratégico como su implementación requieren claramente de una Arquitectura Empresarial y de un sistema de plataformas técnicas de negocios capaz de dar soporte a tal arquitectura, todos ellos alineados con el plan estratégico mencionado.

Saludos, GEN

En ingeniería, la forma sigue a la falla, y no a la función

Cracked Glass

Cracked Glass

La reciente salida de servicio de Amazon Web Services (AWS) puso de manifiesto como afectó a algunos clientes mientras que otros no se vieron afectados, ya que diseñaron sus soluciones On The Cloud con una combinación adicional de redundancia y eliminación de puntos únicos de falla.

Este evento destaca claramente que el problema no está en la madurez de las soluciones Cloud disponibles en el mercado, si no más bien en una visión simplista de como las organizaciones deberían implementar este tipo de soluciones.

Dicho de otra manera, en vez de decir “Creo en Cloud Computing”, deberíamos decir “Le creo a Cloud Computing”.

Si realmente “le creemos a Cloud Computing”, deberíamos aplicar los mismos principios de diseño de disponibilidad de la solución Cloud que contratamos, a la hora de determinar que componentes, dependencias e interacciones nos asegurarán un diseño fault-tolerant.

Como complemento de estas ideas, incluyo dos posts que me parecen interesantes:

http://gigaom.com/cloud/how-to-design-your-service-for-failures-in-the-cloud/

http://www.techrepublic.com/blog/networking/how-innovative-design-allowed-one-cloud-company-to-withstand-amazons-recent-outage/3995

Saludos, GEN

Windows Azure: Para comprender la solución, hay que entender el problema

Tal como señala el título, es conveniente revisar el problema en cuestión, su naturaleza y características, para poder comprender mejor porqué un determinado diseño o arquitectura representa una solución razonable a dicho problema.

Es frecuente que, cuando me veo en la necesidad de explicar un concepto complejo, encuentro útil recurrir a una analogía de la vida cotidiana para facilitar dicha explicación.

En este caso, voy a recurrir a la analogía de un automóvil como un ejemplo de sistema que guarda determinadas relaciones con un sistema informático.

A muchos de nosotros nos ha pasado aprender que, en un automóvil, muchas cosas distintas pueden fallar y dejarnos sin solución. Algo similar sucede con los sistemas informáticos: muchas partes distintas del sistema pueden fallar y dejarnos sin solución.

En un automóvil, al igual que en un sistema, es grave cuando la pieza o parte que falla se caracteriza por ser un punto único de falla: es alguna pieza o parte crucial del automóvil o del sistema que, si falla, nos deja completamente sin solución, por la simple y sencilla razón que el sistema solo cuenta con una pieza de ese tipo!.

En este punto, es conveniente hacernos la pregunta de rigor:

¿ Cómo podemos diseñar un sistema para que sea fault-tolerant ?

Antes que nada, es útil tener una definición operativa de fault-tolerant, aunque no sea una definición académica.

Un sistema fault-tolerant es aquel que es capaz de seguir brindando su servicio a pesar que un determinado subconjunto de sus partes ha fallado.

La solución general de diseño para un sistema fault-tolerant es conceptualmente sencilla: redundancia.

El sistema debe evitar puntos únicos de falla a través de diversas redundancias en sus partes, aunado con un sistema de monitoreo del grado de salud de cada parte o componente del sistema, y con la capacidad de redireccionar la provisión de la función afectada por la falla hacia una pieza redundante equivalente ante la detección del problema.

Para poder seguir con este análisis, debemos orientar nuestra atención a un subconjunto importante de quality attributes (QAs) de un sistema informático.

En este punto solamente me concentraré en los QAs que son relevantes para esté análisis, dado que hay otros QAs que son importantes en general, pero no forman parte de nuestro scope.

Los QAs en cuestión son:

Performance

Escalabilidad

Seguridad

Disponibilidad

El orden de presentación no es relevante, más bien es práctico.

Vamos a dar algunas definiciones operativas de estos conceptos, aunque no sean académicas.

Performance es la capacidad de completar una tarea en un intervalo de tiempo y con un consumo/ocupación de recursos conveniente desde el punto de vista económico.

Escalabilidad es la capacidad de poder atender cantidades crecientes de solicitudes concurrentes de ejecución de una tarea, conservando la performance dentro de un umbral cercano al nivel nominal (el necesario para realizar una sola tarea), de tal forma que mantiene o conserva la conveniencia económica.

Seguridad es la capacidad de garantizar que en un sistema al que acceden muchas personas distintas, cada persona solamente tiene acceso a la información estrictamente necesaria para cumplir con sus objetivos y responsabilidades, ni más, ni menos.

Disponibilidad es la capacidad de un sistema de seguir adelante con la provisión de sus servicios básicos a pesar que un determinado subconjunto de sus partes o piezas ha fallado.

El orden o grado de disponibilidad de un sistema se mide en %, de tal forma que cuanto más cercano al 100% es la disponibilidad del sistema, más conveniente desde el punto de vista económico-financiero es el mismo.

Una forma práctica de entender el orden o grado de disponibilidad es como el cociente entre la cantidad total real de tiempo de operación del sistema durante un intervalo de tiempo (por ejemplo, un año) y la cantidad total nominal de tiempo de operación del sistema durante el mismo intervalo de tiempo, expresado en %.

Un sistema fault-tolerant debe ser capaz de conservar estos cuatro QAs dentro de un nivel económicamente conveniente, a pesar que un subconjunto de sus partes o piezas ha fallado.

Para comprender el problema y su solución, veremos alternativas de fallas cruciales y como la conservación de los niveles aceptables de los QAs mencionados informan cómo debería ser el diseño.

Veamos la escalabilidad. Una forma sencilla de mantener la escalabilidad es usar un server más grande y veloz, con más capacidad de procesamiento, más memoria, más discos, etc.

En realidad, esta no es una brillante idea, dado que estamos permitiendo que exista un punto único de falla.

Esta opción, llamada Scale Up, no es buena, más bien es mejor la opción que permite escalar con un conjunto de servers, llamada Scale Out.

Los clusters de servers con Network Load Balancers (NLBs) apuntan a la opción Scale Out de servers de aplicación.

Sin embargo, los clusters y los NLBs no resuelven el problema de una falla en el servicio de repositorio de datos (en general, bases de datos).

Para ofrecer una solución útil y a la vez, coordinada con el Scale out de servers de aplicación, es necesario tener un diseño que permita un Scale Out de servers de bases de datos que actualice en forma concurrente y distribuida y que soporte failover automático, es decir, la capacidad de detectar que el server primario no responde y es necesario redireccionar la provisión del servicio a un server secundario que ya está actualizado con la misma información, en forma concurrente.

Desde el punto de vista de la seguridad, es más fácil dar seguridad a un esquema Scale Up que a un esquema Scale Out, pero la combinación seguridad + escalabilidad del Scale Out es mucho mejor que la combinación del Scale Up.

En el caso del orden o grado de disponibilidad, es importante considerar como afecta a este factor las paradas programadas y las no programadas.

Es fácil de comprender que se puede hacer mucho por mitigar el impacto que tienen las paradas programadas sobre la disponibilidad, en particular si aumentamos el grado de redundancia de tal forma de tener servers adicionales para hacer las paradas programadas con rotación de servers en operación.

Windows Azure ofrece todas estas capacidades, incluyendo failover automático a un site remoto (ante una catástrofe que afecte al site en su conjunto), más provisión elástica de capacity, más costos variables según consumo.

Windows Azure, una solución Platform as a Service

Windows Azure se presenta como una solución Platform as a Service.

Es conveniente describir brevemente las diferentes opciones de soluciones Cloud para comprender mejor que es Platform as a Service, comparándolas contra el esquema tradicional de IT propio, y entre sí.

En el esquema de IT propio, la empresa tiene la responsabilidad de proveer y mantener todas las partes que componen el stack de soluciones, desde los servers, hasta las aplicaciones de negocios, y todas las tareas y gastos de mantenimiento de cada uno de los componentes del stack de soluciones.

En la primer opción Cloud, Infrastructure as a Service, los servers, storage y network son provistos como un servicio, por lo tanto, la empresa paga en forma variable por el consumo realizado del servicio provisto.

La empresa debe hacerse cargo de las inversiones, gastos y tareas de mantenimiento del resto de los componentes del stack de soluciones, desde el OS en adelante.

En la segunda opción Cloud, Platform as a Service, los servers, storage, network, OS y Application Stack son provistos como un servicio, por lo tanto, la empresa paga en forma variable por el consumo realizado del servicio provisto.

La empresa debe hacerse cargo de las inversiones, gastos y tareas de mantenimiento del resto de los componentes del stack de soluciones, en este caso, las aplicaciones.

En la tercer opción Cloud, Software as a Service, el stack completo de soluciones, desde los servers hasta las apliciones, es provisto como un servicio, por lo tanto, la empresa paga en forma variable por el consumo realizado del servicio provisto.

Soluciones como Hotmail, Google Docs o Salesforce.com son claros ejemplos de SaaS.

En todos estos casos, parte de los principales beneficios de la provisión de partes del stack de soluciones como un servicio son de tipo económico-financiero.

El elemento principal del beneficio económico se centra en la ventaja que los proveedores de estos servicios, debido al tipo de arquitecturas de
virtualización que utilizan, y a la posibilidad de vender en todo el mundo, pueden prorratear los gastos fijos y semifijos en una cantidad mucho mayor de elementos que lo que puede hacer una empresa promedio.

Por ejemplo, un administrador de servers es prorrateado en miles de servers virtuales, dado que puede atender ese orden de magnitud de servidores.

El elemento principal del beneficio financiero se centra en la capacidad de retrasar la necesidad de erogar una determinada cantidad hasta el último momento, directamente cuando se consume el servicio, en vez de tener que hacerlo por anticipado.

Esto redunda en un Valor Actual Neto menor, lo que indica que es una mejor opción de inversión, para la misma provisión de servicio.

Para redondear el concepto, es conveniente destacar cuales son las audiencias objetivo a las que apuntan cada una de las opciones Cloud, para poder comprender en forma más completa la propuesta de valor de Windows Azure.

La opción Infrastructure as a Service, o IaaS, tiene por audiencia objetivo al sector de IT de una empresa, que puede concentrar sus tareas en la administración de los componentes OS y Application Stack.

La opción Platform as a Service, o PaaS, tiene por audiencia objetivo al sector de desarrollo de aplicaciones de una empresa, dado que tiene una plataforma de desarrollo que le permite desarrollar y hacer testing en forma local, además de contar con un conjunto completo de herramientas de desarrollo.

La opción Software as a Service, o SaaS, tiene por audiencia objetivo al sector de usuarios de una empresa,  dado que cuenta con las aplicaciones que necesitan para las operaciones diarias hosteadas en La Nube.

¿ Porqué considerar Windows Azure para mi aplicación ?

CloudEl proceso de análisis necesario para determinar si una aplicación dada puede ser llevada a La Nube es complejo, por lo tanto, acá solamente intentaré comentar brevemente los puntos principales que formarían parte de tal tipo de análisis.

Para poder focalizar mejor, plantearé el análisis en forma de un breve cuestionario o checklist de evaluación para Cloud.

¿ El negocio al que mi aplicación atiende tiene una demanda predecible pero cambiante de requerimientos de procesamiento y/o almacenamiento a lo largo del mes/trimestre/año ?

Un ejemplo permitirá ver más claramente lo destacado de esta pregunta. Supongamos que mi aplicación calcula sueldos, o costos. Durante unos pocos días en el mes, la aplicación tendrá un pico de demanda importante de procesamiento y almacenamiento, para luego hacer muy poco el resto del mes.

En forma similar, aparecen picos adicionales en los meses de pago de aguinaldos y de vacaciones (para el caso de sueldos), que se suman al pico propio del mes.

En el caso de una aplicación de costos, se presenta un pico adicional al comienzo del año fiscal, en que aparece la demanda adicional del cálculo de los costos presupuestados, que se ha de sumar al pico propio del mes.

Es evidente que la demanda es predecible, pero es muy cambiante: un pico importante de demanda en un intervalo corto del mes, para luego entrar en una meseta de demanda también bastante predecible.

Si mi aplicación (y el negocio que atiende) tiene este tipo de característica de demanda predecible pero cambiante, Cloud podría ser una alternativa a evaluar.

¿ El negocio al que mi aplicación atiende tiene una demanda no predecible de requerimientos de procesamiento y/o almacenamiento a lo largo del mes/trimestre/año ?

Supongamos que tenemos una aplicación que presupuesta costos y precios de servicios de organización de eventos, como casamientos, cumpleaños, reuniones de negocios, etc.

La empresa cuenta que una variedad de proveedores de servicios de catering, música y entretenimientos, decoración, filmación, etc., que le permite vender servicios muy diversos, de volumen y ocurrencia muy diversa y poco predecible, desde un cumpleaños para 50 personas, un casamiento para 300 personas, o una reunión de ventas para 2000 personas. En general, en verano hay alguna caída esperable del negocio, por lo tanto, el departamento de venta posee un plan que compensa durante el resto del año.

El mismo plan de ventas también contempla que algunos eventos se contratan y luego se cancelan por diversas razones, por lo que el departamiento asume un porcentaje de sobreventa para compensar por este efecto. En una semana dada se superpone una cantidad variable de eventos, con características y tamaños también poco predecibles.

Si mi aplicación (y el negocio que atiende) tiene este tipo de característica de demanda poco predecible, Cloud podría ser una alternativa a evaluar.

¿ El negocio al que mi aplicación atiende tiene necesidades de un nivel de disponibilidad de tres 9s (un mínimo de 99,9% de disponibilidad), a un precio razonable ?

Mi negocio opera 24 horas al día, los 365 días del año, y para poder operar, necesita una aplicación que esté igualmente disponible para poder atenderlo.

En este contexto, una disponibilidad de 99,9% implica que en un año entero de operación, solamente son “tolerables” un total de 8 horas y 42 minutos sin servicio, por todo concepto, ya sea paradas programadas (mantenimiento, updates, hot fixes, service packs, etc.) como no programadas (incidentes).

El beneficio se multiplica si esta disponibilidad se puede obtener a un precio razonable.

Si mi aplicación (y el negocio que atiende) tiene este tipo de requerimiento de nivel de disponibilidad a precio razonable, Cloud podría ser una alternativa a evaluar.

¿ El negocio al que mi aplicación atiende requiere un business continuity plan tal que la arquitectura de la aplicación debe ser distribuida, flexible y fault-tolerant ?

El proceso de Business Continuity Management brinda un marco de referencia para asegurar la resiliencia de nuestro negocio ante cualquier eventualidad, es decir, cualquier evento adverso.

Este proceso implica una serie de pasos, el primero de los cuales es “Entender las vulnerabilidades de mi negocio”.

Esto implica que la capacidad de poder ejecutar las operaciones del negocio no pueden verse afectadas por ningún factor, como por ejemplo, que la aplicación que soporta a mi negocio posea puntos únicos de falla en su arquitectura.

Aún si se considerase hostear dicha aplicación en La Nube, no sería prudente que toda la capacidad de ejecución de la aplicación esté concentrada en La Nube, porque, de ser así, si el evento adverso implica un impedimento en el acceso de Internet, no tenemos disponibilidad de la aplicación por falta de acceso, aunque el servicio hosteado en La Nube esté operando en forma normal.

Esto implica que la arquitectura de Cloud a elegir debería permitirnos, de ser necesario, diseñar una sola aplicación que parte de la misma puede ejecutarse On-Premises, y otra parte en La Nube, y que cosas como la seguridad federada de las diversas partes de la aplicación sea a la vez sencilla de administrar, configurar y mantener, y por su parte, altamente segura y confiable.

Si mi aplicación (y el negocio que atiende) tiene este tipo de requerimiento de arquitectura, derivado de un conjunto de requerimientos de mi Business Continuity Plan, Cloud podría ser una alternativa a evaluar. Es importante destacar que no todos los proveedores de servicios de PaaS (Platform as a Service) ofrecen el mismo nivel de beneficios en este aspecto, destacándose Windows Azure por sus ventajas respecto de otros proveedores.

¿ El negocio al que mi aplicación atiende requiere de escalabilidad elástica de procesamiento y/o escalabilidad elástica de almacenamiento, ya sea almacenamiento elástico en un modelo de datos relacional, como almacenamiento elástico de file system ?

Este tipo de requerimiento es bastante más complejo de lo que parece, dado que involucra muchos elementos, como por ejemplo, que la arquitectura de la plataforma Cloud a elegir sea capaz de escalar en forma fluida y continua, en vez de hacerlo en saltos, y a su vez, que el proceso de procurement y allocation de escalabilidad elástica debe ser sencillo, flexible y dinámico, como así también razonable desde el punto de vista económico-financiero.

Si mi aplicación (y el negocio que atiende) tiene este tipo de requerimiento de escalabilidad elástica, Cloud podría ser una alternativa a evaluar.

Para redondear este breve análisis, vale la pena destacar que un análisis completo para determinar si una solución dada es candidata para Windows Azure, suele involucrar una cierta cantidad amplia de aspectos, como económico-financieros, de arquitectura, de negocios, legales, y otros, por lo tanto, sería recomendable encarar un proyecto para realizar dicha evaluación.

Antes de lanzarse a llevar a cabo dicho proyecto, es conveniente indicar que tendría sentido tal proyecto para el caso que en una evaluación preliminar, en la aplicación en cuestión se han identificado como probables varios de los puntos destacados en este post, y no solamente uno o dos.