There are three kinds of services that are commonly associated with the cloud: Software as a Service (SaaS), Platform as a Service (PaaS) and Infrastructure as a Service (IaaS). Software as a Service has gotten a lot of good press in the past few years, as Salesforce and the like have seen adoption from the smallest shops to the largest corporations. Beyond a few web service API’s, however, SaaS doesn’t offer much for application developers. Platform as a Service, on the other hand, provides full-service hosting environments that can automatically allocate resources as your applications need them. Google App Engine, for example, supports sandboxed Python and Java environments (PHP is the most requested feature, and hasn’t been ruled out by the GAE team). PaaS environments often extend a SaaS offering, as is the case with SugarCRM’s certified modules. But PaaS has some big shortcomings: your applications are far from portable and are limited to what the vendors specifically permit them to do. Infrastructure as a Service is less confining. Your applications can use these services to scale with the same hardware that backs the largest sites on the web. You can usually install the OS of your choice and run your applications in environments tailored to their needs. The tradeoff is that you have to provision additional resources manually to handle spikes in load, and you must design your applications differently if you’d like to use the services that improve the scalability of your app. As we’ll see later, changing your mindset to take advantage of these services isn’t necessarily a bad thing.

The pricing structure for these services follows the ‘utility computing’ model. That’s a fancy way to say you pay for what you use. What you use is usually measured in terms of hours, bandwidth, and sometimes support. A lot of PHP applications will probably end up on the cloud for this reason alone. With cloud computing, you can shift your capital expenses to operational expenses. That means you don’t need a wad of cash up front to pay for a data center in hopes that your application will eventually return on that large investment. It goes without saying that you should check the pricing model of any cloud vendor you plan to deploy an application on.

Here are a few SaaS, Paas and IaaS cloud vendors you might run into:

Let’s take a closer look at some of these IaaS services. Elastic cloud computing(ECC) is usually the first thing that comes to mind when ‘the cloud’ is mentioned. ECC is simply a pool of virtual servers that you can provision to serve your apps. What makes these services ‘elastic’ is the ability to grow and shrink resources as your applications need them. For example, you can provision 100 additional servers to handle a severe slashdotting. When you’re done handling that big spike in traffic, you can terminate those instances and stop paying for them. With storage services like Nirvanix and S3, your applications can access redundant data stores that have practically limitless capacity. The files are often cached close to your users in a content distribution network (CDN) that either comes with the basic offering or is available as an additional service. Table services like SimpleDB or Quickbase offer a more structured data store, although not as structured as relational databases. While table services lack many query features that RDBMs offer- notably joins- they are more flexible and can scale much more gracefully. Queue services will likely affect your application architecture most dramatically. Using a simple queue model, your applications can pass off big jobs to backend servers and carry on with its prime directive: returning a page to the user as quickly as possible. Logic is now divided between two kinds of application servers: a front-end web server and a back-end job server. When adopted in part or all together, these services will help your applications scale with ease and stay up when things start going pear-shaped.

To illustrate a cloud-enabled application in action, I drew a little picture:

Feel free to click on the image to see the full size version.

As you can see, I’m sitting on the outside browsing in. I’ll send a request to your application running on web servers in the EEC. They will then perform the task at hand, put the response together and point my browser to any images, videos, or other large media that my app needs using public URLs that the unstructured storage service exposes. If your application needs to read or write files on the unstructured storage during my request, it does so through a web service. If your app needs to access application data like users and records, it calls the structured data service through another web service. When your application receives a request that will take some time to process, it puts a message together with all the required data and adds it to a job queue using the queue service. It then serves the page without waiting for the job to finish, impressing me with the ‘snappiness’ of your application. Meanwhile, another part of your application that is also running on the EEC picks up the message and performs the task, possible sending a message back to the web servers letting them know the job is complete. Everyone’s happy. Now multiply this by one million. Everyone’s still happy. That’s what the cloud is all about.

‘The cloud’ isn’t a new idea. Utility computing has been around since the dawn of the mainframe. Grid computing was all the rage until it was overcast by the cloud. Virtualization has been slowly making its way in to the enterprise box by box. But cloud computing rolls up all of these great ideas and throws in a few highly scalable services to make an offer PHP developers will have a hard time refusing.

If you’d like to try Amazon’s EC2 service , Wil and Nick Maiorsky have created an Amazon Machine Image (AMI) with Zend Server. Just select the AMI in your EC2 console and hit the launch button.