When cloud services first became available, it was said that the most dangerous weapon in IT was the article in an airline magazine that attracted the attention of a CIO to a cheap monthly payment per user. Enthused by the notion that they could replace unpredictable and arbitrary costs for running IT systems with a nice, clean monthly bill from a service provider, the CIO returned to their company with all of the zealot passion of the converted and caused havoc for their staff.
Of course, this is a simplistic view of the world and CIOs don’t make long-term strategic decisions on the basis of some dubious assertions by journalists. The articles never explored the costs that lurked behind the monthly bill, but that’s not the kind of detail you can expect over three pages and 1,200 words. For whatever reason, the notion of a cheap fixed price took hold and we’ve been having discussions on that basis ever since.
Indeed, all cloud providers use easily understandable pricing to attract customers, whether it’s the $6/mailbox per month from Office 365 or $50/year from Google Apps. All so much more straightforward than having to grapple with complicated budget calculations involving capital purchases (servers, network equipment, and so on), people costs, and other ongoing expenses like software licenses.
The fixed cost element of using cloud services is easy to understand, easy to bill, and easy to pay and there’s goodness in all of that. Unfortunately, as those who have moved to cloud services understand, a host of other costs hide behind the up-front supermarket-like headline charge. Migrations are seldom joyful and always expensive. Network costs are different because traffic is diverted to external destinations rather than saying within company boundaries. Hybrid connectivity might have to be set up and managed. Single sign-on is highly desirable and needs to be done. The list goes on.
It’s true that a time comes when cost stabilizes and it becomes much easier to understand and measure the true cost of cloud services. It’s also true that this cost is often less than the equivalent of running on-premises servers, if you are able to accurately measure the true on-premises cost. If you are happy with the functionality delivered by the cloud service and its relative lack of flexibility (in terms of customization and the ability to deploy add-on software), then the decision to move to cloud-based services is a good one.
Many small to medium companies are in this situation. They were probably not very good at running IT anyway because it’s not the core competence of the company. Talented individuals working very hard cannot overcome the under-resourcing and aging equipment often found in companies where IT is not a priority. Moving over to cloud services probably results in more functionality, higher availability, and lower costs, all of which are good things. Even if support has improved over the last few years, it remains the Achilles Heel of cloud services and that’s a challenge that the IT department still faces after the transition.
The situation is different for larger companies, those that are more complicated because their operations are more widespread and distributed and cover more areas of activity. These companies tend to have more IT staff and better operations and a fair amount of bespoke code to deal with specific business requirements. It takes a lot more planning, effort, and expense to move these companies to cloud services. The fixed cost argument is not as attractive because in many cases these companies enjoy substantial discounts from IT suppliers for their current systems.
The cloud services provided to date are often pretty utilitarian. The core email functionality of sending and receiving messages is very much a utility operation. Even the more sophisticated aspects such as transport rules or even Data Loss Prevention policies can be delivered in a highly structured and automated manner. All of this is the reason why email is one of the first services that companies consider moving to the cloud. And because the functionality is well-understood and everyone shares many of the same requirements when it comes to email, service delivery is usually pretty good. Moving applications to SharePoint Online takes more effort.
But I think we’re on the cusp of an inflexion point when far more complex software can be better delivered (or only delivered) by cloud services. Software like the Office Graph (project “Oslo”), which Microsoft has talked up recently. The latest news is that it appears very unlikely that Office Graph will appear in a form that can be installed on-premises any time soon. In an interview with Network World, head of Office Technical Marketing Julia White said that Office Graph depends on the “massive compute power” that only exists in the cloud.
The news did not come as a shock because when you think about it, the usefulness of Office Graph depends on achieving an understanding of the many complex and interconnected links that people share within a company. The amount of machine learning that’s necessary to make something like Office Graph work well outside the restrictive boundaries of a software laboratory must indeed be “massive.” More interestingly was the statement that the “intelligence fabric” that represents Office Graph is only possible “because we can update the service with learning every single day.”
Three requirements would have to be met before something like Office Graph could be deployed in an on-premises environment. First, you’d have to be willing to deploy all the necessary software components. Second, you’d have to make large amounts of system resources available. My guess is a pool of dedicated servers and storage to process feeds from systems like Exchange and SharePoint (and other indeterminate sources including Lync and Yammer) that can be used to build the map of connected data presented by Office Graph. Third, you’d probably have to be willing to perform software updates on a very regular basis as Microsoft tweak the algorithms used by Office Graph.
Some companies would be interested and willing to plunge in and run their own Office Graph. I suspect that most others will be quite happy to leave all that work and investment to Microsoft, especially if the new feature is delivered as “evergreen software” covered their subscription (these features will likely only appear in the enterprise Office 365 plans). From the same interview, it seems like the “Clutter” feature, which also depends on machine learning to understand how people deal with new messages arriving in their inbox, falls into the same category.
So, you won’t benefit from new features like Office Graph unless you use Office 365, which then leads us to the conclusion that over time a growing gap is likely to emerge between the functionality that Microsoft delivers to its on-premises customers and that available in the cloud. Over time, it is possible that Microsoft will be able to ready features for transfer to on-premises servers (as they did with Managed Availability in Exchange 2013), but no guarantees exist at this point.
The financial debate about moving to the cloud is therefore not simply about comparing fixed versus variable costs. Some functionality that your company might want to use may be only available in the cloud. I don’t know whether this change will significantly affect the way that companies evaluate cloud services as a lot depends on the exact nature of the functionality gap that develops. That process won’t be fast and we won’t be able to evaluate the impact for a few years yet.
Follow Tony @12Knocksinna
I think the main comparison between on-premises and Hosting / Public Cloud is Security, and I am surprise that you did not mention that. Security will Always be an issue for Hosting / Public Cloud. Bottom line once you are in Hosting / Public Cloud the Vendor OWNS your data & who knows who got access to your corporate data (NSA).
Security is absolutely one point of comparison to use when sizing up cloud and on-premises systems. This post is no attempt to cover every conceivable point that could be included in the comparison. Instead, it reflects that whereas in the past you had similar functionality on both platforms, now we see that a growing functionality gap will appear. That new gap changes the dynamics of the comparison because you’re not comparing like with like any more.
Pingback: Weekly IT Newsletter – May 19-23, 2014 | Just a Lync Guy
Pingback: NeWay Technologies – Weekly Newsletter #96 – May 22, 2014 | NeWay
Pingback: NeWay Technologies – Weekly Newsletter #96 – May 23, 2014 | NeWay
Pingback: Some factors that make it much easier to introduce new features in the cloud | Thoughtsofanidlemind's Blog