Government of Canada Right Cloud Selection Guidance

Note to Readers

If you would like to receive a PDF version of the Government of Canada’s Cloud Adoption Strategy, Security Control Profile for Cloud-based Government of Canada IT Services, or the Government of Canada Right Cloud Selection Guidance, please send your request to Public Enquiries.

Background

In the Summer of 2016 the Government of Canada Information Technology Strategic Plan and Cloud Adoption Strategy were published. They both recognize the importance of leveraging cloud services as a means of improving information technology (IT) service delivery. The Government of Canada (GC) believes that a Right Cloud Adoption Strategy better suits the needs of its departments and agencies. Given the diversity of the IT landscape, a one-cloud-fits-all solution will not serve all needs. The GC will adopt a Right Cloud strategy that will enable CIOs to adopt the deployment model that best suits their business needs.

“The GC’s IT landscape is microcosm of the past five decades of information technology evolution; comprised of bespoke solutions, commercially acquired solutions, legacy solutions and much more. A one-cloud-fits-all solution will not serve all needs. For that reason, the GC will adopt a Right Cloud strategy.”
- GC Cloud Adoption Strategy

The GC Cloud Adoption Strategy puts forward a series of adoption principles for CIOs to consider when choosing and using services with the confidence that they will be maximizing the benefits of cloud, when cloud is appropriate, while ensuring the protection and privacy of Canadian’s data. The onus is on the department to demonstrate which deployment model is right for their business context.

The first step in using cloud is to categorize the data; the second step is to use this document to guide your deployment model selection. Data categorized above Protected B is out of scope of this document as, currently, no cloud security control profile exists above the Protected B level.

This document is intended to detail how business context should be considered when selecting a cloud deployment model. These selection choices are to be reviewed and approved by departmental Architectural Review Boards (ARBs).

Cloud Deployment Models

The spectrum of cloud deployment models available to CIOs are provided below. CIOs should use this document as guidance to selecting the Right Cloud.

: Public Cloud: a commercially available offering procured and security assessed for the use of a single GC organization. Under this deployment model the single organization will share tenancy with private companies, non-profits, and individuals.
: Private Cloud: a non-commercially available cloud offering tailored for the GC. Under this deployment model the GC will be the only tenant residing in the cloud. This cloud may be completely designed and operated by GC resources or with private sector support.
: Non-Cloud: an environment for hosting applications that cannot be deployed to a cloud environment. The majority of the current GC application portfolio fits into this category.

Considering Business Context

The decision regarding which deployment model, and even service model, works best is driven by a particular CIO’s business context. In choosing the deployment model, the following factors should be considered. These factors have been grouped by Business, Information, Application, and Technology viewpoints.

Business
Information
Application
Technology

Business

Financial: Which is more desirable for your program; operational expense or a capital expense? Cloud pricing is consumption based; this may be desirable in cases where demand is controlled, however in some cases where consumption may spike; can your program absorb these costs within its revenue model?
Speed: Consider the speed with which you require a solution. Solutions with standardized offerings and pricing provide rapid access.
Longevity: Consider for how long you will need the solution.

Financial

One of the advertised benefits of a public cloud environment is to convert IT spending from a capital expense to an operational expense. This is often a benefit in a private sector setting where increased consumption of an IT resource such as a website results in increased costs, may be offset by the additional revenue generated. This is often not the case for public sector services.

One should consider the long-term cost of public vs private cloud. Public cloud provides a low entry cost with operating costs tied to consumption. This introduces the risk that if an unplanned rise in consumption occurs, costs rise and may become a financial liability to your budgeting process. Private cloud typically requires a higher initial cost and higher operating cost or reinvestment as assets age. Private cloud may or may not have consumption-based pricing.

If a capital expenditure is desired, a private cloud model may be preferred.
If an operational expenditure is desired, a public cloud may be preferred.

Speed

Public cloud provides rapid access to computing services. Programs often have a requirement to rapidly deploy solutions to meet the needs of new or evolving legislative changes to meet the priority of Parliament. The speed of public cloud offerings comes at the price of standardization; the ability to customize the offering may be constrained.

If rapid access to on demand services is required then a public cloud deployment model should be selected
else any deployment model can be selected.

Longevity

Temporary requirements, such as generating a proof of concept, are well suited for a public cloud environment as little investment is required and, particularity with Software-as-a-Service, provides turn-key solutions.

If the application is expected to meet a long-term need, then any deployment model can be used
else, for a short-term need, a public cloud deployment model should be selected.

Information

Sensitivity: What is stakeholders’ risk tolerance for deploying information to a third-party’s IT environment?
Elasticity: Consider how your requirements will grow with time. Does the program require capacity on-demand at peak periods?
Connectivity: How integrated is your solution with other applications? What integrations are part of your solution? Are analytics a requirement?

Sensitivity

Beyond categorizing data as being protected or classified, the sensitivity of the information must also be considered. Stakeholders may raise concerns about a particular dataset being hosted in a third-party’s IT environment.

If stakeholders view the sensitivity of the data to be high, a private cloud or non-cloud environment may be preferred
Else, public cloud environments are preferred.

Elasticity

Workloads that expect to support high or rapid growth of data storage, bandwidth, or processing power require elasticity. As the consumption of resources grow the ability to add new resources on-demand becomes important. Public clouds provide highly scalable environments, however the financial impacts must also be considered.
With time,

if the resource requirements of the application will remain stable, any deployment model can be considered.
If the requirements will grow or shrink then a public cloud deployment model should be used.

Connectivity

It is often the case that applications are not isolated silos of data, but instead highly integrated with other applications to orchestrate business processes. One must consider the impact to deploying applications across environments. While public cloud providers are increasingly providing integration technologies and application programmer interfaces (APIs), these technologies can solve cloud integration issues.

If the application does not have voluminous transactions with an on-premises database or application then solutions with a hybrid on-premises and off-premises deployment model is not feasible
else, consider keeping all components of the application’s architecture in one data center.

Application

Location: Consider the impact of latency. High chatter applications are sensitive to solution that is physically distant from the users.
Innovation: Is your program service delivery is expected to evolve with new technologies and trends?
DevOps: Consider the speed of which your solution must promoted from dev. to production and the toolset needed to support that process.

Location

High chatter application may suffer due to the latency of accessing data physically located far from the user accessing it. With time, many legacy high chatter file formats and applications are being re-architected for cloud environments. Additionally, consider where the users of the application/website will physically reside. Those websites that have a large global audience may find advantages by deploying in a public cloud.

If the application is not susceptible to latency issues that may arise due to traffic moving through an additional network circuit, then all deployment models can be selected
else, on premises deployment models are preferred.

Innovation

Public cloud environments typically add new services and technologies at a rapid pace with little or no cost to the consumer. As technology trends evolve introducing mobile, big data, internet of things, and social media technologies public cloud providers have a proven track record of rapidly introducing these technologies.

If the project wishes to take advantage of new technology trends as they become available to the market then a public cloud deployment model is preferred
else any deployment model may be selected.

DevOps

The provisioning of infrastructure alone does not meet the needs of the application development community. A complete set of development tools, testing tools, code stores, defect tracking tools and more is required to support the development of applications. Public cloud providers offer a rich set of tools that constantly evolve to meet current best practices and changing technology trends.

If the project wishes to obtain rapid access to a suite of tools to support application development as platform services without making a capital investments, then a public cloud deployment model is preferred
else, any deployment model may be selected.

Technology

Legacy: Can the solution exist in a virtualized environment?
Commoditized: Can the requirement be met with commoditized solutions? What is the market availability of the solution?

Legacy

Most existing applications were not designed to exist within a virtualized environment. For this reason legacy applications are often not appropriate for cloud deployment models until such time as they are reengineered or replaced by more modern solutions.

If the application can operate in a cloud environment and the required virtualized or dedicated hardware is available then a public or private cloud deployment models are options
else, a non-cloud deployment model must be selected.

Commoditized

Is the solution available as a commoditized cloud solution? The market availability of cloud solutions is growing, however many solutions have not yet migrated to the cloud. Additionally if highly customized service level agreements are required, cloud typically resists customization in favor of standardizations.

If the application can operate on the standardized offerings and SLAs then public cloud can be selected,
else, private cloud or non-cloud deployment models must be selected.

Vendor Lock-in

The risks surrounding vendor lock-in are not necessarily a differentiator between choosing public, private, or non-cloud deployment models. Buyers in all cases must take measures to mitigate against the following scenarios:

A vendor ceases to exist through bankruptcy or other means thus bring support to an abrupt end and legal action may follow
A vendor is acquired and the new ownership may pose a risk to Canada
A vendor takes a product or service in a direction not aligned to Canada’s strategic intent
A vendor’s pricing changes significantly posing a hardship to Canada

The GC must be in a position to recompete products and services in order to obtain the best value for Canada. The cost of switching from one vendor’s services to another are often significant as not only do products need to be purchased but staff needs to be retrained. Mitigation strategies for the risks associated with vendor lock-in include:

Encourage competition by investing in products and services from multiple vendors
Purchase products and services from mature vendors with a high number of customers and history of serving those customers
Develop strategies to encourage opportunities for small and medium business
Use open standards supported by multiple vendors
Continue to refresh vendor-lock mitigation strategies

Cloud environments can experience additional risks as the applications and data is hosted within another party’s facilities. For this reason additional mitigation strategies should be employed such as:

Host a disaster recovery and/or back-up solutions in another vendor’s environment
Ensure an exit strategy has been devised that is aligned to the business continuity requirement of the business service being enabled

Vendor Lock-in and the Service Delivery Model

The level of risk associated with vendor lock-in with a cloud provider varies with the service delivery model. Infrastructure-as-a-Service (IaaS) is a fairly commoditized service offering making portability of solutions simpler than Software-as-a-Service (SaaS) which has highly differentiated offerings making portability more challenging.

This spectrum of differentiation and commoditization is analogous to the same spectrum found in the current IT environment. For example Enterprise Resource Planning systems; the cost of switching the underlying infrastructure is relatively low cost, however changing the ERP itself has a significant impact due to the level of impact to the business domain.

Right Cloud Decision Tool

To help organize the decision of which cloud deployment model is the right deployment model for your business context, the following tool can be used. This grid is an evaluation matrix of cloud and non-cloud deployment models.

For each criteria check-off the description(s) that apply to your project/application.
If all of the criteria within a deployment model are checked-off, it is considered a valid choice for deployment.
Of the valid models, the model to the farthest left is the best model for your business context.
Rated criteria can be used to weigh non-mandatory benefits of one model over the other.

Impact levels help the decision maker understand the strength of their rationale.

Mandatory: All criteria must be met for a particular model
Highly Rated: Significant impact on selection
Rated: Desirable features impacting selection

Impact Level	Criteria	Public	Private	Non-Cloud
Mandatory	Sensitivity	Stakeholders have not raised concerns regarding the sensitivity of the data.	Stakeholders view the sensitivity of the data to be high.
	Financial	Budget is available to support an Operational Expense Model; the costs will rise and fall with the consumption of resources.	Budget is available to support a Capital Expense Model; ability to plan for periodic investments in ever greening infrastructure and innovation.
	Legacy	Application can operate in a cloud environment and the required virtualized or dedicated hardware is available in a cloud environment.		Application needs to operate in a non-cloud environment and required highly specialized, dedicated, hardware.
Highly Rated [20 points each]	Commoditized	Application can operate on the standardized offerings and SLAs of public cloud.	Application requires customized offering and SLAs.
	Location	Application is not susceptible to latency issues that may arise due to traffic moving through an additional circuit.	Application is susceptible to latency issues that may arise due to traffic moving through an additional circuit.
	Connectivity	Application does not have voluminous transactions with an on-premises database or application.	Application has voluminous transactions with an on-premises database or application.
Rated [10 points each]	Speed	Rapid access to services is desired. Are the required services available on-demand?	Can tolerate the time required to implement the services that may not currently be available on-demand.
	Longevity	The applications is expected to meet a: Long-term need Short-term need	The applications is expected to meet a: Long-term need Short-term need	The applications is expected to meet a long-term need
	Elasticity	With time, the resource requirements of the application will: Remain stable Grow and/or Shrink	With time, the resource requirements of the application will remain fairly stable.	With time, the resource requirements of the application will remain stable.
	Innovation	Project will want to take advantage of new technology trends as they become available to the market.	Application does not want to take advantage of new technology trends and will remain static.	No new technology is required.
	DevOps	Desire rapid access to a suite of tools to support application development as platform services without making a capital investment.	Willing to invest to deploy application development tools to support project.
Summary	Mandatory Met
Summary	Rated Totals

Conclusion

This document provides the criteria and a tool to determine the Right Cloud for your business context. The tool is intended to document the rationale for your selection and shared with your departmental Architecture Review Board (ARB) for oversight and endorsement.

Page details

Date modified:: 2016-08-10

Language selection

Search