Recomendaciones para el

desarrollo en Microsoft

Azure

Marzo de 2011

Néstor Requesens | nestor.requesens@itequia.com

Team Leader en Itequia

Índice

1. Itequia

2. Mapa tecnológico

3. Escenarios prácticos para ISV

4. 8 Consideraciones de diseño

5. 8 «Best practices» para el desarrollo en Azure

6. Windows Azure Platform AppFabric

7. Conclusiones: Azure – Not to Azure

La especialización como garantía de éxito

«Nada se sabe bien sino por medio de la experiencia» Sir Francis Bacon

Índice

1. Itequia

2. Mapa tecnológico

3. Escenarios prácticos para ISV

4. 8 Consideraciones de diseño

5. 8 «Best practices» para el desarrollo en Azure

6. Windows Azure Platform AppFabric

7. Conclusiones: Azure – Not to Azure

Mapa tecnológico

Índice

1. Itequia

2. Mapa tecnológico

3. Escenarios prácticos para ISV

4. 8 Consideraciones de diseño

5. 8 «Best practices» para el desarrollo en Azure

6. Windows Azure Platform AppFabric

7. Conclusiones: Azure – Not to Azure

Escenarios prácticos para ISV Cloud Storage en aplicaciones internas (1)

App Server

Cloud Storage

Users Infraestructura interna Infraestructura cloud

Posible primer paso al mundo del cloud computing Windows Azure Storage Ejemplo: Aplicación que actualmente hace backups «on premise» puede hacer backups «on cloud»

SQL Azure Ejemplo: Aplicación que necesita compartir un conjunto de tablas relacionales puede hacerlo en la nube

Cloud Storage

Cloud App

Escenarios prácticos para ISV

Combinar aplicaciones Cloud y aplicaciones internas (2)

App Server

Users

Infraestructura interna Infraestructura cloud

Storage Server

Windows Azure & SQL Azure

Inicialmente puede no tener sentido migrar millones de lineas de codigo a la nube...

Ejemplo: Aplicación que en momentos puntuales puede beneficiarse de mayor potencia de CPU o mas memoria

...pero si puede tener sentido desarrollar las nuevas funcionalidades en la nube

Escenarios prácticos para ISV

Crear una versión SaaS de nuestro producto (3)

SaaS Customer

Infraestructura interna Infraestructura cloud

Cloud App and Storage

Beneficios para los clientes SaaS:

• No inversión inicial en la compra de servidores o licencias (menor riesgo)

• Pago por uso (ejemplo: pago por usuario/mes)

• Reducción en costes de deployment

• ...

On-pem Customers

App Server

Beneficios para los ISV:

• Incremento potencial de ventas ya que el cliente tiene menos riesgo

• Mayor facilidad en «updates» a los clientes. Se pueden actualizar todos al mismo tiempo

• Mejor aprovechamiento de capacidades HW

Índice

1. Itequia

2. Mapa tecnológico

3. Escenarios prácticos para ISV

4. 8 Consideraciones de diseño

5. 8 «Best practices» para el desarrollo en Azure

6. Windows Azure Platform AppFabric

7. Conclusiones: Azure – Not to Azure

Consideraciones de diseño ¿Donde ha de vivir nuestra aplicación?

¿Tendremos que ejecutar nuestra aplicación de forma interna y externa simultáneamente?

¿Tendremos que condicionar el código de nuestra aplicación?

if (WeAreInTheCloud == true) { //Do something } else { //Do something else }

¿Como accede nuestra aplicación a la configuración?

• No podemos acceder al registro en la nube

• web.config, app.config no se pueden cambiar en tiempo de ejecución.

• Utilizar Service Configuration u otros gestores dinámicos de configuración.

¿Utiliza nuestra aplicación el sistema de ficheros?

Consideraciones de diseño ¿Donde ponemos nuestros datos?

SQL Azure es un subconjunto de SQL Server 2008

Para migrar un esquema a SQL Azure podemos utilizar herramientas como SQL Azure Migration Wizard

Limite Máx. 50 GB por Base de datos

(Storage)

Blobs: Máx. 1TB por BLOB Estructura simple para almacenar datos multimedia

Tables: Máx. 100TB por Tabla «Tablas simples» no relacionales

Queues: Su uso principal es permitir comunicación estructurada entre «Web Role» y «Worker Role»

Consideraciones de diseño ¿Cómo monitorizamos nuestra aplicación?

¿Qué hacemos cuando algo va mal en nuestra aplicación?

En Azure no tendremos acceso directo a:

• Ficheros de log

• Escritorio remoto

• Diagnósticos del sistema

Definir que información es necesaria en caso de crisis y que información es necesaria para monitorear el rendimiento normal de la aplicación.

Desarrollar servicios para poder obtener estos datos bajo demanda o de manera planificada.

La API de Windows Azure ofrece los ingredientes necesarios para monitorizar nuestra aplicación.

Consideraciones de diseño ¿Dónde ponemos el estado y la cache? Por norma general pensar en modo «stateless» es mejor en el mundo Azure.

Tenemos que ver nuestra aplicación como distintas instancias y no como una sola aplicación.

¿Como usamos la sesión?

¿Como compartimos el estado y la cache? • Utilizar «local storage» no será valido en caso de

tener múltiples roles.

• Tendremos que pensar en usar SQL Azure o Azure Storage para cualquier escenario distinto de «single-instance».

Azure nos ofrece mecanismos para guardar la sesión en Azure Storage. Utilizar: TableStorageSessionStateProvider

Consideraciones de diseño ¿Cómo hacemos los deployments?

La API de Service Management que nos ofrece Windows Azure ofrece mas funcionalidades.

• Deployments Automáticos

• Cambios dinámicos en la configuración

• Automatizar los scale-ups /scale-downs

Consideremos implementar una GUI para configurar / ejecutar las automatizaciones que implementemos con la API

Podemos guardar nuevo código y configuraciones en Azure Storage

Azure Developer Portal ofrece un subconjunto de las funcionalidades que tenemos para hacer «deployments».

Consideraciones de diseño ¿Cómo hacemos backup?

SQL Azure todavía no ofrece una estrategia para hacer backups.

Aunque los datos están replicados 3 veces, podemos perder datos por culpa de fallos en nuestra aplicación o por error del usuario.

Opciones:

• Usar ADO.NET, ODBC u otras APIs para desarrollar nuestra utilidad de backups.

• Utilizar el Bulk Copy Program (BCP) para copiar de SQL a ficheros.

• Usar SQL Server Integration Services

• Copiar nuestra BD distinta en Azure.

• SQL Azure Data Sync (Labs)

• SQL Azure Migration Wizard

Consideraciones de diseño ¿Cómo escalaremos nuestra aplicación?

La escalabilidad es una de las razones de ser de Azure

Azure ofrece soluciones al escalado, pero solo nosotros podemos determinar como y cuando escalar.

Para nuestros servicios deberíamos desarrollar un mecanismo que nos alerte cuando debemos escalar.

El tamaño de maquina virtual escogido jugará un papel importante en las decisiones de escalado.

Podremos utilizar la API de Service Management para ejecutar (o quitar) instancias.

Consideraciones de diseño ¿Cómo autenticamos / autorizamos?

Normalmente nuestras aplicaciones internas utilizan AD o ADFS para las autenticaciones / autorizaciones.

Opciones Azure:

• Forms Authentication contra Azure Storage o SQL Azure

• Claims-Based Authentication usando Windows Identity Foundation y consultando nuestro AD interno

• AppFabric Access Control

Índice

1. Itequia

2. Mapa tecnológico

3. Escenarios prácticos para ISV

4. 8 Consideraciones de diseño

5. 8 «Best practices» para el desarrollo en Azure

6. Windows Azure Platform AppFabric

7. Conclusiones: Azure – Not to Azure

«Best practices» para el desarrollo en Azure

Validar la

compatibilidad de nuestro proyecto con Azure des de

el principio

Ejecutar como

mínimo 2 instancias para aplicaciones de

alta disponibilidad

(Azure SLA)

Las buenas

practicas de SOA se adaptan

perfectamente a Windows Azure

Actualizar al máximo las tecnologias

Microsoft antes de migrar a Azure

«Best practices» para el desarrollo en Azure

Migrar las capas de las aplicaciónes

de una en una

...y de forma consolidada

Aplicaciones «Sateless»

...y si hemos de

guardar el estado hacerlo con mecanismos

Azure

«Data center affinity»

Usar «affinity groups» para

hosting, storage, bases de datos,...

Código y datos en el mismo

sitio

Evitar trafico inecesario entre Azure y nuestra

organización

Índice

1. Itequia

2. Mapa tecnológico

3. Escenarios prácticos para ISV

4. 8 Consideraciones de diseño

5. 8 «Best practices» para el desarrollo en Azure

6. Windows Azure Platform AppFabric

7. Conclusiones: Azure – Not to Azure

¿Que es AppFabric: el lio de nombres?

Compute

Storage

Data Relational

Database

Integration

Security

Marketplace

Frameworks

Table Storage Blob Storage Queue Drive Content Delivery

Network

VM Role

Networking Connect

Applications DataMarket

Access

Control

Service Bus

Composite App

Caching

Web Role Worker Role

Reporting DataSync

Integration Connect (BizTalk)

2007- Internet Service Bus

July 2008 - Project Zurich

2008 Net Services (como parte de Azures Services Platform)

Finally - Windows Azure Platform Appfabric

2009 - Windows Server AppFabric

Para que nos entendamos...

Middleware “en la nube” para desarrollar, desplegar y gestionar aplicaciones

Solución integrada para extender las capacidades de los servicios en la nube

Un modelo consistente de programación y una libreria de herramientas

Índice

1. Itequia

2. Mapa tecnológico

3. Escenarios prácticos para ISV

4. 8 Consideraciones de diseño

5. 8 «Best practices» para el desarrollo en Azure

6. Windows Azure Platform AppFabric

7. Conclusiones: Azure – Not to Azure

Azure – Not to Azure

Aplicaciones que requieren proximidad a otras aplicaciones

concretas

Aplicaciones que necesitan

mucha agregación de datos

Aplicaciones que requieran instalar componentes en el servidor

Para todo lo demás…

Aplicaciones en las cuales se usan muchas herramientas de terceros

Recomendaciones para el

desarrollo en Microsoft

Azure

Marzo de 2011

Néstor Requesens | nestor.requesens@itequia.com

Team Leader en Itequia