Oh O365, Where (and What) Art Thou?

A customer's CIO asked a question today about the difference between SharePoint On-Premise and SharePoint Online in O365; and more importantly "Whether  his organization's workload is ready to be moved to cloud". While I was answering these questions, the obvious question (that I was waiting for) raised it's ugly head: "Is Cloud ready for my organization?".
I have seen this exact conversation play out many a times in last few months. As organizations are introduced to the cloud, one or more of the following three questions invariably gets asked:

1. What's the difference/value, and does it matter for me?
2. Is my organization ready for the cloud? 
3. Is cloud ready for my organization?          

I try to answer these questions in this post by taking SharePoint as an example. 

Lets start with some simple definitions:

• Cloud: Generic term for SaaS, PaaS, IaaS. 
• IaaS: 
• Stands for "Infrastructure as a service." 
• You are renting an infrastructure piece from a vendor.
• Example: Virtual Machines, Hard Drives, High Performance Nodes, Bandwidth, Network Cables, etc.  
• Vendors: Microsoft (Azure), Google, Amazon, Rackspace, etc   
• PaaS: 
• Stands for "Platform as a service." 
• You are subscribing to a platform, that you use to build your own applications. This is analogous to writing code using .Net framework, except the platform is hosted by a vendor. 
• Example: Azure, Google Apps Engine, Amazon EC2. 
• SaaS: 
• Stands for "Software as a service." 
• You are renting a software access.
• Example: Hotmail, Gmail, O365, Salesforce.com, CRM Online, etc.

• SharePoint On Premise: Self- hosted version of SharePoint. This is the traditional mode of deploying SharePoint on your own hardware and (typically) in your own data center.  

• SharePoint Online: Microsoft hosted version of SharePoint. Essentially, you will buy a subscription from Microsoft, that will allow you to log into the SharePoint UI. All the typical IT functions (installation, patches, backup, keeping the lights on, etc) are handled by Microsoft. 
• Refer: SharePoint Online Overview

Note: SharePoint Online is one of the SaaS offerings from Microsoft. You also have the option to rent VM (Virtual Machines) from Windows Azure (Microsoft's IaaS and PaaS offering) or any other vendor; and install your own SharePoint. The capability of such an install will be similar to the On-Premise installation. For the simplicity of this post, I will stick to the comparison between SharePoint On-Premise and O365.  

On-Premise Vs O365!! 

I present the difference based on multiple factors. Organizations may want to give more weightage/priority to some factors compared to others based on their unique needs:

• Procurement and Setup Cost:
• On-Premise: You incur the cost to get the space, buy hardware, license software, etc. 
• SP Online: You buy an Office 365 (or SharePoint Online) plan from Microsoft.

• Maintenance Cost:
• On-Premise: You hire an IT team to keep the lights on and apply patches, etc. 
• SP Online: Microsoft handles all maintenance headaches. 

• Business Continuity:
• On-Premise: You need to plan for backup, disaster recovery, etc.  
• SP Online: Handled by design. MS makes multiple copies of every data by default supported by well defined SLAs.   

• Features Availability:
• On-Premise: Support for Enterprise level features. 
• SP Online: Limited availability of features. Microsoft is continuously adding to the list of features available online. 
• Refer:
• SharePoint feature availability across Office 365 plans
• SharePoint feature availability across SharePoint Online standalone plans
• SharePoint feature availability across on-premises solutions.

• Customization Needs:
• On-Premise: It's your software and hardware. You have full control over how you want to customize it (server side as well as client side)    
• SP Online: Severe limitation for  server side customization (it's a multi-tenant environment after all). Full support for client side customization. You can use the new (and cool) Office Apps model with REST based API for App Store. 
• Refer: Overview of apps for SharePoint    

• Information Security:
• On-Premise:  You are responsible.  
• SP Online: Microsoft follows (and is certified) various industry standards for security. They take this very seriously!!   

• Compliance:
• On-Premise: You are responsible.
• SP Online: Microsoft ensures compliance with certain industry standards and is verified by third party auditors.  

• Size of data (and need to scale up and/or down ): 
• On-Premise: You need to build the extra capacity to scale up and down by buying expensive storage devices. 
• SP Online: Easier to scale up/down. Available storage (and limitations) is based upon the plan that you purchase.      

   Of course, you also have the option to build a hybrid environment that capitalizes on best of both worlds, but I have excluded it out of this analysis for the sake of simplicity. 

  

Hope this helps!! 

Cheers. 

Piyush

Convergence of "Server AppFabric" and "Azure AppFabric"

It's good to see the prediction that I made in December 2010 coming true :). In November 2010, I wrote a post to show the differences between "Azure AppFabric" and "Server AppFabric". Intent was to help people who were confused because of the similarity in name of these two very different products.
   Refer: http://piyushprakash.blogspot.com/2010/11/de-mystifying-windows-azure-app-fabric.html

  I had concluded the post by saying that there is great potential if the capabilities from the "Server AppFabric" were merged with Azure. It's good to see that Microsoft is starting to offer some of the capabilities from the server version of AppFabric in the form of cloud based services.

 For now, I will just provide the difference in the visual representation, and look forward to diving into nitty gritty in subsequent blogs.

   Earlier:

  Now:

          
       
As you can see,  addition of services such as Caching, Composite Apps, etc within Azure AppFabric indicates a move towards evolving it from being "a basic service bus with access control", to being a full-fledged scalable and secure middleware with support for multiple integration patterns.

I hope to dive deeper into some of these features into future posts.

Windows Azure CDN Simplified!!

Okay. I finally got around to trying out Windows Azure CDN. CDN could be a god-send for companies trying to serve a global userbase. Currently, lot of them essentially force their global users from around the world to connect to US based data centers. The latency in delivering content becomes really high when content happens to be something like video, audio or similar such media that requires high bandwidth throughput.

  The Windows Azure Content Delivery Network (CDN) offers a global solution for delivering such high-bandwidth content that's hosted (cached) in strategically placed locations to provide maximum bandwidth for delivering content to end users.

In it's current avatar, CDN is not suitable for many requirements (that can potentially benefit from such a service) because of inherent limitations in terms of secuirty, content type supported, etc. But I defnitely see those limitations going away in next few releases.

Following are the key attributes of this service that one should understand to be able to decide if CDN is the right fit for a solution:

    1. CDN delivers cached content at strategically located physical nodes in the United States, Europe, Asia, Australia and South America. A latest list of nodes is available at the following url: http://msdn.microsoft.com/en-us/library/gg680302.aspx

    2. Microsoft cannot (and doesn't) guarantee that the content will be served from the closest possible node to the user because it's dependent upon many different factor such as current load, availability, node capacity, etc. This is very critical for organizations that have conpliance requirements such as HIPAA, etc.

   3.  It works better for Windows Azure blobs and static contents. It may not be a good idea to use CDN for contents that are frequently refreshed or need to be generated based on real-time data.

   4. CDN is an add-on feature to your Azure subscription (that needs to be enabled through the Azure Management Portal) and costs extra.

   5. Only blobs that are publically available (anonymous access) can be cached with the Windows Azure CDN.

   6. If you use CDN to cache Azure hosted services, it's recommended to enable CDN only for static content. Enabling CDN for dyanamically generated content or services will cost more, and may even have a negative impact on the performance.

  7.  You can set the "time-to-live" setting for content in CDN. If a content has expired in CDN, the call is re-directed to the blob or stoarge service to get the latest content; and is cached by CDN for subsequent calls (till the content expires again after time-to-live setting passes).

Happy CDN'ing !!

WIndows Azure SDK 1.4 Release !

Microsoft released the Windows Azure SDK 1.4 yesterday.  The release fixes several significant bugs including the nasty RDP bug and adds capabilities like multiple administrator support from the enhanced Windows Azure Connect portal.

  Two new features that I am most excited about is "Azure CDN for Hosted Services" and "CDN content delivery over https". 

Windows Azure CDN for Hosted Services: You can now use the Windows Azure Web and VM roles as"origin" for objects to be delivered at scale via the Windows Azure CDN.

Serve secure content from the Windows Azure CDN: A new checkbox option in the Windows Azure management portal enables delivery of secure content via HTTPS through any existing Windows Azure CDN account.

Windows Azure 1.4 SDK is available for download here.

Cheers!!

Current State of Windows Azure (January 2011) - Part 1

I provided an overview of Azure in January 2010. That was a long time ago; and (stating the obvious) Azure has come a long way since it's early beta release. In this post, I make an attempt to present the current state of Windows Azure, what has changed; and the direction in which I perceive it to be going in future. I will also make an attempt to highlight various new features that were added in the November 2010 release.

Current State:
         Since the initial preview when Azure primarily was a way to build Web Role and Worker roles and capable of building very rudimentary web applications, it has emerged into a set of streamlined services that can enable organizations to build scalable LOB (Line Of Business) applications without sacrificing much of the functionalities that they are able to support in an on-premise solution. I have been pleasantly surpirsed by the level of secuirty features that Microsoft has been able to add; and continue to add to this platform.

        The broader platform can be divided into three kinds of services:

                     1. Windows Azure

                     2. SQL Azure

                     3. App Fabric

    

          Additionally, there are few other key components that add tremendous value to the Microsoft cloud story such as:

• Platform Management Portal
• Local Development Environment
• Marketplace

   Following digram provides a good overview of the various components that come together to form Windows Azure:



Windows Azure Components

Windows Azure:  

            Windows Azure has evolved into a platform that is hosted inside (geographically distributed ) data centers, and you can deploy your applications to that underlying world class infrastructure. How you do that is by utilizing a set of services (similar to APIs in the on-premise world) that Azure provides.

    You pay based on the amount of service you use (a.k.a. Utility Computing).

Service #1 : Compute Service
           One simple way to understand this service is to think of it as a meter that keeps track of the amount of  CPU cycle that your code uses. There are currently three ways of writing your code (dependent upon what you want your code to do). These are called roles.
         a. Web Role        => Used for front-end development
         b. Worker Role   => Used for background processing
         c.  VM Role        => Used for hosting your pre-configured Hyper-V image  

Service # 2 : Storage Service
        There are two key types of storage service:
           1. Windows Azure Storage: It's the persistent storage in cloud, but is NOT relational. Currently, there are four types of Azure storage: blob storage, table storage, queue storage and Azure drives.
It's SIGNIFICANTLY cheaper than the SQL Azure (relational version), and good for large datasets that don't necessarily needs relational and Querying capabilities of SQL Azure.

          2. SQL Azure: Variant of SQL Server hosted in Azure with T-SQL kind of querying capabilities. It's more expensive than Windows Azure storage.

     Azure Storage Vs SQL Azure:
           Once simple way to understand the difference:
                      Azure Storage => Raw Storage of objects that you can query using REST or managed API.
                      SQL Azure => Processing engine on top of Storage that has data-processing capabilities (queries/transactions/stored procedures) and therefore, cosumes more resources and therefore, is more expensive.  
         
        One good strategy can be to store the high-volume data in low-cost Azure Storage; and use (expensive) SQL Azure to store indexes (pointing) to the data. Also, there are size limitation of the SQL Azure instances that can be overcome by using partitioning, but improtant to consider during architecting your azure application.

Service # 3: App Fabric

           This is one service that has come a long way since it's initial debut; and is still going through signifincat enhancements. This sevrice is the building block behind many LOB applications, and provides functionalities typically provided by middle tier in a 3-tier on-premise application. It enables web services, service bus, service registry, orchestration, secuirty and other capabilities in the cloud.   

           Each of these features add their own unique value to Microsoft's cloud story, and I plan to cover them in next few posts.

 I hope this post gave a good overview of key Azure pieces, and look forward to diving into details in next few posts.

Cheers!!

Windows Azure SDK 1.3 release!!

I got a demo from Microsoft of some of the goodies that is being shipped with Windows Azure SDK 1.3 release. It's made significant progress since the previous release, especially in the area of IAAS (infrastrucutre  as a service). The new Windows Azure management portal (Silverlight front-end) is also streamlined to support new features and services. Here's some of the key features budled in new release. Cannot wait to try them out:

• VM Role (Beta): Create your own custom VHD based on Windows Server 2008 R2 and deploy it to the cloud. This feature makes it so much easier to migrate existing applications to the cloud, reducing management and hosting costs.
•  Extra Small Instance Size (Beta): Run an extra small compute instance for only $0.05 per hour.
•  Remote Desktop Access: Connect to individual service instances with the remote desktop client as you would with any deployment in a hosted scenario.
•  Full IIS Support in Webroles: Host your web applications in IIS and configure IIS to suit your needs.
•  Elevated Privileges: Perform tasks in a service instance with elevated privileges.
•  Virtual Network (CTP): Use Windows Azure Connect to accomplish IP-level connectivity between on-premises en the cloud.
•  Network Enhancements: Restrict inter-role communication and use fixed ports on InputEndpoints.
•  Performance Improvement: Experience better performance when developing in the development fabric.
Cheers!!

Windows Azure Instances stuck in the Initiatilizing, Busy or Stopping State

Although there could be many reasons for an instance to be stuck in a non-ready (busy/Initiatilizing/stopping) state, I have experienced a common (and silly) reason. It's the the number of instances that you have configured in the portal ( or through the "ServiceConfiguration.cscfg" file ).

I spent about one hour uploading (and of course deleting) exact same Azure package with a single instance of the web and worker role.  Sometimes it would upload and put the instances in Ready state right away, and sometimes it would just get stuck in the initializing or busy state. I have started experiencing this behaviour in last few months. Basically, this has become more frequent with the increase in Azure adoption. Also, this is more frequent duirng day-time (hypothesizing) when there are probabaly more people trying to upload thier packages to the Azure portal.

It turns out (and as warned through a dialog box) when you are trying to upload the package to Windows Azure portal, Microsoft doesn't guarantee any SLA if you are running only a single instance of either web or worker role. In addition to that, I am almost getting certain (after wasting one hour to figure any other logical reason) that they have put in some logic in the Load balancer that de-prioritizes any single instance configuration in favour of the multi-instance configuration during package upload. So, if you are short on time (or want to save some time ) during package upload and instantiation on Azure portal, i would recommend changing the number of instances to atleast 2 even during the develop-deploy-test cycle. This may cost little more in Azure cost (two instance cost VS one ) but I would say it's definitely worth it.

Bottomline - Since Microsoft SLA (99.95%) is not valid for single instance deployment in terms of availability, keeping atleast two instances of your role will save lot of time and headache.

On a side note, there are several other benefits to maintaining atleats two or more instances. For example, a single instance (and therefore the entire role ) can become unavailable whenver the role instance is being restarted by Azure. Azure can restart a role instance for many different reasons, including:
a)      Role instance is being recycled by Load Balancer
b)      Load Balancer Issues
c)      Being Upgrade to a new OS version
d)      Being re-booted to apply a patch or to resolve some other issue

Following blog from Toddy is a good list of other issues that may be causing your roles to be stuck in  Initiatilizing, Busy or Stopping State: http://blog.toddysm.com/2010/01/windows-azure-deployment-stuck-in-initializing-busy-stopping-why.html

Hope this  helps!
Piyush

Azure Components !!

I found this really cool image in the latest Azure SDK that does a good job of explaining key azure pieces in one line each.



Windows Azure Overview

  I think the Microsoft messaging is definitely improving, and will go a long way in making users understand the long term vision. Above positioning of various Azure pieces is much better than the initial days when everyone was having a hard time understanding various roles and where it fits into the long term roadmap. Good job Microsoft!!

Now you only need to make sure that product can support the message. For example; the SQL Azure positioninig above may be right for structured data, but I am not sure about the support for unstructred data in the current version. :)
    

Visual Studio 2010 Release - Impact on Azure Development

I have been playing with Azure for some time now, and also got few opportunities to put together few POCs. I was using VS 2008 for some of the initial attempts, then moved onto VS 2010 RC. Azure was also in flux and went through several changes.

  Now that Azure is a released product, and VS 2010 is also out; I would strongly recommend everyone doing Azure development to get the latest versions of both. VS 2010 has amazing support for Azure when it comes to development as well as deployment to the cloud. Being able to generate a visual UML model from code is icing on the cake (for Azure as well as non-Azure projects).

  I also didn;t come across any significant roadblocks in migrating some of the older code to new SDK and VS 2010. But again, none of my solutions were overly complicated.

  Overall, the transition has been a positive experience. Thank You Microsoft!! There are many other cool new features in VS 2010 that I look forward to talking about in future posts.

  Cheers!!      

Microsoft Azure Vs Amazon Vs Google Vs Others

Oen question I am frequently asked is to compare various cloud offerings in the market. Although I am just starting to play with Azure, I have been using Amazon EC2 for some time now. There doesn't seem to be much overlap between the approach of the three key vendors.

Here is my current understanding (which may change as I dive deeper into Azure). There is also a good chance that Microsoft has unveiled only a small subset of the long term product roadmap, and may release new features in future to compete directly with Amazon EC2 or google apps.

Amaozn EC2:
               Not too different from existing hosters like "Network Solutions" and "Go Daddy", except privides the unlimited elasticity of the resources coupled with "pay as you go" model.

    Simply speaking:
               a. You can rent as many servers as you want (scale up and down)
               b. You can pretty much install anything on those servers (Windows, LAMP, etc)
               c. You pay only for the resources that you use (instead of a fixed monthly fee)
               d. You take care of installing load balancer and such based on how you want to manage session state acorss various servers.

Microsoft Azure: 
             It's more of a platform (or a set of APIs). As long as your code follows the standards defined by the underlying API, Azure takes care of the rest. That rest includes things like:
            a. Setting up of servers
            b. Load balancing      
            c. Scale up (and) down based on your user load and subscription level.

    Essentially, you are not renting just a bunch of hardware and dealing with headache of installing software on it, but building your solution based on some specification and leaving the hardware-software headcahe to Microsoft. Thus, being able to focus more on your business logic as opposed to dealing with software versioning and compatibilities issues.

Google Apps:
        I do not have much experience with Google Apps, but it seems more of a SaaS (Software as a service) play. You essentially subscribe to softwares like Gmail, Google Docs,etc; and  you get certain premium services like backups, restore, custom domain names, dedicated account managers,etc  based on your subscription level. 
    This is similar to SaaS offerings by other vendors like SalesForce.com. Even Microsoft offering live Live Services will fall into this category.

Conclusion:
If I were to put the three vendors into boxes, this is what the boxes would be labeled (based on their respective offerings):

   Amazon : Infrastructure as a Service (IaaS)
   Microsoft : Platform as a Service (PaaS)
   Google : Software as a Service (SaaS)

It would be interesting to see the traction/direction that each of these get over next few months/years to come. I, for multiple reasons (including my Microsoft background), am liking Azure more than the rest, and cannot wait for it to evolve into something magnificient.

Cheers!!