You’re a startup. You’ve got a great idea for an app. You’ve got some friends interested in helping out and you think you can make this work.
So how do you figure out where you’ll host it? How do you decide between a raw infrastructure provider and platform service? How much work do you do yourself and how much should you rely on service providers?
When building a new application, the fundamental rule is that you should choose any services that allow you the greatest combination of flexibility and resources to meet your application’s needs.
I’m largely talking about whether to use Infrastructure-as-a-Service (IaaS) or a Platform-as-a-Service (PaaS), and to some extent, how much to rely on Software-as-a-Service (SaaS) providers or write your own application components.
I think of IaaS, PaaS and SaaS as “stacks” that either reduce the level of effort required to build your application at the expense of flexibility and control, or provide more flexibility and control but with more effort.
For example, IaaS providers will give you raw infrastructure like compute and storage resources. This provides the most flexibility but requires the most hands-on management. Developers interact with the operating systems directly, build/use their own frameworks (e.g., Django, Rails, etc.), and consume server resources directly. If you prefer Nginx over Apache, FastCGI over WSGI (yeah, there’s still some weirdos out there), have a favorite location for your configuration files (/usr/local FTW!), or simply want to control your software upgrade path, then IaaS is probably what you want.
The image below shows the relationship of your application to the services provided by the IaaS provider. Your code sits directly on “top” of the infrastructure resources.
PaaS, on the other hand, will provide a development platform (as a service) to create new applications. You can think of it as cloud-based middleware: it provides services beyond the raw operating system and abstracts the underlying resources from you. The developer doesn’t have to manage compute resources directly. Instead she gets to build on frameworks specifically provided for her application. For small dev teams without infrastructure management capabilities (read: a SysAdmin who *likes* patching servers at 3 a.m.), this is a great way to reduce the “time-to-usefulness” of their project, that is, how quickly the application is built and being used. However, this restricts the flexibility since they must work within the frameworks provided.
PaaS services typically use an underlying IaaS service, since the raw infrastructure is abstracted from the developer. This gives the PaaS provider the ability to change the underlying infrastructure services as needed, or even use multiple providers. The following example illustrates what a PaaS provider might offer to your application: managed development languages and frameworks to access the resources you would otherwise have to manage directly. If you don’t like the idea of updating PHP or Ruby on Rails on a regular basis, this is where you probably want to be.
Most SaaS providers deliver end-user applications on-demand, as a service. Salesforce.com and Google Apps are two common examples. 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.
A SaaS provider may use a PaaS provider or an IaaS provider, depending on the level of development and operational efforts they want to balance out.
Here’s an illustration of how an application may interact with various SaaS providers (though it cleverly avoids indicating what underlying services are powering the application code itself):
Each layer consumes a service from the layer directly underneath it while at the same time, providing the denoted services to the layer directly above it.
Ultimately, the more you move your application “up the stack,” the fewer resources you are required to manage. So 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 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 one moves down the stack, the more the application or Dev/Ops engineer has to interact with and manage.
Of course, no one service is correct for all use cases. Many distributed applications consume one or more portions of the stack on multiple cloud service providers.
The decision to go with one or another ultimately comes down to the resources your team wants to manage, the capabilities of your people building and supporting the application, and how quickly you need to deploy production software with the resources available to them. Pick one that makes the most sense today, and don’t be afraid to change as your needs change over time.