Looking through cloud literature, it seems we've run out of three letter acronyms (TLA), so we're now using four letter acronyms (FLA?). Chief among these are the "as a service" acronyms which describe what level of stuff is handled by the provider. Wikipidia has some sort of explanation buried in the cloud computing page, but I thought I'd give the abridged version.
At the lowest level is "Infrastructure as a Service" (IaaS): You get a virtual server with connectivity to the internet. Examples are Amazon ECS and Rackspace Cloud. In these offerings, you can install almost anything you want (you typically get root access in some manner) and can even install the operating system of your choice. This is a good choice if you're a sysadmin who just doesn't want to muck around with physical hardware.
The next level up is "Platform as a Service" (PaaS): You get some sort of development platform hosted remotely and you have a mechanism to write and deploy applications that run on that remote platform. Often you cannot log onto the server directly and you are sandboxed into a virtual environment with pretty stringent restrictions about what you can do within it. Examples of this are Heroku for ruby and cloud bees run@cloud for java. This type of stack is good for a developer who needs to deploy an application, but doesn't know anything about the underlying technology.
At the highest level is "Software as a Service (SaaS): This is a hosted application that you simply use. Examples would be things like Lucid Chart or Gliffy. You just use this stuff and don't have any software installation or maintenance tasks.
A few providers blur the lines between IaaS and PaaS by offering hybrid solutions. An example of this is Engine Yard who provides what really is IaaS, but is largely centered around the ruby/rails platform. Amazon Elastic Beanstalk is an EC2 based java PaaS that also has more flexibily that something like run@cloud. I would say these last two are probably the most flexible PaaS solutions, but come with a bit more added complexity. They're probably the best for production deployments, but might be overkill for small applications with a limited user base.