 |
|||||||||
|
|||||||||
|
|
As I spend more time with the CTP I will be posting more detailed, in-depth walkthroughs of the technologies as well as code samples (hopefully I'll get approved for my Azure hosting account soon *hint* *nudge* *wink*!!). For now, I'm just going to do a high-level breeze-by of the main aspects of Azure.
Put simply - Windows Azure is a technology that will allow developers to build applications in the cloud. The GUI for the application is in the cloud, the back-end processes that are running are running in the cloud, and the central data store for the application is in the cloud. The great part about this is that you can run it all locally, test it, play with it and vet it. Then you can upgrade it so it's running locally but using cloud storage. When you're finally set that your app is ready for primetime, you can push the app to the cloud and continue using cloud storage.
On a lower level, Windows Azure allows you to build and publish these things called Web Roles and Worker Roles. A Web Role is nothing more than a bunch of code that has been bundled up and pushed into the cloud that responds to HTTP(S) requests. These Web Roles, at least in this CTP, are ASP.NET applications but it looks as though you'll be able to do Ruby on Rails, PHP (god forbid), Python, or whatever you like. I'm hoping for a VS 2008 plugin that lets me build ASP.NET MVC Beta 1 apps that can be published as Azure Web Roles. A Worker Role is a piece of .NET code that is running in the background.
Traditionally one of the biggest problems people have, from hobbyists to developers for huge corporations, is that external hosting facilities only work well if your ASP.NET app is 100% self-contained and requires no additional services and no background processing, etc. Windows Azure lets you develop apps in cloud AND push your services into the cloud AND store your data in the cloud. Keep in mind that a Silverlight application counts as a web application ;) Starting to see the possibilities here?
Apple's MobileMe slogan was at one point "Exchange for the rest of us". .NET Services can be thought of as "Biztalk Services (in the cloud) for the rest of us". The bottom line is that .NET Services are a cloud-centric way of solving many of the problems of distributed applications. There are three main pieces of .NET Services:
Live Services isn't really all that new, they're just being re-branded underneath the Azure umbrella. This is all of the goodies that you get with the Live APIs like contacts, calendars, e-mail, identity, etc.
So..what does all this stuff mean anyway? What's in it for you? In the short term what it means is that developers are going to start finding that they have been given a ridiculous amount of power. This is more than just Microsoft hosting your code in some central data centers... This is Microsoft abstracting away the notions of data centers, virtual machines, or even physical CPU cores (well, that abstraction is coming later). If you want to build an internet application, and you want to build it quickly and easily and you know that your app needs to run "out there", and you don't have the resources to do it yourself, or have your own data center, then you're going to find that Azure may just be that enabling force that we've all been missing for so long.
Windows Azure's concepts of Web Role and Worker Role is absolutely, totally, and unequivocably a game-changer in the world of cloud computing. The best thing we've had prior to this were cloud-hosted VMs that had a predefined stack (e.g. ASP.NET or J2EE or PHP or Cold Fusion, etc) to which we could upload our code and hope it all worked. There are always problems in managing configuration files of hosted apps and your hosted app NEVER behaves the same way while hosted as it does on your home PC. With Windows Azure, they're saying - quit worrying about the physical logistics - build your app, write your logic, use (cloud) data, and fahgeddaboudit. If the price is comparable - where are you going to host your back-end services? Amazon's EC2 or Azure, especially if you want to write your back-end services in .NET?
If the prices are comparable, are you going to write your cloud app to use S3 data or SQL Services or Azure cloud storage?
Even just a few years ago, people didn't live on their computers - they thought of them the same way they thought of their graphing calculators - only they were more powerful. Now, people live on their computers. Moreover, they live online. They live connected. They live attached to the cloud. The problem is that right now, developers don't live attached to the cloud.
Before cloud services, picture a meeting between a couple hobbyists who are thinking of building an app. They say, "Ok, we're going to need a web app.. but, we'll need some services and some central storage." At that point, they're forced to lease space in a data center, paying up front before anyone is even using their app, or they're forced to make COMPROMISES in their app's DESIGN to accomodate limitations of hosting companies.
With cloud services like Azure, those same people in that room talking about big ideas for big apps can now simply concern themselves with what they want their app to do instead of how they're going to manage the logistics.
-- That said, this is all on probably a 1.5 to 2 year time frame before this stuff is fully baked and they've got critical mass adoption. There is a lot of promise in Azure. Here's to hoping they pull it off.
I like how they chose a name that means "clear sky" for cloud computing.
Other then that this sounds awesome.
Well, it's internal codename was "Red Dog", so I think Azure is actually a
pretty good improvement :)
Kevin - I love your posts on our forum (Windows Azure). Can you send me a
email (sriramk_at_microsoft.com) ? I would like to figure out how to get
you into some of our community inputs
You're ignoring the fact that you have to use an API that is exclusive to
Azure and can never be moved to a server not owned by Microsoft, including
your own. This is the ultimate in lock-in for developers. Once your app is
deployed to Azure you pay whatever price MS asks you to pay for hosting
with zero ability to move to a new provider. In that respect Amazon's EC2
makes way more sense: slightly less convenient but much more sensible for
anybody that wants to build more than trivial applications. At least with
Win32 lock-in you can control distribution of your application. With Azure
developers are completely beholden to Microsoft for hosting and have zero
control over their own application.
I disagree. If you decide to use Oracle, you're bound to that decision. If
you decide to build your application against SQL Server, you're bound to
that decision. If you decide your Web App is going to be hosted by
CompanyXYZ, you are beholden to the quirks of their environment (and don't
try and tell me environments don't vary by hoster). You're also beholden to
Amazon's particular environment if you go with that, whether it's
immediately obvious or not. Likewise, if you choose to build your
application in Microsoft's cloud, you're beholden to that decision as well.
It's a functional specification requirement decision, just like any other
development project. It is no more or less a vendor lock-in than any other
decision you make about your application infrastruture requirements.
If I decide to use Oracle or SQL Server I have the option of letting
someone else host my app, or I can buy a server and host it myself. If I
host with Amazon yes there may be quirks with their environment, but my app
is still running on an off-the-shelf Windows or Linux platform and I can
reasonably easily move it to a server of my own. If I code my app for Azure
I am writing to the Azure API, not an off-the-shelf Windows API. If I want
to host the app myself I cannot buy a copy of Azure and host my app on my
own server. My only option is to rewrite my app using a different API. This
is much more burdensome than simply adapting to the quirks of a different
hosting environment.
KJ - I understand you concern, but I think you are missing the point about
Azure; its a whole different concept - its cloud computing where your data
is stored differently, your apps are structured differently, you need
queues, worker processes etc. This makes your application compatible with a
cloud based computing model which gives you benefits of availability,
scalability, automation and more. So by its very nature, you have to code
to the Azure API. Unless some kind of public specification is developed for
cloud computing which vendors adhere to then lock-in is inevitable.
Of course there will be lock-in to the Azure API; that is to be expected in
the same way you would be locked into Win32 or .Net. My concern is being
locked to a single hosting company (Microsoft) with no possibility of ever
hosting my own code/data or moving it to a new provider, because MS is the
only company that will be hosting Azure. If you use the service you're tied
to them for life and if they raise prices or decide that hosting is no
longer profitable and want to shut down you have zero recourse to take your
application elsewhere. That is simply insane for a business to consider and
I'm surprised you accept it so willingly.
In a world of Salesforces, Google Apps, Ebay, Google mail and goodness
knows what else, lock-in is a fact of life; in each case, we should
evaluate the risks involved and make a sensible decision. Lock-in is not a
Microsoft problem - its an industry problem.
I totally agree. Cloud computing is a new paradigm for everyone involved.
Comparisons like the ones we're making in these comments just don't hold
water. If you decide to go into the cloud, you're locking yourself into a
cloud mentality. Whether your low-level layer is translating your stuff
into Azure service calls or Amazon service calls or Bob service calls -
that's not really the point. The point is that at some point, you sat down
with your team and decided that your app was going to reside in the cloud,
and you picked WHICH cloud on which it was going to reside, because we're
not at the point yet where there is some kind of unifying dialect that
allows all clouds to talk to each other. That said, _Azure_ is 100% RESTful
and uses industry standard wire formats like raw XML, Atom Publishing
Protocol, JSON, etc. This is about as open and free from lock-in that you
can get in a cloud services platform.
