Uno de los mayores problemas a los que se enfrentan muchos proyectos de software en Internet es asegurar su capacidad para escalar. Asegurar que el sistema puede asumir cargas crecientes o incluso manejar picos de carga con naturalidad no es un problema menor.
Estas necesidades de escalabilidad pueden aparecer paulatinamente en el tiempo, de forma que pueda haber tiempo para digerir esta nueva situación; o es posible que de manera eventual aparezcan cargas enormes, en respuesta a algo que ocurre puntualmente o incluso a menudo sin previo aviso.
Existen muchas situaciones de este estilo: de repente la web recibe enlaces de otra web muy popular atrayendo mucho tráfico, o mejora drásticamente su posición en los buscadores y las visitas se multiplican. O la pasarela de SMS, fruto de un jugoso contrato tiene que doblar su capacidad de la noche a la mañana. Provisionar de manera ágil el hardware necesario para hacer frente a este tipo de situaciones no es sencillo.
Otra situación que ocurre a menudo es que los sistemas soportan picos temporales de carga durante determinadas épocas del año o ante eventos concretos. Por ejemplo, una web especializada en la venta de cava, en Navidad multiplica por cien las visitas. O pensemos en el sistema de matriculación de una Universidad que, típicamente, sólo trabaja a pleno rendimiento en el mes de septiembre. Sin embargo debe estar dimensionado para esos picos de demanda, lo que tiene como consecuencia que durante once meses al año nuestra carísima infraestructura está ociosa y desaprovechada.
Un buen ejemplo de esta estacionalidad, concreto y real, se evidencia claramente al observar el gráfico de carga de la página web del campeonato de Wimbledon. La solicitación sobre sus servidores es casi nula todo al año, pero alcanza picos elevadísimos durante la celebración del torneo:
Figura 1.- Carga de la página web del campeonato de Wimbledon
Evidentemente resultaría inaceptable que una empresa no pudiese vender en la época más rentable del año, o que la Universidad no pudiese matricular a sus alumnos en Septiembre. También resulta inaceptable para los usuarios que las aplicaciones no estén disponibles cuando las necesitan. Así aparece un nuevo factor en la ecuación: la alta disponibilidad.
Los típicos patrones de carga ante las que el concepto "Nube" puede ayudar son los siguientes:
- Aplicaciones con "picos" predecibles: como el ejemplo anterior de Wimbledon, en el que se sabe de antemano que la demanda va a multiplicarse enormemente en determinadas épocas o ante eventos concretos. Con una implementación tradicional se desperdiciaría capacidad y generaría gran complejidad para el departamento de TI. En la nube se pueden contratar los recursos necesarios exactamente el tiempo que se necesiten.
- Aplicaciones con "picos" impredecibles: no es posible determinar cuándo van a producirse ni de qué dimensión serán, por lo que dimensionar la infraestructura apropiada no es posible con el esquema tradicional. Además estos picos impactan en el rendimiento y por tanto en el negocio, que puede verse incluso interrumpido. Los servicios Cloud pueden escalarse de inmediato ante una demanda inesperada.
- Aplicaciones de crecimiento rápido: aquellas que crecen mucho en demanda en virtud de un gran éxito entre los usuarios. Escalar y crecer es un gran reto tanto de desarrollo como para el equipo de TI de las empresas. Por ejemplo, la verdadera dificultad de una aplicación como Twitter, que es funcionalmente muy sencilla, es el poder crecer y llegar a gestionar millones de usuarios simultáneos. Albergada en un sistema en la nube puede aumentar su capacidad ilimitadamente a medida que el número de usuarios crece.
- Aplicaciones On-Off: aplicaciones que trabajan y se paran de manera predecible, alternando periodos de inactividad con periodos de trabajo intenso. En el esquema tradicional se desaprovechan mucho las capacidades del sistema, que estarán sobredimensionadas. Con el esquema de la nube se pueden gestionar cambios para aumentar y reducir las capacidades según cada fase, disminuyendo los costes a cero en los periodos sin demanda.
En definitiva, son innumerables las situaciones en las que es vital contar con capacidades de proceso, almacenamiento y ancho de banda que se puedan utilizar según las necesidades de cada momento y que sean, a efectos prácticos, ilimitadas.
Infraestructura, configuración y mantenimiento
Desde el punto de vista de los desarrolladores, el mantenimiento de los "elementos base" que facilitan el despliegue de sus aplicaciones es algo de lo que no deberían tener que preocuparse. Así, la única preocupación que un desarrollador debería tener es la de crear las aplicaciones, y que por tanto, el despliegue fuera igual de fácil tanto para un proyecto pequeño como para uno masivo.
Sin embargo existen cuestiones típicas de infraestructura de las que deben estar pendientes las empresas que mantienen sus propios servidores y centros de datos, como por ejemplo:
- Gestión del Sistema Operativo sobre el que se ejecutan las aplicaciones y servicios.
- Configuración de servicios "base": S.O., servidor de datos, servidor de aplicaciones...
- Gestión de actualizaciones y parches de los servicios "base"
- Diagnóstico de fallos de servicios "base"
- Respuesta a fallos de hardware
- Disponibilidad de capacidad de almacenamiento adecuada, lo que puede llegar a ser muy complejo.
- Monitorización
- Respuesta ante desastres
- Configurar balanceado de carga
- Gestionar incrementos súbitos de tráfico y, por ende, potencia de proceso.
- Etc...
Y esto multiplicado por el número de servidores o máquinas virtuales que tengan disponibles, lo cual es exponencialmente complejo. Todo esto impacta directamente sobre otro importante factor a considerar: loscostes de operación.
Finalmente, otra cuestión que preocupa a todos los responsables de sistemas informáticos es la capacidad para recuperarse ante desastres. No es raro ver empresas que ven peligrar la continuidad de su negocio cuando su "cuarto de servidores" se inunda accidentalmente.
Desplegando las aplicaciones en infraestructuras en la nube es posible despreocuparse de todas estas complejidades, centrándose específicamente en las necesidades funcionales de las aplicaciones, y no en los detalles necesarios para hacerlas funcionar.
En definitiva
¿Por qué mantener y pagar sistemas que sólo trabajan a pleno rendimiento en ciertos momentos?. ¿Por qué tener que pagar por infraestructura que se infrautiliza? ¿Por qué no dejar en manos de expertos la seguridad de los datos, la disponibilidad de las aplicaciones?. ¿Cómo asegurar la redundancia de nuestros datos sin carísimas inversiones?.
Escalabilidad, alta disponibilidad y reducción de costes de operación son las principales promesas de la nube.
Microsoft dispone de una herramienta gratuita para determinar los costes totales de propiedad (TCO) así como el retorno de la inversión (ROI) de una aplicación comparando la opción de gestionarla directamente en una empresa con la de albergarla en la plataforma Windows Azure. Es interesante utilizarla para analizar costes y averiguar lo que más puede interesar según el caso.
No hay comentarios.:
Publicar un comentario