Skip to content Skip to site navigation

Platform-as-a-Service (PaaS) Considerations

What is Platform-as-a-Service (PaaS)?

Platform-as-a-Service (PaaS) is a robust vendor-supported, bounded, and preexisting computing environment on which consumer code (customer developed or acquired software) can be executed. PaaS usually offers proprietary supplemental services. With Infrastructure-as-a-Service (IaaS), by contrast, you usually need to assemble system parts (such as server, storage, and networking layer services) from an IaaS vendor catalog to construct a computing environment (or platform).

PaaS is a good cloud hosting option for general application execution and can greatly reduce initial setup time and the amount of in-house expertise required by a consumer. PaaS services can cost more than similar IaaS deployments, though, and Paas has more limited technical variations of system design.

Most PaaS providers have the following features and benefits:

  • Allow the use of programming languages that software developers recognize.
  • Offer tools to support software development.
  • Stock prebuilt modular enhancements (such as libraries) to simplify integrations, to extend functionality, and to provide layered security.
  • Provide application programming interfaces (APIs) for most developer actions, so that changes can be automated.
  • Have no servers to monitor or patch, and are not OS-centric.
  • Have little to no transparency into infrastructure under the code, which reduces the support burden.

These are examples of PaaS providers and their corresponding software product category:

  • Force.com by Salesforce:  Proprietary language (similar to Java) with strong links to Customer Relationship Management (i.e., Salesforce CRM)
  • Acquia:  Drupal web content management service with web server and support for web application execution (such as PHP)
  • Heroku:  Rich general application execution framework for several popular languages: Node, Ruby, Python, Java, PHP, and Go
  • AWS Elastic Beanstalk:  Rich general application execution framework with simplified linkages to a broad array of AWS products

PaaS Checklist

When looking to acquire a PaaS product for the Stanford community, follow this checklist of required attributes. More detail can be found in the sections below.

Required attributes — a PaaS candidate solution must address these three sets of considerations:

Business considerations:

Functional support for Stanford's business
Vendor support and viability
Cost
Lifecycle and exit strategy

Technical/integration considerations:

Scalability and availability
Capability for service health monitoring
Ability to integrate with and operate with Stanford services and products
Ability to integrate with Stanford IAM (Identity and Access Management) infrastructure

Risk management considerations:

Ability to support Stanford's data security requirements
Support for business continuity and disaster recovery
Ability to notify Stanford about breaches or outages
Compliance with University policy and legal requirements

See the content below for details about the items in this checklist. If the product meets these criteria, see Choosing and Purchasing a Cloud Solution, Step 3 for next steps in acquiring and managing the product.

Functional support for Stanford's business.

  • Many PaaS vendors have strong associations with a category of software. For example, if you want to build a custom application that augments CRM activities, and if Salesforce is a good CRM fit, then Force.com or Heroku (which are both owned by Salesforce) are good options.
  • The product fits well with other products in your unit’s portfolio. Can you leverage the combined power of as many of your products and the broader university’s portfolio products as possible? Minimize the number of PaaS providers used as much as practical; maintaining adequate expertise across multiple provider platforms is costly and complex.

Vendor support and viability

  • The service provider must be a stable entity running on a sustainable business model and not likely to disappear. They should be a leader or a relevant player in their segment of the market, with an extensive existing client base. They should interact with other services or tools supporting activities in their segment of the market.
  • The service provider must lead in their segment of the market, matching and exceeding user expectations. Strength in this area ensures that the product continues to be viable as competitors emerge.
  • The service provider offers multiple levels of support and defines them clearly in their terms. The roles and contacts are known, and known to be responsive.

Cost

  • A big advantage of using PaaS is the speed of initial setup. However, there are often many steep cost increases if an application resource consumption increases significantly (i.e., at a higher rate than many consumers realize since light duty use is often very cheap by contrast). Many PaaS providers offer supplemental functions that accelerate application enhancements, but these are usually proprietary and lead to a more expensive and complicated exit strategy.

Lifecycle and exit strategy

  • There must be a clear understanding of the workflow, business data exit strategy, and contractual obligations. Stanford must clearly understand the service provider's responsibilities for supporting exit strategy for Stanford.

Scalability and availability

  • Most serious PaaS vendors offer scalability of some type native to their execution environments. Ideally, this scaling is elastic and increases and reduces compute, storage, or network capacity automatically, as resource monitoring indicates. PaaS resource scaling is often customer configurable, with defined price ranges corresponding to bounded capacities within which a running application can grow. Although such tiers of automated scaling are typical from PaaS providers, the providers do not universally offer high availability and geo-diversity. This differentiation may be important to a given use case depending upon requirements.

Capability for service health monitoring

  • PaaS providers should include a companion status and health check monitoring service so that Stanford can know the current health of the service. Also, for any service outage or security incident, the PaaS provider should have incident notification mechanisms in place, such as email, SMS, etc.

Ability to integrate with and operate with Stanford services and products

  • PaaS providers universally provide some API for configuration and build management. APIs are also the principal method of bulk data loading and extraction, which facilitate onboarding and exit from the PaaS provider. To the degree possible, integrate with Stanford code revision systems, identity and access management (IAM) infrastructure, and central logging service.

Ability to integrate with Stanford IAM (Identity and Access Management) infrastructure

  • Account provisioning and authentication are vital enabling integrations that should be well supported by any PaaS provider. Specifically, SAML2 is a mainstream standard that exists in order to redirect a user authentication from the service provider back to Stanford's IAM infrastructure. Similarly, the group memberships should be controlled programmatically (by some integration). The goal is to enable Stanford users to use their central single sign on credentials, and for Stanford to centrally control the authentication process and group membership/access control.

Ability to support Stanford's data security requirements

  • All reputable PaaS providers have documented their alignment with relevant compliance standards/processes. For example, ISO 27001 is a compliance standard and framework that ensures a range of security practices and controls are performed by the service provider. This and similar objective audits can be a very powerful mechanism to gain and maintain assurance for a range of business uses. For particularly sensitive data or business processes (for example, financial or health care transactions), contact the Stanford University Information Security Office before a PaaS provider is selected or used.
  • For more information see Security When Using a Cloud Product.

Support for business continuity and disaster recovery

  • Any established PaaS provider has a track record for availability, both on uninterrupted normal service and during upgrades/changes. The acceptable level of service availability demonstrated by a provider over time is ultimately a business decision. While not definitively predictive of the future, this is a factor in evaluating a PaaS provider.
  • Usually, demonstrated disaster recovery (DR) readiness is assessed via a third-party audit and is therefore something we find out indirectly. The acceptable level of Recovery Time Objective/Recovery Point Objective (RTO/RPO) demonstrated by a provider is ultimately a business decision.

Ability to notify Stanford about breaches or outages

  • Beyond the operational reporting necessary for incidents, there must be defined service provider responsibilities for reporting timeliness, completeness, root cause, and mitigation strategy.

Compliance with University policy and legal requirements

  • Depending upon the type of data/business process involved with a given PaaS provider, statutory regulations (such as the PCI Data Security Standard or HIPAA) may constrain the location and require very specific notification requirements. Questions regarding these requirements should be directed to the relevant compliance group at Stanford.

Operational practices and considerations when developing on a PaaS provider

  • Keep a developed software repository external to the PaaS provider (such as code.stanford.edu or GitHub), in addition to what the PaaS provider offers.
  • Keep backups of unique data external to the PaaS provider (either on campus or with a different cloud provider).
  • Integrate the PaaS management console with Stanford University’s authentication infrastructure using SAML 2.0 and/or OAuth2.0.
  • Use development, test, staging, and other environments, as you would in any other deployment.
  • Configure logging to send logs and service events to Splunk.
  • When developing applications, be aware of PaaS-specific (proprietary) frameworks, function calls, or other features that are not portable.
  • Monitor the health of the PaaS as well as applications hosted there.

Also see the related Infrastructure-as-a-Service page.

Comments or questions?

Do you have questions or feedback about this page? You can use our Help page to contact UIT’s Cardinal Cloud team.