Software as a Service

Understanding Microsoft Azure Cloud Access Methods

Print
Check out this page on Dell.com! Email
Rate
1 out of 5
2 out of 5
3 out of 5
4 out of 5
5 out of 5

By: Tom Henderson (7/31/2010)

Access to Microsoft’s cloud is strikingly similar to Microsoft’s Active Directory resources, Windows™ Live and public-facing web resources — except that a Microsoft® data center is likely to be hosting them. Microsoft’s Azure platform is a private cloud development and service platform that supports Microsoft’s user Software-As-A-Service (SaaS) applications (such as online Microsoft® Office components) and applications built around various building blocks using Microsoft cloud version “back-end” products like SQL Server. The Azure cloud runs a special version of Windows called Windows Azure, which provides a foundation for naming and aggregating applications that run on top of Windows 2008 Server editions used. Instances of the OS are spawned on top of Microsoft’s virtualization microkernel hypervisor, called Hyper-V. You rent instances, and use the applications, or publish them on Azure for public or private consumption. The “back-end” services consist of Microsoft SharePoint services, Dynamics CRM, AppFabric applications, Azure SQL Services database and Windows Live services. Microsoft also offers a hardware-based Azure Appliance, whose accessibility is the same as Microsoft’s Azure hosted resources. Third parties also sell middleware and additional authentication components to match increased or modified security or compliance needs. Developer Access Application access to the Windows Azure Platform is made by developers in one or more programmatic interfaces. Microsoft renamed its .NET (dot-NET) services to AppFabric, and AppFabric supports traditional Microsoft .ASP code and C# code through Microsoft’s Visual Studio and other developer platforms. Microsoft-supplied SDKs are also available to support PHP, Java, and Ruby application access to the Azure cloud. This allows the use of SOAP, REST, or XML code, once adapted for use with Azure’s platform. Doing so lets Azure become the back-end for applications or workflows based on (or compatible with) Azure’s XML-based APIs. Microsoft’s Code Access Policy Tool joins applications used and deployed on Azure, with Microsoft’s Active Directory application accessibility and use constraints. Developers using Windows Workflow can have their applications call AppFabric’s API set to cache workflows locally or on Azure’s resources. The workflows become part of a series of connections from processes and storage used in the application along a bus. Called AppFabric Cacheing, local workflow caching is added to a bulk updating service, as well as a plug-in for IIS 7+ to monitor preset endpoints on the bus to monitor workflow progress, and the state of services along the bus. Developers can also interject routing rules to allow code “make decisions for itself” on whether to locally cache processes, or send them to the Azure cloud (where the processes ostensibly cost differently) to complete or join workflows, including their storage needs (described below). At their core, the SDKs and Visual Studio languages (along with the Eclipse IDE) use XML-based interfaces between pieces of code (client/server, web proxy, and other relationships among processes) to authenticate where necessary and to deliver data. Persistent data produced by Azure applications can be stored in the Azure cloud via Windows Azure Storage Services API. The WASSA API uses the REST standard web-like services of get, post, put, and delete through one of three services, blob, queue and table. The storage API services require shared key authentication, based on the Azure storage account. Blobs, or large MIME-encoded strings of data (often of indeterminate size like media files) are usually submitted using REST post commands with authentication keys. Blobs can also be set to a read-only public access quality so that they can be referenced without the otherwise required authentication. By contrast, queue messages are less than 8K in size and are designed as pipelined processing commands that can use a shared authentication key. By using a shared key, processing time in the queue can be faster as the authentication step is eliminated; astute developers randomly force re-authentication to prevent authentication credentials hijacking. Azure Storage tables, which are structured rows of data, are updated and accessed in a similar way, by unique or shared authentication key from within requesting applications. Azure SharePoint The Azure cloud can optionally offer organizations hosted Windows SharePoint Services (WSS). SharePoint collaborative services can in turn, be optionally linked to hosted Windows Exchange Server 2007 installations. SharePoint is accessed in the Azure cloud in the same way that it’s accessed on a local network, through the use of Active Directory, LDAP proxy authentication, or HTML/web page logon. Third-party products that are marketed to increase Sharepoint (or cloud-hosted Exchange) security must be checked for support specifically for Azure, as Microsoft’s hosting services may prevent certain types of products from being compatible with the Azure SharePoint/Exchange versions. Windows Live Messenger Wave 4 The Azure platform is designed hosts persistent applications that are used on a regular basis, but the applications built on Azure’s back-end computing infrastructure can also have a public face through direct connection via Microsoft’s SilverLight web applications, and via Microsoft’s Windows Live Messenger Wave 4-based applications. Live Messenger Wave 4, while still in beta, allows access to Microsoft’s social networking infrastructure and to Messenger/Messenger Companion IM products. It has personal synchronization data synchronization features. The Live Messenger authentication still consists of username/password combinations, but can also have federated identity APIs that are linked by developers in line-of-business applications to Azure-hosted SharePoint services and Windows Code Access Policy. These methods can combine for single sign-on services that permit users to authenticate once, yet use a variety of the services hosted on Azure — subject to the policies. End-users and civilians see no changes to how they access the features and services of the Azure cloud unless third-party applications are in the authentication equation. Developers have a number of choices that surround Microsoft’s Visual Studio, but also other integrated development environments surrounding the Azure AppFabric (.NET), IIS7 access methods (for SharePoint and Exchange) and Active Directory controls/policies that will be largely familiar. Related Information From Dell.com: Dell and Cloud Computing

Access to Microsoft’s cloud is strikingly similar to Microsoft’s Active Directory resources, Windows™ Live and public-facing web resources — except that a Microsoft® data center is likely to be hosting them. Microsoft’s Azure platform is a private cloud development and service platform that supports Microsoft’s user Software-As-A-Service (SaaS) applications (such as online Microsoft® Office components) and applications built around various building blocks using Microsoft cloud version “back-end” products like SQL Server.

The Azure cloud runs a special version of Windows called Windows Azure, which provides a foundation for naming and aggregating applications that run on top of Windows 2008 Server editions used. Instances of the OS are spawned on top of Microsoft’s virtualization microkernel hypervisor, called Hyper-V. You rent instances, and use the applications, or publish them on Azure for public or private consumption.

The “back-end” services consist of Microsoft SharePoint services, Dynamics CRM, AppFabric applications, Azure SQL Services database and Windows Live services.

Microsoft also offers a hardware-based Azure Appliance, whose accessibility is the same as Microsoft’s Azure hosted resources. Third parties also sell middleware and additional authentication components to match increased or modified security or compliance needs.

Developer Access

Application access to the Windows Azure Platform is made by developers in one or more programmatic interfaces. Microsoft renamed its .NET (dot-NET) services to AppFabric, and AppFabric supports traditional Microsoft .ASP code and C# code through Microsoft’s Visual Studio and other developer platforms. Microsoft-supplied SDKs are also available to support PHP, Java, and Ruby application access to the Azure cloud. This allows the use of SOAP, REST, or XML code, once adapted for use with Azure’s platform. Doing so lets Azure become the back-end for applications or workflows based on (or compatible with) Azure’s XML-based APIs. Microsoft’s Code Access Policy Tool joins applications used and deployed on Azure, with Microsoft’s Active Directory application accessibility and use constraints.

Developers using Windows Workflow can have their applications call AppFabric’s API set to cache workflows locally or on Azure’s resources. The workflows become part of a series of connections from processes and storage used in the application along a bus. Called AppFabric Cacheing, local workflow caching is added to a bulk updating service, as well as a plug-in for IIS 7+ to monitor preset endpoints on the bus to monitor workflow progress, and the state of services along the bus. Developers can also interject routing rules to allow code “make decisions for itself” on whether to locally cache processes, or send them to the Azure cloud (where the processes ostensibly cost differently) to complete or join workflows, including their storage needs (described below).

At their core, the SDKs and Visual Studio languages (along with the Eclipse IDE) use XML-based interfaces between pieces of code (client/server, web proxy, and other relationships among processes) to authenticate where necessary and to deliver data.

Persistent data produced by Azure applications can be stored in the Azure cloud via Windows Azure Storage Services API. The WASSA API uses the REST standard web-like services of get, post, put, and delete through one of three services, blob, queue and table.

The storage API services require shared key authentication, based on the Azure storage account. Blobs, or large MIME-encoded strings of data (often of indeterminate size like media files) are usually submitted using REST post commands with authentication keys. Blobs can also be set to a read-only public access quality so that they can be referenced without the otherwise required authentication.

By contrast, queue messages are less than 8K in size and are designed as pipelined processing commands that can use a shared authentication key. By using a shared key, processing time in the queue can be faster as the authentication step is eliminated; astute developers randomly force re-authentication to prevent authentication credentials hijacking. Azure Storage tables, which are structured rows of data, are updated and accessed in a similar way, by unique or shared authentication key from within requesting applications.

Azure SharePoint

The Azure cloud can optionally offer organizations hosted Windows SharePoint Services (WSS). SharePoint collaborative services can in turn, be optionally linked to hosted Windows Exchange Server 2007 installations.

SharePoint is accessed in the Azure cloud in the same way that it’s accessed on a local network, through the use of Active Directory, LDAP proxy authentication, or HTML/web page logon. Third-party products that are marketed to increase Sharepoint (or cloud-hosted Exchange) security must be checked for support specifically for Azure, as Microsoft’s hosting services may prevent certain types of products from being compatible with the Azure SharePoint/Exchange versions.

Windows Live Messenger Wave 4

The Azure platform is designed hosts persistent applications that are used on a regular basis, but the applications built on Azure’s back-end computing infrastructure can also have a public face through direct connection via Microsoft’s SilverLight web applications, and via Microsoft’s Windows Live Messenger Wave 4-based applications.

Live Messenger Wave 4, while still in beta, allows access to Microsoft’s social networking infrastructure and to Messenger/Messenger Companion IM products. It has personal synchronization data synchronization features.

The Live Messenger authentication still consists of username/password combinations, but can also have federated identity APIs that are linked by developers in line-of-business applications to Azure-hosted SharePoint services and Windows Code Access Policy. These methods can combine for single sign-on services that permit users to authenticate once, yet use a variety of the services hosted on Azure — subject to the policies.

End-users and civilians see no changes to how they access the features and services of the Azure cloud unless third-party applications are in the authentication equation. Developers have a number of choices that surround Microsoft’s Visual Studio, but also other integrated development environments surrounding the Azure AppFabric (.NET), IIS7 access methods (for SharePoint and Exchange) and Active Directory controls/policies that will be largely familiar.

Related Information From Dell.com: Dell and Cloud Computing

About Author