Ryan Dunn is a Senior Technical Evangelist for SQL Data Services.
Greg Low: Introducing Show 42 with guest Ryan Dunn. Ryan is a Senior Technical Evangelist for SQL Data Services. Welcome Ryan.
Ryan Dunn: Thank you Greg. I appreciate your having me.
Greg Low: As I ask all guests, how did you come to work with SQL Data Services?
Ryan Dunn: I started my career right out of college in consulting. For about ten years I was a consultant. During that time and right around college, I started doing development in Microsoft Access. At the time I believe 2.0. I started doing development and other things. As the database got progressively bigger, I moved to SQL Server. I kept becoming more technical. I never planned on being a technical person. I got my degree in statistics and planned on managing the supply chain and warehouse. In the consulting role you take whatever the customer gives you and it became more and more technical, data analysis, Access, SQL Server, and eventually Oracle for a number of years. I decided to focus deeper on the Microsoft technologies and jumped at the opportunity to learn XML and took ASP. I moved to ASP.net and took a role in consulting organization where they were splitting infrastructures. I learned Active Directory and became Active Directory expert, publishing a book on programming Active Directory with a coauthor. Through this I got hooked into the Microsoft MVP program. During this whole technical path, starting in statistics to heavy programming, moving to the community, and helping other developers, which earned me the MVP award, I was making contacts in Microsoft and other communities. One day my current manager gave me a call saying they had a great job in the evangelism group. He noted that I like to help other people, had the practical experience consulting with customers. He asked me to come work with him. That’s how I ended up at Microsoft, about one and one half years ago. My current role at Microsoft is Technology Evangelist for SQL Data Services and SQL Services. PBC 2008 big announcements were the Azure Services platform, building block services, and essential services. Windows Azure, the computer storage service. On top, Dotnet services, the relay, workflow, access control, then SQL Services with complimentary data services such as SQL Services, data sync, reference service, etc. My role in data services was called SITKA. I look at bleeding edge technologies, build content and demos, then engage with Microsoft field, subsidiaries that work with customers. I don’t work with customers day to day. My job is to get that content, get up to speed, prepare field on talking with customers, prepare partners, those who want early adoption. I get involved and help.
Greg Low: I believe I met you in Singapore last year. If we look at what’s available, it all seems futuristic, I watch the PBC videos, which I encourage people to do, but in general, what stages are we at now, and what’s coming?
Ryan Dunn: We’re fairly cloud services now, and I mean that in industry sense in addition to Microsoft. Increasingly clear that cloud services viewed as way to increase agility, fast provisioning, and instant scale. Will spin up instances, store terabytes of data without buying infrastructure.
Greg Low: Compelling at moment. I see in Exchange. Years ago, those things were in house. I see people paying for Live Services, $50 for Google, whatever. Rapidly rolling out with someone else provisioning. Interesting is that compelling arguments are rather than doing planning I can pay money and be running this afternoon. Different from anything in industry.
Ryan Dunn: Yes. I’ve worked with many clients. You’re spot on. You look at project, say at a bank. They’re implementing new system. Crazy guess on number of users. Start buying ton of servers, bring in, start development. In meantime, something happens like mortgage and real estate issues. What they were designing for in 2005 or 2006 is no longer the business happening today. In meantime, two years effort, bought infrastructure, with payout of nothing. If they had built in cloud, run in cloud, provision multiple instances, parallelism built in, they could scale up if it became critical. They could have done it. With this current meltdown, they could have scaled off or turned off. Pay as you grow. That said, there are challenges of course, working cloud services. You’ll talk to many who say their data will never move out of their control. Two ways of looking at. I ask customers who don’t want data in mythical cloud, wanting it in their control, what do they do for payroll today. They’re using salesforce.com or a check printing company. Outsourcing payroll. Outsourcing HR. Then they’re using Hosted Exchange. You break these objections down and they realize not that big deal to have things out of their data center. There will always be geopolitical restrictions. Germany, Canada can’t have out of country or data center. You always have to have local storage there. For a lot of people, makes sense to look at cloud services as new way of building, can feel comfortable with building and model because of SLA, or guarantee from provider.
Greg Low: When I speak to Gmail experience, when I first configured a year or so back, I expected it to be least reliable service I deal with. I have to say, apart from one outage, it’s been the most reliable mail provider. I deal with about six or seven a day. All that I connect to that run within companies are the ones not as reliable. Huge telco’s, I do better job looking after data than most companies do.
Ryan Dunn: You can talk to CTO’s at different companies. They say they have to have 99.9% reliability. You ask what they have today. They don’t exactly know because they think they need the five nine’s, but they don’t know what they have. They could be at 98 or 99%, and that’s fine for what they’re building. As cloud services mature, it’ll be the standard to which other services will held. On premise won’t be gold standard, it’ll be cloud. Providers like Microsoft. Amount of money and manpower spent on data centers, monitoring services, having uptime, phenomenal. Replicating on premise will be difficult. Not impossible, but very difficult.
Greg Low: Yes. Another aspect of this I find interesting is that when I talk to most business owners, they don’t want to run data centers or systems, things like that. Some of the IT people I talk with don’t understand how little business people want to be involved with on premise IT.
Ryan Dunn: We hear that from IT all the time. If they could get out of business of running data center, with us doing, that would be ideal. With services developed, we’re close. Biggest challenge is managing identities and being able to control access to data. With access control service and Azure services platform, Geneva framework and server, things like that, we’re getting close to that. Being able to transition from on premise to cloud and back with single identity, giving on premise feel. User doesn’t know interacting with service not in same geography as them. Seamless, identity transfer between services, authenticated and authorized. Things just work. With SQL Server working with Access Control Services, you can do powerful things. Federate with different partners, customers. ISVs can be small guy on block, no one knows. 20, 30, 40, 100 instances running. With Identity Services, federating with your clients Active Directory, grants access to SQL Server on backend. Multi-tenant huge system in a tiny shop, paying for what they use. Exciting scenario. Levels playing field for smaller ISVs.
Greg Low: Organizational agility will be key pushing this. I look at idea that today, would I run web server on premise? Almost never yes. When I roll back to when I first started working with web services, it was common to run on your own system, on premise. I wouldn’t consider that today in almost any scenarios. I think most of the data will end up feeling the same way.
Ryan Dunn: I totally agree with you. That’s what’s happening in the industry. To consider, continuum between on premise and Azure services. In between you have hosting. You can rent machines in data center to run three to four instances of your web site. Any hosting provider. Still difference between that and what SQL Server and Azure can do. They’re virtualizing all the services. Management, maintenance, abstracting platform, raising level of up. On premise, you need to manage, patch, etc., When you take to hosting provider, you still have to configure everything, might have to patch, but at end of day, ten boxes in data center, not in your facility. SQL Server Data Services or Azure, you don’t know anything about the machine. You have chunk of code running on Azure. Could be big, little, just put it there and services worries about serving the data. I don’t worry about the log files, spindles separating, best performance, machine memory, patching. Those building applications look at that and see real value. Worry about the application, not the stuff that makes it run.
Greg Low: I find it interesting that my clients moving from in house to larger data centers find it nice that larger data centers allow them to spin off additional servers, make them go away when it’s quiet. I can imagine school with heap of people during certain weeks, then nothing some weeks. Payment models that allow you to spin up and down the degree of computing available. Down the track we might buy computing by the kilowatt hour. Power is the main thing.
Ryan Dunn: I’ve heard that. It’s true. You look at the cost of data centers. Real estate in Chicago might be high, but you see the real cost in power. Huge facilities going up where kilowatts are cheap.
Greg Low: Based on rationale on why we want this to appear, it looks to me a long way from that. Let’s talk where it is at the moment. Services available.
Ryan Dunn: In terms of Windows Azure and Dotnet, SQL Server services. These are the first crack. At same time, interesting scenarios and powerful things you can do. As more features roll out, better management, better adoption by ISVs making consuming easier, ubiquity of broadband, connection of on premise and off premise. Utility of services goes up. With SQL Server today, we have a model in place. Ace model. Authorities, geolocation, entities. You can build interesting applications with that model. Room for improvement and features customers really want to bring to fully relational model they’re used to with SQL Server on premise, but today, I’d say for person looking at this, new applications very relevant. If you’re using new applications, look at architecting so they can move to cloud easily. Identity providers don’t make assumptions on how data interacts physically at service. If you have existing applications, maybe there’s stepping stone to address. You can use some of current applications to extend or archive or data hub, sharing data on premise. Powerful to be able to use on premise data on SQL Server and sync to cloud, then have partners and customers sync down part of that data, maintaining local control, synching back. Expand at periphery using cloud. Still things to do to take existing on premise application and straight port to cloud.
Greg Low: People have idea that we should be able to just drop in as replacement and it’ll work. Will be more successful for applications architected for it.
Ryan Dunn: For sure. No magic bullet. Can’t just tweak on premise application and have run perfectly on cloud.
Greg Low: Not just a hosted copy of SQL Server. That’s not what we’re looking at. I can imagine how to build applications to take advantage of this, but different from what I’m building today.
Ryan Dunn: Yes. Today you look at SQL Server. Looks like distance between this and SQL Server seems large, especially thinking of data model and relational features, joins, things you’re used to. There’s a path, a trajectory of the service. More and more database features will be turned on so you can get those relational features, not giving up functionality, giving up too much. There are things to turn on.
Greg Low: Part of the issue seems to be limitations on opening things up, manageability on backend.
Ryan Dunn: Some cases, could be. What they’ve done intentionally is limit surface area where things can go wrong. Query model different. Not sending TSQL into data services today. Query model chosen, when it boils down to SQL statements on back end, constrained set. Know what it will look like. Cloud service, truly multi-tenanted, so we need to ensure one person not monopolizing, degrading services for others. Shrunk down set of services available. Small set of services, at scale. When proven that it works, features will turn on that are proven to scale.
Greg Low: Good point for a break. We might talk concerns and issues in relation to this after that.
Greg Low: Welcome back. I always like to ask if there is a life outside SQL Server?
Ryan Dunn: For me, my life revolves around my daughter. Just seven weeks ago my wife and I had our first child. I’m on minimal sleep at this point. She’s not difficult, but she has to feed every couple hours. She likes to wake up and have it known she’s hungry. That’s my focus at this point.
Greg Low: Congratulations. Excellent. The sort of issues people bring up when I mention cloud services. Having the data on or off premise. When I was at PASS Summit, there was discussion where people were talking data here but business intelligence somewhere else. If I had to choose, I’d have the other way around. Transactional data in cloud, strategic data closer to chest. Whole discussion around on and off premise. But a lot of the data is already living off premise.
Ryan Dunn: Look at businesses, what’s on premise. People would be surprised at how much data is already off. SQL Data Services, we get that concern a lot. Could be geopolitical. There’s nothing we can do about that. If Germany government says something can’t leave country, at that moment in time, not a lot we can do.
Greg Low: I’ve come across this. Even things like oil rig data. But what sort of data typically has that limitation?
Ryan Dunn: Typically see in government. Anything with government or personal identifiable data in some countries. Law different in different geographies. Hard for worldwide services to be in sync with all of them. Microsoft has commitment to put data centers where it makes sense, but there may be areas where we can’t get in to address this. Just one of those situations.
Greg Low: Down the road, many markets will change their mind on this. In Australia, we had isolated way of doing phone systems. Idea was higher standards. Every piece of equipment we went to attach had to go through loops and accreditations that were higher than worldwide. On surface, great idea. Converse is meant all phone equipment for rest of world not useable here. All you could purchase locally was Rolls Royce type equipment built to our specification. Eventually, torn down now. Counterproductive. Businesses suffer from lack of agility. I can imagine for some government things, might think that way. If your country competing with rest of world and rest is agile, I’m not so sure that all countries will say sorry, that’s how it is.
Ryan Dunn: You’re probably right. Business perspective, competition will be more agile. If you can’t operate in different jurisdictions with data you need. From experience, some government entities won’t budge. Good reasons.
Greg Low: Unfortunately, can be counter argument, reason for companies to not operate in country. If you can’t be competitive, based in that country, big village, base elsewhere.
Ryan Dunn: Beauty of cloud. Doesn’t matter where stuff is coming from as long as you’re geographically located. Latency not an issue. You can put anywhere. Will affect what you store. You talked business intelligence and vast amounts of data on cloud. Interesting scenario. Customers have said they’d love to take huge datasets, archived stuff, put in cloud with idea of live archive. Not as fast as on premise.
Greg Low: Interesting aspect. Access performance totally different for certain data.
Ryan Dunn: We have customers doing that today. On premise, highly cached, very fast, temporarily relevant data with high activity. Time goes on, fade to archive. Mortgage industry, flurry of activity of loan documentation until loan closes. Lots of access to that data. After it closes, need to keep data, but not access it. Store for life of loan which can be 30 or 40 years. Today they have tons of hard drives, put it on tape, or archive to DVD. Something like that. With data center, they can have tiered data access. Pay storage fees no matter, but paying for application responsiveness, may be less for latency, but cold data with higher degree of utility. Bank today. Why can’t you look up statements from seven years ago? If you want to know what you wrote on a check, why can’t that image be available today? Limitation of data storage. SQL Data Services makes that available today. People want to take that data and do things with it. Report on it, build cubes. Capabilities not quite there yet in SQL Data services with business intelligence capabilities. Something we’re investing in. Will have those capabilities you expect in business intelligence in the future. Will be critical when you have mass of data in cloud. Want to do business intelligence and not take down huge volume of data to do local analysis.
Greg Low: I see organizations all the time that have this information, but if they need to retrieve it, don’t have systems to be able to read it.
Ryan Dunn: That’s right. They get the tape. Cost of tape, then finding machine that reads it is comical.
Greg Low: They convince themselves they're in good place. Big thing is privacy. How confident can we be that data private?
Ryan Dunn: Today, SLA guarantee. If Microsoft breaks that SLA you can sue them. What you really want to talk is technical guarantee of privacy.
Greg Low: Both. I look at companies talking technical guarantees. But how many of us deal with Microsoft daily and have NDAs and such. Tons of private information out there. Protected under basis of consequences.
Ryan Dunn: Yes. Will be in SLA. Won’t mine data for ads. Whatever you want to do. Usage pattern, figuring out who you are. Your data is your data when it comes to SQL Data Services. That’s great, but what if subpoenaed? Yes, will have to comply with law wherever you operate.
Greg Low: Question is, whose law? You might be Iceland based, company in South Africa. Whose law applies?
Ryan Dunn: I’m not a lawyer. Whatever jurisdiction applies is what we’ll respect.
Greg Low: Interesting discussion on what jurisdiction does apply. So many things not resolved, bubbling in background. I can’t post website in Australia that refers to someone in libelous way, but nothing to stop me from having a page with first page linking to U.S. site doing same thing. Entire discussions on whose law it is. Interesting. Idea of cross national applications becoming common will become big issue as to who has what jurisdiction.
Ryan Dunn: Someone internally at Microsoft said, likely joking, limiting factor of cloud services isn’t technology, but right number of lawyers engaged in different jurisdictions to smooth it out. You look at Microsoft Messenger and such. They’ve already done that work.
Greg Low: Discussion around global companies cooperating with authorities, monitoring transmissions in applications. Whether or not users aware of. Those same things must end up applying, in bigger fashion. I’m intrigued as to where it goes. Next level, is it an expectation that people would have encrypted data when in cloud anyway?
Ryan Dunn: Definitely expectation for some customers. We’ve made clear not happening. If someone breaks into data center and steal disks, they’ve have data in clear.
Greg Low: What if I encrypt before it goes up?
Ryan Dunn: That’s a technical thing we’ve been investigating. How we do that. Ideal would be you managing keys on your side. You encrypt data, store with us. You can do that today. Problem is opaque to us and we can’t query unless you include hash values of what you might want to search on then having API that says where last name hash of encrypted value, you can search. We want to make seamless. We know interest is there, stored on disk, customer only one to be able to see, yet able to query. Work to be done, but something we’ve heard from customers and something we’re looking at.
Greg Low: In terms of deliverables today. Most of what was shown at PBC, data access looked like dictionaries, value type tables.
Ryan Dunn: That’s the model we started with. If you attended Patrick McElroy’s talk, he eluded to the future, we’ll introduce things like schema, more traditional, relational concepts. Constraints. Idea of relationships between data expressed. Not there today, but on the roadmap.
Greg Low: Today, looks like it would be suitable for object persistence layer? Where I could close to serialize an object and push objects or properties up and down to the data store.
Ryan Dunn: Yes. It does work well for that with simple objects. There are some things it doesn’t do well like nested arrays. For typical data transfer objects, works great. Idea that you just said, serializing objects, is exactly what you can do today. Payload format is XML serializer compatibility. If you return an entity of kind customer, and customer and CLR code match shape, you can serialize directly into the customer object from the service. That’s just how the RES library I built works. Uses the XML serializer and takes CLR object and does the round tripping for you. Uses properties as name value parsers inside SDS.
Greg Low: That’s interesting. Next thing people raise is availability. If I don’t have on premise, do I have less chance of it being available? What SLAs are there?
Ryan Dunn: We haven’t announced anything yet. They’re still working on levels and contractual guarantees. I can tell you general answer is very good SLA, probably stratified. Probably multiple levels of SLA. You can pay for the better ones.
Greg Low: People expect 100% availability, but that’s unrealistic. Even my phone here at my house, in reality there is an SLA on that. It’s pretty lousy, but I have the expectation that it’s available pretty much all the time. There are odd scenarios where things happen and I lose my phone for awhile. In general, that tends not to happen.
Ryan Dunn: If you look at infrastructure, how it’s built out, replication, data will be available at data center and out to you. Challenge is local things where you are. Switches go down in your office, someone runs a backhoe in one of your fiber optic lines, and you go offline. That’s a challenge in services today. One capability we’ve looked at, investing in, is data sync. Way to mitigate that. Microsoft sync framework. Project Heron. Ability to take that data, while it’s up and available, sync locally. If something happens to your connection or you step on plane, you can work locally. Functionality, utility with data. When you connect and back up, sync with cloud. Solve the problem of rendezvous. If you wanted to sync previously, had to know when they were both available so they could find each other. You can assume that service available if Internet connection. Sync up and peer or application goes to same service without relying you’re online. Powerful capability, exactly something we’re investing in, for that reason.
Greg Low: I find myself preaching to DBAs and developers thinking on disconnected applications and/or message based architectures. People tend to build like a house of cards, everything works or nothing works. This will push us further down that path. When you were describing mortgages, I remember work I did for mortgage broker recently. They had big performance issues. They had a loan application, break into 50 to 60 tables in local application, and then use merger applications to merge those across everyone involved. Whenever it looked for synced things, huge, huge task. In end, what was moving was tiny message saying here’s the details of the applications. Solution was stopping the merge of results, and just the merge of the details of the transaction. Rearchitect thing. I can’t help think message based architectures will become more important again. If I build application it will be far more important for me to add message and send to cloud, process it in cloud. If need be, messages back to me. I’m not sure the communications to and fro will be like current TSQL transactions, but more message oriented.
Ryan Dunn: Entirely possible. You pointed out good problems. Like I said, people on data sync side of house have been looking at, trying to shield you from the complexities of doing things like that. Conflict resolution. How to get these things working together. Orthogonal to the application so you don’t have to depend on the sync framework to have application work, but working in conjunction. Sticky problem. At some point, you wonder if you’ve introduced more complexity. We understand client systems and distributive systems from data center. Have we introduced new complexity here?
Greg Low: Service Broker, a technology that I love. Missing is tooling and prescriptive guidance on use. People using applications not used to building message based in first place. What they provide is ability to have server up or down, connected or not, complex application to build, but dramatically more reliable application. These things have same possibilities. I’m also interested in what people do next. PBC video a good starting point. Apart from that, what should do or try, where should they get involved? You? Anyone?
Ryan Dunn: I’d say definitely PBC videos. Channel 9 has done fabulous job. Easy to navigate, good exp. Catch up on where we are with Azure and SQL Data Services in particular. However, also look at Azure Training Kit which has been published on Download Center, liked through any site there. Azure.com, click through dev center links. In that Training Kit are hands on labs for all the services. You can walk through at your own pace, and get your hands dirty with code. Today, provisioning process where you need to request token. Register at Microsoft Connect. Very fast for Dotnet and SQL Services. Sometimes hours, maximum day or two. Grants access to solutions and to create an account. You can access labs using that account. Great experience to see where you’re at, what applications you build. Next, Dotnet User Groups and your local areas if you have MSDN events. Look at this stuff. Keep your eye on it. If you’re thinking about new applications, keep an eye on this space. Makes and ton of sense to look at and design for cloud rather than find yourself a year out with a successful application that you can’t scale. Whole world of cloud services that could help if you had changed your design a bit and not made assumptions that things were always true.
Greg Low: If you had to look in your crystal ball, one question for DBAs is if this is big threat for those who look after in house databases in the future?
Ryan Dunn: No. I don’t believe so. I think role of people having to patch machine and worry about different spindles, where to put the logs, that’s a threat. Might not have to do that anymore. There will always be role for data architects and DBAs to correctly implement data architecture. You can do whatever you want with application but if architecture screwed up, bad performance, lost data, wrong results. Many problems.
Greg Low: I wonder if they need to move towards data modeling.
Ryan Dunn: Might be. If you’re narrowly focused on TSQL or certain features on premise only, yeah, there might be problems. But fundamentally if you know how data works and how to design system for scale and for ease of use through front end, always a role here. Doesn’t matter what data store is. As more features come into SQL Services, and more relational features introduced, model is simple today, but complexity will go up with added features. Will always need people who understand right way to use features. You see applications built where you only know one or two features. You have to have people who understand and do the correct thing.
Greg Low: Thanks for your time today.
Ryan Dunn: Thanks for inviting me. This has been great.