Windows Azure - Uma Plataforma para o Desenvolvimento de Aplicações


Published on

A plataforma Windows Azure abre espaço a desenvimento de aplicações utilizando o novo paradigma: "A Nuvem". Aplicações escaláveis, redundantes, e mais próximas do utilizador final. Isto tudo utilizando como base os conhecimentos que já tem e o novo Visual Studio 2010.

Published in: Technology
1 Like
  • Be the first to comment

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

No notes for slide
  • You can draw the comparison between the desktop/server OS and the cloud OS. The desktop abstracts away things like printers, display drivers, memory etc. So you only have to worry about building your desktop application. The Cloud OS does this for the cloud, but instead of printers, display drivers etc. it does it across multiple servers, networking compoents, provides a “cloud file system” for storage, a programming environment etc.The last 2 points:1. Interoperability – the storage etc uses REST based protocols. Additionally, we support things like PHP, MySQL, Apache, etc. with the release of inter-role communication.2. Designed for Utility Computing – Rather than charging a per-seat license etc. you will be charged by consumption. The pricing is available on the website.
  • Windows Azure is not about letting you setup and run an entire OS with your application.Instead it is about running your service, using commodity servers that are managed by Microsoft. Microsoft take care of deploying your service, patching the OS, keeping your service running, configuring hardware, infrastructure etc. All of this is automated.All you need to worry about is writing the service.
  • Here are some of the features we’ll walk through in the next few minutes.
  • 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,, 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 and now TCP ports – outbound are any TCP Socket, (but not UDP).All servers are stateless, and all public access is through load balancers. You can use inter-role communication to communicate point to point between roles (non-public, non-load balanced).
  • 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.Drives – an NTFS mountable drive backed over blob storage. This enables interop and traditional file system capabilities over blob storage backingTables – 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.
  • Remind them the cloud is all the hardware across the board.Point out the automated service management,
  • Developer SDK is a Cloud in a box, allowing you to develop and debug locally without requiring a connection to the cloud. You can do this without Visual Studio as there are command line tools for executing the “cloud in a box” and publishing to the cloud.There is also a separate download for the Visual Studio 2008 tools, which provide the VS debugging and templates.Requirements are any version of Visual Studio (including Web Developer Express), Vista SP1, Win7 RC or later.
  • There is a small API for the cloud, that allows you to do some simple things, such as logging, reading from a service configuration file, and local file system access. The API is small and is easy to learn.
  • To allow us to deploy and operate your service in the cloud, we need to know the structure of your service. You describe your service and operating parameters through the use of a service model. This service model tells us which roles you have, any service configuration and can also describe the number of instances you need for each role within your service. Whilst this model is simple today, the model will be extended to allow you to describe a much richer operational model – e.g. allowing scale-out and scale-down based upon consumption and performance.This file is also where you would store configuration that may change once deployed. Since all files within a role are read-only, you cannot change either an app.config or web.config file once deployed, the only configuration you can change is in the service model.
  • Key points here are that all external connections come through a load balancer. If you are familiar with the previous model, you will notice that two new features are diagrammed here as well, namely inter-role communication (notice there is no loadbalancer) and TCP ports directly to Worker Roles (or Web Roles). We will still use the storage to communicate async and realiably via queues for a lot of options. However, inter-role communication fills in when you need direct synchronous comm.
  • Key points here are that all external connections come through a load balancer. If you are familiar with the previous model, you will notice that two new features are diagrammed here as well, namely inter-role communication (notice there is no loadbalancer) and TCP ports directly to Worker Roles (or Web Roles). We will still use the storage to communicate async and realiably via queues for a lot of options. However, inter-role communication fills in when you need direct synchronous comm.
  • 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 project.Although the API is REST, there is a supported .net storage client in the SDK that you can 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 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.
  • So how do we do the automated deployment & manage your service.1st – remember the service metadata tells us exactly what we need to deploy and how many instances etc.There is no OS footprint, so your service can be copied around the data center without any configuration requirements.The OS itself is on a VHD, so it was copied to the hardware.The hardware itself was also booted from VHD, which was also copied around.Therefore, to put a new version of your software, or the OS that hosts it, all we need to do is copy it to a new machine and spin it up. It also means we can patch and test the OS offline. No live patching!!!
  • Now your service is deployed, how do YOU monitor it?With the diagnostics and monitoring API, you can deploy your roles and remotely configure what sources your instance should monitor. This configuration can be by role or by instance. You can configure standard tracing in your application, monitor the event logs or performance counters, collect log files like IIS logs or any log file as well as crash dumps of your application. Since this information can be pushed into your storage account on demand or on a scheduled basis, it is both highly scalable as well as easily manageable from outside of Windows Azure.
  • 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?
  • Windows Azure - Uma Plataforma para o Desenvolvimento de Aplicações

    1. 1.<br />11ª Reunião Presencial - 19/06/2010<br />Windows AzureUma Plataforma para o Desenvolvimento de AplicaçõesPedro Rosa<br />
    2. 2. Pedro Rosa - DeepDiveIn<br />Contacto<br />+351 961 624 203<br />LinkedIn<br /><br />Twitter<br /><br />
    3. 3. Agenda<br />Why Cloud?<br />What is it anyway?<br />How can I benefit?<br />
    4. 4. Business Drivers for IT Projects<br />Increase market share and revenue<br />Investing in product development and customer facing interaction channels<br />Increase efficiency and lower TCO<br />Investing in technologies and processes to drive efficiency and lower cost through optimization<br />
    5. 5. Control<br />High<br />Low<br />Economy of Scale<br />Low<br />High<br />Control vs. Economy of Scale<br />
    6. 6. Build vs. Buy<br />Control<br />High<br />Low<br />Economy of Scale<br />Low<br />High<br />This is not new…<br />
    7. 7. On premises vs. in the cloud<br />Control<br />High<br />Low<br />Economy of Scale<br />Low<br />High<br />This is new…<br />
    8. 8. Leveraging Economy of Scale<br />Ratio between $ buckets for <br />medium and very large DC<br />Source: Above the Clouds: A Berkeley View of Cloud Computing<br />
    9. 9.
    10. 10. Short distance access to hydroelectricpower<br />Long distance transmission over the grid<br />Energy generation based on expensive resources<br />Location Matters<br />
    11. 11. Short distance access to hydroelectricpower<br />Price per KWH<br /> 3.6¢ Idaho<br /> 10.0¢ California<br />18.8¢ Hawaii<br />Long distance transmission over the grid<br />Energy generation based on expensive resources<br />Location Matters<br />
    12. 12. Application runs <br />on-premises<br />Buy my own hardware, and manage my own data center<br />Application runs at a hoster<br />Pay someone to host my application using hardware that I specify<br />Application runs using cloud platform<br />Pay someone for a pool of computing resources that can be applied to a set of applications<br />Datacenter Options<br />
    13. 13. Datacenter Options<br />Application runs <br />on-premises<br /><ul><li>Bring my own machines, connectivity, software, etc.
    14. 14. Complete control and responsibility
    15. 15. Upfront capital costs for the infrastructure</li></ul>Application runs at a hoster<br /><ul><li>Rent machines, connectivity, software
    16. 16. Less control, but fewer responsibilities
    17. 17. Lower capital costs, but pay for fixed capacity, even if idle</li></ul>Application runs using cloud platform<br /><ul><li>Shared, </li></ul> multi-tenant environment<br /><ul><li>Offers pool of computing resources, abstracted from infrastructure
    18. 18. Pay as you go</li></li></ul><li>X as a Service<br />
    19. 19. IaaS<br />User gets access to a pool of resources through VM abstraction<br />User needs to patch/maintain the system<br />Scales only if stateless or if well partitioned<br />E.g. Amazon EC2<br />
    20. 20. PaaS<br />User gets access to a pool of resources through a programming model <br />System is managed by the cloud provider<br />Platform (programming model) can provide scalability<br />E.g. Windows Azure, Google App Engine<br />
    21. 21. SaaS<br />User gets access to applications<br />System is completely managed by the cloud provider<br />Cloud provider may offer customization and extensibility options<br />E.g., Microsoft BPOS, Google Apps<br />
    22. 22.
    23. 23. Need for Elasticity<br />
    24. 24. Wall Street firm on Amazon EC2<br />3000--<br />Number of EC2 Instances<br />300 CPU’s on weekends<br />300 --<br />Thursday<br />4/23/2009<br />Friday<br />4/24/2009<br />Sunday<br />4/26/2009<br />Monday<br />4/27/2009<br />Tuesday<br />4/28/2009<br />Saturday<br />4/25/2009<br />Wednesday<br />4/22/2009<br />
    25. 25. Scale through PaaS<br />The platform abstracts the physical infrastructure<br />Ability to scale built into the programming model<br />Google’s AppEngine<br />Microsoft’s Windows Azure<br />Amazon’s elastic MapReduce<br />…<br />
    26. 26. What is Windows Azure?An Operating System for the cloud<br />Hardware Abstraction across multiple servers<br />Distributed Scalable, Available Storage<br />Deployment, Monitoring and Maintenance<br />Automated Service Management, Load Balancers, DNS<br />Programming Environments<br />Interoperability<br />Designed for Utility Computing<br />
    27. 27. Why Windows Azure?<br />OS Takes care of your service in the cloud<br />Deployment<br />Availability<br />Patching<br />Hardware Configuration<br />You worry about writing the service<br />
    28. 28. What is Windows Azure?Features<br />Automated Service Management<br />Compute<br />Storage<br />Developer Experience<br />
    29. 29. What is Windows Azure?<br />Compute<br />Storage<br />Developer<br />SDK<br />
    30. 30. Developer<br />Tools<br />What is Windows Azure?<br />Compute<br /><ul><li>.NET 4.0
    31. 31. Server 2008 – 64bit
    32. 32. Full Trust*
    33. 33. Web Role
    34. 34. IIS7 Web Sites (ASP.NET, FastCGI)
    35. 35. Web Services (WCF)
    36. 36. Worker Role
    37. 37. Stateless Servers
    38. 38. Http(s), TCP </li></ul>Storage<br />
    39. 39. Developer<br />Tools<br />What is Windows Azure?<br />Storage<br /><ul><li>Durable, scalable, available
    40. 40. Blobs
    41. 41. Drives
    42. 42. Tables
    43. 43. Queues
    44. 44. REST interfaces
    45. 45. Can be used without compute</li></ul>Compute<br />
    46. 46. What is Windows Azure?<br />Compute<br />Storage<br /><ul><li>All of the hardware
    47. 47. Hardware Load Balancers
    48. 48. Servers
    49. 49. Networks
    50. 50. DNS
    51. 51. Monitoring
    52. 52. Automated service management</li></ul>Developer<br />Tools<br />
    53. 53. What is Windows Azure?<br />Developer SDK<br /><ul><li>Windows Azure SDK
    54. 54. Local Development Fabric emulates running multiple instances, load-balancing, service API
    55. 55. Local Development Storage emulates blob, tables and queue storage
    56. 56. Command line tools allows integration outside of Visual Studio
    57. 57. Microsoft Visual Studio 2008, 2010 add-in
    58. 58. Provide rich tooling and templates to easily build your application</li></ul>Compute<br />Storage<br />
    59. 59. Windows Azure API<br />All operations are accessed through RoleEnvironment<br />RoleEnvironment Handles<br />Retrieving configuration information<br />LocalResource locations (local disk)<br />Accessing Role information like InstanceEndpoints necessary for inter-role communication<br />Exposes events during instance lifecycle, allowing a chance to respond to topology or config change<br />
    60. 60. Service Models <br />Describes your Service<br /><?xmlversion="1.0" encoding="utf-8"?><br /><ServiceDefinitionname="CloudService1" xmlns=""><br /> <WebRolename="WebRole"><br /> <ConfigurationSettings><br /> <Settingname="AccountName"/><br /> </ConfigurationSettings><br /> <LocalStoragename="scratch" sizeInMB="50"/><br /> <InputEndpoints><br /> <!-- Must use port 80 for http and port 443 for https when running in the cloud --><br /> <InputEndpointname="HttpIn" protocol="http" port="80" /><br /> </InputEndpoints><br /> </WebRole><br /> <WorkerRolename="WorkerRole"><br /> <ConfigurationSettings><br /> <Settingname="AccountName"/><br /> <Settingname="TableStorageEndpoint"/><br /> </ConfigurationSettings> <br /> </WorkerRole><br /></ServiceDefinition><br />
    61. 61. Service Architecture<br />
    62. 62. Service Architecture<br />
    63. 63. demo<br />My First Service (WorkerRole)<br />
    64. 64. Storage<br />Blobs, Drives, Tables, Queues<br />Designed for the cloud<br />3 replicas<br />Guaranteed consistency<br />Accessible directly from the internet via REST API <br />.NET Client library supported<br />Does not require compute<br />Storage account drives unique URL, e.g.:<br />https://<youraccount><br />
    65. 65. Blobs<br />Blobs stored in Containers<br />1 or more Containers per account<br />Scoping is at container level<br />…/Container/blobname<br />$root is special name for root container<br />Blobs<br />Two types, Page and Block<br />Page is random R/W, Block has block semantics<br />Metadata, accessed independently <br />name/value pairs (8kb total)<br />Private or Public container access<br />
    66. 66. Queues<br />Simple asynchronous dispatch queue<br />Create and delete queues<br />Message:<br />Retrieved at least once<br />Max size 8kb<br />Operations:<br />Enqueue<br />Dequeue<br />RemoveMessage<br />
    67. 67. Tables<br />Entities and properties (rows & columns)<br />Tables scoped by account<br />Designed for billions+<br />Scale-out using partitions<br />Partition key & row key<br />Operations performed on partitions<br />Efficient queries<br />No limit on number of partitions<br />Use ADO.NET Data Services<br />
    68. 68. demo<br />Deploying Services<br />
    69. 69. Service Lifecycle<br />Create service package<br />Binaries + Content + Service Metadata<br />Deploy via web portal or Service Management API<br />Add & remove capacity via web portal or API<br />Deployed across fault domains<br />Upgrade with zero downtime<br />
    70. 70. Automated Service Management<br />You tell us what, we take care of how<br />What<br />Service metadata<br />How<br />Metadata describes service<br />No OS footprint<br />Service is copied to instances<br />Instances were copied to physical hardware<br />Physical hardware booted from VHD<br />All patching is performed offline<br />
    71. 71. Service Monitoring<br />SDK component providing distributed monitoring & data collection for cloud apps<br />Support Standard Diagnostics APIs<br />Trace, Debug normally<br />Manage multiple role instances centrally<br />Scalable<br />Choose what to collect & when to collect it<br />Event Logs, Trace/Debug, Performance Counters, IIS Logs, Crash Dumps, Arbitrary log files<br />
    72. 72. Design Considerations<br />Scale and availability are the design points<br />Storage isn’t a relational database<br />Stateless<br />Stateless front ends, store state in storage<br />Use queues to decouple components<br />Instrument your application (Trace)<br />Once you are on - stay on<br />Think about patching & updates<br />
    73. 73. The CxO Value Proposition<br />Time to Market<br />No upfront CAPEX<br />Instant access to compute resources<br />Total Cost of Ownership <br />CAPEX/OPEX<br />Economy of scale<br />Elasticity<br />Productivity<br />Higher level of abstraction for compute resources<br />Risk Mitigation<br />Allows for trial and error<br />Unpredictable utilization patterns<br />
    74. 74. Cloud Pricing<br />Pricing Options<br />Pay as you go – flexible but unpredictable<br />Flat fees, Quotas, Limits allow for better control<br />Decisions based on business model, predictability, IT budgeting<br />Pricing Dimensions<br />Compute pricing <br /># CPUs (hours deployed vs. hours utilized)<br />Dedicated local storage & memory <br />Bandwidth (inbound, outbound, inter-DC)<br />Can become very pricy for large storages<br />Disk shipments<br />Storage<br />Average used storage capacity vs. , “fixe sized” storage<br />Storage transactions (read, write)<br />Used query time<br />
    75. 75. The Bandwidth Challenge<br />Storage vs. Bandwidth<br />Time and cost of transferring data<br />AWS Import/Export<br />Compute and storage location matters<br />Compute where the data is stored instead of moving the data to the compute resource<br />
    76. 76. The Regulation Challenge<br />Safe Harbor Act<br />Datacenter locations matter<br />Patriot Act<br />Big Brother might get access to your data<br />Industry Regulations<br />E.g. Payment Card Industry Data Security Standard (PCI DSS)<br />
    77. 77. Where to Start?<br />Find a business case first!<br />Compute Scenarios<br />Capabilities with little integration requirements<br />Input  compute  output<br />High scalability/performance requirements<br />Challenging utilization requirements<br />Storage Scenarios<br />Archiving solutions<br />Cross-corporate data sharing<br />Look for capabilities with infrequent compute<br />
    78. 78. Questões?<br />
    79. 79. Patrocinadores desta reunião<br />
    80. 80. Próximas reuniões presenciais<br />19/06/2010 - Junho<br />10/07/2010 - Julho<br />14/08/2010 - Agosto<br />18/09/2010 - SetembroReserva estes dias na agenda! :)<br />
    81. 81. Obrigado!<br />Pedro Rosa<br /><br /><br />