Okay, I’m really trying to give CC a chance. The first big issue is pricing, but let’s assume there are some scenarios where it might make sense.
But now the “Terms of Use” (ToU) have come up. Our lawyers reviewed the EC2 ToU, and they are completely unacceptable for anything other than R&D. Amazon takes no responsibility for anything, and they can unilaterally change the ToU at any time. And the “SLA” appears to be pure marketing, as they are apparently under no commitment to achieve that SLA in the ToU. So there’s still no real SLA.
Has anyone negotiated a more commercial-friendly agreement with EC2? Did I miss the menu option for commercial users?
This is really a very long way from becoming anything but a toy, between the pricing and ToU, unless again I’m missing something.
Generally different tools find different ways to be implemented, and
different (though perhaps overlapping) audiences to serve. The whole
ownership issue, as stated, is a throwaway in my mind. It's just not
clear what the point of that is, what your definition of cloud
"ownership" is, and it doesn't provide any proposed solution to the
alleged problem of cloud ownership.
brian
--
Brian K. Jones
Python Magazine http://www.pythonmagazine.com
My Blog http://www.protocolostomy.com
Sharing our experience on EC2.
We (Catalytic Software) have used Amazon Web Service EC2 since February for two production servers in a commercial project. In that time we have had 0.0% downtime due to EC2 failures. The only problems we had were in the setup – it was a little difficult to figure out how to get our first instance uploaded. Once we crossed that barrier, we have had no problems due to AWS EC2.
AWS offers reasonable prices, scalability, secure storage as well as a number of other features we don’t use at this time, but potentially might use later. They have a web page dashboard which shows whether their systems are performing normally. Given our good experience, we think Amazon is suitable for commercial applications.
I’m sure their ToA is written to minimize liability if something does happen, but we now have almost 20 (combined) months of service with no disruptions.
-Sid Porter
I'm very much reminded of the hijacking of the term 'hacker' from back
in the day. For those who recall, a 'hacker' simply meant a
programmer, but the term was hijacked by the media and hence the
mainstream to refer to malicious attackers. Despite all attempts,
'hacker' still has a clear connotation.
Whining about how 'clouds' are 'grids' isn't helpful. Next topic
please.
--Randy
On Nov 12, 2008, at 8:48 AM, Jonathan Davis wrote:
> The term cloud computing is today being used by many providers who, in
> fact, are actually offering Grid Hosting.
Randy Bias, Founder, The CloudScale Project
BLOG: http://neotactics.com/blog
-- =================================================== Ioan Raicu Ph.D. Candidate =================================================== Distributed Systems Laboratory Computer Science Department University of Chicago 1100 E. 58th Street, Ryerson Hall Chicago, IL 60637 =================================================== Email: ira...@cs.uchicago.edu Web: http://www.cs.uchicago.edu/~iraicu http://dev.globus.org/wiki/Incubator/Falkon http://dsl-wiki.cs.uchicago.edu/index.php/Main_Page =================================================== ===================================================
Commodity prices? Have you actually looked at their prices? The annual
cost of a four core instance is five times the cost to buy a more core
capable physical server. Toss in the co-lo costs and it's still many
times the cost of buying a server. And they give no service on the
instance whatsoever -- none.
I just don't get it. Their prices are whacko for 24/7, their service is
less than minimal (consisting a virtual reboot on demand), and their
terms of use let them kick you off for "for any reason or for no reason"
with 60 days notice on a fully paid up account.
Yet the people of this list think it's the bees knees. Why? No one has
answered Marks post of about costs (and no one answer mine earlier in
the summer). And no one has answered why a company would put investment
in as service that could be canceled "for any reason or for no reason"
in 60 days.
(My next batch of servers, each more capable than Amazon's SLA and not
subject to additional compute charges, are $1,152 each. Hardware is
cheap, friends. Service is expensive. But Amazon doesn't provide
service...)
What, in your experience, makes OpsWare unviable in public clouds?
Does that carry into private clouds (ie. Utility-style Capacity on the
floor, Provisioning whole applications instead of just VMs), or do you
think enterprises will use OpsWare to build their private clouds?
Do you see HP building their cloud stuff out of OpsWare or something
all-new?
What, in your experience, makes OpsWare unviable in public clouds?
1) solaris patching is supported via a couple different mechanisms, especially in the new release, in earlier releases we supported solaris patching via a custom extension developed by our professional services team
2) no AD is required at all, or even recommended? We have LDAP integration for customers using SSO infrastructure, and AD hooks for generating group perms
3) virtualized resources are our primary focus in the latest release, and lots of our customers manage virtual resources via HP SA
4) high concurrency is a core competency, and our capabilities meet the needs of our customers, who could be considered the most demanding in the world :)
Also when discussing automation, it's important to mention storage and network automation, along with process automation, which we have broken out into dedicated products.
The general feel that enterprise management tools are too "heavy" for CC seems like an attempt to disparage applicable solutions for being comprehensive. Relating install media size to the overhead or memory usage of an app as you kind of try to do seems like a bad analogy. Most of the install media is supporting the fact we can install on solaris or RHEL, requiring 2 copies of a lot of the binaries, not to mention the database options we provide to clients taking up media space. We don't even end up using anywhere near half that 25G number on disk after the install is completed.
Also if you could clarify what you mean by private versus public clouds and an example of one of these public clouds you refer to where management infrastructure (recommended, not required) is unavailable? I find the idea of these public clouds interesting, but I don't know of any. Even EC2 is a private cloud by your definition near as I can tell, but I digress.
Also when discussing automation, it's important to mention storage and network automation, along with process automation, which we have broken out into dedicated products.