SharePoint and Windows Azure
are two sizeable platforms unto themselves. SharePoint is one of
Microsoft’s leading server productivity platforms — the collaborative
platform for the enterprise and the Web. Windows Azure is Microsoft’s
operating system in the cloud. Separately, they have their own
strengths, market viability, and developer following. Together, they
provide many powerful benefits. For example:
- They help expand how and where you deploy your code and data.
- They increase opportunities to take advantage of the Windows Azure
“metered usage” model while at the same time reducing the storage and
failover costs of on-premises applications.
- They provide you with new business models and offerings that you
can take to your customers to increase your own solution offerings.
SharePoint and Windows Azure have evolved quite a
bit since mid-2010 (when Microsoft introduced the topic) into a mature
set of integrated technologies. Figure 1
illustrates the fact that each of the three categories of Windows Azure
can in some way, shape, or form be integrated with SharePoint. For
example, within the IAAS category, you can stand up servers in Windows
Azure with fully functional SharePoint farms (whether they are
stand-alone servers or connected servers that include Web front ends,
index servers, SQL Servers, and so on). You can see here it’s possible
to support SharePoint for Internet Sites (FIS) sites, or Business
Intelligence (BI) servers that run SQL Reporting apps. You can also
create development and test or training environments on Windows Azure
Virtual Machine (or IAAS). Within PAAS, you use the core services
within Windows Azure to build applications, so much of what you would
do here to integrate with SharePoint apps or sites would be hosting WCF
or REST services in the cloud, integrating with workflow, building
media-rich applications, hosting data, and so on. Finally, the SAAS
model extends on the subscription-based Office 365 core functionality
to integrate with Windows Azure and build complete cloud-based
solutions (for example, a training solution that uses Media Services to
stream videos to your SharePoint site) or line-of-business (LOB)
applications such as Dynamics CRM integration or data-synchronized apps
that reflect on-premises LOB applications.
Windows Azure is not just about the integration
of cloud apps with SharePoint though; it’s also about extending your
apps in other directions and to other endpoints. For example, you can
also build services that not only integrate Windows Azure SQL Database
data with SharePoint but also wrap cloud-based services that project to
devices, phones, and Windows 8 tablets. With the integration of
SharePoint and Windows Azure, cloud-based applications are entirely
possible.
1. Understanding SharePoint Cloud-Hosted Apps and Windows Azure
In SharePoint 2010, Windows Azure and
SharePoint were two distinct platforms and technologies; you could
integrate them easily enough, but they were not part of the same
“system.” However, in SharePoint 2013 this has changed.You can
build two types of Windows Azure integrated applications. The first type of application is Autohosted, and the second is Provider-hosted (sometimes referred to as self-hosted). The major difference between the two is that Autohosted applications
natively support a set of Windows Azure features (for example Web Sites
and SQL Database) with the SharePoint development and deployment
experience, and Provider-hosted applications
are meant to integrate with a broader set of web technologies and
standards than Autohosted applications, one of which is Windows Azure.
Thus, you can take advantage of the entire Windows Azure stack when
building Provider-hosted apps that use Windows Azure.
To show just how closely integrated Windows Azure
and SharePoint have become, for the Autohosted app model, Office 365
has its own flavor of a Windows Azure site that it uses behind the
scenes. You can use it to effectively leverage the core Windows Azure
features. Not only is this important from the feature-sharing aspect
between the two platforms, but it’s also important from a security
perspective — HTTPS is supported across these two connected domains.
This HTTPS support extends to Provider-hosted
applications that are deployed to Windows Azure as well. For example,
if you build and deploy a Windows Azure Web Site, you’ll note that it
natively supports HTTP and HTTPS.
This has significant implications for when you want to secure your web
assets and have them conversant with SharePoint. That is, you don’t
have to purchase a certificate from a trusted body such as GoDaddy,
upload it, build it into your Windows Azure application, and so on. All
you need to do is deploy your website to Windows Azure and then
register the HTTPS-based URL with SharePoint and connect the
applications.
You use the Autohosted cloud app model to build
and deploy smaller, cloud-hosted apps to SharePoint. The Autohosted app
leverages a smaller subset of the Windows Azure platform — namely Web
Sites and SQL Database. Using these areas, you can build some
lightweight, data-driven apps where the code lives in Windows Azure and
the configuration for that code lives in SharePoint. Figure 2
illustrates how an app deployed to SharePoint comprises two main parts:
the .APP that is deployed to SharePoint, which contains configuration
and registration information, and the functional code, which is
deployed to Windows Azure.
One of the principal items to keep in mind with
Autohosted apps is that they’re an evolution towards a more
cloud-hosted model. When you compare Autohosted apps to Sandboxed
solutions, for example, you have much more power and developer
capability at your fingertips with the former. But similar to Sandboxed
Solutions, Autohosted apps get your code off of the server, while still
allowing you to build interesting applications.
Autohosted apps are different from
Provider-hosted apps in that the SharePoint environment executes code
that is deployed to Windows Azure; this is abstracted from the view of
the developer but is still a native part of Windows Azure. This is
really good for singular deployment and billing, and enables you to
build once, but automatically deploy to the right places.
Provider-hosted apps are a slightly different
breed with which you can build more broad-reaching web apps that
integrate with SharePoint. Within Provider-hosted apps, you’re managing
your own hosted web environment and then integrating the applications,
services, or data from those separate domains with SharePoint (for
example, one domain being SharePoint and the other being Windows
Azure). Thus, using a Provider-hosted app is not as simple as using the
Autohosted app in regards to integrating Windows Azure. The Autohosted
app model automatically registers the code that is deployed to Windows
Azure, but in the Provider-hosted model you need to configure the
registration of the Windows Azure application to authenticate the app
and the events in that app such that they can fire within the
SharePoint environment. As discussed previously though, there are
mechanisms between Windows Azure and SharePoint that make the
authentication process a smooth one (such as HTTPS support across
SharePoint and Windows Azure Web Sites). Also, the SharePoint
client-side APIs facilitate cross-domain events such as reading or
writing list items.
Provider-hosted apps are also different because
you can deploy and integrate apps that go beyond Windows Azure. Thus,
it’s not just about Windows Azure; the Provider-hosted apps support
PHP, Java, and so on.
