Fast tracktothecloud nestorrequesens-itequia-20110331

748 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
748
On SlideShare
0
From Embeds
0
Number of Embeds
12
Actions
Shares
0
Downloads
6
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Fast tracktothecloud nestorrequesens-itequia-20110331

  1. 1. Recomendaciones para eldesarrollo en MicrosoftAzure Marzo de 2011 Néstor Requesens | nestor.requesens@itequia.com Team Leader en Itequia
  2. 2. Índice1. Itequia2. Mapa tecnológico3. Escenarios prácticos para ISV4. 8 Consideraciones de diseño5. 8 «Best practices» para el desarrollo en Azure6. Windows Azure Platform AppFabric7. Conclusiones: Azure – Not to Azure
  3. 3. La especialización como garantía de éxito «Nada se sabe bien sino por medio de la experiencia» Sir Francis Bacon
  4. 4. Índice1. Itequia2. Mapa tecnológico3. Escenarios prácticos para ISV4. 8 Consideraciones de diseño5. 8 «Best practices» para el desarrollo en Azure6. Windows Azure Platform AppFabric7. Conclusiones: Azure – Not to Azure
  5. 5. Mapa tecnológico
  6. 6. Índice1. Itequia2. Mapa tecnológico3. Escenarios prácticos para ISV4. 8 Consideraciones de diseño5. 8 «Best practices» para el desarrollo en Azure6. Windows Azure Platform AppFabric7. Conclusiones: Azure – Not to Azure
  7. 7. Escenarios prácticos para ISVCloud Storage en aplicaciones internas (1) Posible primer paso al mundo del cloud computing Cloud Storage Windows Azure Storage Ejemplo: Aplicación que actualmente hace App Server backups «on premise» puede hacer backups «on cloud» SQL Azure Ejemplo: Aplicación que necesita compartir un conjunto de tablas relacionales puede Users Infraestructura interna Infraestructura cloud hacerlo en la nube
  8. 8. Escenarios prácticos para ISVCombinar aplicaciones Cloud y aplicaciones internas (2) Windows Azure & SQL Azure Inicialmente puede no tener sentido App Server migrar millones de lineas de codigo a la Cloud App nube... ...pero si puede tener sentido Cloud StorageUsers desarrollar las nuevas funcionalidades en la nube Ejemplo: Aplicación que en momentos Storage Server puntuales puede beneficiarse de mayor potencia de CPU o mas memoria Infraestructura interna Infraestructura cloud
  9. 9. Escenarios prácticos para ISVCrear una versión SaaS de nuestro producto (3) Beneficios para los clientes SaaS: • No inversión inicial en la compra de servidores oSaaS Customer licencias (menor riesgo) • Pago por uso (ejemplo: pago por usuario/mes) • Reducción en costes de deployment Cloud App and Storage • ...On-pem Customers 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 App Server Infraestructura interna Infraestructura cloud • Mejor aprovechamiento de capacidades HW
  10. 10. Índice1. Itequia2. Mapa tecnológico3. Escenarios prácticos para ISV4. 8 Consideraciones de diseño5. 8 «Best practices» para el desarrollo en Azure6. Windows Azure Platform AppFabric7. Conclusiones: Azure – Not to Azure
  11. 11. Consideraciones de diseño¿Donde ha de vivir nuestra aplicación?¿Tendremos que ejecutar nuestra ¿Como accede nuestra aplicación a laaplicación de forma interna y externa configuración?simultáneamente? • No podemos acceder al registro en la nube • web.config, app.config no se pueden¿Tendremos que condicionar el código cambiar en tiempo de ejecución.de nuestra aplicación? • Utilizar Service Configuration u otros gestores dinámicos de configuración. if (WeAreInTheCloud == true) { } //Do something ¿Utiliza nuestra aplicación el sistema else { //Do something else de ficheros? }
  12. 12. Consideraciones de diseño¿Donde ponemos nuestros datos? (Storage)SQL Azure es un subconjunto de SQL Blobs: Máx. 1TB por BLOBServer 2008 Estructura simple para almacenar datos multimediaPara migrar un esquema a SQL Azure Tables: Máx. 100TB por Tablapodemos utilizar herramientas como «Tablas simples» no relacionalesSQL Azure Migration Wizard Queues: Su uso principal es permitirLimite Máx. 50 GB por Base de datos comunicación estructurada entre «Web Role» y «Worker Role»
  13. 13. Consideraciones de diseño¿Cómo monitorizamos nuestra aplicación? La API de Windows Azure ofrece los ingredientes necesarios para monitorizar nuestra aplicación. Definir que información es necesaria en¿Qué hacemos cuando algo va mal caso de crisis y que información es necesaria para monitorear elen nuestra aplicación? rendimiento normal de la aplicación.En Azure no tendremos acceso directo a:• Ficheros de log Desarrollar servicios para poder obtener• Escritorio remoto estos datos bajo demanda o de• Diagnósticos del sistema manera planificada.
  14. 14. Consideraciones de diseño¿Dónde ponemos el estado y la cache?Por norma general pensar en modo ¿Como usamos la sesión?«stateless» es mejor en el mundo Azure.Tenemos que ver nuestra aplicacióncomo distintas instancias y no comouna sola aplicación.¿Como compartimos el estado y lacache?• Utilizar «local storage» no será valido en caso de tener múltiples roles.• Tendremos que pensar en usar SQL Azure o Azure Azure nos ofrece mecanismos para Storage para cualquier escenario distinto de guardar la sesión en Azure Storage. «single-instance». Utilizar: TableStorageSessionStateProvider
  15. 15. 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 APIAzure Developer Portal ofrece unsubconjunto de las funcionalidades que Podemos guardar nuevo código ytenemos para hacer «deployments». configuraciones en Azure Storage
  16. 16. Consideraciones de diseño¿Cómo hacemos backup?Aunque los datos están replicados 3 SQL Azure todavía no ofrece unaveces, podemos perder datos por estrategia para hacer backups.culpa de fallos en nuestra aplicación opor 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
  17. 17. Consideraciones de diseño¿Cómo escalaremos nuestra aplicación? Para nuestros servicios deberíamos desarrollar un mecanismo que nos alerte cuando debemos escalar. Podremos utilizar la API de Service La escalabilidad es una de Management para ejecutar (o quitar) las razones de ser de Azure instancias. Azure ofrece soluciones al escalado, El tamaño de maquina virtual pero solo nosotros podemos escogido jugará un papel importante determinar como y cuando escalar. en las decisiones de escalado.
  18. 18. 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
  19. 19. Índice1. Itequia2. Mapa tecnológico3. Escenarios prácticos para ISV4. 8 Consideraciones de diseño5. 8 «Best practices» para el desarrollo en Azure6. Windows Azure Platform AppFabric7. Conclusiones: Azure – Not to Azure
  20. 20. «Best practices» para el desarrollo en Azure Validar la Ejecutar como Las buenas Actualizar al compatibilidad de mínimo 2 practicas de SOA máximo las nuestro proyecto instancias para se adaptan tecnologias con Azure des de aplicaciones de perfectamente a Microsoft antes el principio alta Windows Azure de migrar a Azure disponibilidad (Azure SLA)
  21. 21. «Best practices» para el desarrollo en Azure Migrar las Aplicaciones «Data center Código y datos capas de las «Sateless» affinity» en el mismo aplicaciónes sitio de una en una ...y si hemos de Usar «affinity guardar el estado groups» para Evitar trafico ...y de forma inecesario entre consolidada hacerlo con hosting, storage, mecanismos bases de datos,... Azure y nuestra Azure organización
  22. 22. Índice1. Itequia2. Mapa tecnológico3. Escenarios prácticos para ISV4. 8 Consideraciones de diseño5. 8 «Best practices» para el desarrollo en Azure6. Windows Azure Platform AppFabric7. Conclusiones: Azure – Not to Azure
  23. 23. ¿Que es AppFabric: el lio de nombres?Marketplace DataMarket Applications 2007- Internet Service Bus CompositeFrameworks Caching App July 2008 - Project Zurich AccessSecurity Control ConnectIntegration Service Bus Integration (BizTalk) 2008 Net Services (como parte de Relational Azures Services Platform)Data Database DataSync ReportingCompute Web Role Worker Role VM Role 2009 - Windows Server AppFabric Content DeliveryStorage Table Storage Blob Storage Queue Drive NetworkNetworking Connect Finally - Windows Azure Platform Appfabric
  24. 24. 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
  25. 25. Índice1. Itequia2. Mapa tecnológico3. Escenarios prácticos para ISV4. 8 Consideraciones de diseño5. 8 «Best practices» para el desarrollo en Azure6. Windows Azure Platform AppFabric7. Conclusiones: Azure – Not to Azure
  26. 26. Azure – Not to Azure Aplicaciones que requieren proximidad a otras aplicaciones Para todo lo demás… concretas Aplicaciones que necesitan mucha agregación de datos Aplicaciones en las cuales se usan muchas herramientas de tercerosAplicaciones que requieran instalar componentes en el servidor
  27. 27. Recomendaciones para eldesarrollo en MicrosoftAzure Marzo de 2011 Néstor Requesens | nestor.requesens@itequia.com Team Leader en Itequia

×