IT training mesosphere ebook hybrid and multicloud solutions 1 khotailieu

Co
m
pl
im
ts
of

Steve Suehring

en

Hybrid and
Multicloud
Solutions



Hybrid and
Multicloud Solutions

Steve Suehring

Beijing

Boston Farnham Sebastopol

Tokyo


Hybrid and Multicloud Solutions
by Steve Suehring

Copyright © 2019 O’Reilly Media Inc. All rights reserved.
Printed in the United States of America.
Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA
95472.
O’Reilly books may be purchased for educational, business, or sales promotional use.
Online editions are also available for most titles (). For more infor‐
mation, contact our corporate/institutional sales department: 800-998-9938 or cor‐


Editor: Jonathan Hassell
Production Editor: Deborah Baker
Copyeditor: Octal Publishing, LLC
Proofreader: Matthew Burgoyne
February 2019:

Interior Designer: David Futato
Cover Designer: Karen Montgomery
Illustrator: Rebecca Demarest

First Edition

Revision History for the First Edition
2019-02-05: First Release
See for release details.
The O’Reilly logo is a registered trademark of O’Reilly Media, Inc. Hybrid and Multi‐
cloud Solutions, the cover image, and related trade dress are trademarks of O’Reilly
Media, Inc.
While the publisher and the author have used good faith efforts to ensure that the
information and instructions contained in this work are accurate, the publisher and
the author disclaim all responsibility for errors or omissions, including without limi‐

tation responsibility for damages resulting from the use of or reliance on this work.
Use of the information and instructions contained in this work is at your own risk. If
any code samples or other technology this work contains or describes is subject to
open source licenses or the intellectual property rights of others, it is your responsi‐
bility to ensure that your use thereof complies with such licenses and/or rights.
This work is part of a collaboration between O’Reilly and Mesosphere. See our state‐
ment of editorial independence.

978-1-492-04719-3
[LSI]


Table of Contents

1. Understanding the Hybrid Cloud. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
What Is a Hybrid Cloud?
Hybrid Cloud Challenges
How Can I Use a Hybrid Cloud?
Conclusion

1
3
6
7

2. Hybrid Cloud Architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Understanding the Components of the Hybrid Cloud
Architecting the Hybrid Cloud
Conclusion

9
16
17

3. Choosing a Hybrid Cloud Solution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Examining Capabilities
Examining Decision-Making Criteria
Conclusion

19
21
23

iii



CHAPTER 1

Understanding the Hybrid Cloud

The datacenter has undergone fundamental changes over the past 10
years. Virtualization technology enables organizations to create
internal private clouds, speeding up delivery of software projects. In
many cases, public cloud providers provide a viable substitute for
local data, and in other cases, public cloud providers supplement the
private cloud.
As the world moves to the cloud, organizations are increasingly
looking for ways to take advantage of their investment in private
clouds for a competitive advantage. This advantage can be achieved

by combining public and private cloud technologies to create a
hybrid cloud.
This chapter examines the hybrid cloud, beginning with some basic
vocabulary and continuing with use cases for the hybrid cloud.

What Is a Hybrid Cloud?
A hybrid cloud is a combination of one or more public cloud pro‐
viders (like Amazon Web Services [AWS], Microsoft Azure, and
Google Cloud Platform [GCP]) and a private cloud platform (hosted
on-premises for use by a single organization) or private IT infra‐
structure. The public cloud and private infrastructure are distinct
and independent elements that communicate over an encrypted
connection. This enables organizations to store secure data in their
own datacenter while using computational resources from the pub‐
lic cloud to run applications that rely on this data.

1


Many organizations use a combination of resources from both
external providers and internal IT-based hardware and services. The
use of each type of resource has changed over time, and organiza‐
tions manage both internal and external resources through existing
management practices and by using existing infrastructure tools.
An important change in enterprise computing in the past decade—
which has shown increasing growth in the last three to five years—is
the use of automation and DevOps practices. The premise is to auto‐
mate as much as possible—from testing, to build, to production
migrations—that leads to repeatability. Processes to test and build a
project can be repeated as many times as necessary and should bring

the same results every time.
Automation, Continuous Integration/Continuous Delivery (CI/CD),
and related practices enable a more efficient use of resources. As the
organization grows and as service offerings from public cloud pro‐
viders mature, processes that were previously handled internally are
moving to external providers.
However, much of the work to move jobs and processes between the
private and external cloud is manual, requiring not only engineering
and IT, but also architectural assistance. The labor-intensive migra‐
tion of workloads is also error prone and works against the efforts
toward automation and repeatability.
Organizations are increasingly looking for ways to automate and
control the movement of workloads between private and public
clouds. With automated, repeatable processes, IT can now seam‐
lessly move between cloud services to take advantage of cost savings
and resource availability.
Hybrid cloud enables organizations to reduce costs by utilizing the
least inexpensive resource for the task while taking advantage of the
best solution for that task. For example, organizations might keep
bandwidth-intensive operations on-premises, within their own data‐
centers or private clouds, where the on-premises network can easily
handle the traffic.
Hybrid cloud architectures also enable a more efficient use of
resources. For workloads such as CPU-intensive operations, an
organization might offload the process to a public cloud to save the
investment in hardware. Applications themselves can be deployed

2

|

Chapter 1: Understanding the Hybrid Cloud


without needing to focus on the underlying platform on which the
application resides.

Hybrid Cloud Challenges
Although the hybrid cloud solves many problems, it also presents
some challenges. Migration of workloads and integration between
the private and public clouds are primary challenges. Ensuring that
applications and data do not become fragmented between clouds is a
key issue as well.
This section expands on some of those challenges.

Workload Migration
Integrating clouds is a labor-intensive process, and simply choosing
when to use a public cloud provider is a daunting task as well.
Applications previously deployed within the internal datacenter can
be the most challenging to move. From an operational standpoint,
the applications are working well, so there is a natural tendency to
leave these applications alone.
From a development standpoint, shifting legacy applications
presents challenges. If the application has not been changed recently,
there might be a lack of organizational knowledge about how the
application works internally. When there is an enhancement project
for the application, the fact that it still resides on physical hardware
and does not use DevOps deployment practices becomes a hin‐
drance to accurately completing the project on time.
There are three primary means to move legacy applications: bigbang, phased, and pilot. With a big-bang rollout, the application is

turned off in the legacy environment and immediately begins pro‐
cessing transactions in the new environment. A phased rollout sees
portions of the application moved to the new platform. Finally, a
pilot-based rollout tests major functionality of the application in the
new environment.
There are problems with each approach. With a big-bang rollout,
there is no clear path to migrate back to the legacy environment if
there are problems with the new system. This means fixing issues as
they arise and hoping that none of the issues are critical. A phased
rollout might be difficult because it requires decoupling portions of

Hybrid Cloud Challenges

|

3


the legacy application, which can be difficult or impossible in some
situations. A pilot approach can miss key functionality and therefore
not be a valid test of the new system.
It’s important to note that these issues exist regardless of whether an
organization is migrating within their own cloud or between clouds.
However, a key element to success in all cases is visibility. Being able
to see what is happening at all phases, from development to rollout,
leads to the ability to better control all aspects of the project.
Control over workload migration is a fundamental problem. The
sheer number of tools involved in management of systems presents
its own set of problems. Tools that help to abstract the issues around
management are quite helpful.

Integrating Between Clouds
After you have moved workloads to a public cloud, managing the
integration is the next challenge. There can be portions of the work‐
load in each cloud. For example, the data processing and analytics
might be handled in the public cloud, whereas other business rules
are applied in the application hosted within the private cloud.
Public cloud providers manage resources such as compute, memory,
and disk as pools of on-demand resources from which the organiza‐
tion can draw to meet its needs. For example, adding more RAM for
a particularly memory-intensive task is straightforward with a pub‐
lic cloud provider.
When working with a private cloud, abstracting the technology to a
higher level and treating the underlying server and other hardware
resources as a single entity enables management of the private cloud
in much the same way.
It’s when you need to manage the public and private clouds together
that administration tasks become more difficult. The vendors for
both clouds are usually different, sometimes requiring different
skillsets for troubleshooting. On-premises management starts at the
bare metal and goes to higher levels from there, whereas public
cloud management brings with it a web interface or an application
programming interface (API), both of which present difficulties.

4

|

Chapter 1: Understanding the Hybrid Cloud

Obtaining Support and Assistance
Organizations frequently sign service contracts with public cloud
providers for extended support. These contracts provide additional
assistance when issues arise. Enterprise organizations, or those with
specialized workloads, might also use technical sales representatives
to help determine how the cloud provider can best meet the project
requirements.
For internal cloud and datacenters, traditional support methods
from employees are supplemented with support from consultants,
usually on an as-needed or per-project basis. Service contracts with
various vendors provide the additional level of support when
needed.
However, when problems arise with a cloud-based workload, espe‐
cially those that are split between private and public clouds, obtain‐
ing support can be quite difficult. When an issue crosses vendors
and providers, there is a tendency for vendors to provide inconsis‐
tent troubleshooting assistance. This can create an especially diffi‐
cult situation when the issue in question creates an outage or
emergency.
Being able to obtain a unified support experience can be the differ‐
ence between an outage and an anomaly. The anomaly might only
show in the internal monitoring software, but a single call for assis‐
tance prevents the issue from continuing or expanding in scope. The
root cause analysis and determination become much easier when
you’re managing a hybrid cloud with unified support.

Avoiding Fragmentation
Keeping track of which workload is running on internal versus
external can be challenging but is necessary in order to avoid frag‐

mentation, where workloads and resources are orphaned within one
of the environments. Tracking down whether the resources are still
being used or are still needed also presents a challenge for the sys‐
tem administrator.
However, it’s usually necessary to take this hybrid approach because
portions of workloads might simultaneously run in both environ‐
ments. For example, to obtain the most efficient use of resources, a
data analysis job might feed its output into another job that runs on
the internal cloud.
Hybrid Cloud Challenges

|

5


Test environments are also frequently split between clouds, with
portions of the environment being placed internally and other por‐
tions in the public cloud. When the projects that use the test envi‐
ronments go live, cleaning up and decommissioning those
environments is a manual process.
Tracking how and where workloads reside is a serious and necessary
task because real costs can accrue if resources are not decommis‐
sioned from public clouds in a timely manner. It is also inefficient to
leave unneeded environments running within the private cloud.
Successful hybrid cloud architectures use a control plane that helps
facilitate migration of workloads between the private and public
clouds. The control plane abstracts resources into a single, unified
interface from which workloads can be seamlessly managed.
A single control plane helps to avoid fragmentation because work‐

loads and environments can be tracked through a single interface.
Commissioning and decommissioning are also easier when utilizing
a single control plane for management of the hybrid cloud.

How Can I Use a Hybrid Cloud?
From being able to migrate between clouds to supporting local data
regulations, hybrid cloud enables the advanced level of management
of computing resources that is necessary to gain competitive advan‐
tage in today’s business climate. However, simple migration isn’t
enough. It takes the ability to seamlessly manage and move work‐
loads and jobs between clouds that provides the next level.

Temporary Offload of Certain Services
Data Extract, Transform, and Load (ETL) processes can be quite
resource-intensive and thus overwhelm the capabilities of an inter‐
nal cloud and datacenter. Machine learning and other analysis tasks
can also be moved based on lowest cost and availability.
A key requirement is to be able to seamlessly move these and other
resource-intensive services to the public cloud and between the pub‐
lic and private clouds. Therefore, even a single control plane is not
sufficient for meeting the requirements. Instead, the single control
plane with additional management capabilities is needed to move
workloads between clouds.

6

|

Chapter 1: Understanding the Hybrid Cloud

Supporting Local Data Regulations
There are increasing legal and regulatory requirements for data stor‐
age and processing. For example, European data protection laws
require protections for personal information that are significantly
different from regulations in the United States and other regions. In
the United States, medical privacy laws such as HIPAA and others
create strict requirements on storage and use of medical data.
Utilizing a hybrid cloud is a step in the right direction because you
can use public cloud providers in specific regions to support the reg‐
ulations for processing and storage. The work to move data and
environments is too often manual and error prone, though. There‐
fore, a layer of abstraction to be able to integrate public and private
clouds would make these migrations easier.

Backup and Warm Recovery
There are multiple levels and types of backups that apply to tradi‐
tional datacenters, to private clouds, and to public clouds. For exam‐
ple, there are Storage Area Network (SAN) backups that are created
at the logical unit number (LUN) level, others at the disk or block
level, some at the data level, and others at the application level.
The requirements of a given application or business requirements
for providing backup sometimes determine the type of backup that
you need to use. For instance, data might be replicated in real-time
between datacenters or between the private and public cloud in
order to meet reliability and uptime requirements. Data might need
to be backed up to an offsite location or multiple locations in order
to meet requirements for durability and disaster recovery.

Conclusion

The hybrid cloud is the connection between internally managed
resources within an organization’s own datacenter or datacenters
and externally managed resources purchased from cloud providers
such as Amazon, Google, and Microsoft. Managing these resources
efficiently is the key challenge for many organizations. Currently,
the private and public clouds are frequently managed as separate
entities. This leads to inefficiencies in resource utilization and also
leads to higher costs overall when the least expensive service is not
chosen for a given workload.
Conclusion

|

7


There are several challenges for an organization that wants to use
the hybrid cloud efficiently. Moving workloads between the private
and public clouds is frequently a manual task. As such, migrations
are error-prone and can lead to downtime. Migrations are not usu‐
ally seamless to end users and therefore are not performed as often
as they could be.
Integrating resources between private and public clouds is also a
challenge for many organizations. Resource types and the underly‐
ing management thereof are so different from each other that it’s
impossible to manage them as a single set of resources to be used
when needed. This again leads to inefficiencies and management
difficulties for system administrators.
Obtaining support when workloads are split between private and
public clouds provides yet another challenge to organizations that

use both types of resources. Vendors used within a private cloud are
not necessarily those that are used in the public cloud, leading to
finger-pointing between vendors. With that in mind, creating an
integrated workload is avoided when possible.
Integrated workloads are also avoided because of fragmentation.
Parts of previous jobs or environments can be orphaned within the
private or public cloud. These orphaned environments are difficult
to find, and decommissioning them is difficult to do without know‐
ing whether the environment is still in use.
That said, the hybrid cloud offers advantages over separate environ‐
ments. Being able to use resources efficiently is a primary advantage.
Regulatory compliance provides a strong argument for utilizing a
hybrid cloud, as well. Finally, providing efficient backup and warm
recovery can mean significant cost savings for organizations that use
both private and public clouds.

8

|

Chapter 1: Understanding the Hybrid Cloud


CHAPTER 2

Hybrid Cloud Architecture

In Chapter 1, we discussed some of the vocabulary associated with
the hybrid cloud. We also looked at some uses for the hybrid
approach and why the hybrid cloud approach is important. The

basic components of hybrid cloud include public cloud and private
cloud components. From a private cloud perspective, the resources
of the datacenter are the primary component, including internal
infrastructure. On the other hand, public cloud is one or more cloud
providers like Amazon Web Services (AWS), Google Cloud Platform
(GCP), and Microsoft Azure.
This chapter adds more depth to the discussion from Chapter 1 by
looking at the components involved in a hybrid cloud and how
those components facilitate an advantage for companies using
hybrid cloud technology. Creating a hybrid cloud architecture con‐
cludes this chapter.

Understanding the Components of the Hybrid
Cloud
This section examines cloud components, both internal and exter‐
nal, showing similarities between the two, along with how those
components might differ.

9


Internal Components
A private cloud consists of the following basic building blocks:
• Compute
• Memory
• Storage
• Network
However, management of computing-related resources was not
always done as aggregate resources like a cloud. This section pro‐
vides some perspective on how the technology has evolved to cloudbased resource allocation and usage.

A short history of private clouds
Prior to resources being managed as a cloud, these components
appeared in the form of hardware servers, with each server contain‐
ing its own preset amount of each resource, as illustrated in
Figure 2-1.

Figure 2-1. A traditional server, with fixed resources allocated to it.
As datacenter needs matured, virtualization became more robust
and enabled management of resources from another layer of
abstraction, pooling memory, processing, storage, and network.
However, as Figure 2-2 demonstrates, the components were still
limited to single server architectures, with the possible addition of
external Storage Area Network (SAN) storage.

10

|

Chapter 2: Hybrid Cloud Architecture


Figure 2-2. Managing virtualized resources into virtual servers.
Importantly, even with virtualization, resources could still remain
idle, with compute resources allocated to a virtual server and not
being used efficiently. As virtualization technologies matured,
dynamic allocation of many resources became available, but the
underlying technology itself was not as self-service oriented as
today’s environment demands.
Virtualization led to private clouds, in which resources are managed

in aggregate at a higher level. Private cloud architectures accomplish
this by adding another layer of abstraction, with memory and pro‐
cessing from multiple physical hardware servers combined into
larger pools that can be managed and allocated on-demand based on
business needs. The on-demand nature of the private cloud facili‐
tates self-service and automation.
From the internal perspective, a cloud is an aggregation of storage
and networking along with bare-metal components such as RAM
and processing (CPU and Graphics Processor Unit [GPU]). On top
of these hardware components sits a control plane. The control plane
is used to allocate and manage the hardware elements below it, as
shown in Figure 2-3.

Understanding the Components of the Hybrid Cloud

|

11


Figure 2-3. Components in a private cloud.
Virtualization led to containerization with software like Docker, in
which applications are managed as a single entity. Containerization
enables portable deployment, without needing to worry about the
configuration of the underlying operating system or infrastructure.

Creating a private cloud
Deployment of a private cloud requires a large outlay of funds to get
started. The initial capital expenditure for hardware is one compo‐
nent and is sunk as soon as the datacenter is operational. Further,

the monthly cost to maintain a datacenter does not vary much based
on usage. In other words, whether the datacenter is being utilized at
only 5% or is being utilized at 100%, the costs are roughly the same.
Beyond the hardware and infrastructure-related expenses, controlplane software needs to be deployed in order to manage the hard‐
ware resources. Because this software provides the basis for
management of the private cloud, stability and maturity are impor‐
tant. Being able to obtain timely and expert support when necessary
is important to organizations, as well.

Disaster recovery with private cloud
Disaster recovery and providing for multiple region-separated and
logically separated datacenters are consistent challenges with private
clouds. The cost to create, manage, and maintain physically geodispersed datacenters is prohibitive for many organizations. Not
only is duplicating the hardware costly, but maintenance of hard‐
ware and network means hiring staff in those locations to perform
the work.

12

|

Chapter 2: Hybrid Cloud Architecture


However, business needs frequently dictate the ability to perform
recovery and this translates into redundancy and replication across
regional datacenters or private clouds.

Cost recovery
Some organizations perform a certain level of chargeback to the

business area based on usage for private cloud components. This
mirrors the charges incurred when using a public cloud provider
and helps to offset costs associated with various business units’
needs. For example, if a business unit requires a large amount of
data storage and redundancy across datacenters, the costs charged
for those services would be higher than those charged for a simple
development environment deployed in the internal cloud.
Although some organizations do not perform direct chargeback to
the business unit, the resource usage and utilization can still be
tracked in a much more direct way when compared to virtualization
technologies.

Self-service
Private cloud deployments vary with regard to the amount of selfservice that project teams are able to perform with the cloud.
Deployments might be accomplished by only IT staff such as system
administrators. This ensures a level of control over the environment
and the resources in a managed way.
A DevOps team might also control access to deployment within the
cloud, helping to guide both developers and operations staff as to
usage and resource needs. DevOps teams lead the way in automat‐
ing processes including allocation of cloud resources during devel‐
opment, testing, and production promote.
Finally, developers can also deploy environments into the private
cloud, thus providing true self-service for the cloud resources.
Deployments can be template-based and limits are typically placed
on the amount and types of resources that can be deployed by a
developer without additional assistance from a member of the
DevOps or IT team.

Understanding the Components of the Hybrid Cloud

|

13


External Components
In many ways, the architecture of private clouds mirrors that of
public clouds such as Amazon, Google, and Microsoft. For all three
companies, compute, memory, and storage are managed as separate
entities, and network is handled externally.

Creating a public cloud
Getting started with a public cloud provider means manually allo‐
cating and managing resources on an as-needed basis, commission‐
ing and decommissioning environments when required. This is
usually done through the cloud provider’s web interface and is labor
intensive. Day-to-day management is accomplished through a com‐
bination of web interface and application programming interfaces
(APIs).
Figure 2-4 depicts the typical view of a public cloud provider.

Figure 2-4. Resources in the public cloud.
Of course, there are ways to control costs with public cloud provid‐
ers, such as paying an up-front fee for guaranteed resources. But
doing so defeats the purpose of paying on-demand, and it becomes
clear that an investment into internally based resources makes
financial sense in those cases.

Disaster recovery with public clouds

Deployment of resources and environments across multiple regions
is also much easier with public cloud providers. There is no need to
invest in hardware or geographically dispersed staff to maintain the
regional locations. This significantly reduces initial costs to get
started with public cloud providers and is one reason why many
organizations deploy only into public clouds.

14

|

Chapter 2: Hybrid Cloud Architecture


Cost recovery
As an organization matures and grows, the on-demand nature of
public cloud resources means that costs begin to increase, as well.
All resources are billed on an as-used basis, usually by the minute.
Controlling costs for compute and memory resources is feasible
because those resources can be added and removed easily. However,
storage costs accrue and become larger and larger over time because
of the nature of storage itself.
Storage grows over time because of direct data collection. As trans‐
actions are moved from online data collection sources like NoSQL
databases and into relational data stores or other data storage, data
can be filtered and de-duplicated. Even with de-duplication and
other cleansing efforts, storage requirements will still continue to
grow. This adds up to increasing costs over time unless that data
storage can be moved to less-costly means for long-term storage.

Self-service
As the organization’s use of the public cloud matures, more and
more automation is added to the process. At first, templates might
be used for specific applications or for environments. Over time,
templates turn into additional automated use to add and remove
environments when needed.
DevOps and scripting practices have further enhanced the automa‐
tion of cloud environments, notably for external providers for which
APIs are used to create the environments as part of a deployment.
The automation usually also decommissions environments and
resources when they are no longer needed. This is the case for test‐
ing environments through the software development life cycle. Not
only do developers benefit from dynamically allocated testing envi‐
ronments, but automated testing and the quality assurance team
also benefits.

Application platforms
Many public cloud providers also feature application platforms that
go well beyond simple compute-type or raw resources. These appli‐
cation platforms, like AWS Elastic Beanstalk, provide a managed
environment from which an application can be launched without
needing to manage the underlying operating system. Orchestration

Understanding the Components of the Hybrid Cloud

|

15

with these application platforms is more complex than managing
the external cloud as a resource pool.
When application platforms are used, backward and crosscompatibility between the private and public cloud is more difficult.
While there is typically transparency or at least visibility into the
environment of the application platform, recreating that environ‐
ment internally is again a manual process.

Architecting the Hybrid Cloud
Thus far, the components of both private clouds and public clouds
have been discussed. Both clouds are similar insofar as they both
manage resources in aggregate and give some of the same benefits to
organizations that deploy one or both.
A hybrid cloud is the connection between the private and public
clouds. However, it’s not just a private network connection between
the two that makes the difference. A true hybrid cloud has manage‐
ment of both private and public clouds as one single unified
resource pool, as illustrated in Figure 2-5.

Figure 2-5. A hybrid cloud brings together private and public clouds.
It is the management and control layer of a hybrid cloud that brings
value to an organization. With a true hybrid cloud, an organization
can move workloads between the private and public clouds based on
spot pricing and resource utilization. For example, if it is less expen‐
sive to process a job internally and there is capacity available, the job
is moved internally. If capacity doesn’t exist internally or if it is less
expensive to run a workload externally, the job is moved to an exter‐
nal provider.

Management Layers
Work within the cloud is sometimes split between short-running

batch-style jobs and long-running services. Containers are also used
16

|

Chapter 2: Hybrid Cloud Architecture


in order to better and more portably manage jobs and services.
These elements are executed within the software layer of a hybrid
cloud along with message queuing monitoring and the tools used
for DevOps and Continuous Integration (CI).
The software used for jobs and services, along with the other items
in the software layer, are managed by a platform layer. A platform
layer provides abstraction and orchestration for the software layer.
Things like networking and storage are found on the platform layer
along with management for clusters and containers and security.
The hybrid cloud is then managed as nodes with an agent running
on each node for management and monitoring. Workloads are
routed to the appropriate node, whether in the private or public
cloud.
Logging and metrics are also contained in the platform layer to pro‐
vide a centralized location for gathering and processing of this infor‐
mation.
A platform layer is dependent on its underlying infrastructure layer.
At the infrastructure layer in a hybrid cloud are the cloud compo‐
nents themselves. This includes private and public cloud compo‐
nents and generally any suitable infrastructure components even if
not part of a formal cloud.
The platform layer enables management of software as packages and

management of containers within a repository or registry. The pack‐
ages and containers can then be installed and deployed within the
private or public clouds or a combination of both, depending on the
needs of the application. Ideally, package management would be as
seamless and automated as possible, and not require the administra‐
tor to manually repeat steps to install the package. This level of
orchestration is enabled because of the abstraction of the infrastruc‐
ture.
Automation is facilitated through command-line and API interac‐
tions, both of which enable programmatic and scripted access into
the architecture.

Conclusion
The ability to create a private cloud has evolved from simple, singleserver deployments, through virtualization, both static and
dynamic, to management of resources in pool and dynamic alloca‐
Conclusion

|

17


tion of those resources on an as-needed basis. Private clouds can be
costly to deploy, but the investment is mitigated by a more efficient
use of the deployed resources.
Disaster recovery and high availability are challenging for private
cloud deployments because providing both typically means deploy‐
ment of redundant resources in multiple locations. Those resources
might be unused and therefore idle throughout an application’s life
cycle.

As use of the private cloud matures within an organization, more
and more automation and self-service processes are added. Automa‐
tion comes from DevOps practices and Agile development method‐
ologies, where environments are deployed as needed and only when
needed. This is the case for testing environments in which code
builds can be automated and an environment deployed for testing
without any manual intervention.
Getting started with a public cloud is usually much less expensive
than creating a private cloud. The initial outlay does not exist for
external cloud deployments beyond any automation or other
orchestration deployed within an organization. Resources can also
be used in a more efficient manner because disaster recovery is eas‐
ier. Cloud providers enable deployment into multiple regions, thus
alleviating the need for an investment into hardware at multiple
locations.

18

|

Chapter 2: Hybrid Cloud Architecture


CHAPTER 3

Choosing a Hybrid Cloud Solution

Connecting the private and public clouds is where many organiza‐
tions stop. The benefits of going further are obvious, but the added
complexity can make creating a true hybrid cloud seem too difficult.

Although there are solutions available, it can be difficult to find a
robust solution offering the necessary level of support and advanced
capabilities. This chapter helps with the decision with respect to
choosing a hybrid cloud solution that can make deployment of a
hybrid cloud much easier.

Examining Capabilities
Several capabilities are necessary in order to provide the level of ser‐
vice necessary in today’s modern organization. When looking at
cloud-specific capabilities, these are key ingredients:
• Extensive workload support
• Advanced resource pooling
• Application-centric automation
• Connectivity across clouds
• Zero-downtime migrations

Extensive Workload Support
Cloud workloads consist of long-running services and short-lived
jobs. Although both private and public clouds support both types,
19