Speech Transcript – Paul Flessner, Tech-Ed 2002

PAUL FLESSNER: Well, that’s the kind of wakeup call you need after a long night in the French Quarter, hmm? (Laughter.)

All right. Well, thanks a lot for coming out. The first thing I want to do is thank all of you very, very much. We appreciate you taking the time out of your schedules and traveling and getting up early this morning after you were probably out until early this morning, and we really want to pack the show with a lot of good information, so hopefully you had a good time yesterday and learned a lot and hopefully you’ll do the same for the rest of the show, so you could take a lot of good information back to your job and do a better job for everybody involved.

I’m pretty excited about this talk actually. I mean, when they came to me and they said, “Flessner, we need you to do the vision thing,” me on the vision? I’m the product guy. I’m the builder. I’ve always been the D part of research and development, not the R part.

They said, “No, you’re up for the vision thing.” And I said, “Okay.” I was always kind of envious my entire career. I spent 20 years building product and I was always kind of envious of the research guys, thinking, “Man, they sit there. They think these ponderous and sometimes pompous thoughts about the future and then they throw it over the wall and they say, ‘Why don’t you just go ahead and build that for us, buddy.'” And they kind of complain when we don’t get it done on time or the way we want it, so I thought, “Man, this is pretty cool; I’m going to get a chance to talk about the future.” But hopefully it’s a little future that’s grounded in development.

You know, my background is development and product development and this is a little bit of a different talk. You’re not going to see a product roadmap specifically. We are going to talk about a roadmap in terms of what we think the industry is headed for in terms of Web services.

So it doesn’t take a large stretch of the imagination to think okay, you know, if that’s where Microsoft believes the industry is going and where we’re trying to push the industry in some ways, it doesn’t take a large stretch of the imagination to think that’s also where their products are going to go.

We didn’t make a specific product roadmap because it’s hard sometimes. It’s hard when you’re looking out into the future to always be able to map the products to it. You can map products pretty accurately, the release you’re working on and probably the next release after that, but that’s only about a three-year window overall. After that, if people are telling you the product roadmap you want to kind of look at it with a squinted eye because you know it’s going to change somewhat. When you start to look out five, 10 years, which in some cases this talk does, it’s a little bit fuzzier and I want to say that right up front.

So from a couple different perspectives this talk is different. It’s not a product talk. There are no demos in this talk and we cover a lot of space and a lot of area, and there’s a lot of angst back at Microsoft about this talk. They said, “My God, you’re going to be touching on these new topics and you’re going to have new terms.” Well, terms are a bad thing, right? If you’ve got terms, you’re going to introduce new terms at Microsoft you’ve got to go to the word police and legal and everybody else because they get really nervous about new terms.

So we purposely used kind of some goofy names for some of this stuff, things like Fiefdom and Emissary and Workspace and others because we know it won’t stick and honestly we don’t want it to stick, okay? So we’re just going to introduce some new concepts and talk about that. We’re also going to talk about when it’s appropriate, where our products map to that, and again overall I think it’s very fair to think about our product map over time mapping very well to what we’re going to talk about.

So with that let’s get started.

I came from IT. I did 13 years in IT before I came to Microsoft, all the way from a developer job up into managing a data center and then to CIO. So I understand the position very well and I continue in my job to work very closely with IT professionals and developers, and I always mapped it to two big things. The job I believe of IT and all of us that help IT is two things. It’s do more with less. It’s about productivity. It’s about really making sure that we’re leveraging the assets that we’ve got. It’s about making sure that we are very efficient in our thinking. It’s about leveraging new technology, but in the eye of not for the sake of technology, in the eye of always being more efficient, because we are a cost overall to the operations that we support.

At the same time we’re a cost we always have to add value. So business value is critically important, and I think business value from IT comes in kind of three dimensions. One, how are you helping us grow our revenue? How are you helping us get out and touch our customers? How are you helping us build customer satisfaction? So getting out there and getting connected to our customers.

The second is how are you helping us increase the profitability of the company? How are you helping us connect to our partners? How are you helping us cut costs out of our supply chain; so really focused on growing profitability. Wall Street only rewards two things: revenue growth and profitability growth and you have to have both.

And the third is empowering employees. Are employees absolutely productive? Do they have all the information they need? Are they helping you to grow revenue and profitability?

And those two primary areas, the TCO and managing TCO and business value are fundamentally how I ground the development teams at Microsoft and it’s the way we think deeply about the things that we’re evolving forward.

So that extended enterprise, as I call it, is something we’re going to talk quite a bit about today. I think business value is a key thing that we’re bringing with Web services and that’s how we want to kind of frame some of this discussion.

We started looking around for some data points around this extended enterprise concept. If you remember back in the ’80s there was a ton of mergers and acquisitions. They were happening all the time. Some of them were successful but many and most weren’t. I actually lived through one that wasn’t successful. It was praised in the late ’80s as a very successful merger. Six years later they actually broke the companies up and went back. And because they find out that two companies that have their own centers of expertise don’t always complement that well, cultural differences, things just don’t like up; sometimes they’re just 100 percent redundant, which causes a whole other array of problems. So mergers and acquisitions, and these are actual numbers, have really leveled off.

But look what’s happened to this concept of strategic alliances. This is a concept where everybody does what they do best but we work together. So if I’m a manufacturer and that’s my area of expertise, I’ll manufacture. If you’re a distributor, rather than me buying you or you buying me I’ll hand off to you. If I’m a services organization I’ll work with the distributor and the distributor, services, manufacturing all line up as part of this strategic alliance.

And, you know, strategic in this case means something real, not a couple of marketing brochures but some real business dependency, and you can see they really have taken off.

So I believe it is one of the imperatives for us in IT to make sure that those strategic relationships can work and that we can build this economy and help all of it to function in our areas of expertise and allow those things to hook up and grow.

So we started thinking a lot about this analogy of Web services. The Internet is out there, right? It’s been out there, but is it functioning as effectively as it could? Eric had a slide yesterday at the beginning of his keynote that talked about the evolution of the Web kind of HTML and then kind of the better UI and update and then kind of XML in terms of programmability. And Web services are really about getting it all connected and making the Web more productive.

And I was trying to think of an analogy, something in history that would kind of resonate with people to try to make this point. And believe it or not, my colleague, who will be out here in a minute and I’ll introduce Pat Helland, came up with this idea of the railroads. He said, think about the railroads. They started laying track for railroads back in the 1840s and it went along and kind of plodded along happily for about 40 years up to the 1880s, and then things started to really take off. You can see it on the graph how the miles of track really exploded.

Well, what do you think happened about 1880 that made that explode? They introduced standard gauge track. Before that, if you were in a train there was actually this statement was true, “You can’t get there from here.” There were different size tracks and they were different widths and you had to build different locomotives. And one locomotive couldn’t work on another set of track and things just weren’t mapping together, and people realized, “Hey, guys, this isn’t going to work. We’ve got building railroads down; we know how to do that. We’ve got building locomotives and train cars down; we know how to do that. But this stuff isn’t lining up and it’s not happening the way we want it to.” So you can see the explosion of track when we got standardized, standardized on track and standardized on cars.

Look what happened to the gross domestic product of this nation soon after things started to line up. You can see it start to jump about 1890, ten years later, and then really take off kind of the 1900 timeframe when Ford was starting to figure out assembly manufacturing and all those kinds of things.

So I thought this was kind of an interesting analogy to think of. So we’ve had the Internet, right, and what we’re trying to do with Web services is really get the rails to align and really get the next push of productivity out of this thing.

So in terms of this talk and how we want to think about the impact that Web services are going to have on technology we’re going to look at it kind of across three dimensions and we’re going to do that across those three dimensions kind of for today and tomorrow. I’ll talk a bit more about that in a minute. But we’re going to do it in terms of the application model, you know, what impact it has on the way we program and how we think about messages and transactions. We’re going to do it in terms of data, how we think about data today and tomorrow. And we’re also going to talk about trustworthy computing, and trustworthy computing is a pretty big umbrella. In my mind it’s the abilities, a lot of the things we think about in terms of TCO, manageability, serviceability, scalability, on and on, and it’s also quality, it’s also security and it’s also privacy. And we’re going to talk about each of those dimensions.

But rather than jump right into the talk I thought what we’d do is bring out a customer, who’s actually done a lot of work in the area of Web services today, because I want to make sure that everybody understands that Web services are real today and that there’s a lot more work we can do to make them better.

So what I want to do right now is bring out Dave Green from Nationwide Building Society in the UK. They’re a big retail banking and mortgage company in the UK and he’s going to talk about their experience with Web services.

Hey, Dave.

(Applause.)

DAVE GREEN: Good morning, Paul.

PAUL FLESSNER: You want the clicker? Okay. Well, tell us about Nationwide and your experience with Web services.

DAVE GREEN: Okay. Well, the Nationwide Building Society, to set this in context, we’re actually a retail financial organization. We have about 700 branches in the UK and assets, by the way, are currently about 75 billion sterling, which if we operated in the U.S. market would make us the 11th largest bank.

We actually came to the conclusion over a year ago that .NET is a pretty impressive piece of technology and potentially of enormous significance for our business, but being technically impressive does not automatically make it good for business. So what we wanted to do was to set out and find out whether that was the case.

And the sort of things you need to be good for business you need obviously to do scalability, productivity and that sort of thing, but the thing we focused the most on and the thing we thought we would at least like to get an answer off the ‘Net on is, Can it build a serious business system?

So what we did is we took a system we had already live in which we’d invested 40 man-years of assets, and it, in fact, is an extended enterprise system. It takes mortgage business from a mortgage broker that we then fulfill with mortgage products. It’s an important business for us. As it says down there, it is a significance business and I can’t say how much, but if you think in six figures a day you might not be too far out.

So what we did is we took this thing and because we have high quality methods today to run it we generated an equivalent in Visual Basic .NET, which, as you can see there from the numbers, turned out to be quite a substantial application. It came out to 23 megabytes of compiled code in the end.

We liked two things in particular about what we did with this. The first is that we actually got rid of 200,000 lines of proprietary infrastructure. That’s expensive stuff to maintain. We found that using the CLR that we only needed 10,000 lines of CLR code to do that work, and that’s because all of the rest of that infrastructure functionality was delivered by the CLR and that replaced the proprietary stuff we’ve been doing before with the same function.

The other thing we liked about it is it works. It went in on February the 8th. The customer, which, as I said before, is an important intermediary channel for us, didn’t actually experience any impact. It just went in and it worked.

So it was a good experience with Web services.

PAUL FLESSNER: It’s always a good experience when it works.

DAVE GREEN: It’s a very good experience.

So now I want to take you forward. So let’s imagine that we liked that experience so much, and we did like that experience actually; we’re committed to rolling .NET across the enterprise for our development. Now let’s fast-forward a bit. Let’s imaging a world where we’ve wrapped all of our existing legacy hosts, we’ve wrapped all of our Web servers and our internal NT-based servers with Web services. That’s what that line along the bottom represents. Of course we’ve got to deliver those services or the data from those services to a lot of channels and this is a representation of most of the channels we deal with, the call center, the Internet, third parties and so forth.

Now, if you actually look, and these lines are, in fact, a realistic representation of how these things work, these are the interconnections of which of those channels use which of those Web services today, and, in fact, we’re pretty much at this situation because we’ve been working on proprietary precursors of Web services, hence the 200,000 lines of infrastructure we got rid of. So that’s where we are.

The thing to note about this picture, apart from how it’s fairly complicated, is that it is a massive success. We’ve found it to be a big win. It means that we can deliver the data we need into the applications that we actually need to deliver to our business users and we can get that working and we can do that without the constraints we had from the sort of stovepipe approaches that were in the past, where typically you’d have a system that delivered that data to that channel.

However, you get to some of the upper ends of success and apart from the reward of getting the business function delivered the other main reward is a new set of better problems, and this is not exception; there are some better problems. And what I want to do is talk about that set of problems because I’m hoping my pals here might do something about solving them.

So the first problem I want to talk about is actually indicated on the slide. You’ll notice that some of the boxes along the bottom don’t have business names, aren’t named after business functions; they’re named after the systems on which they run. This is the hint that something is not entirely right. And, in fact, if you look at what those boxes do you’ll find that there’s an unfortunate dramatic implication between them of function. This is because they weren’t designed to cooperate in the distributed environment and over design stand alone silent.

So you’ll find that we have several implementations of support for mandates, such as things like the ability to make payments through standing orders and to write debits and so forth. We have several implementations of the end-space with the inter-bank payment clearing systems. Why? Well, it’s history.

But the unfortunate consequence of that is it means it restricts our business agility, because if we want to make a change to let’s say the way our payment systems work what we’ve got to do is we’ve got to find all the places that we have to touch not a trivial problem in itself, and then we have to change them all and we have to coordinate the release of those changes; again, not a trivial problem.

So what we expect to happen over time is we expect to be taking those duplicated functions off the old big iron and deploying them on the servers, because the server technology is just a fast place to develop; why wouldn’t we develop there? That’s what we want to do.

Okay, so we can expect to see more of those server boxes and we can expect to see them exposing particular business functions and that means the data that goes with them.

Of course, as that goes on what it means is there will be mission critical data and over time more and more mission critical data exposed on those servers. And that will raise the architectural questions of here we’ve got mission critical data now for the first time playing internally in a distributed environment. What are the architectural issues that that raises and how do we solve them?

The second set of problems I want to talk about can be classed as management and we have two management problems. The first management problem is operational. Today we have over 450 NT and Win 2K servers in our data center, and we have a couple of guys whose reason for living is to manage those beasts. And I have to say, without giving too much competitive information away, that we haven’t actually got it quite cracked yet. You know, this doesn’t always go entirely to plan.

So if we’re building more of these servers then we’re building Web farms, we’re building farms for them in order to get the availability and reliability up. What’s going to happen on the management front? These systems are not being managed by rocket scientists; these are being managed by ordinary human beings. And another key thing we need to make this platform a realizable possibility is that the management stuff is easier and easier to do and there has to be less and less human interventions over time.

The other management problem that this raises is what I call managing the manager. And the reason for that is every time I say I want to move some mission critical data off my big iron, where everyone feels sale; it’s been there for years, onto one of these newfangled server things they all go, “Hmm. So you’re proposing to do this mission critical delivery on this new technology. This is Microsoft, right? This good news is overwritten by the next good news in the history of Microsoft. Why would I believe that this major investment you’re making in .NET delivery of mission critical data doesn’t look a sort of trifle dusty a couple of years down the line in the sort of way that other component and so forth do now?”

Right, Paul?

PAUL FLESSNER: Totally. (Laughter.)

DAVE GREEN: So I’ll be interested in hearing something on that.

PAUL FLESSNER: We’ll get to that.

DAVE GREEN: Good man. (Laughter.)

The last issue I would like to raise is a complaint we get from the branch staff. Okay, now delivering all these Web services, I’m delivering all this magnificent data toward the end point; I still get complaints from my end users, I get complaints from the branches that say, “Well, I can get to all these functions, I can get to all these things now, but actually when a customer comes into the branch they don’t say, ‘Do this and do that,’ they say, ‘What I want to do is I want to close an account. I want to take all the funds out of that, I want to use that to pay off part of my mortgage.'”

Well, as a member of the bank staff you have to know which things to go to in what order to actually achieve that outcome. And if it’s bad for a member of the branch staff, how bad is it for a customer on the Internet bank? We would actually love our customers to be do as much as possible in Internet banking, first of all because it makes them feel empowered and secondly because it saves us money; let’s be honest about it.

So in order to do that they’ve got to be able to approach the system in a way that speaks in their terms, and that’s actually not directly possible from Web services today.

So what we expect to happen over time is we expect little clouds to appear and those little clouds to represent and encapsulate pieces of useful business function that are expressed in a way the customer can understand. Those get exploited in multiple channels and they in turn consume the Web services to get access to the data.

That’s about all I’d like to say. I’d like to hand you back now to Paul Flessner, who’s going to tell you how all these dreams are going to get made reality.

PAUL FLESSNER: There we go. Thanks, Dave. Thanks very much.

(Applause.)

PAUL FLESSNER: That’s a good practical example of some Web services for today and then some thinking about what they want to do in the future, and what we want to do is talk about how we’re going to make that happen both today and tomorrow. So again we’re going to go back to that previous slide and think about the application model and how we build applications and we’re going to talk about that from a today perspective and what’s possible and where we’re at and, when realistic, I’ll talk to you about the product plans in that space, what’s shipping and what’s soon to come, and then also tomorrow and we’ll do the same for the tomorrow space.

So we’ll go down and we’ll talk about the application model, the data and trustworthy computing. And to help me go through this process I want to bring out a colleague, a gentleman named Pat Helland. Pat’s actually kind of famous in the industry. He’s been in the industry a long time and dates back to kind of the beginning of time of transactions and did some groundbreaking work in the early days of transactions. He worked at the Tandem computing company where he worked on TMS and did kind of the base plumbing for the TMS technology that went into the Guardian operating system and also worked in the area of database on Nonstop SQL.

Since coming to Microsoft he’s done a lot of work on our transaction model, the COM Plus transaction model and is now doing some work in the future that will ship in the future around our messaging strategy and our transaction strategy.

So Pat’s got a lot of rich technical experience. He’s a senior architect at Microsoft and he’s also a heck of a nice guy and kind of entertaining. So help me welcome out here Pat Helland. (Applause.)

Hey, Pat!

PAT HELLAND: Thank you, Paul. Thanks for having me, and I just want to point out that I’ve been at Microsoft for a while. I’ve done a few of these events and I’m particularly struck today at the progress we’re making, especially in the area of scalable middleware. They got me a shirt that fit! (Laughter, applause.) I can’t believe it; it’s the first time.

PAUL FLESSNER: All right. I told you he was a little entertaining. This is a great personal career risk for me to have Pat on stage. (Laughter.)

All right, so the way this is going to work is, I’m going to talk a little bit about today, as I said, and then Pat is going to talk about tomorrow. We’re going to tee this up and talk first about the interconnected monolith. When we say monolith in this case we mean applications. So how are we going to use Web services today to get these big applications that we’ve already got, legacy applications we’ll call them — legacy means working and earning money — and how could we get them connected and how can we use this concept in Web services.

So we call this connecting the monolith. Now connecting the monolith in this case is something that we’re all familiar with. EAI, you’ve all been there and done that, right? Inside the firewall you’re wiring this stuff together. These are systems that normally aren’t even made to talk to each other. This is your SAP and your Siebel and your JD Edwards and your Home Grown. Trying to get all that stuff to work together is painful, it’s tedious. We have gateways, we have connectors. But it’s very important and we have to do it. That’s inside the firewall.

Outside the firewall you’ve still got to reach out, right? Remember, we’ve got to connect the customers, partners and to employees. So we’ve got to get outside the firewall and we’ve had some success with that. I mean, EDI, I did a lot of EDI translation with AMPX 12 translators, and we made a lot of things work: The grocery industry, healthcare all have been very successful around that, but it was never really designed to be a native protocol for programmability and something that you could discover and really propagate. And so it really hasn’t been the big success that we had hoped.

There’s also just a lot of point-to-point communication, you and your trading partner agreeing on a protocol. It really isn’t something that spreads out wide but it works and you’ve made it work.

And all this stuff is kind of complicated work and we actually have a name for this. We sometimes call it HST — Hooking Shit Together. (Laughter.) It’s a very technical term that we worked on. (Applause.)

So I think the first Web services, just like Dave talked about and many others have talked about, will just be wrappers and that’s okay. Nobody should feel bad about going home and saying, “I’ve got to think of pragmatic ways I can make this work.” I was talking to Daryl Plumber for Gardner and he said he was talking to a customer who said, “I’ve done my first Web service and it’s just a listener and a proxy for Port 80. That way I don’t have to go and fiddle with all the other ports; I’m just going to listen on Port 80 and be a proxy server there.” And there are all kinds of practical examples for Web services and that’s okay.

In our space we’ve got a product called BizTalk Server that does a great job in this space. It can sit there. It can be your connector to your back-end systems. It can also reach out through the wall in XML as a Web service and communicate with other Web services. In that process there is data transformation; sometimes there’s workflow and BizTalk does all of that and can make your job a little easier. So that’s our helper in that space.

So Web services overall, as I said before, is just about I think a lot about connectivity, standardizing connectivity and making sure things will work together. And the set of standards that we’ve been working on with a lot of other companies as well are really kind of the key to get this whole thing going, and you can see the list of standards we’ve got up there. I actually did this slide for you last year at Tech Ed. UDDI, a locator, some people need those locators to find a service, maybe for an auction or something or just something out there you want to hook up with. Some don’t. You could still do Web services with people you know and can connect to. WSDL, understanding what the service does. SOAP, kind of a descriptor and a wrapper for how things come together. XML and IP, you’ve heard all those.

Well, we are excited to make an announcement. I woke up this morning and turned on the TV and there it was, and Bloomberg was talking about the alliance that IBM and Verisign and Microsoft have put together to really think about Web services in terms of security end-to-end; obviously an important topic to all of us and very timely.

And we’re announcing today ASPEC, a specification on security and how you actually will take security tokens and SOAP wrappers and get secure across the Internet. We’re also announcing a roadmap for six more specs to come that will think entirely about security end to end. This is a very complicated topic as you start going cross domain and delegation and all those kinds of things, and you have to recognize that there will be multiple different tokens for different kinds of systems that will all need to be in one packet and cooperate.

So I’m very excited to be able to have the privilege to announce today this working cooperation and that’s going to be important. Web services don’t work, right, the rails don’t align unless we all agree on a set of standards. And we’re excited to work with these partners to get this thing promoted.

So with that I want to kind of walk away from the monolith and let Pat talk about what the heck autonomous computing is.

PAT HELLAND: So I’m going to explain what the heck autonomous computing is. Autonomous computing starts out with the idea that you’ve got a system and that system is independent. It’s not going to trust anybody. It’s managed independently. Somebody’s job is on the line if it doesn’t work. It’s doing a business function and so it’s really, really carefully not going to trust anyone from the outside. It’s managing data that is shared across lots of users, classic transaction processing, getting in and out of the data that you’ve got inside.

So how are you going to get work done from this fiefdom? The only way you’re going to get work done is to send a message in, give it a request.

Now, this fiefdom is going to have business logic that picks up the request, processes it and does the work and gives back an answer. I think you guys would see that this is what’s happening in the industry because machines don’t trust other machines, so the only way in is via a message and business logic with the answer coming out in a message. So we’re putting a name to that concept and calling it a fiefdom.

PAUL FLESSNER: It’s a goofy name, a name that won’t stick.

PAT HELLAND: It’s a goofy name, right, but it’s a name to make you see that this is a thing that’s surrounding that shared, protected data, and it’s not going to trust outsiders, it’s not going to do a distributed transaction with someone else because that other person might hold the lock stuff and there’s no way my data is going to get locked up by Paul. I certainly don’t trust him, right, no way to do that. When the work comes in you are going to verify that everything is okay as that message comes in before you give an answer back out.

So again this fiefdom might be one machine, might be a collection of machines, but it’s always going to be managed and deployed by one organization and it’s not going to trust the outsiders and it’s going to do work on that behalf to care for that shared data.

Now, an important point is we actually think the design of this, the design of the Web services interactions coming in and out of the fiefdom is one of the most important things that we’re going to see in applications as we move forward.

Now, we’re going to introduce another kind of program, and again I believe this is something that’s occurring through the industry. People are building this. We’re just putting a goofy name to it. It’s called an emissary.

Now, what does an emissary do? An emissary helps you work with a fiefdom. What does it do? Two things: It displays information and it helps prepare requests that are going to go back to that fiefdom to get work done because it’s kind of a pain to fill out those forms and get all that filled out. A human example of this would be a mortgage broker helps you fill out the forms to get a loan from a bank, talks to you, is pretty friendly and then sends the stuff in.

Now, in general the emissary is not trusted by the fiefdom. When the work comes into the fiefdom it’s going to go through all of the fields in the message and say, “Hey, if this isn’t right I’m rejecting it,” or “This is okay; I’m going to do the work.”

A very important part of an emissary is that it only uses two kinds of information: reference data and per user data. Go back to the mortgage broker. It’s got loan rates. The mortgage broker has information about what banks will send you what, what the qualifying rules are to get a loan, how the form gets filled out, and then there’s a folder for you as a specific client that gets put away and there are other folders for other clients. But that mortgage broker never works on two clients data at the same time. It’s always one at a time.

Emissary can be Web services; it’s a great way to build them. And we see this pattern over and over that a lot of code is build not using the shared data but using reference data and just single user data.

PAUL FLESSNER: That should give us a lot better scalability, which is going to help.

PAT HELLAND: Oh, way better scalability. We’ll be talking about how that helps with the scalability, the fact that you’re not fighting over the shared data.

PAUL FLESSNER: Excellent.

PAT HELLAND: So let’s rethink data. Only that fiefdom has that current shared mission critical data. Only inside of the boundaries of that protected machine does it know the true state of the inventory, the reality of what the business mission critical data looks like.

Now, that fiefdom isn’t going to share a transaction, because if it does it’s going to have to lock its data up and it’s going to be, at least for that piece of the data, kind of temporarily out of business and that’s not good.

So what’s he going to do? He’s going to get a message, do some work with the transaction, change some stuff maybe and send some information back out, but it’s committing and unlocking as it does that.

So the data you see outside that fiefdom, hey, it was true at the moment you unlocked it but there’s nothing to say somebody didn’t come right after it and change it. So if you’re outside the fiefdom and you see the inventory balance is 200 widgets, it might just be a hundred widgets because somebody else ordered a hundred right between when the message was sent to you and when you saw it. This is how people are building these independent, autonomous machines.

The idea behind the autonomous computing application model is that it describes how the heck you’re going to get work done when these independent machines can’t keep things locked up, when the data you know isn’t current, isn’t the latest and greatest.

Most of your application is going to run outside of that tightly coupled fiefdom that owns the mission critical data. How do you get work done when it doesn’t know the authoritative latest and greatest current information? And so that’s the point and it really doesn’t matter if the data is a second old or a month old; you just flat out don’t know that it’s still true anymore.

PAUL FLESSNER: Well, that seems kind of scary. What are we going to do about that?

PAT HELLAND: What are we doing to do about that? We’re going to talk about that.

PAUL FLESSNER: Great. It worries me that I have old data.

PAT HELLAND: It worries me that you have old data. There are a lot of things that are old about me that worry me. (Laughter.)

So I’ve got fiefdoms and emissaries. Both fiefdoms and emissaries are Web services. Both of them communicate using Web service requests to each other and to the outside world.

So what we’re going to do is talk about how the apps can be comprised of these loosely coupled systems where the stuff on the outside doesn’t quite know the latest and greatest but it’s still doing wonderful and useful work and the stuff on the inside is controlling the latest and greatest data.

So again fiefdoms, in summary, use any kind of data they want. They’ve got the shared data, the reference data and maybe some per user that; that would be fine. Emissaries use read-only snapshot reference data. I like to think, for example, of the JC Penney catalogue or some department store has sent out this catalogue and that’s reference data and it hasn’t changed in the last three months, it’s still good for six months, and I can sit down and fill out the form on it. An emissary works in the same way. It’s using reference data that’s a little bit old, but it’s okay that it’s old because the app is designed for it to be old.

PAUL FLESSNER: The key thing is understanding which is your shared data that’s critical that you can’t replicate and which is going to be this reference data.

PAT HELLAND: That’s correct. And not only that, designing the incoming request to the fiefdom so that they can tolerate the fact that the data is a little bit old in the right circumstances and have the correct answer that meets your business goals.

So let’s talk about transactional services. I’m an old-time transaction guy. I believe in transactions, bit time. Both fiefdom and emissary services are implemented in the same way. The particular work for that particular thing is stored in the database so it can survive crashes, it can restart easily and if it comes up and it’s halfway through a transaction and crashes it goes back and starts over. That’s normal goodness of database transactions.

Each piece of ongoing work is what we call a service instance, so that would be like a single purchase order. I might have the purchase order service but I’ve got lots of, maybe 10,000 different purchase orders going on and I’ve got information about this one and information about that one and information about that one. Each of those is a separate service instance.

Incoming Web messages are going to invoke the service instance. And if this Web message is related to a previous chunk of work for a purchase order, you’d better go find the data about purchase order number 12345 and tie it together with the incoming message.

You’re going to have a transaction that will consume the incoming message, modify that per instance data, just the stuff about this purchase order. If it’s a fiefdom it might modify the inventory, something else that’s shared, right, and then it will generate outgoing messages and commit.

So what you see here is the incoming message, modifications of the shared stuff, modifications of the private stuff and generation of an outgoing message, and if you wrap that all in a transaction this is just a chunk of work, a quanta that if you fail partway through can be re-driven off of the incoming message.

PAUL FLESSNER: Well, transactions occur within an emissary and within a fiefdom, but messages communicate between the two?

PAT HELLAND: That’s correct. Transactions occur around the consumption and generation of the messages, but you’re going to be using the messages to hook the loosely coupled pieces together, because you’ve got a fiefdom, I’ve got a fiefdom. We’re going to send messages back and forth and my transaction is going to be separate from your transaction.

So let’s walk through an example application. I’m going to do order processing for some big online retailer. So I’ve got a fiefdom and it’s really doing the honest-to-God order processing. It’s going to periodically publish reference data: the product catalogue, the price list, the reviews, product reviews — do I like this book, don’t I like this book — availability — usually ships in 24 hours; things like that are information that’s a little bit old but really valuable reference stuff.

Now, I’ve got an emissary. It’s going to do the shopping. It’s going to do Web service or HTML support coming in. It’s going to build up a shopping basket we don’t have depicted because the screen is so busy, but that guy is going to have his shopping basket for each separate user as per user information.

Then it’s going to invoke a Web service to ask the order processing fiefdom; somebody pushes Submit, not it goes back to do the honest to Goodness work.

I want you guys to think about the fact that everything you did before pushing Submit was not in the fiefdom. It was sitting outboard, so all that chatter — looking, shopping, adding to basket — all running outside of that guy who’s got the special protected data.

PAUL FLESSNER: And that’s reference data that we can scale that out —

PAT HELLAND: Oh, reference data; you can make copies of that till the cows come home. You can just make lots of replicas of that because it’s okay. It’s not any different than a department store letter bombing the United States with big catalogues. It’s just a little faster and it’s electronic.

Now, that order processing is then going to perhaps talk to another business to do a credit check, talk to another business to do shipping. There you’ve got a fiefdom talking to somebody else’s — he doesn’t know if it’s a fiefdom or an emissary; he’s just invoking a Web service to talk to something else.

Let’s look at another part of this puzzle. I might have a fiefdom that surrounds a customer’s info preferences. I call this a partitioned or at least partitionable fiefdom. I’ve got important long-running data that I have to take good care of, my customer information, but you know I never mess with this customer at the same time as messing with that customer, so I could put it on 10 machines and if 10 machines isn’t enough I can put it on 20 machines and it partitions beautifully. So that’s what I would call a partitioned fiefdom.

And here I’ve got an emissary that’s going to come in to do update customer info. In this case he’s not going to use reference data. He’s going to probably go and say what’s the current data, modify it and then say, “Well, as long as it hasn’t changed, send it back,” and that works really well for customer updates.

But he’s also going to push out, hey, here’s information about my customers. That reference data is allowed to get a little bit old and you know we can do a cool thing with that; that’s great data for ad targeting. So as you come in with requests where you’re displaying things and you’ve got advertisements, which are looking at user preferences, it can work off of that reference data.

So here’s an example application that’s broken into pieces while giving the behavior that you need to build the solution.

We are solving two big problems with autonomous computing and Web services. One, connecting these monoliths: That’s what Web services is doing. And then finally decomposing the monolith: The new apps are going to be comprised of pieces and those pieces themselves are connected with Web services and so you can send the emissaries. You can either build them in your own Web far, if you want to, or we can talk about how emissaries can be run offline or run that other people think to prepare the Web services, if that’s what you want to do.

So here we have an existing app. It’s connected with Web services to another existing app, but we can take the app on the right apart and put it back together with shared data in a fiefdom, single user emissaries and Web data, and Web services coming in and you’ve got the Web services coming in this case directly into the emissary to do the job of the work on the outside.

PAUL FLESSNER: So there’s no rip and replace here at all. You can actually just wire two monoliths together and then over time start replacing them with this new design.

PAT HELLAND: Nobody believes that you can bulldoze your entire enterprise’s IT. It ain’t going to happen. It’s like building a subway through the city; you’ve got to figure your way around the historical monuments, and that’s what it takes.

Now, if you care more about this application model, I’m going to be talking at noon today in room C2 to go over this in more depth, this autonomous computing application model.

And so now it’s Paul’s turn to talk.

PAUL FLESSNER: Okay, data: This is one that all of us struggled with for a long time. Not all data is created equal, right? Knowledge workers deal with mail systems and file systems and pictures and documents and all those things and that’s a pretty good world but it’s not a world that gets connected real easy and a lot of people get very confused. They end up turning their mail folders into their file system and then if you’re clever you actually try to replicate your folder structure out in the file system and you always forget where you moved your attachments. It’s kind of a big nightmare and at the end you’re trying to search and find stuff, both files and content; it gets very complicated and hard to do.

PAT HELLAND: Some people say it’s a pain in the back; others have a lower opinion. (Laughter.)

PAUL FLESSNER: Exactly.

The home user has the same nightmare, you know, lots of different data and then more and more these worlds are coming together. The line of business app has been kind of a protected king for a long time to store massive amounts of information, quick updates, lots of fast queries but never the twain shall meet in the world today. You’ve got the files and what that represents and then you’ve got the database. So the knowledge worker data is not equal to the line of business data and the home data certainly isn’t equal to the line of business data.

XML has brought us a long way. It really does help us with data equality. Anything can be stored in XML, whether it’s a novel or a purchase order. The cool thing about XML is it’s self-describing and it’s tagged so you can start to understand, oh that’s the customer number that I’m seeing and you can do that programmatically. And that concept, that tagging, which databases have had forever — that’s structured data — is now going to become propagated both across unstructured data and structured data.

So XML has brought us a long way and a lot of product support, and I’m going to list the products there, a lot of product support from Microsoft and from our competitors, support XML today and that’s a great thing. It’s important that we’ve made that milestone going forward.

But honestly that doesn’t create overall unified data and I think we’ve got some more opportunities there, Pat.

PAT HELLAND: Yes, so I’m going to talk about what it means to unify the data and a couple of ways of unifying that data.

First of all, we think there’s going to be a common programming model moving forward. There is overall information rather than files versus database versus whatever. There are two trends that are coming together. The databases are adding chunky things. You’re getting blobs. The databases are storing things a lot bigger than an Nth nowadays and putting them out there and factoring them into how it’s used. Chunky data — files, stuff, e-mails, things like that — it’s getting more attributes. More and more is being decorated. You’ll start seeing things like cameras that can keep the GPS location within a few feet so that you can then collate that with the map to know, oh this was taken at grandma’s house, and you can search for pictures that were taken at grandma’s house; more and more decoration of these chunky things that we’ve historically called files and e-mails and things of that nature.

So these data objects are getting a richer structure, more stuff all tied together in them. XML is a great representation of that. You can put lots of things into XML, including the metadata describing, oh this is what this field means. This is how I interpret this other thing. We have a huge ongoing effort as an industry together, which is how do I rationalize the interpretation of this field against the interpretation of that field? What’s an address? What’s a person? What’s a contact? What are all sorts of different things? How does this program interpret it versus that program?

I actually think this is very analogous to what happened in the United States after the railroads started shipping stuff all over when you needed to be able to get nuts and bolts from different manufacturers. You didn’t have to do that back when there was only one local manufacturer. Now things have to fit together at an information level and that’s an effort that we’re all going to be working together to make progress on.

PAUL FLESSNER: Now, we are going to see some of that technology in the Yukon release of SQL Server. We’ve talked about that previously, been pretty open about it and we’re excited to talk about that, but I wanted to make that clear that that is a piece of technology that we’re certainly working on today.

PAT HELLAND: You know, I really like that animation. You were talking; I’m going to do it again. (Laughter.)

PAUL FLESSNER: You worked really hard on these slides.

PAT HELLAND: All that stuff goes into these workspaces and then it gets put away. (Laughter.) The art guys did just such a cool animation. I was so impressed. (Laughter, applause.) So they worked really hard, really hard on this.

PAUL FLESSNER: She was up all night actually.

PAT HELLAND: All night, all night making it look so pretty and I’m very impressed.

Workspaces define collections of data: files, e-mails, pictures, music. The data is going to have attributes and it may be searched. Those workspaces might be shared, you know, this is for my group, this is for my soccer team, or they might be private, this is my workspace, or it might be that my team at work, which is going to get things added to the workspace about to-do items for my department to do, and I’m one of the workers in the department.

These workspaces might be replicated. I could have a copy kept on my desktop, laptop or device. I keep it down wherever I am and I can have that workspace whenever I need it.

One part of the vision is if you get a new PC or a new device, all you’ve got to do is logon, say I’m Pat, and all my stuff can come back down from where it’s stored and kept safely, and so that workspace is just managed for you as a replica that can go offline or online.

It’s not trivial; there’s a lot of work to do. That workspace would always be accessible. We fundamentally assume that connectivity is going to come and connectivity is going to go. Sometimes I’ve got high bandwidth; sometimes I’ve got low bandwidth. Sometimes I’ve got no bandwidth, which can be painfully slow.

Rich subscriptions can exist about the way data changes. I can sign up and say, “Look, I care about things that are happening up in the sky over here and they should show up in my workspace.” Is there an e-mail from my mother-in-law? Is there a new report out from hog futures? Have the sales of turbines in Europe fallen by 3 percent? Tell me what’s happening on the status of my order over here.

PAUL FLESSNER: And the SQL Server notification feature that we announced yesterday —

PAT HELLAND: Is a great start on this. It’s doing a ton of work towards getting at the SQL Server notification.

But those notifications in this new future are going to reach me wherever and however I want, reliably and securely but maybe not when I’m in a high priority meeting with some important executive or something like that, and it will probably know where my GPS location is to interpret that maybe I’m in the restroom and it’s not the right time for this to be delivered to me. (Laughter.) It’s true; we’ve got cell phones, right? And it might be based on bandwidth. You know, this is a time when I’m in a really painfully slow circumstance, so don’t send me that 1 megabyte file because it would just be a drag.

Now, making the workspace accessible: Each workspace is going to have an authoritative home. Web services are used to connect to those copies. Updates are published and the requested changes are sent back. This is not necessarily classic replication because as the work goes back to the authoritative home you can talk about business rules that decide whether it just is an update in place with a change or whether you’ve pulled it into some business logic, and there you’re getting kind of like the fiefdoms and emissaries where the fiefdom is deciding what’s the right thing to do to the authoritative state of the data.

What we’re talking about is creating a framework for reconciliation, different policies used for different apps and circumstances.

This is about data equality. A person is interested in many things — pictures, contacts, e-mail, music, homework, to-do items, personal club deductions, soccer schedules; you name it, there’s a lot of stuff people care about.

Interestingly enough, line of business applications can actually give you the things that you need to do is a worker in the enterprise and have them show up kind of like a document. Here is some stuff I’ve got to get done and when I’m done then I do the following action to submit it. And that little bit of did I get it done can probably be done offline and then when I reconnect off it goes to the line of business application.

All of this can be in the workspace. What’s cool is I could go to that workspace and say I really want to look at the things related to Paul that happened during the month of April, and that might be a lot of things, including pictures of when we went out to get a beer and work items and documents and e-mail messages. And because they’re all represented in the same way I can grab them and ask questions about them. Once it’s in structured storage you can do all sorts of software to help you manage that information, and it’s about putting attributes on those items and reliably storing them and searching them and filtering them and finding them.

So in summary, what we’re doing is unified data and Web services. The Web services are the foundation upon which we can build this. Because we can use Web services to communicate in an open fashion that people can understand, those files and line of business data are easily accessible anywhere and any time.

PAUL FLESSNER: And we have made some concrete steps here as well. As we said, a lot of the technology goes into Yukon and we’ve also announced that Yukon, the technology of the Yukon store will be utilized as the next store for our Exchange server. So that ability to start combining messages and mail and all that goes on there in a rich structured store that can be backed up and maintained and very high speed and very high scalability is very much on our roadmap today.

So I guess I’m up.

Security, privacy and the abilities is something that we certainly work hard on, and honestly can do a lot more in the industry.

Quality is near and dear to my heart. I tell you that this is something that we have worked hard on and there’s much, much more work to go. And all of you build applications in some level or another and you understand what we’re talking about in these bullet points.

End-to-end quality in our software in the software industry, we just don’t think about it well enough. We all do design, we all do testing and building and it’s an iterative process, but do we really think about it end-to-end? Do we really think about it end-to-end in terms of quantifiable metrics that we’re going to release again?

We certainly try and we certainly are doing our best, but I honestly have to say there’s a lot more that we can do there, and I know there are a lot of changes going on at Microsoft in our methodology, some of which has been prompted by the security work, some has just been prompted by the fact that you know what, customers over and over tell us, “We just want it to work. You don’t have to give us a bunch of features; we just want it to work every time.” And that honestly is just better engineering around quality and something that we’re working very hard on.

This next bullet is really important: instrumented error reporting. You’ve seen this. We call it Dr. Watson internally and are making it available to lots of different customers to use, but the statistics that come back from the work on Windows XP and Office XP are phenomenal. One percent of defects, 1 percent result in 50 percent of crashes for customers.

Every product goes through this cycle. Initially just a few defects account for a huge number of overall crashes. Now you’re saying to yourself, “Why the heck don’t you fix those before you ship it?” The reality is no matter how much testing we do, no matter how good we get we miss some of those things.

Now, as the product goes through its lifecycle and we have this feedback we think that curve will flatten out dramatically, but initially we’re learning phenomenal things from this tool. And we want to do better instrumentation here, we want to do more end-to-end diagnostics. It takes a room full of people today, experts to diagnose a performance problem end-to-end from client through middleware back to database back out to the client. That shouldn’t be that hard. We have to do better there.

Root cause analysis: What’s the first thing that happens when a customer calls with a problem? Well, support is on the phone going, “Got to get them up, got to get them up, got to get them fixed.” They’re not thinking about root cause analysis. We’re going through a lot of training right now at Microsoft to really first get the customer’s problem solved but also to think deeply about the root cause of that problem and push that back into the end-to-end design of the product.

Quality, quality, quality: I absolutely believe it can be a competitive advantage for Microsoft and we’re going to push very hard on that and that’s an absolute promise to all of you.

Privacy: Put users in control of their data. That’s what you all want. I forwarded that message and said, “Please do not forward.” How many of you have ever forwarded one of those? (Laughter.)

Well, with DRM and that technology you can’t forward them. I can tell you that you can read it once. I can tell you that you can’t archive it, you can’t cut and paste and cheat it. DRM is interesting and exciting technology and it should really help us take the next step forward in terms of privacy.

Privacy is different than security. You kind of want to think of them the same but they are honestly very different. You know, privacy means I’ve got it to where I want it to securely, but at that point something else may have happened. And security; I’ll tell you we have done a huge amount of work inside Microsoft and we’ll continue to do all the work we need to kind of make sure the windows and doors are closed, but I’ll tell you the big problems come from the guys that are flying down the chimney or coming up through the plumbing. This threat analysis modeling is just something — you know, shame on us, maybe we should have been more paranoid but the world was a different place; it wasn’t happening. So it’s happening now and we’re doing a lot more threat modeling and a lot harder analysis of how we release things. There are good tools coming out, tools in Visual Studio 7 that are shipping that eliminate buffer overruns, which are a chimney that a lot of people try to come down in terms of just parachuting in.

Extensive training and awareness not only of us; every developer and every tester in all the server products at Microsoft are going through a class in terms of how to build secure code. We think you should do that, too. There are great books about it. Michael Howard has got an excellent book about writing secure code. Read them; they’re important. Get your developers trained. It’s not just our code that has to be secure; it’s your code as well, and we want to help you.

And there are some really exciting ideas out on R & D. One that I’m most excited about is called quarantining. You’ve got to assume, no matter how good you are, no matter how tight you locked the doors and even if you put a cap on a chimney, that bad people are going to get in. And the idea on quarantining is stop them once they’re in; look for errant behavior and let you define rules and if you see errant behavior stop that server, shut it down, take it offline and don’t let it propagate. That will get you a long way in foiling the kind of people that are doing this.

PAT HELLAND: Well, and the common language runtime helps a lot with that for the applications themselves, too.

PAUL FLESSNER: Absolutely. Absolutely.

The abilities: With scalability we’ve come a long way. You know, this is an amazing graph when you think about. Certainly hardware has helped us but look at the progression that we’ve had in terms of the one prox, two prox, four prox. That’s four prox; that’s about 55,000 transactions per minute. Again, I don’t want to argue about TPC and representing real world; it’s just a workload, okay? It’s a medium size workload, kind of like a credit card validation. Fifty-five thousand transactions per minute is about 79 million a day, which adds up to about 29 billion a year, which is about exactly what Visa does in a year in terms of total transaction. And it’s an amazing amount of work on a four-by.

Now, you wouldn’t put all of Visa’s credit card authorization on a four-prox because they have a bit of a peak load situation at Christmas and things like that, but it is a great story about scalability.

Our biggest benchmark is not even on here. We’ve got a scale out benchmark at over 700,000 transactions per minute, which does over a billion transactions a day. There’s no company on the planet today that has that kind of workload.

It’s not just the scalability; availability is a big one. We’ve done a lot of work. Customers I think today, professional customers managing an application professional at the data center can get to four 9s on our platform without a lot of problems. We’ve worked hard on that. There’s more work we can do but things like scale out, fail-over clustering, mirroring of data and partitioning all help that.

Getting to five 9s is very hard. You’re going from at four 9s 30 minutes of unplanned down time a year, at five 9s you’re talking about five minutes, so any kind of hiccough is going to be a big problem.

PAT HELLAND: That takes a lot of discipline, a lot of work, a huge amount.

PAUL FLESSNER: There are a lot of things that will have to go into that, hot plugging and online upgrade and all those things.

And manageability has just kind of faded off the screen, but today we don’t really manage applications; we manage clients and we manage servers and we look at disk thresholds and CPU activity. We don’t really think about the application end-to-end, and that’s something that we’re going to have to do a much, much better job of.

Client management, you know, shame on us in some ways. We can do a lot better there in helping you bring down the clock. It’s in your best interests and certain in our best interests to have you on the most current software and if rolling that out is taking too long there’s more that we’ve got to do and we’re taking that very seriously and working on it.

So that’s kind of I think the state of trustworthy. There’s a lot more investment to be done there and I think some pretty exciting concepts. The world of interconnected Web services has a lot of dependencies and we need to make sure we do a good job here.

PAT HELLAND: And if we start with Web services there are some really interesting things we can do and we’re going to introduce an idea we call service centers, which are really based upon supporting incoming Web services. And because you know that it’s Web services that are coming in, there are some really cool things that you can do based upon that.

So let’s look at the trends. Hardware keeps getting more powerful. You know, the CPU, Moore’s Law, keeps on going up. Bandwidth is even more aggressive than Moore’s Law. Disk capacity is astounding. They are predicting a hundred times capacity over the next ten years and it might be the next seven years. That means where today you can go down and for a couple hundred bucks get a 180-gigabyte disk drive today, that’s going to be like terabytes pretty darn soon on one little disk. It’s like now what are we doing to do? Capacity ain’t the problem; we’ve got that to spend.

Disk I/O latency is sitting at around two milliseconds but interestingly enough you can do a message with data communications across town in a metropolitan area network in another two milliseconds, so that one interesting observation is I can do a local I/O in two milliseconds and I can do a remote I/O across town in four milliseconds. You kind of stand back and you ‘d say, “Huh, what am I going to do with that? How can I do some cool things with that?”

PAUL FLESSNER: Fiefdoms and emissaries are possible, I’d think.

PAT HELLAND: Well, they make some cool things that could be done with fiefdoms and emissaries.

PAUL FLESSNER: I set you up there.

PAT HELLAND: Okay, I understand. (Laughter.)

So hardware is cheap and people are very precious, very important, and the things we have to save are the people. Cost of a raw terabyte of disk today is about a thousand dollars. And I go around and I talk to people and it’s the typical story that if someone has a terabyte of data in an enterprise they’re spending about $300,000 a year just for care and feeding of that terabyte of data — backup, support, management, all of that kind of stuff. Those are funny numbers, right, and it occurs to me we can spend some raw disk to reduce all of the costs associated with managing that stuff.

PAUL FLESSNER: Certainly we want to deploy our people doing something else.

PAT HELLAND: Yeah, the people have much better things to do, much more important jobs that we can give them because there’s no shortage of stuff to get done. People’s time is precious but the cost of managing these systems is huge. It’s okay to use a CPU, disk and bandwidth to save people’s time so they can do other things. It allows people to do more interesting things.

Disk capacity, putting a gigabyte on a disk is really close, depending upon where you look, it’s within a year or right now, to the cost of the tape, not the drive, the tape holding a gigabyte. So you just have to look at that and you have to say tape is not where things are going to be as you look into the future. It’s not going to be the important media because there’s no good reason not to keep it out on a disk where it’s quicker to get to and we can do more cool things.

And it’s okay to keep many copies of the data, as long as those correct versions are automatically used and the software helps you not get all confused about what to do, and it saves human time.

So we’re introducing a concept that we call service centers. Now, what is this? This is a unit of deployment. This is a thing that I would go and put a collection of Web services and their databases and all of the things it takes to support the Web services on the Internet and put that into the service center so it can be self-managing as much as possible and implement and support the Web services.

It’s designed for massive scale out. It’s designed for geographic distribution. So if you look at the picture, on the right hand side you have site A and site B. Both of those together are the one service center and what’s going to happen is Web services will go and route it to the correct place based upon configuration rules and deployment rules.

You’re seeing in the top part of the picture on the left someone sitting at a desktop invoking Web services, which just get fulfilled in the service center. And then you’re seeing the use of these workspaces and the unified data all being managed by this service center, because it’s using Web services in order to do the management of it. And then on the bottom on the left you see other service centers invoking via Web services to get into the service center that we’re talking about.

Now, there’s a very important point I want to make here, which is this is about technology. We are talking about how we could build software that lets you use the hardware to do these cool things. We expect some people would use this to provide services on the Web as just their enterprise, on the enterprise; other people might want to help do service rental kinds of things using this. But we’re talking the technology; we are not talking about the business model.

Now, a service center is implemented using bricks. A brick is just a system. It’s got lots of cheap memory, lots of cheap disk, cheap and fast CPU, lots of cheap but fast networking. These bricks are going to plug into the service center. So you’re going to plug it in and it hooks up and it finds what sub net it’s on. It says, “Oh, here I am,” and then the service center says, “Oh, you’re here. I know what I can do with you. You’ve got all that storage. I’m going to make some more mirrored copies of my data onto you. I’m going to send some computation to you.” All the human did was go whoomp and shove the darn thing in.

When it’s broken there’s this really cool feature that we’re proposing for a brick. You have a red light and you have a green light. (Laughter.) And when the light is red it is broken. This is kind of how we’re thinking about management. (Laughter.)

Now, I want to be really clear. Bricks are just systems. These are these little pieces of hardware that plug into the rack. So when we put this cube here, don’t go thinking we’re talking too esoteric. This is stuff people are building today. What’s missing is the software to make it really easy to use and really easy to have us support Web services.

What can you do with this? You could do automatic mirroring and backup. So what do you do? You mirror the data across many bricks; fast, fast network, fast system area network. We can do mirroring across town. Like I said, two milliseconds to do a local I/O, four milliseconds to do it across town; not that big a thing if the software is designed right.

In my opinion, temp files get two copies, because I think it’s important that if a mirror fails the human doesn’t have to experience a failure associated with a temp file.

The important files get lots of copies because the capacity of the disk is very inexpensive compared to the failures and the difficulties that someone has if the data is unavailable.

Data is automatically — the software controls it and it just works — mirrored across sites, within that same service center. So again I might have site A and site B and maybe site C on different parts of town where I can very quickly do I/O and networking to them, but it’s one service center. That provides disaster protection.

Why take backups? Backups are important for a couple of reasons. One, to cope with hardware failures, because I didn’t have the stuff, right? Well, here we’re coping with that. Even if a site fails we have mirrors, we have copies of the latest and greatest data. But there’s another reason. One is because you say, “Oh my gosh, my app just screwed up. I really want my data back from last Wednesday.” Or you hit the wrong button and you delete the file and you’d really rather go back for it. There is no reason why that has to require operator intervention. The system itself can just know previous versions that have been snapshotted and left a little behind because you want the behind version of it, and allow you to go and get those and pull those forward.

Stored on disk and not on tape; stored in multiple sites.

Let’s talk about databases and how they interact with service centers. Databases are really interesting technology and I’ve spent a lot of time working on them, but they do some things that most folks don’t think about. Databases mask disk latency. They make it be the case that you don’t have to be in a hurry to get the data written immediately to disk. That database is smart and it can launch lots of parallel I/Os and watch them and when they finally get done take them off the list of things that had to get done and then keep launching some more. So it’s not going to hurt if it takes four milliseconds instead of two milliseconds or if you’ve got five copies to write and so it’s going to take a little longer to get all of those five copies written. By juggling more outstanding stuff it’s okay if each one takes a little bit longer.

The database is a computational unit. It can access any of the data in the service center, share-nothing databases over shared disk storage. Service centers have many database engines and the fault tolerance can come by when a failure occurs popping it back up in another computation unit because the storage is still there.

Now, we have a notion we call big brick, and big bricks are for those tough to partition databases. It’s a big SMP with lots of memory, but it’s still doing its I/Os out to the little disk. And here you see in the upper right that big CPU heavy computational unit.

So services live in the database; ongoing work in the database. Each Web site instance is kept in the database and the state is kept in the database.

So what’s going to happen? Messages come in. You find a purchase order for like your ongoing purchase order. You find the data. You pop it up with a message, process it, and generate the outgoing message in the database.

So the work that we have to do for an incoming Web service request is route it to the correct database. And when it gets there what you’re going to see is you’re going to see the incoming message is a transaction, the service processing consumes the message, generates the message, and then you’ve got a transaction sending the work out. So integrating Web services in with finding the correct database is the interesting observation.

So autonomous computing and service centers, that fiefdom itself is a Web service that has that mission critical, shared, multi-user data. It’s not always easy to partition. Sometimes you can, like the customer example earlier, but if you can’t you need to get a big SMP with a lot of memory, but again it can plug into this model.

Emissaries, on the other hand, partition and replicate very easily because they’re just using reference data and single user data, so emissaries scale out and the service center itself can manage that to make that work automatically.

In the picture on the lower right what you’re seeing is the computational process of the database engine can be running on the emissary across a lot of little bricks and if it dies we can pop it back up onto another little brick.

So service deployments, the service center, what are you going to do? You’re going to go and you’re going to install the service into it and not worry about those individual bricks or nodes. The fiefdom itself is going to scale up or if it’s partitionable scale out. Emissaries, they’re cool; you could just spread the work out and the service center can automatically manage that. Those user workspaces where you’ve got that data that’s being cared for that the person can get to wherever they are as long as they’re connected, that can be kept up and spread around. It partitions really nicely. The workspace can go in a different brick and you can have lots of mirrors of it.

So another part of this vision is that users sign up and just get their app. I’ve licensed Office. I don’t know why I can use Office on Paul’s machine. I’ve licensed it. It’s accessible and available to me. The configuration and preferences are in there. Workspaces can be cached so I can take them offline, and simple user interfaces to make it all work.

PAUL FLESSNER: So we know we’re running a little bit over and I apologize for that. We should be able to wrap this up in just a few more minutes.

PAT HELLAND: We’re trying really hard to get through it. There’s a lot of content.

PAUL FLESSNER: We’re covering a lot of space, but hopefully you can be patient. Thank you.

PAT HELLAND: So to manage it, capacity planning is dynamic. There’s a simple meter, which says, “You know, I’m getting full; you’d better go buy some more little bricks,” and then you run and you plug them in and then you add more bricks to it and then that just makes it work.

So in summary, service centers are something that work because they’re supporting Web services and they’re providing the computation and the database support and the data storage management support to automate the actual management of this stuff.

And here we see the total Web services roadmap and the thing that’s interesting is application model is really about Web services. You can see the green in there. Data is really empowered by Web services to do these cool things, and trustworthy computing really is leveraging the Web services as the way to get work done.

PAUL FLESSNER: Excellent. Excellent. Well, Pat, we’re wrapping it up.

PAT HELLAND: I’ve got a few more slides, but thanks, thanks very much.

PAUL FLESSNER: All right, thank you.

(Applause.)

So we did cover a lot of space there and I warned you about that up front but hopefully you found it informative.

What I want you to understand is this is how we’re thinking about things going forward and we are mapping to it; as I said, not specific of product plans at this point but you know how our product map is and that’s what this slide depicts and that’s exactly how we’re thinking about it going forward and it’s not surprise that that’s how we’ll think of our features as we go forward.

So it’s up to us. It worked for the railroads. They absolutely had that productivity gain and had the big jump. This is an exciting time in the industry for us. I think it really is our opportunity to figure out how we’re going to make the Web really build and bring the productivity to all of us both at home, the knowledge worker and the line of business worker to really be the most productive, and hopefully we can be the ones, we can be the ones who drive the next push in productivity and drive the GNP up.

So it’s certainly been my pleasure today to have this opportunity. Again, I apologize for going over for a few minutes. I thank you for attending and I thank you very much for your business.

(Applause.)