If you are talking about cheap way to create cloud then you are in wrong direction. Cloud is not cheap thing, it cost a lot. Even OnApp license will cost you more than 2 servers, if you use them. Apart from price, creating cloud is a science and it need expertise. In short, you'll need the following:
- API based access, so that your customers can create/update/delete cloud servers on demand
- hourly billing
- cloud features
- ability for users to create/update their own images
- ability to create private networks, connect to public network
- extra services
- volumes
- firewall
etc
To be honest cloud is loosely thrown around with a lot of providers, especially new companies, but that problem really just stems from it being a vague term in itself with the many variations of what constitutes a cloud. A "cloud" is really just a pool of computing resources, so it is wrong if companies are representing a dedicated VPS on an individual piece of hardware as being cloud service, but I think this is rarely the case; VPS just gives your shared of computing pool. "True Cloud" is something that can scale and is ultra redundant.
True but the real cloud platform has more infrastructure setup for this. As load-balancing, redundancy, sync etc to store the content to multiple location. But for a budget hosting provider, its not feasible. There is however really only a couple ways to do this.
You could use DRBD to replicate one server to a backup. If the primary fails you can use heartbeat to change / add ip(s) to the secondary server. Once the primary server comes back up it turns into the secondary server. This is just a 1+N setup. You'd only ever have 1 server responding to requests but you can replicate to as many backup servers as you'd like.
You could use a HA file system and run on your own private (or even public) cloud. There are some 'cloud' services which truly are 'cloud' services (not just vps on one machine with local data store). When the physical server fails the node will be restarted automatically on another node.
There will be some downtime with both of the above methods, but only seconds.
The third method would be to make the application you're hosting redundant. You'd run multiple webservers, database servers, etc so if any one server goes offline it has no impact into your site availability. The load balancer is still a single point of failure in this scenario though. With the load balancer you can make it more redundant, but there is still some downtime when heartbeat or pacemaker swaps the LB from one node to another. (Again, just downtime in seconds).
You can do any of these 3 methods for relatively cheap (couple $100/mo). You can also mix and match. You could use cloud nodes and make your application highly available / redundant. The minimum number of nodes required for a fully redundant application is 3. You'd need 3 galera nodes, 3 apache nodes, and 3 pacemaker nodes. You can install galera, apache and pacemaker on the same node. You might have some quorum problems out of pacemaker and galera with this configuration though. You could host this on amazon, google, azure, etc for $100-$200/mo.
Just look at the requirements of something like:
OnApp and OpenStack
Then think scale and business model, because competing in today's world is probably a lot harder than before when it comes to cloud.
What exactly are you trying to do?