Hello everybody, here we are in lovely Las Vegas, Nevada at the Microsoft Mix 2009 conference in the Venetian, as you can tell from the lovely gold backup that we have. And we've got a guest with ourselves. Would you like to introduce yourself? I would. Hi, I'm Patrick McElroy. I'm the Group Program Manager of the SQL Data Services team within the SQL Services team at Microsoft. We've been talking about Azure and cloud computing and things like that. And so, I think people know what SQL Server is, and that's that. Databases are covered as it were. Right, and the whole data platform. Exactly. Like just the relational database, but the BI. That's right. And oh, and you guys have Project Historia under. We do? No, it's in the same division, yeah. And you've got data services. Yeah. You can't use the code data. Of course not. How is SQL Server moving into Azure into the cloud? Yeah, it's a great question. So, the SQL Data Services is the first of a series of staffs. But we'll take key parts of that SQL Data Platform. And we'll extend it to both include what it does now, of course, desktop and server. And mobile will extend it into the cloud. Is there going to be sort of a relational, like typical database-like way of using it? Or is it going to be a REST sort of thing? Yeah. I mean, what are the interfaces playing out to be? And I ask that because as developers move to the cloud, there seems to be, typically it seems like you have to go through a technological shift. Well, it's true. And there are clearly some differences in building services-based applications. And that will impact on the applications that you build. But obviously there's value in keeping those differences to an absolute minimum. Right. And so one of the things we're doing, in fact, we announced last week, and we're reinforcing and giving some detail here at Mixon, is we are going to take SQL Data Services and we're actually going to expose the relational database capability that we have as a service, but using the TDS, the Tabular Data Stream Protocol, and the T-SQL query language, expressing to get a high degree of symmetry between the on-premise experience that you have with SQL Server and the rest of the SQL Data Platform,
2:10and now this cloud service that's built on the same technology foundation. So backing up a little bit to usage of things, while there's sort of legacy usage patterns that you want to definitely keep and enable, like, aside from, I mean, obviously if you're deploying an application in the cloud, you need to have a data store of some sort. That's right. But are there things about being in Azure or the cloud that, like, give you something different that you didn't have previously? There certainly are. So, you know, the core relational model and the relational query capabilities that you have as part of the platform are the part that's the symmetry. We think that there's a number of, we call them services goodnesses. Right. But good things that come from being able to deliver this as a service. Things like self-service provisioning, friction-free provisioning. And will this prevent people having to wait, like, ten weeks for the DVA to create a column on the table? Exactly. And then four weeks before that to actually provision the machine to go put the database on and then wait for ten weeks to have the DVA create a column. Right, right. But, yeah, just so you can go through a very quick provisioning process and without having to stand up hardware or install or anything like that, you can get a database to build, you know, departmental and web workload apps on. And there are other that are a little bit more subtle, potentially, but the fact that we will redundantly store the data and we'll do all that behind the scenes for you means that even with that very simple provisioning experience, you'll get automatic fault tolerance and high availability out of the servers. Yeah, that's interesting because I remember one of the, well, one of the surprises that people have used cloud things for, like, whether it was EC2 or, you know, Amazon Cloud, is people backing up their database. Right. And just having, like, somewhere else to back their database up to you, which, you know, I always think when it comes to cloud computing, essentially storage is one of the low-hanging fruits, if you will, and everything that comes out of that. And the infrastructure that we built, again, based on that SQL Server technology foundation, but also the fault tolerant and the self-healing and the automatic fabric that we have around that SQL Server foundation.
4:18And the way the service will use that foundation will give customers that high availability and that fault tolerance simply by virtue of creating a database, so really without any rocket science at all. Right. Maybe it's something that is here to forward and only available through something like the rocket scientist. Exactly. Another key workload that we're targeting is the ISV workload. And as it turns out, it's particularly well-suited for an ISV that's building an application that will scale horizontally. Sure. So as with any kind of cloud platform or any kind of cloud technology, their scaling is one of the benefits of it. And with SDS, and particularly for, again, a horizontal scale.app, the ability to create those, think of them as partitions, but they're really new databases. Right. To scale your app, particularly if it makes sense to create a database per customer that you have for your app, is a very natural data model that you get. The interesting subtle point there is that once you do that, the fact that we're running on thousands of servers means that as you issue a query and you issue them against multiple databases, you now can get great benefit from that because your query now runs in parallel on dedicated processors. And you can process an amazing amount of data in parallel very, very quickly. And it's a very natural thing that you get because you've built your app. It's sort of bringing enterprise-grade sort of grid, you know, benefits down to just anyone who might want to use it. Yeah, and doing so in a very highly parallelized infrastructure. Right. So rather than scaling up the machine and buying a 64 processor with 12 terabytes of RAM, you know, you're just able to run this thing across a broad set of commodity blades. Right, right. But the throughput for queries can be just amazing. It's a little out of left field. But looking at the tooling that you've done for Azure, are there benefits that you're pulling back into on-premise SQL Server installs? Sure. The reason why we started with the SQL Server Technology Foundation is because it's a fantastic foundation.
6:24But the reason why we're thinking about this as part of extending the platform is because there's a lot of benefits kind of both ways. Right. The move to TDS and T-SQL has also allowed us to kind of open up to customers just the amazing ecosystem that you can use. You know, you've got a lot of resources, you've got a lot of resources, you've got a lot of resources. You've got a lot of resources. You've got a lot of resources. You've got a lot of resources. You've got a lot of resources. You've got a lot of resources. You've got a lot of resources. You've got a lot of resources. You've got a lot of resources. You've got a lot of resources. You've got a lot of resources. You've got a lot of resources. You've got a lot of resources. You've got a lot of resources. You've got a lot of resources. You've got a lot of resources. You've got a lot of resources. You've got a lot of resources. You've got a lot of resources. You've got a lot of resources. You've got a lot of resources. You've got a lot of resources. You've got a lot of resources. For example, a developer who's familiar with Visual Studio, familiar with the SQL Server tools that are in Visual Studio, can continue to use those as they build out applications that they'll deliver to as a service. Right. At a point where they're ready to deploy, rather than deploying to a SQL Server in your corporate LAN environment, you'll point that script to an endpoint in SDS, and you'll deploy in the same way, but you've spent all of your time in the rich tool set, and the rich ecosystem that you have in an on-premise environment, in a mobile development environment. That makes sense. It's great, great synergy. Of course, it will be, particularly in our V1, it won't be 100% compatible, but we think for the vast majority of apps, 80% of apps, and certainly even 90, 95% of the Carmel and Web Workload apps, that the compatibility that we'll be able to deliver in V1 will mean they'll literally just point their deployment script at the endpoint. They'll deploy it and they're out and running. Another aspect that I'm interested in that you touched on briefly is, I guess you would call it the DBA aspects of dealing with that. And traditionally, like I was kind of cruelly joking about earlier, you know, the DBA is sort of a center of power and control in the enterprise. They are. So on the one hand, the question is, you know, for existing DBAs,
8:25how can they maintain that nice position they have as things move to the cloud? But then on the other hand, how does the role of the DBA sort of, I mean, does it get affected by just simply moving, you know, having SQL Server beyond the firewall? Well, I think it will be impacted. And I think that certainly the feedback that we've gotten from customers is that it will be a way for the DBAs and the IT staffs, corporate IT, to be able to provide a richer set of capabilities to back to their businesses. Right, right. And so it was really actually kind of interesting that we've been doing this now since the last next. So a year ago is when we first announced the service. And over time, we've been engaging, of course, with DBAs as well as data programmers. And the early feedback from DBAs was one of nervousness. Right. Like, what's happening to me and what am I going to do now in this world? And over time, the feedback from them and as they learn more about the system, this becomes another tool that they have to deliver capabilities to their businesses. Right. And in fact, again, just as we were talking about before with some of the query performance, you know, there are--Corp IT will actually find that there are some hidden benefits in here that may not be apparent. A great example is right now a lot of our customers will talk to us about, you know, that have this database sprawl effect, whether it be SQL Express or MySQL or something. It's databases will spring up like weeds in departments. Yeah, and that's when you mentioned many different versions. In many different versions. And particularly in, you know, the day and age in which we live around corporate compliance, there's some CX type, you know, CXO officer who has to sign off that all the policies have been applied to all the data, Right. which they sort of get nervous whenever they have to sign them. You fast forward and say, well, rather than building that under somebody's desk on a piece of, you know, used hardware, if you could just provision that in the cloud, not only do you get that self-provisioning you talked about, but now you get compliance, you get the ability to discover without getting in the way of somebody who needs to go build an app for their business.
10:27Right. Central IT can go discover that, can make sure policies are enforced appropriately on that, and really now can get the insight that they need in order to do the corporate compliance they have. That gets at another thing that I was curious about, especially when it comes to, you know, compliance and regulations and everything. And, you know, your data and therefore the databases are often at the heart of that. Right. Absolutely. And, of course, the idea of Azure or any cloud computing thing is that you'll have, you know, many different data centers spread out everywhere. What can we expect from, you know, the SQL server SDS area of Azure as far as I need this data to be in Germany or I need this to be in China? I mean, how does that sort of play out? Obviously Microsoft's investment in data centers around the world is a great investment that we'll live on and we'll live in those data centers and that'll be great for customers. The Windows Azure folks, in fact, at the conference are announcing an ability to name the geographic location that you'll handle deployment in and we expect to follow suit with that. So just as you can say, my computer is going to go in, you know, the Pacific Northwest somewhere in whatever data center that maps to, you'll be able to say the same thing about your database in SDS. And then you can, by doing that, control the fact that you want your compute near your data. Those two things will communicate over a pretty fat pipe in the data center and you'll get the performance you need, but you'll be able to kind of control where that might be. So while we have you here, it's a little bit off topic, but because I've closely followed the team and the project for a few years now, can you give us an update of, as I still like to affectionately call it, project a story? Like what's going on with that? Sure, sure. ADO.NET Data Services. Yes. Okay. So ADO.NET Data Services is the framework piece that will allow you to provide an entity model and an APP and REST-based interface on top of relational data. We're continuing obviously to invest in that and ship that as part of the .NET framework.
12:30And that turns out to very, very nicely with the relational model that we have. Exactly. Given that the way people currently consume that technology on-premises to do exactly that, is to take that framework, you know, do the development work that you need to fill out that framework, do the data mapping that you need, but then put that on top of a relational data model in a relational database. Sure. That will fit very, very naturally in the new SDS and in the new world without a story piece. The data services piece will be deployed into Azure Compute. Your database will live in SDS and it will work great in that environment as well. It will be a fantastic model. And, you know, another key thing that we're focused on is, of course, the breadth developer. Right. And it turns out, again, something sort of is counterintuitive, but, you know, supporting TDS and the T-SQL interface, you know, all of the client-type libraries that exist that live on that same foundation, ODBC, and then in turn, all of the open source client libraries, will work very nicely in that way. Right. But the ADO.NET Data Services is a great investment there as well about, you know, if you need to access your data through REST, Atom Pub, you're going to do it on an entity base. Right. It's a fantastic network. Well, great. Well, thanks for spending all this time to talk to us. Quite welcome. Thanks for the opportunity. Thanks.