I'll do the easy one first. Users of any internet service may know about servers, routers, load balancers, multi-tiered distributed architectures, et cetera, but they don't care. They care about where the service is and what it does. For example Google email is a well-known internet service. You can find it at the URLcalled www.gmail.com. You know that you can go to that service and use web mail. Whether Google has implemented the server on one server, many servers, on-demand servers or whatever, the user has no idea. He only knows that http://www.gmail.com is the URL that gives him gmail service. i.e. For users, cloud computing is just the computing services they get from the internet.
The next one is harder. What about producers of cloud computing services? Historically, a producer had to develop his application and then deploy it to on a server to be visible on the internet via URLs. The producer acquired an IP address for the server, and then mapped his domain name to that IP address via his domain host. For example a friend of mine runs a site at http://www.marmah.com. The domain (marmah.com) is registered at a domain name service, and it points to an IP address at his hosting provider.
However, when sites got more traffic, it was hard to serve the same domain name with just one server. That is when loadbalancers were brought in. A loadbalancer is just a device that appears like a server, but it takes requests to the server and dispatches them to one of many actual servers which then fulfil the request. Adding servers allowed web sites to do more and more work while acting as one URL. However, the producer of the web site had to set up load balancers, servers, and networking between them to make sure that they got the job done.
Setting up a little network of loadbalancers and servers was hard, and took time. If traffic went up it took a long time to acquire, provision, and deploy more servers. And the producer had to pay for that infrastructure even if traffic went down.
Eventually large companies such as Amazon and Google had to deploy large numbers of servers, but that meant that they had to detect, find, and fix/replace failed servers more often. (This is expensive to do manually). Eventually they figured out how to install enough banks of idling extra servers to be able to take over from failed servers automatically and almost immediately. Eventually, they made it so that provisioning servers from the inventory of installed but idling servers could happen by a configuration action and even an automatic action. These last two developments were crucial to the development of cloud computing because it meant that application producer from Amazon or Google did not have to worry about the servers, load-balancing, fault-tolerance, recovery, because it was handled consistently and automatically. With the worry of provisioning the servers and network infrastructure taken away, cloud computing was born within Amazon and Google. Eventually somebody realized that they could provision a few more banks of servers, put a billing engine on the servers, and rent the servers out on demand as components of various Amazon Web Services, GMail, and Google Apps. i.e. For application producers, cloud computing is the ability to deploy applications without having to worry about physically provisioning servers, networking, storage, and the cumbersome details of application deployment.
There are a few different flavours of cloud computing.
- Infrastructure-as-a-Service (IaaS) - This is where servers, storage, networking can be provisioned by the cloud application producer using provisioning interfaces (e.g. Web, command line, API), but the cloud producer must configure these devices and their software stacks, and then deploy his application, and implement monitoring, automatic scaling, et cetera. Examples include Amazon EC2, Zerigo,
- Platform-as-a-Service (PaaS) - This where servers, storage, networking, and some programming stacks, and automatic application deployment tools come bundled as provisionable entities. The cloud application producer must use the automatic deployment tasks to deploy their applications, but everything else is handled by the PaaS provider. Examples include Heroku.com, Cloudcontrol.com, Google App Engine. PaaS platforms often come with severely limited choice in the programming stack, but that is the price that cloud application producers pay for not having to worry about configuring the infrastructure.
- Web Services - This where a distinct service has been made available on the web for others to consume via web service APIs where each API is accessible at a set of URLs. Examples include Google search, Google Maps, PayPal, JanRain Engage authentication, Facebook Login, Twilio, Zerigo DNS, etc. Users may or may not also see these services as distinct applications (SaaS), but cloud application producers may use these APIs to build their cloud applications. Web services are monitored and measured, and often billed as well.
- Software-as-a-Service (SaaS) - This is where a cloud application producer has deployed the application to a cloud computing platform/infrastructure, and only makes the service available via a URL. SaaS is usually not relevant to cloud application producers unless the SaaS also has a web services API which allow the web service to be consumed by another cloud computing application.