Category Archives: Architecture
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.
After hollidays, I’m back with one of the last posts regarding this introdutory discussion of Windows Azure Platform.
So, running applications and storing data in the cloud are both important aspects of cloud computing. They’re far from the whole story, however. It’s also possible to provide cloud-based infrastructure services. Filling this gap is the goal of Windows Azure AppFabric. The functions provided by AppFabric today address common challenges in building distributed applications.
The functions provided by AppFabric today address common challenges in building distributed applications. Figure 4 shows its components.
As the figure suggests, all of the components of Windows Azure AppFabric are built on Windows Azure (although they don’t all provide services solely to Windows Azure applications). Those components are the following:
- Service Bus: Exposing an application’s services on the
Internet is harder than it might seem. The goal of Service Bus is to make this
simpler by letting an application expose endpoints in the cloud that can be
accessed by other applications, whether on-premises or in the cloud. Each
exposed endpoint is assigned a URI, which clients can use to locate and access
the service. Service Bus also handles the challenges of dealing with network
address translation and getting through firewalls without opening new ports for
- Access Control: There are many ways for a user to get a digital identity today. The
options include Active Directory, Windows Live ID, Google Accounts, Facebook,
and more. If an application wants to let users log in with any of these, the
application’s creator faces the daunting challenge of supporting this
plethora of approaches. Access Control simplifies this by providing built-in
support for all of them (and more). It also provides a single place for
defining rules to control what each user is allowed to access.
- Caching: It’s common for applications to access the same data over and over. One way to speed up this kind
of application is to cache frequently accessed information, reducing the number
of times that application must query a database. The Caching service provides
this—and the performance boost it brings—for Windows Azure applications
Microsoft has announced plans to add more services under the Windows Azure AppFabric banner, so expect this list to grow in the not-too-distant future. As with Windows Azure and SQL Azure, customers use a browser-accessible portal to sign up for AppFabric. Once this has been done, these services can be used in a variety of ways. Here are some of the possibilities:
- Suppose an enterprise wished to let software at its trading partners access one of its applications. It could expose this application’s functions through SOAP or RESTful services created using WCF, then register those service endpoints with Service Bus. Its trading partners could then use Service Bus to find these endpoints and access the services.
- Imagine that the creator of this same application needs to let trading partners log in with a variety of different identities. Rather than implementing support for these identities himself, he could use the Access Control service to hide this complexity.
- A Windows Azure application created using ASP.NET might use the Session object to store per-client state. By changing only a configuration setting, the application can cause this data to be kept in the Caching service rather than, say, Windows Azure Storage tables. Doing this is likely to make the application faster and more scalable.
Along with the cloud-based services of Windows Azure AppFabric, Microsoft also provides an analogous technology known as Windows Server AppFabric. As its name suggests, the services it provides run on Windows Server—they support on-premises applications—rather than in the cloud. The on-premises services aren’t exactly the same today as those in Windows Azure AppFabric (although Microsoft’s
announced plan is make the two congruent). Don’t be confused; throughout this paper, the name “AppFabric” is used to refer to the cloud-based services. Also, don’t confuse Windows Azure AppFabric with the Windows Azure fabric controller. Even though both contain the term “fabric”, they’re wholly separate technologies addressing quite distinct problems.
Well that is it for now. In my next post, I’ll be talking about Azure Marketplace.
See you here soon.
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.
Just found a nice article on MSDN Magazine talking how to connect Sharepoint to Windows Azure using a Silverlight Webpart.
Check the new CDN(Content Delivery Network) guide for Windows Azure on MSDN:
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.
Today, at time of PDC 2010, Charles Petzold released a full featured nice eBook under Microsoft press brand about Windows Phone 7 Programming.
More information and where to download links: http://blogs.msdn.com/b/microsoft_press/archive/2010/10/28/free-ebook-programming-windows-phone-7-by-charles-petzold.aspx
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