Select the correct cloud adoption pattern

Uncovering the best adoption pattern to integrate new services and extend business capabilities

Patterns contain best practices and expertise for complex tasks, distilled from repeated real-world engagements; they help define good solutions in a clear format that addresses reoccurring problems. Organizations planning to implement a cloud presence should look at "cloud adoption patterns" as a way to start that process. The authors detail how to apply cloud adoption patterns — with each pattern outlined with its specific characteristics — to support the business and technical requirements of your organization's cloud implementation. The examples explain how a cloud solution provider can build private and public clouds to house client applications either fully in a cloud environment (like those provided by IBM® cloud service offerings) or partially in the cloud and partially on-premise.

Share:

Tina Abdollah (abdollah@us.ibm.com), Senior Certified Executive IT Architect, IBM

Tina AbdollahTina Abdollah is a senior certified executive IT architect for IBM Global Business Services, an Open Group Distinguished Certified IT architect, and a member of the IBM Academy. She has more than 25 years of experience working with information technology systems in distributed network environments, focusing on designing and implementing large complex enterprise IT solution using various technologies and methodologies such as enterprise architecture, cloud computing, business process service optimization, and SOA/web services.



Bernie Michalik (Bernie@ca.ibm.com), IT Architect, IBM

author photoWith more than 25 years of experience in designing, creating, and implementing complex IT solutions, Bernie Michalik has performed in a wide variety of roles, from leading large teams in the creation of large-scale infrastructures to individually developing custom software for global clients. His experience covers a wide variety of methodologies and emerging technologies.



29 May 2013

Also available in Chinese Russian

Patterns contain best practices and expertise for complex tasks distilled from repeated client and partner engagements. Patterns help define good solutions in a clear format that addresses the reoccurring problems; this can then be applied in concrete use cases regardless of used technologies, including software, middleware, or programming languages.

As more and more solutions are deployed to the cloud and as cloud computing becomes an emerging development field of commerce, new products and technologies are made available to cloud users; understanding cloud patterns, especially an adoption pattern, and reconciling the most appropriate pattern with your business's implementation scenario, motivation, and mitigation, can help you build a sound cloud solution.

For example, a full cloud solution in which all of the IT resources resides in the cloud may not be the best solution for certain requirements if the solution needs to integrate with IT components that either reside in on-premises or other cloud environments. Having topologies and patterns that match up with certain requirements help architects narrow in on the solution elements to support both functional, as well as non-functional, requirements.

Patterns also help identify the implications of choosing one pattern over another, which helps architects highlight to the business the ramifications of the choice being made.

The goal of this article is to help cloud architects select a suitable cloud adoption pattern that helps extend business capability and integrate existing on-premise systems with new services provided by cloud providers. The focus is mainly on the integration aspect that uses adoption patterns to support both cloud service models (Infrastructure as a Service [IaaS], Platform as a Service [PaaS], Software as a Service [SaaS], and business process as a service) and cloud types (public, private, hybrid, and community) in an abstract form to categorize the cloud solution offerings. These abstracts should help you select a proper adoption model based on your own business model, desired cloud maturity level, and technology choices (such as software, platform, and tools) — the main goal is to provide you with one of the first critical steps to a holistic path forward towards cloud implementation or extension.

In the following sections, we review key cloud adoption patterns and describe their attributes, characteristics, topology, motivation, and other decision factors; we offer user scenarios and case studies as examples to help provide the context.

Meeting the cloud adoption patterns

Generally speaking, there are four types of cloud patterns that are differentiated based on applications, data, and infrastructure-sharing characteristics:

  • Applications are hosted in on-premise cloud (private cloud); data and infrastructure are not shared.
  • Applications are hosted in the public cloud; data and infrastructure can be shared.
  • A combination of both private and public (hybrid cloud) for applications; data and infrastructure are selectively shared.
  • A community cloud, designed for specific community capabilities, to allow community users to collaborate among themselves.

These cloud patterns are related to but different than cloud service models. Cloud service models (for the purpose of this article) can also be categorized into four different groups:

  • Infrastructure as a Service
  • Platform as a Service
  • Software as a Service
  • Business process as service to support different types of services

The adoption pattern models described are based on the first group of characteristics and encompass some of all of the cloud service models. The cloud adoption patterns are called:

  • Primary hybrid cloud (PHC)
  • Extended hybrid cloud (EHC)
  • Full cloud (FC)
  • Extended full cloud (EFC)

The following sections outline each pattern's attributes, characteristics, and topology. Each section also provides motivations for why you might use them, the pros and cons for choosing one pattern over another, and what the implications can be of adopting a specific pattern.


Primary hybrid cloud (PHC)

The primary hybrid pattern is a method for extending on-premise or hosted deployments into a cloud environment. Processing instances are deployed on demand or pre-allocated and they are not typically integrated into runtime service feeds.

This pattern has a mono-direction scheme for service delivery that only relies on one source being operational at a time. The data center capabilities may offer such services as data services, business support services (for billing, customer management, etc.), operational support services (like service automation, metering, etc.), and support, monitoring, security, and network services.

Characteristics

With this pattern, there is limited integration with on-premises components; components are loosely coupled with no bi-direction synchronization. There is no integration with other cloud solutions.

Topology

Conceptually the primary hybrid pattern can be represented as in Figure 1:

Figure 1. Primary hybrid cloud topology
Primary hybrid cloud topology

There is limited integration between the on-premise components on the left and the cloud components residing on the right. Logically it looks something like Figure 2:

Figure 2. Primary hybrid cloud logical structure
Primary Hybrid Cloud logical structure

Motivation

Motivating reasons you might adopt this pattern include:

  • You need additional capacity for processing that can't be met on premise and that can operate without limited input from on-premise systems.
  • You have a need to pre-process a lot of raw data but you don't want to store all of it on-premise; you just want to store the results.
  • You require software components that can't run on premise.
  • You don't have the existing in-house skill set to set up the environment or run the software on premise.
  • Your time-to-market is short and your business needs can be met with a cloud provider but can't be met with on-premise technology.
  • You think you might need an extended hybrid cloud but you aren't ready to do that yet.

Key user scenarios

Businesses that use the primary hybrid pattern typically have these business requirements:

  • You want to run additional batch processes but there are no processing windows currently available on your on-premise systems.
  • You have a big data project that collects data from the Internet and you want to data mine it (for example, business intelligence [BI] reporting) based on inputs from on-premise systems.
  • You want to host a content management system in the cloud that contains a subset of your content management system on premise.
  • You need a test a new application that runs on an operating system that runs in the cloud but not on premise.
  • You want to share on-premise data via replication for users who are off premise.
  • You want to provide additional services (like data analytics) outside of the core services that are based on on-premise systems but are not necessary for the core business.
  • You want to take outsource-specific e-commerce functionality, such as payment services or billing, to an SaaS provider.

Deciding factors

Factors that determine whether you adopt this pattern are:

  • You want to limit your commitment to a full cloud deployment.
  • Risk isolation: For instance, batch processes may fail but may not have a service impact in a daily context and that would have minimum impact on your core business and would not need much support from on-premise facilities.
  • Investment minimization: You want to quickly gain initial cloud experience before launching the full cloud.
  • Flexibility: This pattern allows you to expand you existing business with the least amount of commitment.
  • Minimize the integration and process dependency.
  • You don't need to partition your data.
  • No need for real-time transactions.

Implications

If you adopt this primary cloud pattern, key implications to consider are:

  • The need to maintain one support structure for the cloud and one for on-premise systems that may contain redundancies or conflicts.
  • There may be little if any on-premise monitoring for the cloud environment that may require you to provide your own monitoring.
  • The work that is required for you to do the limited integration from your on-premise systems to the primary hybrid cloud services.
  • Establishing a governance model (for example, change control, QoS) and standards with the cloud provider.
  • Contract management needs to be set up with terms and conditions.
  • Security of cloud solution will likely differ from on-premise solutions.
  • Existing operational support capabilities might not stretch to cloud solutions which may require review and refine current support structure.
  • Establishing metrics to verify and audit the services the cloud provider offers.
  • User education and training may be required to cover the extended capability.
  • Application migration and patch management support.
  • The need for a disaster recovery plan to include the cloud extension.
  • There may be limits in your ability to receive real-time integration with the primary hybrid cloud services.

Extended hybrid cloud (EHC)

Extended hybrid clouds involve attaching one or more on-premise or hosted environments to a cloud environment. It consists of a mixed resource environment, combining both local and cloud resources to provide a cloud service; it relies on both environments to deliver true end-to-end functionality. Extended hybrid clouds have a bi-directional reliance for service delivery since they rely on two separate sources to be active and running in order to deliver a service.

Characteristics

With this pattern, there is significant integration with on-premise components and the components are more tightly coupled with bi-direction synchronization. This differentiates it from the primary hybrid pattern. The data and functionality is somewhat tightly coupled between the existing IT and the cloud environment to deliver the expected service; however, this is a standalone cloud solution and there is no integration with other cloud solutions. All integration is with on-premise systems.

Topology

Conceptually, the extended hybrid pattern can be represented as shown in Figure 3:

Figure 3. Extended hybrid cloud topology
Extended hybrid cloud topology

There is much closer integration between the on-premise components on the left and the cloud components residing on the right than there is in the primary hybrid pattern.

Logically it looks something like Figure 4:

Figure 4. Extended hybrid cloud logical structure
Extended hybrid cloud logical structure

Motivation

The reasons you might adopt this pattern are:

  • Cloud components depend on on-premise data stores or vice versa.
  • On-premise operational facilities are necessary for the operation of cloud components or vice versa.
  • On-premise processing is required for cloud processing or vice versa.
  • Real-time or near real-time processing and communication with the cloud components and data store is required.

Key user scenarios

Businesses that use the extended hybrid pattern typically have these business requirements:

  • Transactional processing where your data is created, updated, or stored in a synchronous way both in the cloud and on premise.
  • Business process transactions that require a blend of both cloud processing and on-premise processing to complete.
  • Transactions where some key components must reside on premise while other components reside in the cloud.
  • On-premise transactions where some reporting capability (such as expert data analysis, etc.) requires additional data and processes from the cloud for the reports.

Deciding factors

Factors that help determine whether you should adopt this pattern are:

  • Enable reuse of the existing on-premise IT investment.
  • Allow the ability to partition the data based on privacy considerations.
  • Offer real-time or near real-time BI or process integration.
  • Extend existing business capability via the cloud components.

Implications

If you adopt this cloud pattern, key implications to consider are:

  • On-premise operational staff must understand the cloud components and vice versa (for example, downtime, failover, etc.).
  • You must require better management of the service level agreement.
  • Before moving the workload and data to the cloud, you need to:
    • Validate data privacy and compliance
    • Validate and integrate flow of the workload

Moreover, this pattern requires tight collaboration between the service consumer and provider since this pattern is based on bi-directional reliance. This includes:

  • A middleware framework to choreograph and route the communications between the on-premise and cloud services.
  • Governance processes and standards must be established to support change control and life cycle management.
  • Planning and design of the integration, testing, and support.
  • Clear roles and responsibilities must be defined; some organization and cultural changes may be required.
  • Contractual agreement with external cloud providers must also be defined and agreed upon by all parties.
  • Security of cloud solution will likely align with on-premise solutions.
  • Operational support capabilities likely extend to cloud solutions.

Full cloud (FC)

A full cloud solution involves delivering a production-ready solution using only cloud services from one or more cloud providers. All functional aspects of a full cloud solution used to deliver the client-visible services (things like business and operations support systems) reside completely within a single cloud hosting environment.

Non-production-facing elements such as development and testing may use a hybrid cloud or a fully on-premise solution. Also, non-production elements do not change the definition of full cloud for production purposes.

Characteristics

With this pattern, there is no integration with on-premises components and support structure. All integration occurs with a single cloud environment and managed by one data-center-hosting provider. Application integration happens within the cloud platform and leverages the common cloud framework and IaaS.

Topology

Conceptually the full cloud pattern can be represented as in Figure 5:

Figure 5. Full cloud topology
Full cloud topology

There is no integration between the on-premise components on the left and the cloud components residing on the right any integration occurs only within the cloud.

Logically, it looks something like Figure 6:

Figure 6. Full cloud logical structure
Full cloud logical structure

Motivation

The reasons that you might adopt this pattern are:

  • You need to guarantee success by using the best of breed, industry-proven cloud solution.
  • You don't have in-house cloud skill set with either hardware or software currently to set up the cloud environment and develop and manage the solution.
  • Your time-to-market is short and requires using an existing cloud provider.
  • This is a short-term or an experimental business initiative and you want to leverage an external cloud environment to minimize upfront investment.
  • Your cost consideration; it may be cheaper by using an external cloud provider than set up on your own environment.
  • You may deploy the solution in a private managed cloud or public cloud environment that depends largely on your security and privacy, flexibility, support, and accessibility consideration.
  • You may want to establish yourself as a cloud service provider (CSP) and offer your solution to your existing or new customers. The cloud service will provide a new ROI using a pay-as-you-go (PAYG), metering, and charge-back cloud model, as well as expand your commercial presence within your industry area.

Key user scenarios

Businesses that use the full cloud pattern typically have these business requirements:

  • A need for short-term solutions such as a marketing event.
  • Solutions that depend on technology that is incompatible with your on-premise IT.
  • A proof of technology, proof of concept, or pilot program site.
  • A new line of business or service offering.
  • Joint venture sponsored by independent parties.
  • Business process transactions requiring both cloud and on-premise processing or data where all the components reside in the cloud.

Deciding factors

Factors that determine whether you adopt this pattern are:

  • The need to eliminate on-premise IT support
  • The flexibility and elasticity of a cloud environment
  • A more cost-effective model like PAYG
  • A short time-to-market
  • A new business ROI

Implications

If you adopt this full cloud pattern, key implications to consider are:

  • You must establish your own service level agreement with the cloud service provider to insure it will meet your operational needs.
  • You also need to validate that the cloud will meet your data privacy and compliance requirements and standards.
  • You must establish governance processes and standards to support change control and life cycle management as well as legal compliance.
  • Business supporting services must be established to support the new cloud model; for example, subscription, customer on-boarding process, and financial management.
  • Having a self-service web portal to support provisioning, reporting, etc.
  • The hosting provider must be able to support disaster recovery and backup to protect the integrity of the data and applications.
  • Must have adequate service support and patch management to guarantee the health of the environment.
  • Require proven change/release management processes and more than one environment - for example, dev/test, QA/DR, and production — before the new functionality goes live.

Extended full cloud (EFC)

The extended cloud scenario is a simple extension of the full cloud. A provider who chooses to use more than one cloud data center and to link or decouple services may extend its service portfolio across numerous infrastructures.

Characteristics

With this pattern, there is integration with one or more cloud solutions in other cloud environments. There is no integration with on-premise resources.

Topology

Conceptually the extended full cloud pattern can be represented as in Figure 7:

Figure 7. Extended full cloud topology
Extended full cloud topology

Integration occurs between components residing in different cloud environments. Logically, it looks something like Figure 8:

Figure 8. Extended full cloud logical structure
Extended full cloud logical structure

Motivation

The reasons that you might adopt this pattern are the same motivation as the full cloud pattern, but with the additional need to integrate with other clouds.

Key user scenarios

Organizations that use pattern typically have these requirements:

  • To provide a variety of cloud services (SaaS, PaaS, IaaS, business processes) that gives users access to services from different cloud service providers.
  • To route users to different cloud services based on their request.
  • To extract data from one cloud service, transform it, and then load it into a different cloud service.

Deciding factors

Factors that help determine that you adopt this pattern are similar to the full cloud pattern, namely:

  • The need to eliminate on-premise IT support
  • The flexibility and elasticity of a cloud environment
  • A more cost-effective model like PAYG
  • A short time-to-market
  • A new business ROI

Additionally, you need to address the ability to bring together other cloud services.

Implications

If you adopt this pattern, the implications are similar to those of the full cloud pattern. In addition, you must also understand the operational aspects (and other aspects) of working with multiple cloud environments and more than one provider to address such considerations as:

  • Adoption of open and industry standards
  • Integration framework that allow you to integrate and choreograph the services
  • Authentication and authorization support such as a federated identity manager with single sign-on functionality
  • Multi-tenancy management
  • Self-service portal such as a customer and provider web portal
  • Uniform and common service platforms
  • Governance standards, process, and procedures
  • A revenue-sharing model needs to be established
  • Metering and chargeback capability
  • Contract management
  • Monitoring and auditing capability
  • Service automation
  • Patch management

Conclusion

This tour of the characteristics of these cloud adoption patterns - primary hybrid cloud and extended hybrid cloud and full cloud and extended full cloud - should help you select the appropriate cloud adoption pattern that can make it easier for your organization to integrate new services and extend business capabilities by implementing a new cloud environment or extending your existing one.

Resources

Learn

Get products and technologies

  • Evaluate IBM products in the way that suits you best: Download a product trial, try a product online, use a product in a cloud environment, or spend a few hours in the SOA Sandbox learning how to implement Service Oriented Architecture efficiently.

Discuss

  • Get involved in the developerWorks community. Connect with other developerWorks users while exploring the developer-driven blogs, forums, groups, and wikis.

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Cloud computing on developerWorks


  • Bluemix Developers Community

    Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.

  • developerWorks Labs

    Experiment with new directions in software development.

  • DevOps Services

    Software development in the cloud. Register today to create a project.

  • Try SoftLayer Cloud

    Deploy public cloud instances in as few as 5 minutes. Try the SoftLayer public cloud instance for one month.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Cloud computing
ArticleID=931843
ArticleTitle=Select the correct cloud adoption pattern
publish-date=05292013