But once we decided to really make it like a Windows in the cloud, that's a decision where you say, well if we're going to build those APIs [application programming interfaces] for our groups internally, let's make sure we also give them to people externally because they'll find just as much benefit as we did. They don't have those people who run hundreds of millions of user services as we have. So I can't say there was ever a time that it was only for internal use or only for external use -- they really kind of grew up together. There should be no question it will help us run our internal things more efficiently, but we're really measuring our success more from the external feedback because it's more balanced than the feedback we get internally.
So you said Azure is different than just taking things and putting them on the cloud. Can you tell me how?
Let me try to describe it -- this is not an analogy I've tried. Let's say that Richard [Eckel, Ozzie's colleague] over there tossed me a tennis ball, and then he tossed me a second one, and he tossed me a third one. I could possibly juggle those three. Each ball that I'm taking, I'm doing what we in the industry call scaling up. I'm the computer and I'm doing these things as much as I can. Now, let's say he throws 100 balls at me. There are limits to the scale-up model and if I fail, all the balls will fall to the ground. But if we together as a group decide we're going to take turns, as he starts throwing them -- hey you grab that one, I'll grab that one, he'll grab that one -- there's a chance that by just adding more people, we can take any number of balls that he'll throw at us. And if one falls down, then maybe the guy next to him will pick it up, but he'll keep going. That's called scale out. It's basically saying the more tasks you're juggling, the more you can just keep adding things, and it just works in that way. The systems we've built for enterprises are really the scale-up model. We build a system and we try to add hardware to make it get bigger and bigger and support bigger and bigger enterprises but eventually that kind of falls apart. Something like Notes or Exchange has a history in building up and up and up. Hotmail started at exactly the opposite way, knowing it had to scale to hundreds of millions. There's a process you use to take an enterprise app and change it and rethink it to be that broad, horizontal thing. We've done that with Exchange, and we're doing that with more and more.
So that's the model Azure is going to take. It seems like it's more like worrying about how you're going to architect the hardware to meet the application, but the application sort of meets the challenges [of different tasks].
That's exactly right. It would be writing a program to be able to catch one ball and keep bouncing that one ball and cranking up a lot of them to handle all of them coming at you instead of designing the app to try to juggle.
