Everyone is excited about the cloud! Well, at least that is the theory. Microsoft introduced Azure such a long time ago - how many of us are really using it? SharePoint BPOS is around, but we still run servers in our backyard! So, why now? And why are things different this time around?

This time around, things are different, for many reasons.

Microsoft release Azure a while ago, but the most exciting parts of Azure are finally coming online. Also, the standards around security and communication are finally maturing with very rich support in both .NET and Visual Studio.

BPOS was little more than hosted SharePoint. I used to call it big piece of stick. And you would completely miss the point if you put Office 365 in the same bucket! Not only does Office 365 build upon SharePoint 2010 - a platform that considered cloud from its very inception, it also learns from the experience of BPOS that customers want more than hosted SharePoint. They do not want multiple identities, they want a development story, and they want delegation of management at various levels. Office 365 is all that and more.

In this article, I hope to provide a basic introduction to both Azure and Office 365 and provide a pre-cursor to the various integration possibilities. In subsequent articles I will dive deeper into specific examples. So, let’s start with a basic introduction.

Azure

Azure has been defined as a cloud operating system. That sounds like very fancy marketing. What do we developers care for? We want the details right? So here are the details. Azure is comprised of many offerings, but at a high level, Azure is comprised of Windows Azure, SQL Azure, AppFabric, and Azure Marketplace. Let me dive into each of these.

Windows Azure

Windows Azure in itself has three main constituents: compute, storage, and virtual network.

Compute refers to the ability to host your own applications, written in .NET. You can host ASP.NET websites, or WCF endpoints in a web role, or you can host the equivalent of Azure Windows Services in a worker role. You also have a virtual machine role designed for scenarios where you want control on the actual hardware - except, it is virtualized hardware. You can think of worker and web roles as highly abstracted where you never have to worry about patching the OS, setting IIS permissions, etc. But in return you give up the flexibility of writing to the disk, having session state, etc. Once you consider the AppFabric caching service, you will see why ASPNET session state is out of fashion, much like Donald Trump’s hairstyle.

Storage refers to the ability to store. You can store in tables, blobs or queues. Blobs are binary objects - you can store up to 100TB of content, and up to 1TB of content in a single container. If you wish to emulate blob storage on your development environment, you are limited to 2GB, however, which is plenty for development purposes. Tables are not SQL tables. Tables are non-relational tables with up to 255 columns, and each row is limited to a maximum of 1MB data in size. Of the 255 columns, three are reserved - PartitionKey for indexing, RowNumber and TimeStamp. But Table storage is designed to be very scalable, flexible and secure. Finally, queue storage is a place where you can dump messages for other worker roles to pick up and process. It is interesting to note that all of Azure’s storage facilities are accessible over a secure manner over Microsoft’s CDN (Content Delivery Network), they have support in both the REST API and .NET class libraries. Perhaps the most exciting part here is that these APIs are securable over many mechanisms, including claims-based identities over the web. Very exciting!

Finally, you have virtual network, designed for the interim where you have on-premises applications not ready to move into the cloud yet, and you need to set up network connectivity that you can manage between on-premises resources and Windows Azure resources. This also comes with a Windows Azure traffic manager - which can be thought of as a load balancer - after Azure’s main load balancer. Whenever any request hits Azure, it is automatically load balanced in the cloud - in order to load balance within your own space in the cloud, (cloudlet?), you can use the Windows Azure traffic manager to perform such behavior.

SQL Azure

SQL Azure is another main constituent of Microsoft Azure - it gives you a relational database in the cloud. You can grow it and manage it as your needs grow. It supports many of the facilities that SQL Server 2008 does - in fact, it communicates with its clients over TDS, so any TDS client thinks it’s just SQL Server. This means you can manage it through SQL Server management studio. SQL Azure has three main constituents as well - SQL Azure Database, SQL Azure Data Sync, and SQL Azure Reporting.

SQL Azure Database is the actual relational database in the cloud. You can login to the Windows Azure portal, provision databases, decide size, location affinity and setup firewall rules. There are many notable differences between SQL Server 2008 on premises and SQL Azure. For one, many things that are considered necessary in on-premises databases, such as replication, are redundant on SQL Azure - and thus not offered. Why would you replicate something that is guaranteed to be available? On the other hand, many features that you may be used to in SQL Server on-premises are also not available in SQL Azure.

SQL Azure Data Sync is a cloud-based synchronization service built on the Microsoft Sync framework. It lets you do bi-directional synchronization of SQL Azure data with another SQL Azure database, or an on-premises database.

And finally you have SQL Azure Reporting, which lets you use familiar tools such as Business Intelligence Development Studio (BIDS) to author reports for SQL Azure.

AppFabric

AppFabric is a paradigm change. That’s my definition. Microsoft’s definition is that it is a cloud-based middleware platform for developing, deploying, managing and maintaining your applications on the Windows Azure platform. Figure 1 shows AppFabric’s main constituents.

The ServiceBus provides secure messaging between any two applications in the world - as long as they can reach out to the Internet. The communication is secure, highly flexible and reliable. I often ask myself if this is MSMQ for the Internet, but it is so much more!

Access Control provides an easy-to-manage way to provide identity and access control to web applications and services. It is built on claims-based authentication.

AppFabric caching provides a distributed in-memory application cache with very low latency and almost infinite scalability. So there is no configuration required, no servers to install, and you can throw whatever you want in the cache - it’s there and it just works!

AppFabric integration provides BizTalk server integration capabilities (pipelines, transforms, adapters). If you’re a BizTalk geek - this is your landing area in Azure.

Finally, AppFabric composite app is a new way to write applications so you can have a design-time experience in Visual Studio in a declarative form, the application’s lifecycle is fully managed, and you are given a complete hosting environment for WCF and WF.

Azure Marketplace DataMarket

Azure Marketplace DataMarket fits into the Software as a Service group of Azure. There are many applications and datasets available on the Internet that you can subscribe to. These are grouped broadly under data and applications. The idea being that if I need a new functionality, say a content management system - I can look for a CMS in the Azure Marketplace DataMarket and simply start using it. No installation required, no patching, no code to write, just use it! Similarly, for the data marketplace, there are many published datasets on the web that your applications can benefit from. For instance, it would be wonderful to have a dataset that provides real estate prices in a neighborhood, and another dataset that provides crime stats in a neighborhood. You can easily write an application that combines the two and create a mashup! And pay for what you use! That is the Azure Marketplace DataMarket.

Office 365

With the background of Azure behind us, now let’s talk about Office 365. It is no secret that every product group in Microsoft is trying to get on the cloud. Not just within Microsoft, almost everywhere. SharePoint is doing the same. Generally SharePoint comes in all levels of SKUs - free to very expensive. But practically speaking, installing SharePoint on-premises has been the work of consultants, on expensive servers, and customizations done by developers - usually expensive developers. I just didn’t see my local kabob shop installing SharePoint to facilitate collaboration between the cooks.

Office 365 changes all that. I don’t find it completely inconceivable that even my local kabob shop might be interested in it. But it’s not about just bringing SharePoint to the low customization and low needs installations. In fact, it isn’t just about SharePoint either.

Office 365 is about bringing SharePoint, Exchange, Office Professional and Lync to whomever needs it - no matter what their size is, and no matter what their needs are. It comes in many payment plans grouped in three major categories - K for kiosk (designed for education or simple needs), P for small businesses (starting as low as $6 per user per month), to E for enterprise. Even within each of these three tiers there are many sub tiers. So you can pick and pay for exactly what you need - and no more.

In addition, Office 365 is designed to be as much administration as you like. You never manage the web application. You have the ability to manage site collection(s) and below. But, you can choose to use Microsoft online identities, or directory synch, or even use federation, so your active directory users get a single sign on experience, much like they expect from an on-premises SharePoint installation. You can also pick and choose the application functionality set you wish out of Office 365. It can range from simple Exchange mailboxes all the way to integrating with your enterprise voicemail and PBX. Office 365 is also designed for very flexible administration. You may perform administration of Office 365 in three ways:

  1. Through the browser: Where you login at www.microsoft.com/office365, and can perform role-based administration such as adding users, configuring mailboxes, adding services, etc.
  2. Through PowerShell: Where you can use PowerShell 2.0’s remote management capabilities to administer your Office 365 investments from a PowerShell window running on your desktop. You can see this technique demonstrated in this article: http://blah.winsmarts.com/2011-4-Using_PowerShell_with_Office365.aspx.
  3. Through partner delegation: Where you can identify and delegate a partner who does the administration for you. I envision a whole new slew of businesses sprouting up who do Office 365 management for large enterprise customers.

Office 365 also supports a development story. Farm solutions are not supported. Several articles ago I was howling at the top of my lungs telling you how great sandbox solutions are and you need to learn them. Well now you see why! Office 365’s development story is sandbox solutions or declarative code such as Workflows written in SharePoint Designer 2010. Now, there has been a lot of rap about Sandbox solutions being lame - primarily because some people think they are too restrictive in what they allow you to do. But, that is where Azure comes in - you can do quite an amazing bit with Sandbox solutions. In fact, very rarely do I get stuck delivering business functionality that matters, as long as I am able to combine Azure and SharePoint together.

Where Do We Go from Here?

Office 365 and Azure are a paradigm change. They are a new way of thinking about your enterprise deployments and development. They are future looking and they are how we will write applications in the future. This is not an opinion, it is a fact. In this article I covered the basics of Office 365 and Azure. In subsequent articles I will demonstrate solving core business problems with Azure and SharePoint 2010. I will focus on SharePoint 2010 on premises with Azure, Azure and Office 365, and having all three in the mix. The set of technologies I will use will be claims-based authentication, .NET 3.5, .NET 4.0, jQuery and Silverlight.

Until then, stay tuned and Happy SharePointing.