Replicando una aplicación tradicional a Windows Azure I: Base de Datos

ABSTRACT

Esta es una serie de post en la que exploraremos las condiciones que deben tener las aplicaciones web para poderse ejecutar desde Windows Azure, bien sea porque se requiere hacer una migración, o porque se quiere tener las dos versiones (hosting tradicional y cloud computing) para una aplicación dada. Este es el post 1/3 y mira los aspectos esenciales a tener en cuenta en lo referido a bases de datos. Los siguientes dos hablarán de la capa de negocios, y de la interfaz gráfica como tal.1

Nivel: 100-200 Básico

El rango de opciones para tener una aplicación que se comporte igual de bien tanto en Windows Azure como en servidores tradicionales, depende mucho del tipo de aplicación que se tenga. En esta serie de posts, estaré tratando únicamente aplicaciones web (también en Azure se pueden desplegar servicios destinados a ser consumidos por clientes inteligentes, móviles, a través de TCP, etc).

Las aplicaciones Web estándar, generalmente tienen la siguiente distribución: Una base de datos (Sql Server, Oracle, etc), una capa de acceso a datos (Entity Framework,LINQ2SQL, ADO.NET, Hibernate, etc) , una capa de negocio (uno o varios proyectos de tipo Class Library) y una capa de presentación conformada por WebForms.

En este post específico, estaremos observando qué pasa primero con la base de datos:

Base de datos

SQL Server

Si la base de datos viene siendo SQL Server o alguna de sus variantes (Como SQL Compact, SQL Express, etc), nos encontraremos con el caso más sencillo a desplegar en Windows Azure, donde como saben el acceso es casi transparente para las aplicaciones que usan estas variaciones.

Los temas que deberíamos tener en cuenta en este caso serían sobretodo aquellos que tienen que ver con escenarios muy específicos como:

1. Consultas distribuidas (no son soportadas)

2. Tamaño máximo por Base de datos de 150GB

3. El escenario actual de SQL Azure está completamente enfocado a almacenamiento transaccional y reportería. No tenemos aún servidores de integración ni BI en SQL Azure. Solo OLAP y Reporting. Sin embargo esto no impide que servidores externos a Windows Azure puedan conectarse a las bases de datos de SQL Azure para manipular su información.

4. La estructura interna e implementación física de SQL Azure es distinta a la de SQL Server; sin embargo para los clientes esto es totalmente transparente, pues SQL Azure ofrece la interfaz TDS que soporta perfectamente las cadenas de conexión tradicionales, así como el T-SQL que todos conocemos. De esta manera podremos acceder a la DB a través de ADO.NET, OLEDB, ORMs como NHibernate, LINQ, Entity Framework y muchos otros.

Otros temas más fáciles de solucionar se pueden arreglar automáticamente a través del Sql Azure Migration Wizard

Otros Motores Free

Si la base de datos se encuentra en otros motores free como MySql, tendremos una limitante total y es el hecho de que para poder instalar un MySQL en Windows Azure, es necesario usar el VM Role de Windows Azure, que permite crear una máquina virtual a la cual le adicionamos un disco duro virtual (VHD) que tiene la configuración previa que le hemos hecho. Esta configuración previa entonces puede incluir la instalación de MySQL por nuestra parte antes de agregar el VHD. Sin embargo, los VM Role son stateless. Esto quiere decir que si por algún motivo la máquina ha de ser reiniciada, todos los cambios generados desde la distribución del VHD se perderían. Situación nada conveniente cuando se tiene la DB instalada en una instancia. En un ambiente de Web Roles y Worker Roles, esto no es un inconveniente, pues su única función es operar y no almacenar. El almacenamiento está en SQL Azure. Pero si en el VM Role ponemos una DB, con cada reinicio, aunque la DB aparezca instalada, estará restaurada a su condición inicial.

Una de las próximas características que estaremos liberando en Windows Azure, son VM Roles persistentes que permitan instalar servidores de Sharepoint, Biztalk, y herramientas de terceros como MySQL y hasta otros sistemas operativos como Linux.

Si se implementasen los VM Roles persistentes s instaláramos por ejemplo MySQL, tendríamos una complejidad adicional y estaríamos desperdiciando ciertas características de nuestra plataforma.

Cuando tenemos un servidor como MySql, que es gratuito, no tendremos ningún problema en instalarlo en un VM Role de Windows Azure. Esto se logra haciendo una instalación del MySQL en una máquina virtual local, y luego subiendo el disco duro de esta máquina virtual a Windows Azure, donde quedará desplegada para ser accedida desde cualquier parte del mundo. Como se aprecia, ya de entrada hay una complejidad y es el proceso de preparar la máquina virtual y luego subirla a Windows Azure.

Otros problemas se presentan cuando nuestra base de datos MySql comienza a requerir escalabilidad. Es así como si la máquina en la que habíamos instalado el MySql ya no es suficiente para los requerimientos de nuestros usuarios, habremos de entrar a una operación manual de migración hacia una máquina más grande.

Sql Azure está diseñado para auto escalar los recursos que necesita, de acuerdo a la demanda por parte de los usuarios. Es así, como automáticamente se administra la memoria, discos, etc., para brindar un funcionamiento óptimo.

Por otro lado, dado que la única opción para instalar MySql sería en un VMRole, entonces necesitaríamos entrar a ejecutar operaciones administrativas adicionales a las que requeriríamos si usáramos solo SQL Azure. En SQL Azure nos desentendemos de la administración del sistema operativo, sus parches, sus actualizaciones, etc. Solo nos enfocamos en usar y mejorar la base de datos. Pero el VM Role al estar más cerca a la Infraestructura como Servicio (IaaS) que a la Plataforma como Servicio (PaaS) requiere un trabajo manual que en SQL Azure se puede omitir completamente.

Todo esto sin mencionar que no habría un SLA para la MySQL, mientras que para SQL Azure si hay y es de 99.99%

Recomendación: Migrar la DB a SQLAzure

Otros motores no Free

Otros motores no free, como Oracle se podrían instalar en Windows Azure, con las mismas consideraciones de los motores free. Pero adicionalmente le deberíamos sumar otra complejidad, y es que por lo general estos productos aún no tienen definida una licencia específica para ser instalados en esquemas de Cloud Computing como Windows Azure, por lo cual se podría entrar en conflictos legales al desplegar un servidor de estos en la nube. Primero ud. Debería consultar con su proveedor e investigar alrededor de este tema.

Recomendación: Migrar la DB a SQLAzure.

Conclusión:

Una aplicación web que se pueda desplegar fácilmente entre ambientes tradicionales y Windows Azure, debería emplear para su DB (si es que usa DB), un esquema SQL Server. Luego, en la evolución hacia la nube, este SQL Server debería migrarse a SQL Azure (las aplicaciones tradicionales se pueden poner a apuntar a la nube y seguirían funcionando perfectamente) y finalmente la aplicación como tal se pasaría de los servidores tradicionales a la nube, sin tener que hacer cambios sobre la DB. Recordemos que operaciones de Servicios de Integración de Datos, Análisis y Minería siguen estando disponibles a través de conexiones de servidores externos que tengan estas funcionalidades, a la nube.

Este es el post 1/3 y mira los aspectos esenciales a tener en cuenta en lo referido a bases de datos. Los siguientes dos hablarán de la capa de negocio y de la interfaz gráfica como tal.