In our previous post, we described IaaS (Infrastructure as a Service) and PaaS (Platform as a Service). Today we’ll discuss how Software as a Service (SaaS) fits into the stack and explore which type of infrastructure makes sense in different scenarios. Various combinations of these services can help meet your needs for flexibility and resource control so you can manage and create applications as desired.

SaaS
Most SaaS providers deliver end-user applications on-demand, as a service, over the Internet. Salesforce.com and Google Apps are two common examples of this. However, many SaaS applications can provide services to other applications, usually via a SOAP or RESTful API over the Internet. A good example of this is how Yelp integrates Google Maps into its mobile application – Google is the SaaS provider, and the Yelp application becomes the consumer of the software service.

A SaaS provider may use a PaaS provider or an IaaS provider, depending on the level of development and operational efforts they need to balance out.

Here’s an illustration of how an application may interact with another SaaS provider:

As you can see, the application now interacts with other applications for complete functionality. Just as a developer can increase speed-to-launch by using a PaaS provider (at the expense of flexibility and customization), this developer can use existing third-party SaaS applications without having to recreate each piece of functionality desired.

Ultimately, the more you move your application “up the stack”, the fewer resources you are required to manage. Integrating an application with SaaS providers allows a developer to consume SaaS services as components and building blocks without having to reinvent the wheel (e.g., using Google Maps for location services, using RSS aggregators for content/news services, etc.).

Using a PaaS provider will provide a framework for you to develop your own application without having to manage an infrastructure. And if the PaaS is too limiting – say, you want to use certain web server features not provided by the platform, or you want to use a preferred development framework – then IaaS may make more sense.

As indicated in the final illustration below, the further down the stack, the more lower-level components a developer will need to recreate and maintain.

There is plenty of opportunity for “mix and match”. No one service is correct for all use cases, and I can certainly see distributed applications consuming one or more portions of the stack on multiple cloud service providers.

The decision to go with one or another ultimately comes down to a few considerations:

  • The resources the team wants to manage.
  • The capabilities of the development (and operations) teams building and supporting the application.
  • How quickly the team needs to deploy production software with the resources available.