Definitely. I am a really high CPU user but don't need hardly any storage (I'm doing chess calculations). With bundled resources I always notice I am always over-specced on RAM and storage (in particular). Would be nice to have 'liquid' computing resources. As you say, nice post and nice to see someone doing that.
The post (marketing article) says nothing and doesn't identify what vendor they are trashing. As far as I know my 'IaaS' vendor doesn't retain root access. The article makes almost no sense, it starts be trashing iaas, then suggests paas, with out attempting to explain any difference between a 'platform' and 'infrastructure'.
The only thing missing from the article is an affiliate code on the enstratus link. Then it would be fully clear who wrote it and why. Has anyone not selling something ever uttered the phrase 'deploy best of breed solutions'? I think not.
If my current iaas vendor retains root access then I certainly don't want a more 'managed' solution.
Having just read the post I disagree. The post clearly says that most current vendors place significant restrictions on the software and networking layers in their cloud. As someone who has used GoGrid, Rackspace and AWS I can concur with this position. You have a lot less control over your cloud servers than you do over say a dedicated server.
CloudSigma are an IaaS provider who presumably take a different approach.
Overall I think it is a valid point for them to make, especially as it seems that a lot of these restrictions are vendor created.
I think that most of the problem with IaaS vendors, EC2 in particular is that the IO throughput is absolute shit. I've never had a problem with the software I'm allowed to run on EC2, I've always had a problem with its horrible IO throughput.
There is also a lot of comfort in knowing everyone else is running the same kernel and there will be some difficulty in executing various exploits for the hypervisor.
Actually in our cloud there aren't any shared software resources between cloud servers which is why you can run any operating system you like. Each cloud server is a standalone entity in its own container. We feel this is a lot more secure and flexible.
With regards to IO throughput, this along with networking performance are two areas we identified and sought to address when designing and building out our platform. You might be interested to read my blog post earlier about benchmarking cloud servers and differentiating performance between clouds at http://bit.ly/a7CqV3 . Basically storage performance is one of the key differentiating factors between clouds. Again the performance has as much to do with vendor hardware and architecture choices as it does to do with fundamental cloud computing issues.
There are people moving towards an open source implementation of high scalability cloud services. For example, the OpenStack project at http://www.openstack.org.
The main pieces were contributed by Rackspace and NASA, but dozens of other contributors are involved in the project now.
The API doesn't solve the real problem of vendor lock-in and the OpenStack API is basically the Rackspace API with all those restrictions. We posted regarding this previously at http://bit.ly/fSJZ79 . It isn't fundamentally bad but it just reinforces the same restrictive model.
It doesn't answer the fundamental points we raise regarding false constraints imposed by vendors such as yourselves (not specifically aimed against Rackspace) like:
- bundling of resources
- fixed instance sizes
- software level control by the vendor
- filesystem visibility by the vendor
etc.
We have taken a different approach. Our point is there are many approaches and implementations to IaaS and the current larger ones impose many restrictions on customers and are much more like traditional hosting type models on something that can be a lot more open and flexible. We are talking about the true sense of 'open'.
Why not allow customers to have control of their operating systems, networking and server instance sizes? The underlying virtualisation platform supports it. That means the vendor is actually choosing to impose those restrictions on the customer in their software. We choose not to. Its just a different approach.
As a counterpoint, I'd like to say that it makes a lot of sense to retain some level of control of servers you are renting. You want to avoid your cloud becoming a botnet cloud (what would that be, a virus cloud? O.o).
If you have your own admins keeping things up to date and polished, it removes (1) some grief from the customer and (2) allows you to rest more comfortably knowing your admin (theoretically) knows what he's doing.
The author points out that for conventional electric devices, there is no input from the electric company. True. But, if one puts in an industrial facility, the electric company starts caring, because the loads can not be simply ignored (c.f. inductive/reactive loads). That has analogies to the cloud.
There are decided advantages for the customer to have full control, there are decided advantages for the vendor to have full control.
Yes you are right, it is certainly easier to snoop on customers as an IaaS vendor if you keep full root access and file system visibility. I'd say that constitutes 'lazy policing' and not needed and that is certainly our experience :-)
Botnets etc. rely on free hijacked capacity not computing resources bought on an industrial scale on commercial terms. The cloud is no more prone for use as a botnet or other problematic activity than dedicated hardware. Although often touted, I've yet to hear a compelling case for IaaS clouds being any more susceptible to such use than VPS, shared hosting etc. etc.
Likewise, such activity becomes very obvious very quickly and it isn't access inside a customer's cloud server that allows you to spot such activity.
As I say, there are not real reasons not to give customers full control of their cloud servers any more than they have full control of their dedicated servers. In fact, the flexibility of the cloud makes policing it more easy than dedicated hardware without snooping inside customer servers or restricting their ability to control their computing.
In terms of administration, customers can choose to use their own in-house admins or that of a third party and many of our customers do. The point is they done have a choice, with other clouds they have one choice, the cloud vendor as the admin. That's overly restrictive and it isn't surprising why you get such concerns raised over security and control in the cloud.
10 comments
[ 3.5 ms ] story [ 20.9 ms ] threadDefinitely. I am a really high CPU user but don't need hardly any storage (I'm doing chess calculations). With bundled resources I always notice I am always over-specced on RAM and storage (in particular). Would be nice to have 'liquid' computing resources. As you say, nice post and nice to see someone doing that.
The only thing missing from the article is an affiliate code on the enstratus link. Then it would be fully clear who wrote it and why. Has anyone not selling something ever uttered the phrase 'deploy best of breed solutions'? I think not.
If my current iaas vendor retains root access then I certainly don't want a more 'managed' solution.
CloudSigma are an IaaS provider who presumably take a different approach.
Overall I think it is a valid point for them to make, especially as it seems that a lot of these restrictions are vendor created.
There is also a lot of comfort in knowing everyone else is running the same kernel and there will be some difficulty in executing various exploits for the hypervisor.
With regards to IO throughput, this along with networking performance are two areas we identified and sought to address when designing and building out our platform. You might be interested to read my blog post earlier about benchmarking cloud servers and differentiating performance between clouds at http://bit.ly/a7CqV3 . Basically storage performance is one of the key differentiating factors between clouds. Again the performance has as much to do with vendor hardware and architecture choices as it does to do with fundamental cloud computing issues.
Best wishes and thanks for your feedback,
Patrick CEO CloudSigma http://www.cloudsigma.com
The main pieces were contributed by Rackspace and NASA, but dozens of other contributors are involved in the project now.
Full disclosure: I work at Rackspace.
It doesn't answer the fundamental points we raise regarding false constraints imposed by vendors such as yourselves (not specifically aimed against Rackspace) like: - bundling of resources - fixed instance sizes - software level control by the vendor - filesystem visibility by the vendor etc.
We have taken a different approach. Our point is there are many approaches and implementations to IaaS and the current larger ones impose many restrictions on customers and are much more like traditional hosting type models on something that can be a lot more open and flexible. We are talking about the true sense of 'open'.
Why not allow customers to have control of their operating systems, networking and server instance sizes? The underlying virtualisation platform supports it. That means the vendor is actually choosing to impose those restrictions on the customer in their software. We choose not to. Its just a different approach.
Best wishes,
Patrick CEO CloudSigma http://www.cloudsigma.com
If you have your own admins keeping things up to date and polished, it removes (1) some grief from the customer and (2) allows you to rest more comfortably knowing your admin (theoretically) knows what he's doing.
The author points out that for conventional electric devices, there is no input from the electric company. True. But, if one puts in an industrial facility, the electric company starts caring, because the loads can not be simply ignored (c.f. inductive/reactive loads). That has analogies to the cloud.
There are decided advantages for the customer to have full control, there are decided advantages for the vendor to have full control.
Botnets etc. rely on free hijacked capacity not computing resources bought on an industrial scale on commercial terms. The cloud is no more prone for use as a botnet or other problematic activity than dedicated hardware. Although often touted, I've yet to hear a compelling case for IaaS clouds being any more susceptible to such use than VPS, shared hosting etc. etc.
Likewise, such activity becomes very obvious very quickly and it isn't access inside a customer's cloud server that allows you to spot such activity.
As I say, there are not real reasons not to give customers full control of their cloud servers any more than they have full control of their dedicated servers. In fact, the flexibility of the cloud makes policing it more easy than dedicated hardware without snooping inside customer servers or restricting their ability to control their computing.
In terms of administration, customers can choose to use their own in-house admins or that of a third party and many of our customers do. The point is they done have a choice, with other clouds they have one choice, the cloud vendor as the admin. That's overly restrictive and it isn't surprising why you get such concerns raised over security and control in the cloud.
Thanks for the great feedback by the way.
Best wishes,
Patrick CEO CloudSigma