Frans Bouma's blog - All Comments

re: "Cloud Cloud Cloud, if you're not in it, you're out!"... or something

Haripraghash — Fri, 20 Nov 2009 00:49:14 GMT

Wow!!Thats some thoughtful insight:)Never thought about azure this way

re: "Cloud Cloud Cloud, if you're not in it, you're out!"... or something

thebitstreamer — Thu, 19 Nov 2009 07:30:17 GMT

I guess you dont now about what problem the Cloud address. Please think about: resilency, on-demand scaling, business continuity and other problems that are becoming more and more complex to address inside organization.

Obviously to solve these problem the application must observe some rule by design. These rules are enforce on the cloud but not on the 99% of the other software platform.

Then, for a sysadmin like me, as these policy are enforced by infrastructure is much much simple to grow, to protect to enpower infrastructure

re: "Cloud Cloud Cloud, if you're not in it, you're out!"... or something

Erwyn van der Meer — Wed, 18 Nov 2009 19:23:57 GMT

The details of how the Windows Azure Platform solves the OS update problem haven't changed since last year's PDC. Maybe we didn't clearly communicate them enough.

Windows Azure is a virtualized OS currently based on Windows Server 2008 running on a specialized version of Hyper-V. You specify the number of virtual machines you want (per role) and we take care of the OS and app provisioning.

If the OS needs to be patched, a new VM is spun up based on the new OS image and your app is automatically deployed into that image. This new image comes online as soon as your app is initialized. The old machine is taken offline and recycled. If you have multiple machines per role, the load balancing will take care of the rest.

Updating your app or increasing capacity works largely the same.

Does this mean that your app needs to deal with state differently if you rely on in memory state? Yes! Your app should only rely on state in memory for caching and all data that needs to be persisted needs to be persisted on disk. This can either be persistent local storage (which *is* preserved across VM recycles), SQL Azure or Azure tables and queues.

But not relying on the persistence of in memory state is always a best practice. You need to be prepared for system failure at any time even if you run your app in your own datacenters on your own physical machines.

Regarding an identical test environment. You can use a staging environment that is identical to production. When you hit the take into production switch, this staging environment even instantly becomes the production environment. The development environment is different in scale and is simulated using the Dev Fabric provided with the Azure SDK and the Visual Studio Tools.

re: "Cloud Cloud Cloud, if you're not in it, you're out!"... or something

Alex Yakunin — Wed, 18 Nov 2009 16:20:07 GMT

It seems you'd like cloud to be a virtualization platform allowing existing software to scale up without being significantly changed. But this won't work well, and the reasons are the same as for migration to multicore CPUs: software must be designed differently to take all the benefits of new environment.

E.g. in case with clouds it's theoretically impossible to provide isolation, scalability and performance all together, and you must consider this if you're going to use petabytes provided there.

The same about concurrent data processing: theoretically you can accomplish some tasks quite fast there (e.g. using DryadLINQ), but you must involve a special API to make this happen; moreover, you should take into account your planned data flows while utilizing it. So this is no the same as e.g. relying on TPL.

Finally, requirements to fail tolerance in cloud are different: you must admit any node you your code runs at may fail, and this is absolutely normal case. And it's your problem to implement a successful recovery there (if it isn't solved on lower layers). A good fail tolerance here implies implementation of distributed state machine - that's what you never need on regular servers.

So dealing with cloud is intrinsically different. Of course, in many many cases you don't need to think about this to get some benefits for free (multicore CPUs also provide some of them - e.g. different programs on your PC runs in parallel, because OS takes care of this). But generally, there is no free lunch.

re: "Cloud Cloud Cloud, if you're not in it, you're out!"... or something

Thomas Wagner — Wed, 18 Nov 2009 15:00:05 GMT

We are years away from a useful solution or useful offer in the cloud space. Who wants to part with their sensitive data? The whole thing feels a little like a solution in search of a problem. There will be something good that comes out of this... but I dont think its what the pundits and marketing people proclaim right now.

re: "Cloud Cloud Cloud, if you're not in it, you're out!"... or something

Keyvan Nayyeri — Wed, 18 Nov 2009 14:56:03 GMT

Great post, Frans :-)

I also shared my thoughts here:

nayyeri.net/is-windows-azure-the-right-technology-for-the-future

re: "Cloud Cloud Cloud, if you're not in it, you're out!"... or something

Awkward Coder — Wed, 18 Nov 2009 13:51:12 GMT

I thought one of ther main ideas around the 'Cloud' was reduced provisioning time when you need to increase capacity etc...

re: "Cloud Cloud Cloud, if you're not in it, you're out!"... or something

Christopher Mahan — Wed, 18 Nov 2009 13:12:50 GMT

What if as a developer I want to be able to develop the app directly in the cloud space that the app will occupy while running. Does Azure offer that?

And as far as uptime is concerned, this "cycle" the machine is why I have moved to debian stable. The only reason you have to cycle the machine is to upgrade major kernel releases, and that's rare. Even with hardware upgrades, power failures and so on, it is not uncommon to have uptime exceeding 300 days. I don't know how that will translate with running debian stable on amazon ec3, but it might.

re: "Cloud Cloud Cloud, if you're not in it, you're out!"... or something

David Hope — Wed, 18 Nov 2009 12:56:09 GMT

This article was a pleasure to read specially after having seen the following production from IBM. I didn't think it was possible to combine two buzz techs into the same product but they managed it.....

WebSphere CloudBurst Appliance

Extend Smart SOA applications and services into a private cloud

re: "Cloud Cloud Cloud, if you're not in it, you're out!"... or something

FransBouma — Wed, 18 Nov 2009 12:42:30 GMT

@Craig: you say Azure will largely solve these problems, but how will it do that? Does it provide to be a virtualized windows environment? Or do I run a VM with 2008?

I'm willing to believe what you say, but to me it's not clear that it will do that. For example Amazon's EC2 has the same selling point but also can't provide you a zero-maintenance OS layer: it provides a way to run an image (OS + app) at whatever spec you want, 1, 10 machines you name it. But that doesn't free you from patching tuesday. that your app can run on two VMs to provide 100% 'uptime' is not easy if your app isn't build with 'I run on multiple machines at once so there's no state' in mind.