Aucune remarque pour cette diapositive
Microsoft Software + Service strategy was developed in respond to customer requests and growing trends in the marketplace. In the messaging and collaboration space, we have found that collaboration applications are increasing becoming mission critical components of a company’s daily operations. Even though many of these companies understand the need to increase the “speed to value” of equipping employee with the latest collaboration tools, their IT department struggles to keep the software up to date. CIOs are faced with the difficult choices of deciding where to spend their limited IT resources: keeping up existing infrastructure, investing in software upgrades, or focused on other LOB applications. In addition, today’s business environment demands IT to generate a high return on investment based on a predictable cost model and avoid the high project based capital expenditures while having the flexibility to react quickly to business growth.
Virer le slide
Note : faire animtextes en bullets + imagePour en savoir plus allezsur www.globalfundationservices.com (GFS : filliale qui gère et opère les datas centers)Key Points:No one has the breadth of cloud servicesOnly Microsoft has a the wide set of cloud services that complements on-premises softwareScript:In addition to our consumer-facing cloud services, Microsoft offers the most complete set of cloud-based solutions to meet your business needs including advertising, communications (email, telephony, meetings), collaboration (document storage, sharing, workflow), business applications (CRM, business productivity), storage, management and infrastructure services. And unique to Microsoft these sets of cloud services complement a full and rich set of on-premise software enabling often times to add cloud functionality to your existing software or move between cloud and on-premises systems.Click:And with BPOS we are seeing quite a bit of momentum of customers moving to the cloud.
SEBMonter plus haut dans la présentation en fonction de la timeline jouée !
Service managementDefine the rules and provide codePlatform deploys, monitors, and manages the serviceStorageSimple storage provided by Windows AzureT-SQL capability delivered through SQL AzureDeveloper experienceFamiliar tools, technologies, languages for MS developersSupport for non-MS technologies, frameworks and toolsIntegration with on-premisesExtend on-premises applications to the cloudFederate identities across cloud applications
AppFabric :Parler oralement de Integration (type Biztalk : pipeline, transform et adapter)Composite App : application WF & WCF
Un système d’exploitation pour le Cloud Voir si on garde dans le timeline
Whether an application runs in the cloud, uses services provided by the cloud, or both, some kind of application platform is required. Viewed broadly, an application platform can be thought of as anything that provides developer-accessible services for creating applications. In the local, on-premises Windows world, for example, this includes technologies such as the .NET Framework, SQL Server, and more. To let applications exploit the cloud, cloud application platforms must also exist. And because there are a variety of ways for applications to use cloud services, different kinds of cloud platforms are useful in different situations. Microsoft’s Windows Azure platform is a group of cloud technologies, each providing a specific set of services to application developers. The Windows Azure platform can be used both by applications running in the cloud and by applications running on local systems. The components of the Windows Azure platform can be used by local applications running on a variety of systems, including various flavors of Windows, mobile devices, and others. Those components include: Windows Azure: Provides a Windows-based environment for running applications and storing data on servers in Microsoft data centers. Microsoft .NET Services: Offers distributed infrastructure services to cloud-based and local applications. Microsoft SQL Azure: Provides data services in the cloud based on SQL Server. Each component of the Windows Azure platform has its own role to play. This overview describes all four, first at a high level, then in a bit more detail. While none of them are yet final—details and more might change before their initial release—it’s not too early to start understanding this new set of platform technologies.
For WAPU: We’ve just introduced the three main parts of the Windows Azure platform. This slide lets us walk through some broad scenarios of how they might be used.Original Slide Notes---------------------------------------------------------------------------------------------------------------------------------With Windows Azure and existing Microsoft technologies, cloud computing is not an all-or-nothing proposition. The ability to combine deployment options, installing applications on premises, with traditional posters, or within Windows Azure, is deeply ingrained in the technology of Microsoft Windows server and Windows Azure. Customer's can make decisions where to host all or part of their applications based on desired cost model, ability to manage and maintain systems, software licensing requirements, and desired hardware investment models. No other infrastructure provider or cloud computing platform gives customers that choice and flexibility.
Le plus intéressant sont ces 4 scénarios là !
Todo : Mettre les tarifs en EurosAvec la plate-forme Windows Azure, vous ne payez que ce que vous utilisez. La diapositive ci-dessus montre un bref résumé des prix des différents services de la platefome Windows Azure (prix en dollars).Certains points méritent qu’on s’y arrêtent:- Les instances sont de différentes tailles, allant d'une seule machine virtuellesur une machine virtuellequadri-cœurs.- Le stockage BLOB propose un prix par transaction. Ce n’est pas le cas pour le stockage relationnel. Le prix mensuel pour le stockage relationnel est basé uniquement sur la quantité de données stockées.- Toutes les données déplacées entrantes et sortantes des data centers Windows Azure entraîne des frais de bande passante. Toutefois, une application fonctionnant par exemple sur Windows Azure et utilisant des données stockées dans les blobs dans un même data center n’impliquera pas de frais de bande passante supplémentaire.- En raison des coûts sensiblement plus élevés, les frais de bande passante sont plus élevés dans la région Asie / Pacifique: $0.30/GB entrants et $0.45/GB sortants.Ce sont des prix à la consommation standard. Il y a aussi des rabais disponibles, y compris les réductions de prix pour les partenaires Microsoft et des rabais offerts dans le cadre d'un abonnement MSDN.Quand vous faites des comparaisons de prix entre la plate-forme Windows Azure et d'autres alternatives, il est important de comparer des pommes avec des pommes. Avec Windows Azure, par exemple, Microsoft prend en charge la gestion vous n'avez pas besoin de créer et d'administrer les machines virtuelles, installer des correctifs, et ainsi de suite. De nombreuses variantes, deux options d'hébergement et de plates-formes de cloud autres, laisser cette tâche à vous, ce qui implique des coûts plus élevés. La comparaison des prix nécessite précision comprendre exactement ce que sont les services inclus pour un prix donné.
Les questionspositionnentdans le bon schéma mental pour évoluervers AzureParler MAP 5.5 & WAC
As the figure shows, Windows Azure runs on machines in Microsoft data centers. Rather than providing software that Microsoft customers can install and run themselves on their own computers, Windows Azure is a service: Customers use it to run applications and store data on Internet-accessible machines owned by Microsoft. Those applications might provide services to businesses, to consumers, or both.
Read the slide headlines, answer questions
All Windows Azure applications and all of the data in Windows Azure Storage live in some Microsoft data center. Within that data center, the set of machines dedicated to Windows Azure is organized into a fabric. As the figure shows, the Windows Azure Fabric consists of a (large) group of machines, all of which are managed by software called the fabric controller. The fabric controller is replicated across a group of five to seven machines, and it owns all of the resources in the fabric: computers, switches, load balancers, and more. Because it can communicate with a fabric agent on every computer, it’s also aware of every Windows Azure application in this fabric. (Interestingly, the fabric controller sees Windows Azure Storage as just another application, and so the details of data management and replication aren’t visible to the controller.) 8 This broad knowledge lets the fabric controller do many useful things. It monitors all running applications, for example, giving it an up-to-the-minute picture of what’s happening in the fabric. It manages operating systems, taking care of things like patching the version of Windows Server 2008 that runs in Windows Azure VMs. It also decides where new applications should run, choosing physical servers to optimize hardware utilization. To do this, the fabric controller depends on a configuration file that is uploaded with each Windows Azure application. This file provides an XML-based description of what the application needs: how many Web role instances, how many Worker role instances, and more. When the fabric controller receives this new application, it uses
The Windows Azure Compute service can run many different kinds of applications. A primary goal of this platform, however, is to support applications that have a very large number of simultaneous users. (In fact, Microsoft has said that it will build its own SaaS applications on Windows Azure, which sets the bar high.) Reaching this goal by scaling up—running on bigger and bigger machines—isn’t possible. Instead, Windows Azure is designed to support applications that scale out, running multiple copies of the same code across many commodity servers. To allow this, a Windows Azure application can have multiple instances, each executing in its own virtual machine (VM). These VMs run 64-bit Windows Server 2008, and they’re provided by a hypervisor (based on Hyper-V) that’s been modified for use in Microsoft’s cloud. To run an application, a developer accesses the Windows Azure portal through her Web browser, signing in with a Windows Live ID. She then chooses whether to create a hosting account for running applications, a storage account for storing data, or both. Once the developer has a hosting account, she can upload her application, specifying how many instances the application needs. Windows Azure then creates the necessary VMs and runs the application. It’s important to note that a developer can’t supply her own VM image for Windows Azure to run. Instead, the platform itself provides and maintains its own copy of Windows. Developers focus solely on creating applications that run on Windows Azure. 4 In the initial incarnation of Windows Azure, known as the Community Technology Preview (CTP), two different instance types are available for developers to use: Web role instances and Worker role instances.
Regardless of how it’s stored—in blobs, tables, or queues—all data held in Windows Azure storage is replicated three times. This replication allows fault tolerance, so losing a copy isn’t fatal. The system guarantees consistency, however, so an application that reads data it has just written will get what it expects. Windows Azure storage can be accessed either by a Windows Azure application or by an application running someplace else. In both cases, all three Windows Azure storage styles use the conventions of REST to identify and expose data. Everything is named using URIs and accessed with standard HTTP operations. A .NET client can also use ADO.NET Data Services and LINQ, but access to Windows Azure storage from, say, a Java application can just use standard REST.
Managing applications in this complex environment is challenging. For example, how do you upgrade your apps without bringing it down or degrading its performance, or how do you upgrade an underlying OS without degrading your app's performance of bringing it down. Windows Azure can handle both of these scenarios. Windows Azure separates the applications from the underlying OS so both the application and the OS are managed separately. Microsoft manages the OS and ensures it is up-to-date and always available and the developer of the service can focus exclusively on delivering their business logic. At the heart of Windows Azure is a so-called “fabric controller”. This manages services running on Windows Azure. Developers interact with the fabric controller, hand it their services and tell it how they wish to run their service. The fabric controller is then responsible for deploying the service to the global data center and ensuring its availability.In today's world services are expected to deliver 24/7 availability. Windows Azure strives for this in two important ways. First, all our components are built to be highly available. Fabric controller and storage system are built in a highly redundant and a four-quadrant way. No single processor are a disk failure. In fact, no double failure of these components can bring either of these services down. For massive scale, our storage system partitions and replicates the data across multiple machines, possibly thousands of machines, using adaptive replication, caching, automatic load balancing, our storage systems can maintain high availability under varying loads with no user intervention.Automates Service Management:You tell it what to do—it figures out howScale up, scale down, update or roll application back to a previous versionFabric:Abstracts the VMs from the physical devices
SQL Azure Database provides the best aspects of simple, cloud-based storage and a hosted RDBMS.Developers have the flexibility of being able to choose the data access model that best fits the application requirements. They can use the same tools and libraries as with on-premise client applications to build client applications or Web applications hosted in Windows Azure that access data through familiar data access APIs. Alternatively, they can use ADO.NET Data Services and the Entity Framework to expose a REST-based interface that enables rich Internet applications to access data in the cloud.Whichever data access model is used, SQL Azure Database significantly reduces the effort and cost associated with provisioning data storage for an application. You can just use the Web-based interface to create a new database, and then start building your application. As your scalability requirements increase, SQL Azure can grow with you to meet your specific needs.By using SQL Azure Database, you eliminate the need to manage your own data center servers. Maintenance is automated, reducing your administrative overhead.BackgroundThe initial release of SQL Azure was announced at the PDC in 2008. It consisted of a cloud-based data store that provided an HTTP/REST and SOAP based data access interface and a data object model based on authorities, containers, and entities. While this release provided a great way for developers to build rich applications that access data in the cloud, it lacked some of the key capabilities of a traditional, on-premise SQL Server-based database solution.The REST-based interface and ACE data model has been replaced with a TDS interface and a relational, Transact-SQL-based programming model– just like an on-premise SQL Server instance. This means that developers can create client applications for SQL Azure that use the same data access libraries as traditional, on-premise SQL Server solutions. For scenarios where a REST-based interface is desired, developers can use ADO.NET Services (formerly known as Astoria) and the ADO.NET Entity Framework in the Windows Azure platform to expose SQL Azure through a REST-based data access interface.
The SQL Azure storage platform was designed for extreme scale and low cost. To achieve this, it uses a partitioned data architecture where data is physically distributed across multiple servers in order to provide the high scalability and query performance associated with a federated database solution. The partitions are replicated to provide redundancy and failover capabilities. All partitioning, failover, and load-balancing is automatic.Rather than take a “single image” approach in which each customer gets a dedicated database server, customer data is physically spread across multiple servers in order to maximize scalability and read/write performance for common data access patterns. Workflow is used to achieve transactional consistency across partitions.The end result of this architecture is a highly scalable data platform that requires little to no administrative effort on the part of the customer to provision or manage. Operations and maintenance are automated, with built-in intelligence to detect failures and trigger automatic failover.Goal: A storage platform built for extreme scale and low costCommodity hardware to lower CapExLights out operations and self healing to lower OpExOptimize I/O throughput for specific app patternsOptimized for a handful of hardware SKU’s for datacenter operationsAchieved by:Partitioning dataApps are partition aware to exploit data parallelism for HA, scaling and throughputPartitions are replicated to achieve reliabilitySystem is self healing - automatically partitions data, fails over, load-balances, and scales-upTrade off single system image for scale at very low cost and high throughput“Fan out” operations for large scale cross partition query workloadsDistributed transactions enabled through workflowSpecific IO optimizations to reduce random writes and readsOptimized code paths for high throughputEasy to deploy and manageNo DBA required to manage clusterUse automated provisioning, deployment / rollback and monitoringUse distributed fabric for reliable failure detection, primary election, failover and load balancingFramework for deploying and running scheduled and one off tasks
From the customer’s perspective, SQL Azure provides logical databases for application data storage. In reality, each customer’s data is actually stored in multiple SQL Server databases, which are distributed across multiple physical servers. Many customers may share the same physical database, but the data is presented to the customer through a logical database that abstracts the physical storage architecture and uses automatic load balancing and connection routing to access the distributed data. Security and isolation is managed automatically.The key impact of this model for the customer is a move from managing physical servers to focus on logical management of data storage through policies.
In terms of security, SQL Azure uses the same authentication and authorization model as SQL Server. Logins are created at the Server instance level, and mapped to user accounts and roles at the database level. Access to objects and data in the database is based on permissions granted or denied to database-level user accounts.One key difference from SQL Server is that SQL Azure Db supports only SQL Server authentication – integrated Windows authentication is not supported. Authentication is achieved through a username and password transmitted over a secure, encrypted connection. Future released of SQL Azure may support additional authentication models.When a client opens a connection to SQL Azure, the connection context is set to a specific database. If no database is specified in the connection information, the database context is the Master database. Once a connection is established, the client application cannot change the database context by using the USE Transact-SQL keyword or a fully-qualified database name.
Provisioning is handled by a utility service that is exposed through a Web-based portal and an API. The utility service can be used to enumerate the servers associated with a customer account, show server usage statistics, and other common administrative tasks. You can also use the utility service to manage logins and create new databases with the CREATE DATABASE Transact-SQL command.
What is the difference between SQL Azure and SQL Server?How do we think about compatibility on/off premises – as necessary to provide a broad platform for customersKey Differences – v1 TimeframeSQL Azure v1 will cover a vast majority of the “feature/function” surface area SQL Server (RDBMS). Exceptions:SQL CLRServer-scoped catalogue (shared environment)Few T-SQL constructs not appropriate in a shared environment (global temp tables, DTC)Longer term, will extend other parts of the data platform to cloudSQL BI platformDWCore RDBMS functionality with necessary restrictions due to:SecurityResource GovernanceDatabase independence
This slide describes four common customer scenarios that AQL Azure supportsDepartmental workgroup applicationsBuilt with SQL Express or AccessSmall in size, 5 GB or lessLess than 10,000 rowsSmall number of concurrent users (tens)Owned by a department, not central IT.Often grows out an excel spreadsheet or Access databaseTypically one of the following types:Tracking app (purchase orders changes)Simple reporting app (CSS tool for tracking issues)Commonly pulls reference data from other systems.Simple security needs (a set of people all get read access, with a small number of people with Admin access)Do not have a dedicated DBA (usually managed by a department level IT helper or a technically savvy IW)Developer often a technically savvy IW. Especially for the Access apps.Web applicationsTypically built by a small development team with no little or administrative capabilitiesNeed to start small, but then be able to scale-up quickly and easily as required.Secure data hubs enable you to consolidate existing data store investments and access them through a single cloud-based hub. The security features provided by the SQL Azure Database platform ensure movement of, and access to your data is secure at all times. This enables you to develop or modify applications to provide geo-dispersed data access and enables the complete mobility of your workforce. You can be certain that if your employees have access to the internet they have access to their data!ISVs and SaaS ProvidersGrowing trend towards cloud-based LOB application offerings.Need global reach and scalability with the ability to quickly provision multiple tenants and manage billing