Comments on: Cloud platform patching conundrum: PaaS has it much worse than IaaS and SaaS

By: » Come for the PaaS Functional Model, stay for the Cloud Operational Model Cloud Comedy, Cloud Tragedy

Fri, 03 Feb 2012 04:56:10 +0000

[...] I’ve covered this in more details before and so has Chris [...]

By: William Vambenepe — Lifting the curtain on PaaS Cloud infrastructure (can you handle the truth?)

Wed, 20 Oct 2010 04:25:36 +0000

[...] I have described before, change and configuration management in a PaaS setting is a thorny problem. This console [...]

By: William Vambenepe — Analyzing the VMforce announcement

William Vambenepe — Analyzing the VMforce announcement — Wed, 28 Apr 2010 05:05:17 +0000

[...] make sure the change is scheduled during a non-critical period for theirbusiness. I wrote an entire blog post on this issue six months ago and it’s a little bit disheartening to see the issue flatly [...]

By: William Vambenepe — Desirable technical characteristics of PaaS

William Vambenepe — Desirable technical characteristics of PaaS — Tue, 10 Nov 2009 20:01:45 +0000

[...] Assistance for debugging platform-hosted code (see this entry). [...]

By: Alain Yap

Alain Yap — Tue, 27 Oct 2009 07:01:47 +0000

Getting educated via your posts, William. Thankful for this as we still consider ourselves a Paas player, first and foremost, and we think that our releases are pretty much tops with help from the different open source dev communities.

Of course, personally, the threat that cloudsAmazon creeping up on incorporating Paas features is definitely real but then again, I think our guys are way ahead for now.

Thanks.
Alain
G2iX

By: links for 2009-10-22 « On IT-business alignment and related things

links for 2009-10-22 « On IT-business alignment and related things — Thu, 22 Oct 2009 23:13:33 +0000

[...] William Vambenepe — Cloud platform patching conundrum: PaaS has it much worse than IaaS and SaaS Gets a little deep on the tech, but a great analysis of the potential risks of supplier patching in different kinds of Cloud environment. (tags: cloud_computing itil risks app_containers) [...]

By: William Vambenepe

William Vambenepe — Thu, 15 Oct 2009 17:45:26 +0000

Hi Sam,

I hope you’re right and I am overly worried. But you haven’t convinced me yet. You write that

“Google App Engine for example is fairly careful about its releases such that they’re in a pretty good state by the time they see the light of day.”

That’s nice but you know Oracle and its competitors are also “fairly careful” (actually more than that) about patches and updates. Does this mean that when the customer gets them they should deploy them immediately on their production systems? Not necessarily. If it’s mission critical, they’ll test on a replicated environment, they’ll schedule the change and they’ll have a rollback strategy. That’s not because Oracle is sloppy. Most of the time they’d be fine blindingly applying the patch. But “most of the time” does not cut it for mission-critical systems. The issue I describe is in the context of such systems (maybe I should have been more explicit), which are the systems for which so much config management technology/processes have been created.

For these systems to run in PaaS environments, this issue needs to be addressed. As usual, it will be through a mix of technology and processes.

By: William Louth

William Louth — Thu, 15 Oct 2009 10:14:02 +0000

Would it not be just better to offload the actual (Java) computation work onto an appliance that has very little of such configuration artifacts like Azul Systems Compute Appliance – http://www.azulsystems.com/. If you still need native OS integration it is possible though at a cost of a network roundtrip (to and from the appliance). That is better than not being able to do it at all.

By the way how many of those files visualized above are actually likely to be under change management?

By: Sam Johnston

Sam Johnston — Thu, 15 Oct 2009 08:47:43 +0000

Interesting read as usual, but in reality I’m not seeing this being a problem. Sure we’re not seeing millions of applications hosted on “cloud platform services” (can we drop the “aaS” already please?) but vendors like Google are already doing a lot of what you talk about.

Google App Engine for example is fairly careful about its releases such that they’re in a pretty good state by the time they see the light of day. Updates are incremental so developers can deal with issues one by one rather than bundled together in a large release. It exposes only a narrow view of both Python and Java APIs so as not to give developers enough rope to hang themselves. I *love* this – so many failures are caused because of developers straying from the garden path and many of these “opportunities” have been taken away. There is versioning (though I’m not sure it’s really used) and all their nodes are the same so it’s overwhelmingly unlikely that you’ll run into configuration related problems.

Salesforce is more from a software background so they do “seasonal” releases… that’s good for stuffy enterprise change management monkeys but not really fitting with the “cloud way” of change management – small, incremental changes on an ongoing basis. One advantage of the Salesforce way is that you can just patch the specific bugs and nothing more (ala Debian Security Advisories) but that doesn’t give you a way to introduce new features without having releases. Google Apps is also worth a look in this regard as they allow you to stop pre-release features from filtering through, in which case they are battle tested by the time you invariably see them.

Sam