Sign in / up

back to article 'Full' SQL Server planned for Microsoft's Azure cloud

Microsoft plans to make a full version of its popular SQL Server database available in the cloud in response to pressure from partners. The company told The Reg it's working to add as many features as possible from SQL Server to its fledgling Azure Services Platform cloud as quickly as possible, following feedback. General …

COMMENTS

House rules Send corrections
This topic is closed for new posts.
  1. Henry Wertz Gold badge

    I've wondered...

    I've wondered about this Azure stuff how much porting has to be done? (Both by end users, and by Microsoft especially to provide services?)

    1) Are they just hammering and adjusting settings? 2) Minor code adjustments? 3) Or are they having to make large changes, or almost write from scratch, to make SQL Server etc. work "on the cloud?" I think there's no way I'll get an answer to this but I have kind of wondered.

    If 1, they are just making marketing decisions, trying to figure how much power they can have with Azure without cannibalising SQL Server sales. If 3, they really ARE deciding how many features to put in because they have to get them working.

    Also, if 3, the other cloud services have a huge advantage -- they are running more or less off-the-shelf open source software (with some cloud-specific APIs on top.) I don't know if they are at stage "1" or "2", but Python, MySQL, etc., they sure aren't rewriting them from scratch.

    0 0
  2. John

    Don't forget Windows Azure storage

    True about SDS becoming a more full-featured relational db in the cloud. But, SDS is just a small part of the storage options in Windows Azure and the Azure Services Platform -- don't forget about Windows Azure storage. The foundational Windows Azure platform - the "Windows in the cloud"-- includes it's own storage service capabilities beyond what SDS does. As an analogy, Windows exposes a file system - that's different than SQL Server -- similarly, Windows Azure has storage services that are different than SDS.

    Windows Azure storage includes blobs, "tables", and queues. Blobs can be huge - for now I *think* they are limited at 50GB, but that's not a technical constraint - this limit could go higher after the CTP. To help manage large blobs effectively, they are segmented into small blocks so you can change a blob by just updating a single block vs. reloading the entire huge binary.

    "Tables" in Windows Azure storage is sort of a funny name - it's not like SQL table, but rather is like an entity bag with name/value pairs. The values can be anything and very long.

    Queues provide a way for the "Web role" of the Windows Azure compute service to exchange information, assign tasks, etc. with the "Worker Role" of the Windows Azure compute service. The Web role is like a web server, the worker role is a server that does other things (e.g., things that don't require inbound connections).

    Learn more about storage options for Windows Azure and the Azure Services Platform in the short videos linked here: http://tiny.cc/KMETS .

    0 0
  3. John

    A few things to keep in mind

    @Henry, A few things to keep in mind. First, Winodws Azure and the Azure Services Platform have a couple years of significnt R&D behind them. Windows Azure is not simply a Windows Server VM. Windows Azure It's based on Windows Server, but includes many unique innovations. When MS says it's an OS for the cloud, that's distinct from an OS for a machine.... Windows Azure is an OS in the sense that it's a collection of compute, management, and storage services tied to together with a controller. The story is similar for the Azure Services Platform -- it provides a cloud application platform for the cloud OS - .net services with workflows, identity, and interop service, SDS for future db services, and Live services for social services that you can build into your own apps. (Collaboration services based on sharepoint an CRM services based on Dynamics CRM will come in the future). Personally, I'm not expectng SDS to be the same as exposing SQL Server in a VM - SDS will be based on SQL Server, but expect it to be more abstracted so you can focus more on your own intellectual property vs. needing to operate the database.

    Second, the porting story is different for different parts of the app. If you have .net code running on a web server, in many cases you'll be able to run your .net code without too much trouble. That said, some folks may want to re-factor some of their code to better leverage the native advantages of the cloud platform's scalability. BTW, the Windows Azure team wants to build Windows Azure to support non-.NET code in the future, as well. Already, you can run Python and Ruby code via IronPython and IronRuby using Silverlight.

    The data base layer can require a significant amount of work with the present version of Windows Azure storage and SDS. Once the SQL Server-ish version is out, porting should get signifcantly easier.

    Third, a couple comparisons. Amazon will give you VMs to run LAMP, and also VMs to run Windows/SQL Server. Could be an easier migration path for an exsting windows app, but also is offering more of an "Infrastructure-as-a-Service" vs. a "Platform-as-a-Service" -- so the potentia upside is limited. E.g, you still have to manage your own firewalls, set up and manage db, patch everything on your VM, license all software on your VM seperately, etc. Windows Azure's first priority is to deliver a full platform that lets you focus just on the unique bits of your app.

    Google App Engine on the other hand provides a platform-as-a-service, but requires you to write in python, and requires a special data structure called "BigTable". My understanding is that an existing python app may or may not need to be re-written, depending on the app, but the db-layer is a significant re-write. Not sure if GAE is working on allowing a model for existing apps vs. requiring re-writes.

    0 0
This topic is closed for new posts.

Other stories you might like