Fast tracktothecloud albertesplugas-mic-productivity-20110331.jpg
Fast tracktothecloud nestorrequesens-itequia-20110331
-
Upload
micproductivity -
Category
Documents
-
view
603 -
download
0
Transcript of Fast tracktothecloud nestorrequesens-itequia-20110331
Recomendaciones para el
desarrollo en Microsoft
Azure
Marzo de 2011
Néstor Requesens | [email protected]
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 | [email protected]
Team Leader en Itequia