A big part of Microsoft CIO Tony Scott's job in Redmond is to personally use all of Microsoft's technologies, including its cloud products. Microsoft types call this "eating your own dog food."

Microsoft IT was an early test environment for cloud-based productivity suite, Office 365, and Windows Azure, the company's platform-as-a-service offering that is the basis for its cloud strategy.

Research firm Gartner said at its Gartner Symposium recently that despite the complexity of Microsoft's cloud services, the company has "one of the most visionary and complete views of the cloud." Late last week at Microsoft's PDC (Professional Developers Conference) event in Redmond, the company stirred the Windows Azure pot by announcing new virtualization capabilities designed to entice developers.

In an interview with CIO.com's Shane O'Neill, Microsoft's Scott discussed some best practices for CIOs that he's learned from "dogfooding" Windows Azure. He also shares his views on how the cloud will change the financing of business projects and how CIOs can prepare accordingly.

CIO.com recently published a story about cloud adoption that cited a survey where the number one reason for not moving to the cloud was "Don't Understand Cloud Benefits." How is Microsoft cutting through the noise and confusion to clearly outline for CIOs how a cloud model will help their organization?

In my experience CIOs are practical folks, with a healthy level of skepticism about the "next big thing." Conceptually, they all get the benefits of the cloud. But there's a lot of uncertainty out there about how to get started. It can be a little bit intimidating.

Our role at Microsoft IT is to dogfood all our own products, so we started by moving some basic apps to Azure. This was two years ago, before the product was released to the public. We were just getting our feet wet, and I saw some healthy skepticism at the time even in my own organization.

But once you dip your toe in, the learning process begins. We saw an improvement in the quality of the apps we moved to Azure. One example is MS.com, which we moved to Azure and were able to scale the services based on demand versus based on peak capacity. We really saw the advantages of a standardized cloud platform versus fine-tuning every server to each application.

A great example of this is our Microsoft Giving Campaign tool, which we use for internal fund-raising for non-profit organizations. That app gets most of its usage once a year in October during the Giving Campaign. The rest of the year it sits idle. That is a perfect application for the cloud. The new Giving Campaign tool was built on Azure and on the last two days of the campaign, where we often see the peak loads, it never slowed down and the results were phenomenal. We raised twice as much money as we had in any prior year.

So CIOs just need to get started. That's the hardest part. But once they get in there and experience a cloud platform, it will boost their enthusiasm and willingness to move forward.

Conceptually, we all understand the benefits. We've operated on what I call the double-double rule for years. Which is you figure out what capacity you need and double it and then double it again just for insurance. But that's frankly why you find that most apps running in production use only 20 percent of the resources. In a cloud platform you can improve utilization without penalty because you can expand capacity at will and only pay for what you need.

When an enterprise starts moving applications to a cloud platform, what is tougher for IT groups: the change in technology or the internal politics that arise as the cloud forces traditional IT roles to change?

I haven't seen much internal political conflict, to be honest. I think most on the business side like the idea of more reliability and paying for what you use. So from a business perspective I haven't seen a lot of resistance to the cloud.

One thing I have seen both internally and externally, is that the cloud is changing how projects are approached. The shift has gone from capex [pay upfront] to opex [pay as you go]. We're used to the capex world where we buy a bunch of servers, which is very predictable financially. And predictability is a good thing in business.

When you shift to opex with the cloud model, you can have peaks and valleys, and it's not predictable in the same way capex is. From a budgeting perspective, CIOs are saying to finance people: "The good news is that we're using our resources better. The bad news is that we're not sure what the actual costs are going to be."

As for rolling up your sleeves and moving applications to the cloud, how should an organization get started? Do it piecemeal? E-mail first, and then grow from there?

Yes, we're definitely seeing an incremental approach rather than a Big Bang. IT lends itself to trying something, seeing how it scales and then modifying it.

The first apps to go are what I call "finished apps" like e-mail and CRM. With those apps it's kind of game over. There's very little uniqueness in how we use those apps, so they are the most ready to go to the cloud. In five or 10 years, we'll look back and say, 'why did we ever think about doing those ourselves.'

Custom-built applications are different. There are regulatory issues around line of business apps that a company has built. Also, they were developed a generation ago and appropriate for the technology of the time. They need to be modified for the cloud.

Internally at Microsoft, we have a complicated licensing application that manages volume licenses bought from Microsoft and supports our whole partner ecosystem. It has 100 components and lots of interfaces. It's not that we think it won't work in the cloud, but we must modernize it first. It was built 15 years ago. It's the kind of custom-built app that can't be taken as is and moved to the cloud.

At the enterprise level, most organizations want a private cloud. In an already crowded market for private cloud offerings, what is Microsoft's advantage?

A lot of it is portability. CIOs want to take advantage of the market, and you'll have private cloud offerings built on Microsoft technology available from us, from third parties, or you can build your own. Those are all indicators of our technology advantage. From a cost standpoint, those options will make a Microsoft cloud more available and less costly over time than models that have a narrower set of deployment and development tools.

Also, if you're already a .Net developer with .Net skills, it's a pretty fast transition from where you are today to a public or private cloud with Azure. There's no skill retooling needed.

What are some factors that could prevent an organization from moving to Azure?

I think the biggest barrier are applications a company has built that were not well architected for the cloud. So in that sense you can't move them to our cloud platform or anyone else's either. Those apps just need to be redone.

On the commercial apps side, the big platform vendors that are supporting Microsoft today will likely continue supporting Microsoft. At the end of the day, I think Microsoft will offer the broadest set of choices across the broadest set of technologies, whether it's support for PHP or whatever programming environment you really like, it's more likely to run on Microsoft technologies than any others.

What do you say to CIOs who still don't trust the security of a cloud model?

Well, it's something we always should ask about, but there's great precedence in the outsourcing world. We've all moved our servers to other people's data centers over the years. The concept is not new.

I do think there's a false sense of security when you're running your own data center. There's a lot security in having a contract in place that makes a third party responsible for security. My view is that it's similar to the outsourcing model in terms of the benefits, but you also have this contractual right to expect great security from your cloud provider, which is probably better in the long run than the old practice of running everything yourself.

Copyright 2017 IDG Communications. ABN 14 001 592 650. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of IDG Communications is prohibited.