[Code Camp 2009] Cloud Computing - Explorando Windows Azure Services (Carlos Peix + José Mariano Álvarez)


Published on

[Code Camp 2009] Cloud Computing - Explorando Windows Azure Services (Carlos Peix + José Mariano Álvarez)

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • This is the exploding cloud diagram
  • Windows Azure runs on Windows Server 2008 running .NET 3.5 SP1. At MIX09, we opened up support for Full Trust and FastCGI. Full Trust is starred here because while Full Trust gives you access to p/invoke into native code, it is code that still runs in user mode (not administrator). However, for most native code that is just fine. If you wanted to call into some Win32 APIs for instance, it might not work in all instances because we are not running your code under a system administrator account.There are 2 roles in playA web role – which is just a web site, asp.net, wcf, images, css etc.A worker role – which is similar to a windows service, it runs in the background and can be used to decouple processing. There is a diagram later that shows the architecture, so don’t worry about how it fits together just yet.Key to point out the inbound protocols are HTTP & HTTPS – outbound are any TCP Socket, (but not UDP).All servers are stateless, and all access if through load balancers.
  • This should give a short introduction to storage. Key points are its durable (meaning once you write something we write it to disk), scalable (you have multiple servers with your data), available (the same as compute, we make sure the storage service is always running – there are 3 instances of your data at all times).Quickly work through the different types of storage:Blobs – similar to the file system, use it to store content that changes, uploads, unstructured data, images, movies etc.Tables – Semi-structured, provides a partitioned entity store (more on partitions etc. in the Building Azure Services Talk) – allows you to have tables containing billions of rows, partitioned across multiple servers.Queues – Simple queue for decoupling Computer Web and Worker Roles.All access is through REST interface. You can actually access the storage from outside of the data center (you don’t need compute) and you can access storage via anything that can make a HTTP request.It also means table storage can be accesses via ADO.NET Data Services.
  • In this next section, we’ll dig a little deeper on storage.Recall there are 3 types of storage.Recall the design point is for the cloud, there are 3 replicas of data, and we implement guaranteed consistency. In the future there will be some transaction support and this is why we use guaranteed consistency.Access is via a storage account – you can have multiple storage accounts per live id.Although the APU is REST, there is a sample .net storage client in the SDK that you can compile and use within your project. This makes working with storage much easier.
  • BlobsBlobs are stored in containers. There are 0 or more blobs per container and 0 or more containers per account. (since you can have 0 containers, but then you would not have any blobs either)Typically url in the cloud is http://accountname.blob.core.windows.net/container/blobpathBlob paths can contain the / character, so you can give the illusion of multiple folders, but there is only 1 level of containers.Blob capacity at CTP is 50gb.There is an 8k dictionary that can be associated with blobs for metadata.Blobs can be private or public:Private requires a key to read and writePublic requires a key to write, but NO KEY to read.Use blobs where you would use the file system in the past.
  • Queues are simple:Messages are placed in queues. Max size is 8k (and it’s a string)Message can be read from the queue, at which point it is hidden.Once whatever read the message from the queue is finished processing the message, it should then remove the message from the queue. If not the message is returned to the queue after a specific user defined time limit. This can be used to handle code failures etc.
  • Tables are simply collections of Entities.Entites must have a PartitionKey and RowKey – can also contain up to 256 other properties.Entities within a table need not be the same shape! E.g.:Entity 1: PartitionKey, RowKey, firstnameEntity 2: PartitionKey, RowKey, firstname, lastnameEntity 3: PartitionKey, Rowkey, orderId, orderData, zipCodePartitions are used to spread data across multiple servers. This happens automatically based on the partition key you provide. Table “heat” is also monitored and data may be moved to different storage endpoints based upon usage.Queries should be targeted at a partition, since there are no indexes to speed up performance. Indexes may be added at a later date.Its important to convey that whilst you could copy tables in from a local data source (e.g. sql) it would not perform well in the cloud, data access needs to be re-thought at this level. Those wanting a more traditional SQL like experience should investigate SDS.
  • Once you have built and tested your service, you will want to deploy it.The key to deployment and operations is the service model.To deploy – first you build your service, this takes the project output + Content (images, css etc.) and makes a single file. It also creates and instance of your service metadata.Next you would visit the web portal and upload the 2 solution files – from there the “cloud” takes care of deploying it onto the correct number of machines and getting it to run.To increase and decrease capacity today, you would edit the configuration from the web portal.For more than 1 instance, you should be deployed across fault domains, meaning separate hardware racks.In the portal you have a production and staging area, with different urls. You can upload the next version of your project into staging, then flip the switch – which essentially changes the load balancers to point to the new version.
  • Some key things to rememberDesign points are scalability and availability – think it terms of lots of small servers rather than a single BIG server.Table storage is semi-structured – ITS NOT A RELATIONAL DATABASE – IT NEVER WILL BE. THAT IS SDS.Everything is stateless (you can maintain state in table or blob storage if YOU want to)Decouple everything using queues, and write code to be repeatable without breaking anything – in other words design for failure!Instrument and log your application yourself.Work on the idea that once you are on – stay on.How will you patch/update your service once it is switched on?
  • The step-by-step demo script for this demo is included in the Azure Services Training Kit. DEMO SCRIPT: Connecting to SQL AzureDEMO SCRIPT: Creating Objects in SQL Azure
  • [Code Camp 2009] Cloud Computing - Explorando Windows Azure Services (Carlos Peix + José Mariano Álvarez)

    1. 1. Explorando Windows AzureServices<br />Ing. Jose Mariano Alvarez<br />CTO<br />SQL Total Consulting<br />Ing. Carlos Peix<br />Chief Geek<br />Praxia<br />
    2. 2. Cloud Computing<br />La computación en nube es una tecnología que permite ofrecer servicios de computación a través de Internet. <br />
    3. 3. Azureservices<br />
    4. 4. Plataforma Windows Azure<br />Computación<br />Almacenamiento<br />Gestión<br />Base de datos<br />Serviciosgenerales<br />Control de acceso<br />
    5. 5. ¿Qué es Azure?<br />
    6. 6. Un sistema operativo para la nube<br />Abstracción de Hardware de múltiples servidores<br />Almacenamiento distribuido escalable y altamente disponible<br />Gestión automática del servicio, Balanceo de carga<br />Interoperable (REST)<br />Sin licencia, costo por servicio utilizado<br />Datacenters operados por Microsoft<br />
    7. 7. Windows Azure<br />Compute<br />Storage<br />Developer<br />SDK<br />
    8. 8. Compute<br /><ul><li>.NET 3.5 SP1
    9. 9. Server 2008 – 64bit
    10. 10. Full Trust*
    11. 11. Web Role
    12. 12. IIS7 Web Sites (ASP.NET, FastCGI)
    13. 13. Web Services (WCF)
    14. 14. Worker Role
    15. 15. Servidores sin estado
    16. 16. Http(s) </li></ul>Storage<br />Developer<br />Tools<br />Windows Azure<br />
    17. 17. Developer<br />Tools<br />Windows Azure<br />Storage<br /><ul><li>Durable, escalable, disponible
    18. 18. Blobs
    19. 19. Tables
    20. 20. Queues
    21. 21. REST interfaces</li></ul>Compute<br />
    22. 22. Servicio<br />Arquitectura <br />Worker Service<br />Worker role<br />Internet<br />LB<br />Tables<br />Almacenamiento<br />Web Site<br />(ASPX, ASMX, WCF)<br />Web Site<br />(ASPX, ASMX, WCF)<br />Web role<br />(ASPX, WCF)<br />LB<br />Queue<br />Blobs<br />
    23. 23. Almacenamiento<br />Blobs, Tables, Queues<br />Diseñado para la nube<br />3 replicas<br />Consistencia garantizada<br />Accesible por internet mediante REST API<br />Multiples storage account<br />Storage Client en el SDK (Helper)<br />
    24. 24. Blobs<br />0..N Blobs por Containers<br />0..N Containers por cuenta<br />El alcance es a nivel de container<br />http://accountname.blob.core.windows.net/container/blobpath <br />Capacidad 50GB (CTP)<br />Privados o públicos <br />Utilizar Blobs donde usábamos archivos<br />
    25. 25. Queues<br />Simple Cola de envío asincrónica<br />Mensajes<br />Tamaño máximo 8kb<br />Operaciones:<br />Enqueue<br />Dequeue<br />RemoveMessage<br />
    26. 26. Tables<br />Entidades y propiedades (filas & columnas)<br />El alcance es por cuenta<br />Diseñada para miles de millones<br />Escala hacia afuera mediante particiones<br />Partition key y row key<br />Operaciones realizadas en particiones<br />Consultas eficientes<br />No hay límite en el número de particiones<br />ADO.NET Data Services<br />
    27. 27. Ciclo de vida de la aplicación<br />Crear paquete de (publish)<br />Binario + Contenido + Metadata<br />Deployvia web portal<br />Agregar y quitar capacidad viametadata<br />Se actualiza sin perdidad de servicio durante la actualización<br />No se puede usar un Debugger en la nube<br />Eventlogs vía web<br />
    28. 28. Consideraciones de diseño<br />Escalabilidad y disponibilidad son mas importantes.<br />El almacenamiento NO es relacional.<br />Stateless<br />No existe Session ni Application, pero hay providers basados en storage.<br />Usar el colas para desacoplar procesamiento.<br />Cuando se pone en línea, queda en línea.<br />Hay que pensar dos veces en los mecanismos de actualizacion.<br />
    29. 29. Demo<br />
    30. 30. SQL Azure<br />
    31. 31. Extending SQL Data Platform to Cloud<br />Reference Data<br />Business Intelligence<br />Data Sync<br />Reporting<br />SQL Azure Database<br />Symmetric Programming Moel<br />Data Hub Aggregation<br />
    32. 32. Evolución de SQL Azure<br />Evoluc<br />BrowserApplication<br />Application<br />Application<br />BrowserApplication<br />Application<br />ODBC, OLEDB, ADO.Net PHP, Ruby, …<br />REST Client<br />SQL Client*<br />REST Client<br />Cloud<br />Cloud<br />Windows Azure<br />REST (Astoria)<br />Web App<br />ADO.Net + EF<br />REST Client<br />HTTP+REST<br />HTTP+REST<br />HTTP<br />TDS<br />HTTP<br />Windows Azure<br />Web App<br />SQL Client*<br />Data Center<br />Data Center<br />TDS + TSQL Model<br />REST/SOAP + ACE Model<br />SQL Azure<br />OLD SDS<br />
    33. 33. Opciones de bases de datos<br />Value Props:<br />Full h/w control – size/scale<br />100% compatibility<br />Roll-your-own HA/DR/scale<br />Dedicados<br />On-premise<br />Value Props:<br />Auto HA, Fault-Tolerance<br />Friction-free scale<br />Self-provisioning<br />High compatibility<br /> SQL Server or other s/w on-premise<br /> Resource governance @ machine<br /> Security @ DB Server/OS<br />Recursos<br />Hosted<br /> Hosted SQL Server or other<br /> Resource governance @ VM<br /> Security @ DB Server/OS<br />SQL Azure (RDBMS)<br /> Virtual DB server<br />Resource governance @ LDB<br /> Security @ LDB<br />Value Props:<br />100% of API surface area<br />Roll-your-own HA/DR/scale<br />Compartidos<br />Objetivo de SQL AzureV1<br />Bajo<br />Control<br />Alto<br />
    34. 34. SQL AzureDeployment<br />Web Portal<br />(API)<br />DB Script<br />SQL Azure<br />TDS<br />
    35. 35. SQL AzureAcceso<br />Web Portal<br />(API)<br />Your App<br />SQL Azure<br />TDS<br />Change Connection String<br />
    36. 36. Database Replicas<br />Single Database<br />Multiple Replicas<br />Replica 1<br />Single Primary<br />Replica 2<br />DB<br />Replica 3<br />
    37. 37. Demo<br />
    38. 38. Ejemplos de Compatibilidad<br />Alcancepara v1<br />Fuera de alcancepara v1<br />Tables, indexes,views<br />Stored Procedures<br />Triggers<br />Constraints<br />Table variables, session temp tables (#t)<br />…<br />Distributed Transactions<br />Distributed Query<br />CLR<br />Service Broker<br />Spatial <br />Physical server or catalog DDL and views<br />
    39. 39. Administración lógica vs física<br />SQL Azure se focaliza en la administración lógica<br />Schemas<br />Optimización de Query<br />Gestión de seguridad (Logins, Users, Roles)<br />El servicio realiza la gestión física<br />Alta disponibilidad “out of box”<br />Load balancing<br />
    40. 40. Más Información<br />Windows Azure Platformhttp://www.azure.com/<br />Assemblahttps://www.assembla.com/wiki/show/prx-guamini<br />Todos los artefactos de la presentaciónhttp://code.assembla.com/prx-guamini/subversion/nodes/trunk <br />Blogshttp://blog.josemarianoalvarez.com/http://blog.carlospeix.com/<br />
    41. 41. ¿Preguntas?<br />