Choosing between off-premise Public Clouds and on-premise Private Clouds

Given the wide range of infrastructure cloud computing (IaaS) options soon to be available to staff, faculty and researchers at CU Boulder, we’d like to provide some initial guidance as to how to choose between these options. Many services are well suited for off-premise public cloud environments, but there are also some that would be much better served in an on-premise private cloud, whether the OIT private cloud or the Research Computing offerings. 

As we consider this decision there are a few major factors to consider:

  • Business Drivers: characteristics of the service that drive value back to the business
  • Data Gravity: maintaining data “close” to the application
  • Service characteristics: aspects of the service itself that “fit” a particular cloud
  • Natural Affinity: characteristics of the service may naturally fit with a specific provider (e.g. Microsoft centric services may be a better fit on a Microsoft cloud)
  • Security/Compliance: regulatory requirements may be a factor for a specific cloud

Business Drivers

  • Agility: Off-premise public cloud can provide agility in the form of improving speed of delivery, adjusting to changing requirements and providing a platform for quick innovation. It is important to consider the user base of the application and their willingness to adapt to change quickly since that may limit the practical agility of the overall solution
  • Cost: monetary cost savings should not be the primary driver for public cloud adoption as it is not always less expensive from a financial perspective. Implicit or opportunity costs in terms of time saved by leveraging one option or another may be a contributing factor.
  • Expected Growth Pattern: applications which have the potential for fast growth in usage may be a good fit for public cloud since new resources can be added much more quickly
  • Elasticity of load: if an application is highly used at certain times of the day or year relative to low baseline usage it may benefit from giving back unneeded resources during slow times (cost savings)
  • Short time to live: if an application is only needed for a short period of time, public cloud may provide a platform to improve speed of deployment and teardown (agility). 
  • Identifying a clear service owner for the application/service is imperative to ensure someone is empowered to makde tradeoff decisions (e.g. cost/performance) so that the flexibility of public cloud will be fully realized.

Data Gravity

Generally, computing resources should be placed as closely as possible to the bulk of data that they will operate on. Often times this creates a natural grouping of applications or services which should choose to be deployed and run together either in off-premise public cloud or on-premise private cloud.

Service Characteristics

  • Applications which can scale horizontally (adding more servers) rather than vertically (larger servers) tend to benefit more from off-premise public cloud infrastructures
  • Applications which do not support clustering or other high availability options are generally not well suited for off-premise public cloud given that a single server in off-premise public cloud tends not to have a clear SLA on availability
  • Container friendly or cloud-native - some applications have been designed from the ground up to run in off-premise public cloud environments and likely will benefit significantly from being placed there. This is especially true of container based applications as well as cloud-native services.
  • Legacy services that rely on older architectures should be examined closely. Many older architectures were not designed with cloud in mind and so may require a specific cloud to function.
  • Latency sensitive applications - applications that are especially sensitive to network latency must be examined carefully to determine if the an off-premise public cloud service, where network latency is less predictable or potentially less cost-effective than on-premise private cloud, is appropriate. Examples include:
  • Internal sensitivity such as cluster heartbeats, reliance on infiniband type technologies (e.g. for message-passing in HPC applications)
  • External sensitivity such as database links across applications used in synchronous operations
  • Identify acceptable performance or other key performance metrics in a current service or identify them for a new service such that a move to the off-premise public cloud can be measured and level of success can be determined based upon these metrics.

Natural Affinity

  • Applications may have a natural affinity to a particular cloud environment, e.g. Microsoft services may run more smoothly on Microsoft Azure
  • Certain services may only exist in a particular cloud or be much stronger in a certain cloud at a particular time


  • Based on various prioritization decisions and constraints both within and outside OIT’s span of control, OIT may choose to support certain security or compliance requirements only in certain clouds. These will be documented as we move forward but may necessitate a specific location for certain applications.
  • Data classification may drive a specific choice of environment. More guidance on this will be provided as we define off-premise public cloud security in concert with the security office.