The difference between VPS and Cloud
caker
Linode Staff
Thanks,
-Chris
28 Replies
Cloud - I get resources, scalable as needed, across a cluster of boxes.
Last weekend I was reading some threads at wht about this same topic and this post has a good explanation:
> It is not any particular technology. It an approach to computing, a model that allows for distributing computing resource through a network of servers. In Web Hosting a cloud computing infrastructure means - high availability, load-balancing, system and service scalability, redundancy on software and hardware level, and flexibility.
caker
Linode Staff
-Chris
@caker:
To clarify…
Now I'm confused.
Can a single box be a "cloud"
@caker:
To clarify, I'm asking about one VPS vs one Cloud server (linux box). IaaS, not PaaS.
Well, then, you're defining "cloud" as a VPS.
"Cloud" is a meaningless feel-good term, like "green" or "next-generation" or "healthy." Without some additional context, "cloud" seems to mean "something you can't kick."
Things that are green: hybrid cars, energy-efficient UPSes, recyclable coffee cups, R-134a, cloth diapers, frogs, staycations, new buildings
Things that are cloud: Linode, Gmail, Dropbox, the Amazon family of brands, FedEx Office, fog, Google App Engine, high-availability shared hosting
See, it's a meaningless term on its own. You cannot ask the difference between VPS and Cloud, as it makes as much sense as asking the difference between Toyota Prius and green. Best you can do is come up with reasons why VPS might not be cloud.
Some might say VPS is not cloud because it is typically unmanaged: you have to actually do something to make your application run. To this I say that Google Docs is not cloud because you have to set up formulas and all that to make a spreadsheet balance your checkbook.
Some might say VPS is not cloud because it does not automatically scale. Indeed, this is very closely related to the unmanaged nature of the service. It cannot automatically scale unless you make it automatically scale, which is entirely possible to do.
There are probably other reasons and whatnot, but I think I'm procrastinating by writing this post, so I shall stoke the fire and be off.
Cloud: It's in an undetermined location (chosen by provider when it's instantiated, may move during use, might not even be on one physical machine) and offers and agreed amount of resources (memory, cores, compute units, disk, network).
Of course, you could use one service for the other - I could treat Linode as a cloud in this sense by turning on a whole bunch of nodes, and then shutting them down in a day after the jobs are completed. Or I could leave my EC2 instances running forever to serve my website. I think it's pretty clear though that each service is tailored particularly to each use-case, so Linode would be considered a VPS while EC2 is cloudy.
On a side note, there is another usage of cloud that occurs when people say "the X is in the cloud". This usage has to do with doing work locally on your machine but having the storage and hard computation occuring server side ("My email is in the cloud", "I store all my cow photos in the cloud").
- long term being relative
A cloud is a collection of resources that may not necessarily be co-located. "Applications" which run within the cloud are not necessarily bound to specific hardware and can migrate between them (dynamic migration during run-time is an advanced cloud feature and not a hard requirement of a cloud). New application instances can be created and existing instances destroyed quickly. Billing is typically pro-rated at a relatively granular level and based on some usage metric.
A VPS is an operating system instance. This instance may be created as an application in a cloud, or it may be tied to resources on designated hardware; it's not relevant.
I'm guessing the original question is leading to whether Linode is a cloud provider or not. In my mind, no; the OS instance ("application") is tied to specific hardware. It can me migrated but this is slow and relatively painful (block copying of images between machines). Resources are managed and allocated on a per host basis and not dynamically allocated across the infrastructure. To make Linode become closer to a cloud operation would require something like the disk storage being SAN or NAS based and for the instance to be brought up on any host in the datacenter (probably at boot time) - hence the centralised storage requirement. This "instanced tied to dedicated hardware" is, in my mine, what makes Linode a more traditional server farm based outfit rather than a cloud based outfit.
But this is just one man's opinion
And it would suck if you did that
VPS's do not necessarily make up a Cloud; they can be arranged to form a traditional, non-Cloud infrastructure. The V in VPS stands for virtualization. If the OS is not running directly on the physical machine, then it's a VPS. It doesn't matter what you do with the virtualized instance, it's still a VPS.
Likewise, Clouds do not necessary consist of VPS's. One could imagine Clouds made up of non-virtualized physical machines. That might reduce flexibility, but it's still a Cloud in the sense that individual machines don't really matter much. Google uses millions of machines, not all of which may be virtualized. EC2 is obviously made up of highly flexible VPS's, but something like S3 could be running on non-virtualized machines for all I know. Nonetheless, both are Cloud services.
I've never used a cloud based service as a developer or owner of a business who needs or thinks they need it, just as an end user of some services like most of us. Here's my take.
Could based services, while they have the ability (on paper) to scale big and well, there are bits and pieces of every service that reside on specific servers. When (not if) those servers go down that part of the service fails. I've seen this on Facebook, gmail, you name it.
Facebook for example, where I could view comments on one friend's post, but on another friend's post I got a "database error" message. So these are obviously split up among different servers and certain people or parts of their data sit on certain physical servers.
To me on paper, the idea of cloud is great. But in reality, user accounts, settings, programs, your data (some or all of it) still resides on a single physical server. When that server, network link, cluster, etc goes down and if it's fail-over doesn't work, there goes those user accounts until the physical problem is fixed.
I know someone who works for MS's "cloud" service and this has happened. I can even give him email addresses and he can look up to see what server (not "cloud" or even cluster of servers, but a single server) their accounts sit on.
There is a lot of data that isn't "floating" in the "cloud" if some unseen piece of the cloud fails that data becomes unaccessible, instead of just "floating" to another accessible and functioning piece of the cloud. Yeah, I understand a lot of that has to do with how the application or service is developed, but it still seems like there is a long way to go with "cloud"
Personally, I'm not convinced "cloud" is the way to go and really only fits into a very small fraction of business models and companies;
Yahoo
Microsoft
MySpace
Amazon
Ebay
For most, "cloud" computing seems to be a hugely stupid marketing term. My opinion.
So yeah, I agree with devjonfos, "clouds are pretty"
1) For specific purposes where you do not care about locations, hardware, operating system, etc.:
Amazon S3 - simple for data backups from anywhere to anywhere
Google AppEngine - e.g. for CRM with logins via Google accounts
2) When you want to outsource hardware issues, but want/need to control OS and specific software:
Linode - very good VPS with continuously adding cloudy features; may be that some network storage would enhance it.
RackSpaceCloud - can have 0 to N instances and change it dynamically, can have several disk snapshots, and e.g. just store them (without actual usage) at small fees; but seems to be less powerful than Linodes.
3) Developers oriented services: SourceForge, Launchpad, …
@kvutza:
3) Developers oriented services: SourceForge, Launchpad, …
Now that's interesting. Your definition of cloud includes SourceForge?
3. Granularity of computing resource (cpu, disk, network, etc…)
- Transparency of resource assignment (knowing where the resource is) Both of these are a spectrum. Resources can be allocated anywhere from tiny fractions that have no direct correspondence to physical devices up through aggregation of multiple physical devices. And those resources can either clearly be associated with physical devices or any mapping to such physical devices can be completely obscured.
Now there are other features often touted in the "cloud", like self-healing or redundancy or transparent migration or whatever, but in general I find that the availability and impact of such features have a pretty good correlation to where on the spectrum of resource allocation the provider falls. If I'm using a service whose resource assignment is completely opaque, they're much more likely to be able to offer me a transparent migration/healing service since they can just move that assignment at any time without me noticing. Likewise with reallocating to a new level of resource.
If plotted in 2D, a physical PC I have on my desk might be considered to be at the low end of each metric (say the origin of the graph). That's also where a dedicated co-lo provider PC would be. It has absolute transparency of resource assignment - I can touch the hardware (or have the co-lo provider do so with their pair of hands). It has very low grained resolution of resources - exactly matching hardware. Changing either requires an intensive effort on my part and moving around real world devices.
I think the "cloud" (at least the ideal of its proponents) lies towards the other end of the spectrum - say way out there in quadrant 1 on the graph. That would be a provider who lets me allocate any resources (independently) at a very fine granularity, but who tells me nothing about where those resources are coming from or how they map to physical hardware. In that case making changes should be extremely low overhead, can take effect instantly, and I won't even have to know if my resources get moved around. I don't think this provider exists yet nor even can without real R&D and technology improvements (nor do I always think this is the best model, given real world constraints), but it's probably the ideal of the "cloud". Of course, very little of what is sold as the "cloud" actually comes anywhere near close to that ideal, though pure storage providers are probably closer than compute-server providers. But its a cool place to be heading.
To the original question of comparing a VPS and "cloud server", I think you have to identify how far apart the two choices are on my hypothetical graph. I think some current "cloud" offers barely differ from other current "VPS" offers, while other comparisons vary more significantly in one or both of the metrics. I don't think one answer fits all.
Specifically for Linode, I'd consider it close to the origin of my graph, so to me it's not really "cloud"-like. The same would hold true for most VPS systems (less so for those using a SAN structure). But I still currently prefer Linode's model for most uses. While there's only a few specific resource levels (and different resource types are coupled together), there's a lot of transparency as to how that resource maps to real world hardware.
The problem for me is that the more cloud-like you get in today's world, the more moving parts and things that can go wrong with less transparency. When it works it can be great and have very interesting features, but when it breaks down, it's tricky. As an administrator, simplicity does have it's advantages too. Not to mention that right at the moment, true cloud-like behavior (by my two metrics) costs more to deliver, and thus costs more to purchase. So economics needs to be weighed in for real life choices.
For example, SAN usage becomes important to help separate storage and cpu resources for finger grained allocation, but that leads to new failure modes, coupled with less transparency as to what's going on, which makes it harder for me as a user to deal with outages. Technology also isn't that good yet at melding multiple discrete hardware (say different PCs) together in a distributed fashion, so you'll still hit boundaries of CPU resource when you hit physical hardware "chunks".
Live migration is another thing that could be a killer feature (ask for more CPU than the current physical host has, just migrate to a bigger host without any downtime), but I don't think is mainstream yet. So while it interrupts more, I find myself more confident knowing with Linode just where I am migrating from and to, and the steps the process takes.
The "far upper right" cloud part of my graph will obviously continue to improve, but whether or not it meets all the goals of cloud-proponents is unclear quite yet. I think longer term we may need to change how hardware works. For example, some providers let you allocate things like cpu in small chunks, but what if the underlying hardware used to run the system itself was simple a humongous cpu farm (lots of little cpu modules in a big box) so you weren't stuck with an n-core box as a step function. If a "cloud pc" was really itself a combination of very granular cpu, memory and disk subsystems, we might get better failure modes while still having a highly granular service definition. You might say we can do that today by just using individual PCs as the subsystem, but then we need much better algorithms and techniques to tie those PCs together as a single compute fabric.
– David
@jed:
@kvutza:3) Developers oriented services: SourceForge, Launchpad, …
Now that's interesting. Your definition of cloud includes SourceForge?
Well, they are at least a "potential-cloud". I do not care what are the shell servers and if they vary, similarly with svn, download, etc. servers.
shows a balance of 133 USD for a 9 day usage and 160GB traffic.
I believe I could handle 5 times the same load at half price with a Linode 2048.
So why I did not host this event on a Linode VPS?
May be it is not technically correct but I felt my VPS would affect
all the customers on the same host negatively during peek times so I decided to host on cloud.
But with cloud server I don't have this feeling, I will rent the share for a few days
and use it to its maximum power and terminate it.
So in my opinion there is no technical differences of a Linode VPS and Cloud type server.
But there is a psychological difference in the eyes of customers.
Linode does a pretty good job of managing resource contention behind the scenes. As long as there isn't wanton disregard for the system as a whole (e.g. swap-thrashing, Spaceheating@Home), my rule of thumb is that any productive use of available resources is fair game. Even if it's just for a few days.
Perhaps it's the community aspect. You see other Linode customers as humans, but not so much the other cloud provider customers. But the psychology of business decisions is neither here nor there.
1) A possibility to load homegrown images (via Eucalyptus), to snapshot current system, and to have zero to N currently running instances off that snapshot.
2) Provide instance types for:
a) not to use too much of CPU and HDD (the current state)
b) any amount of CPU being able to use, just not thrashing the HDD
c) taking a private cloud with any CPU usage and HDD thrashing
3) Join cloud alliances, advertise your shiny LinodeCloud, make profit.
A bit off-topic:
Personally, I would like to have some solid anti-hdd-thrashing monitoring. Sometimes, I feel like somebody use twice more RAM (for a default LAMP) or something like that.
And a local anti-virus/anti-spam service would be great too. Mail checking does an amount of HDD loading too, thus leaning into HDD thrashing.
@bor:
When can we apply for a cloud hosting account at linodecloud.com?
Where they will charge twice as much for the same service?
@Stever:
@bor:When can we apply for a cloud hosting account at linodecloud.com?
Where they will charge twice as much for the same service?
Sign me up!
I think the real difference between VPS and cloud is that VPS is a more specific term than cloud.
Just like 'chisel' is a more specific term than 'pointy thing'.
…
To add more to the discussion:
VPS does things that high-availability/clustered shared hosting aka "cloud sites" cannot do, in that it provides a fully virtualised server. You cannot clustering a virtualised machine over multiple physical machines, you can only cluster a higher-level environment, where you have less control over the hardware, installation of software, choice of operating system, etc and what you have is essentially glorified shared hosting. I don't need or want Linode to move in that direction.
As for whether Linode could get away with calling its existing Xen VPS service a 'Cloud' service, that's fine with me. I don't care what it's called as long as it's a virtual server, and it seems other people are using the term 'cloud' with similar services.
To regular consumers, the cloud is the thing that sits out there and does stuff for them over the network and is always on. When I have a thin client app that stores part of its data in my server(s), so that my users can log in to other devices with this thin client and access their stuff, they describe this situation as their data living in the cloud, and they describe my app as being cloud-based.
They don't care if the cloud-enabled app is storing it is a VPS, a dedicated server, or trained hamsters with abacuses. They don't know what scalability is, but they know their friends can sign up too and also have their stuff be in the cloud. They know it sits out there somewhere, somewhere above and nebulous, and it's there when they need it from multiple devices/clients.
This term was used before for telco stuff. When you make a phone call, it goes through the cloud, they say, but only industry people would call have it that decades ago.
With telephony, there is an elaborate international switching system with a complex mix of hardware, facilities, companies, contracts, etc., that enable people to make phone calls from any device to any other device nearly instantly, through that cloud. I don't care what's in the cloud, I just care that I can almost always get to it instantly from a very diverse set of locations/devices.
Applying this concept to the internet is very natural. In diagrams the internet itself is often depicted as a cloud. Instead of the old telco cloud that just supports phone calls through the cloud, we have specialized services in the cloud that compute and store and possibly do other things.
So in my mind this isn't a technology stack question. The only time I see this term applied to technology stacks is when hosting companies want to leverage the cloud hype to sell something, and that's why nobody can agree on the meaning there. Pretty much anything could enable a cloud-based service, it's just that some technology works better than others to enable a particular use.
But from a user perspective, the concept of a cloud is actually very consistent, in my mind.
In the utility computing case, the cloud-based service is one that supplies on-demand computing resources, and the users are developers. This doesn't mean the developers need to themselves offer cloud-based services. They might or they might not. It just means that the users, who are developers in this case, can dial up the service, get computing resources, use them, and turn them off, like making a phone call.
A VPS could lend itself to this use because it's quick and cheap to provision a new VPS. But allowing average setup/teardown times to be low will always require some stock of unused VPS nodes. Regular servers could work just as well, with some sort of fast custom setup/teardown process, just that using them might result in higher costs that might not be justified.
But again the hardware stack shouldn't matter.
There are several services that have mobile phones wired up in racks so they can be interacted with remotely. You pay by the minute to use them to test your mobile app. I would call this a cloud based service. Whenever I want to test a mobile app, I dial it up and tell it which type of phone I want and run my app on it, and when I'm done I disconnect and am no longer billed. Of course they have to stock a lot of phones, track which types are in high demand, etc.. But in general, this is in my mind phone-testing in the cloud.
A VPS is totally analogous to a mobile phone in the above test rack. The VPS itself has nothing to do with being a cloud, it is just a resource/service that some people can choose to provision for and offer using cloud-based practices.
In my mind anyway..