The cloud servers in a perfect world even if the reliability, and performance was there still incur the same high costs as a dedicated server for less of a ‘machine’. You can tout scaling but there isn’t a cloud system out that that can get a more than a bare bones cloud server up quick than you can turn up a phsyical server, or better yet turn up your own VM.

The potential for cloud servers is there, but until price & features/reliability/performance meet, I’m afraid it’s more marketing hype than a truly viable solution.

We have found the cloud to fill certain roles very nicely and will continue to expand our footprint with those services.

Here’s some bad and good we’ve experience so far.

The Bad:

While stability has improved tremendously, some issues continue to hamper wholesale switch to the cloud:
- Private network maintenance/issues
- SL maintenance
- Lack of Transparency
- Critical Failures

Though it is decreasing, private network maintenance pulls your cloud instances offline. This increases downtime compared to a dedicated server. Also, consider that this work is not under your control but at SL’s discretion.

Once again decreasing, but we’ve noticed maintenance impacting cloud instances more frequently than dedicated resources.

In more than one case, we have had cloud instances fail to respond to any control methods via the portal. To resolve the situation, we have to open a ticket with SL to get it resolved. The underlying cause is not always shared or known making it difficult for us to assure clients that issues are not recurring.

We have have 2 total failures where multiple cloud instances have failed due to SAN or network problems. The ability to isolated instances into different groups so they would not be impacted by the same point of failure would be very helpful.

The Good:

Besides the obvious, less costs, rapid deployment, etc. Here are some other ways we are really leveraging the solution:

- Development systems
- DOS/Security Mitigation
- Rapid Recover
- Diagnostics

Instead of maintaining various build boxes internally, we now have cloud templates for various development tasks. When we need them, we spin them up, build our tools, shut them down. Using a template assures a standardized build environment.

We have put up reverse proxy/filtering systems in case of an attack. Very quick and easy, especially when using portable IPs.

As with the DDoS, if you use portable IPs, you can often bring up a new cloud instance using your templates much faster than SL can fix some outage.

We use them for diagnostic purposes. If a box is having some odd issue, we can easily clone it and diagnose without impacting production operations.

I am hoping that over the year the bad will continue to decline and that we will find many more good uses.

The short answer to the question of upgrading disk capacity of a cloud instance is that it can’t be done without moving to another instance … Once it’s locked into place, it’s effectively a fixed-maximum hard drive.

As I understand it, an LVM can be used on a secondary “disk” in the cloud to enable additional disk space (up to a total of four secondary disks). I don’t think we typically manage this kind of administration, but it’s relatively straightforward to set up.

Does that help?

The one question I have yet to be able to get a straight answer on is, say we purchase a private cloud instance with say 250gb of disk storage and all of a sudden, we need more disk capacity. How do we add, say another 250gb of disk that to the current private cloud instance without having separate /home dirs or having to move to another instance?

Would this be accomplished by having SL setup the instance with the Centos LVM or does that matter?

Regards,
Eric Caldwell – CEO
Web-JIVE.com