Microsoft works to claim its own slice of the cloud

SCOTT FULTON, Managing Editor, Betanews: I've heard every company -- Microsoft included -- that tries to make a name for itself in the cloud space, use some type of scale-based analogy. Talking about "economies of scale" or "scale-based computing," and that the model "scales" better if you adopt it. What you're saying...sounds to me like it doesn't scale for everyone.

I'm thinking of it this way: If we really worked on a proper economy of scale, then every good scale has a basis. A small customer would be able to invest in cloud computing technology, and be able to reap the benefits of that investment, on the same basis as a large customer, because what you would be scaling is the investment, but what you would be reaping would scale with the investment. So you would think that, if you say, "Well, you'd be able to recoup your investment in three years," maybe that three years would apply to a small company, a medium company, or a large company if what they're saying, if the model truly does scale, is accurate. But it sounds like you just said your customer did the model and said, "You know, I'm not going to be able to recoup these costs."

JAMIN SPITZER, Director of Platform Strategy, Microsoft:For some apps. And a lot of that is, we're really looking at existing apps and existing app architectures.

SCOTT FULTON: Which is the stuff that people want to leverage.

JAMIN SPITZER: Right, exactly. So if cost is the primary driver, for some application scenarios, it makes sense -- cost, security, compliance, control of data -- that this stuff stays on premises. Other circumstances, it makes to say, "Okay, that's a commodity workload, and it would take 100 man-hours to take that app and put it in the cloud." That's something that's worth investing in. Or maybe it's not, it depends on how much work it's going to take to re-implement that application, whether it's on hosted infrastructure or in a cloud-based, multi-tenant, "scale-out" environment.

SCOTT FULTON: So have you come up with a set of rules, like expert system rules, for helping a customer determine when their existing investment in applications can scale better to a cloud scenario, and when it does not?

JAMIN SPITZER: Yea, we are actually in the process of being able to articulate some of that stuff. There's a group within DPE called Patterns & Practices that has some work that is coming out, and part of that is also a learning experience for all of us. So getting Azure to market, getting enterprises and partners to really start kicking the tires -- and we're really in that phase right now -- we don't necessarily know all of the existing scenarios and choices that customers have made. In a lot of cases, it's going to be dependent on, how tightly integrated is that application to other applications? What's the data schema? How much processing does that application itself actually do?

If you bought cap-ex hardware and you're running that on premises, the cost consideration for adding more processing is a very different equation than saying, "I'm going to pay for processor by the hour." I'll give you an example of a company that we're working with right now, where they did a very small change to their application that had real dramatic impact on costs. It was an on-premises app that basically had some screens in which the user -- which in this case was a sales support person -- would enter data from the customer interaction. And then all that stuff would get pushed to the server, and the server would do some processing and come out with some outcomes. And what they realized they could do was actually change the app a little bit, do some of that processing on the client so that the client is doing a little more lifting, and in so doing, push so that the data that ends up getting sent back to the service is more metadata oriented and more "half-finished" workload, so to speak. And in so doing, the solution required less processing on the back end, and perhaps more importantly, less bandwidth on the back end.

SCOTT FULTON: In the scenario you just described, you could make the case for a sale for asynchronous processing as a model, saying you would not have to make too much investment in humanpower and resources to switch from a sequential processing model to an asynchronous one, that would enable you to do some processing on your premises, some on your client system, and some in the cloud.

JAMIN SPITZER: Right. But in every case, you need to ask how that app was originally written, and how that app has been upgraded, and how it's been maintained. In almost every case, there's going to be a number of variables that will have an impact on a) how much will it cost to change it; b) what will those costs look like when they become part of a metering system?

SCOTT FULTON: When Windows Azure was first announced publicly at PDC 2008 in L.A., at the time, the folks in charge of the platform were saying, "We're jumping into waters where we really don't know where we're going on some of this, and we're going to find out some of these things along the way." Now, here we are in July, and we're talking about a situation where on almost a per-customer basis, we have to learn what the customers' needs specifically are, on a very granular level, finding out whether it's possible to re-architect their applications for an asynchronous scenario. And it requires, I would think, a lot more in-depth communication -- maybe on a level that Microsoft hasn't done in a long time -- with each customer. And I guess the question Dr. Phil might ask at this point is, "How's that workin' for you?"

JAMIN SPITZER: Well, bear in mind, we are still in the Community Tech Preview phase. So how's it workin' for us? In that [phase], we're learning a lot. And I think that some of those app patterns that we're driving towards, I think we're in the process of learning. And I think that's an important piece that we and our customers and partners learn about.

If you look at what Amazon is doing, and you compare it to what we're doing and what Google's doing, we feel like where we are is both a better place in terms of taking advantage of the cloud, but also providing flexibility and deployment of choice that is perhaps not prevalent elsewhere. And that requires a lot of nuance. So in order to be able to say your app should work symmetrically across Windows Server and Windows Azure, you need to do (foo)...I think we're getting closer to that, and we're starting to work with the right customers and partners that are helping us inform those decisions.