Category Archives: Windows Azure

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

Advertisements

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.