Seemingly every computing service is available in a ‘Cloud’ form now: raw compute and data storage, hosting of custom applications, and ‘standard’ collaboration applications like word processors or email.
There are three primary models used by providers to deliver Cloud services to users:
- Infrastructure as a Service (IaaS) – the consumer architects, deploys, and manages application infrastructure using the provider’s services as building blocks
- Platform as a Service (PaaS) – the consumer deploys their applications to the provider’s infrastructure using one of the provider’s supported architectures
- Software as a Service (SaaS) – the consumer uses or composes the provider’s application running on the provider’s infrastructure
Delivery models for ‘as a service’
Let’s break each of these ‘as a service’ delivery models down a bit. Managed computing services are a way to delegate a portion of responsibility for running an application to someone else. In order to delegate responsibility for supplying and managing those application components, you’ll trade a few things, primarily money and flexibility. You will also take on some risk associated with the new dependency, though that risk might be lower than owning it yourself.
Consider the deployment of ‘simple’ web api that might be used by a mobile or single page web application:
The (most-)visible parts of the application are:
- a load balancer that handles connections from clients
- multiple instances of the stateless api server that processes incoming requests using data from the database
- a database that stores and safeguards the application data
On-prem
Some people’s application deployment model is to build, deploy, and operate all components of an application themselves. You have both responsibility and control over almost everything.
One way to think of this is that you select and purchase, and assemble all of the raw ingredients for a meal from the produce, bakery, and deli counter at the grocery store.
Of course, the line starts to get fuzzy when ‘on-premises’ really means the organization rents space in a commercial datacenter and co-locates their applications alongside cages of that datacenter’s other customers. You’ll certainly be getting power, regional network connectivity, and other infrastructure provided from the datacenter. You may also be required to use load balancers and firewalls provided by the datacenter.
I don’t know if bread from a bakery qualifies as a raw ingredient, but maybe networking is the on-prem equivalent. They both come in many shapes and flavors.
Infrastructure as a Service
When using infrastructure as a service, you trade responsibility and control for some of your application’s dependencies to the infrastructure provider.
IaaS providers offer services that are the building blocks for application architects. This is kind of like building a meal with a grocery store’s fresh prepared offerings in the buffet salad bar. You have a ton of flexibility to mix and match from the store’s selection, it’s quick, and it costs a bit more than doing the prep yourself.
I work with a lot of teams and ‘infrastructure’ means a lot of different things depending on who and when you’re talking. Sometimes it seems like the colloquial definition for infrastructure is “the dependencies that I don’t want to concern myself with (right now).”
As a result, IaaS providers offer building blocks up and down the application delivery stack that can be composed into applications:
‘Low-level’ services that provide compute resources for an application to execute in the form of virtual machine, container, or function execution. Examples:
- AWS: EC2, Fargate, and Lambda
- OpenStack: Nova Compute
‘Mid-level’ services that the application is tightly integrated with and uses to perform internal application operations. The service may provide a relational or document store to the consumer’s application’s via a network endpoint. Examples:
- AWS: Relational Database Service and Aurora, Simple Queue Service, DocumentDB, DynamoDB
- Google Cloud Platform: Cloud SQL, PubSub
- Mongo Atlas, RedisLabs Cloud, Confluent Cloud (Kafka)
Even ‘high-level’ service that implement a portion of the application:
- Machine Learning
- Identity Provider
While IaaS is very flexible and the ‘hyperscale’ Cloud providers like AWS, Azure, and GCP can support a huge number of workloads, the choice and responsibility of managing all these components is not for everyone. The platform as a service model simplifies some of this.
Platform as a Service
A platform as a service offers a prescriptive way to deploy applications that conform to popular architectures. Architectural flexibility and cost are traded for speed of deployment and simplicity of management.
This is kind of like ordering lunch from a “fast, casual” restaurant like Chipotle. First you choose the architecture and packaging of your meal: between burrito, salad, or bowl. Then you specify particular ingredients: the filling, toppings, and sides.
With a PaaS and its included service add-ons you should be able to say, “I’ll have a golang web api, backed by Postgres, with a Redis cache.” The load balancer and DNS records were implied by ‘web api’ and will be provided by the platform with minimal configuration, at most.
Our example api service is common enough that it could probably be deployed to many PaaS platforms easily:
- Heroku
- CloudFoundry
However, if we were migrating our example api from an existing deployment to a PaaS we might run into trouble if a dependency wasn’t supported. For example, suppose the current api implementation depends on Oracle and the PaaS only supports Postgres and MySQL. Engineers must also develop and implement a data migration strategy to the target database offering.
The process for deploying applications to PaaS platforms will be well-prescribed by the platform and its tooling.
The architecture and deployment constraints enable the PaaS to provide a lot of support to applications in the form of scalability, fault tolerance, and security.
Software as a Service
Software as a Service (SaaS) is the final major Cloud service delivery model. With Software as a Service, the provider develops, operates, and delivers software to customers over the Internet. The customer has the ability to configure certain aspects of the software, and a customer’s deployment may run on dedicated infrastructure resources. However, the SaaS provider controls all of that.
SaaS provides a prepared and packaged set of functionality to many different customers. This is similar to how you might pick up pastry from the grocery store’s bakery or sub sandwiches from the deli.
The amount of software delivered as a service is vast, but here are few examples:
Examples:
- Identity Provider: Auth0, Okta, Cognito (yes, a repeat from ‘high-level’ IaaS services)
- Payment Processing: Stripe, Paypal, Square
- Commenting: Disqus, Postmatic
- Directory Services: Office365 AD
- Communications: GSuite, Office365
Many of these services are meant to be composed into larger applications. Identity Providers are a good example.
Suppose our example api was a custom identity provider. Perhaps you should adopt a SaaS application identity provider service like Auth0 instead of building, deploying, and operating this common service yourself.
SaaS can be a great way to shift responsibility for feature sets with high complexity and low product differentiation, as long as you are comfortable with managing the risk associated with that dependency.
Wrapping up
Some companies deliver services in via multiple models. Once an Infrastructure as a Service provider has good ‘low’ and ‘mid’ level services, they can package those up into a platform as a service. Conversely, a platform as a service might offer advanced features that provide customers some of the control they would have with an IaaS.
Some Cloud companies have offerings in each of the infrastructure, platform, and software delivery models.
Hopefully, this has distinguished different Cloud delivery models for you and clarified how you might make tradeoffs.
Questions or comments? Shoot me an email!
Stephen
#NoDrama
