The toolkit provides you with:
- Binaries for your Windows Phone 7 applications
- Project templates to optimize new phone application creation
- Sample applications in both C# and VB.NET
- A dependency checker that checks the prerequisites required by the toolkit
- Setup and configuration documentation, toolkit content review, a getting started walkthrough, and troubleshooting tips
Once you’ve downloaded the toolkit, you can use the phone and compute emulators to quickly get a new phone application running into Microsoft Windows Azure.
Windows Azure version of BLAST(Basic Local Alignment Search Tool) helps Scientists on University of Washington to search all available sequence databases for similarities between a protein or DNA query and known sequences in the cloud.
With running applications, another attractive way to use the cloud services, is to store data. SQL Azure addresses this area offering a relational database in the cloud. As following picture shows, SQL Azure is built in three components:
SQL Azure provides relational database services in the cloud.
The components of SQL Azure today are the following:
• SQL Azure Database: It’s a cloud-based database management system (DBMS). This technology lets on-premises and cloud applications to store relational data on Microsoft server hosted in Microsoft datacenters. Like other cloud services on Azure, an organization pays only for what is used, increasing and decreasing usage (with the cost of course) as the organization’s needs change. Using a cloud database also allows converting what would be capital expenses, such as investments in disks, DBMS software, backups, etc., into operating expenses.
• SQL Azure Reporting: It’s a version of SQL Server Reporting Services (SSRS) that runs over the cloud. Intended primarily for use with SQL Azure Database, it allows creating and publishing standard SSRS reports on cloud data.
• SQL Azure Data Sync: Allows synchronization of data between SQL Azure Database and on-premises SQL Server databases. It can also be used to synchronize data across different SQL Azure databases in different Microsoft data centers.
SQL Azure is built on Microsoft SQL Server and with it, developers can create indexes and views, use stored procedures, define triggers, and more. Applications can access SQL Azure data using Entity Framework, ADO.Net, and other Windows data access interfaces. In fact, applications that today access SQL Server locally will largely work unchanged with data in SQL Azure. Customers can also use on-premises software such as SQL Server Analysis Services to work with their cloud-based data.
While applications can use SQL Azure much as they do a local DBMS, the management requirements are significantly reduced. Rather than worry about mechanics, such as monitoring disk usage and servicing log files, a SQL Azure customer can focus on their data; Microsoft will handle the operational details. And as with other components of this cloud platform, customers use the common Windows Azure platform portal to access its services.
Applications might use SQL Azure in a variety of ways like those samples above:
• A Windows Azure application can store its data in SQL Azure. While Windows Azure provides its own storage, relational tables aren’t among the options it offers. Since many existing applications use relational storage and many developers know how to work with it, a significant number of Windows Azure applications rely on SQL Azure to work with data in this familiar way. For example, a SaaS application built on Windows Azure might create a separate SQL Azure database for each customer, providing an intrinsically multi-tenant design. And to improve performance, customers can specify that a particular Windows Azure application must run in the same data center in which SQL Azure Database stores that application’s information.
• An application in a small business or a department of a larger organization might rely on SQL Azure. Rather than storing its data in a SQL Server or Access database running on a computer under somebody’s desk, the application can instead take advantage of the reliability and availability of cloud storage. It can also create reports on this data using either SQL Azure Reporting or SSRS on-premises. If the organization wishes to maintain an on-premises copy of the data as well, it can use SQL Azure Data Sync to synchronize the cloud and on-premises databases.
• Suppose a manufacturer wishes to make product information available both to its dealer network and directly to customers. Putting this data in SQL Azure would let it be accessed by applications running at the dealers and by a customer-facing Web application run by the manufacturer itself.
Whether it’s for supporting a Windows Azure application, making data more accessible, or other reasons, data services in the cloud can be attractive. The goal of SQL Azure is to provide these services in a familiar, easy, usable way for cloud and on-premises applications. That’s all for SQL Azure. Next post I’ll be briefing about Windows Azure AppFabric.
Do you want your Cloud application to appear on Microsoft Case Studies Page? Do you want to use the powered by Windows Azure Logo on your products?
So, just send a email to firstname.lastname@example.org for more information on how to submit your application to this program.
In a high level point of view, Windows Azure is very simple: It runs Windows applications and stores data in the cloud. Following picture describes its components.
Windows Azure provides compute and storage services in the cloud.
The five parts of Windows Azure today, are the following:
• Compute: The Windows Azure compute service runs applications on a Windows Server foundation. These applications can be created in any .Net languages like C# and Visual Basic, or any other supported language like C++, Java, PHP, Ruby, and others. Developers can use Visual Studio or any other development tools, and they are free to use technologies such as ASP.Net, Windows Communication Foundation (WCF) and PHP.
• Storage: This service allows storing binary large objects (blobs), provides queues for communication between components of Windows Azure applications, and even offers a form of tables with a simple query language. (Windows Azure applications that need traditional relational storage can also use SQL Azure.) Both Windows Azure applications and on-premises applications can access the Windows Azure storage service, and both do it in the same way: using a RESTful approach.
• Fabric controller: As the figure suggests, Windows Azure runs on a large number of machines. The fabric controller’s job is to knit the machines in a single Windows Azure data center into a cohesive whole. The Windows Azure compute and storage services are then built on top of this pool of processing power.
• Content delivery network (CDN): Caching frequently accessed data closer to its users speeds up access to that data. The Windows Azure CDN can do this for blobs, maintaining cached copies at sites around the world.(you can see the CDN guide on other post here in the blog: https://galvesribeiro.wordpress.com/2010/11/08/windows-azure-cdn-guide/)
• Connect: It’s often useful for organizations to interact with cloud applications as if they were inside the organization’s own firewall. Windows Azure Connect allows this, making it easier for, say, a Windows Azure application to access an on-premises database.
Running applications and storing data in the cloud can have clear benefits. Rather than buying, installing, and operating its own systems, for example, an organization can rely on a cloud provider to do this for them. Also, customers pay just for the computing and storage they use, rather than maintaining a large set of servers only for peak loads. And applications written for Windows Azure can scale better, be more reliable, and require less administration than those written using the traditional Windows Server programming model.
To create, configure, and monitor applications, Windows Azure customers can use a browser-accessible portal. A customer logs in with a Windows Live ID, then chooses whether to create a hosting account for running applications, a storage account for storing data, or both. Microsoft then charges each customer based on how much compute time, storage, and bandwidth that customer uses. How an application charges its own customers—if it charges them at all—is entirely up to the people who create that application.
Windows Azure is a general platform that can be used in a broad set of scenarios. Here are a few examples:
• An independent software vendor (ISV) creating a software-as-a-service (SaaS) version of an existing on-premises Windows application might choose to build it on Windows Azure. Because Windows Azure mostly provides a standard Windows environment, moving the application’s business logic to this cloud platform won’t typically pose many problems. And once again, building on an existing platform lets the ISV focus on business logic—the thing that makes them money—rather than spending time on infrastructure.
• An enterprise creating an application for its customers or employees might choose to build it on Windows Azure. Because Windows Azure supports .NET, developers with the right skills aren’t difficult to find, nor are they prohibitively expensive. Running the application in Microsoft data centers frees the enterprise from the responsibility and expense of managing its own servers, turning capital expenses into operating expenses. And especially if the application has spikes in usage—maybe it’s an on-line flower store that must handle the Mother’s Day rush—letting Microsoft maintain the large server base required for this can make economic sense.
• A start-up creating a new Web site—the next Facebook, say—could build its application on Windows Azure. Because this platform supports both Web-facing services and background processes, the application can provide an interactive user interface as well as executing work for users asynchronously. Rather than spending time and money worrying about infrastructure, the start-up can instead focus solely on creating code that provides value to its customers and investors. The company can also start small, incurring low costs while its application has only a few users. If the application catches on and usage increases, Windows Azure can scale the application as needed.
These three examples illustrate the kinds of things organizations might do with Windows Azure, but they’re not an exhaustive list. As interest in cloud computing continues to grow, expect to see a variety of applications created for this cloud platform. That’s all for Windows Azure. See you in the next blog post where I’ll explain SQL Azure.
Using cloud computing can make a lot of sense. Instead of buy and maintain your own machines, why we just don’t use the internet-accessible servers offered today? For some applications/solutions, both code and data might live in the cloud, where some other company manage and maintain the computers you are using. In other hand, you can just have applications that run inside an organization (called on-premises), where data are stored in the cloud or relay on other cloud infrastructure services.
Well, whether an application runs in the cloud, uses services provided by it, or both, same kind of application platform is required. Viewed broadly, an application platform can be thought of as anything that provides developer-accessible service for creating applications or storing data. At the world of on-premises Windows, this includes technologies such as Windows Server and SQL Server. To make use of all the cloud benefits, a cloud platform must also exist.
This is what Microsoft Windows Azure platform provides. It’s a group of cloud technologies, each providing a specific set of services to application developers. The following picture shows its components:
The Windows Azure platform supports applications, data, and infrastructure in the cloud, together with a cloud marketplace.
The Windows Azure platform today, has four parts:
• Windows Azure: A Windows environment for running applications and storing data on computers in Microsoft data centers.
• SQL Azure: Relational data services in the cloud based on SQL Server Data Services.
• Windows Azure AppFabric: Cloud-based infrastructure services for applications running in the cloud or on premises.
• Windows Azure Marketplace: An online service for purchasing cloud-based data and applications.
All four of these components run in Microsoft data centers located around the world (two in North America, two in Europe and two in Asia). Developers that makes use of the platform can control which data center runs their applications and stores their data, enabling them to place both closer to their users.
Each part of the Windows Azure platform has its own role to play. This overview series will describe each one of the four, first at a high level, then in a bit more detail. The deal here is to provide a deeply big-picture introduction to this cloud platform.
See you in next post of the series.
Microsoft released today last update for Windows Azure AppFabric SDK, the October Update. Feel free to download it from here http://www.microsoft.com/downloads/en/details.aspx?FamilyID=39856a03-1490-4283-908f-c8bf0bfad8a5&displaylang=en