Removal of passive voice from chap 7, arch guide
Removal of passive voice from section_user_requirements Change-Id: Ie28bcfc7955d90c39ae14463328690840c022d2f Closes-bug: #1429696
This commit is contained in:
Alexandra Settle
asettle
parent
186bcaf23c
commit
4ec2cd2818
@ -6,13 +6,11 @@
|
|||||||
xml:id="user-requirements-hybrid">
|
xml:id="user-requirements-hybrid">
|
||||||
<?dbhtml stop-chunking?>
|
<?dbhtml stop-chunking?>
|
||||||
<title>User requirements</title>
|
<title>User requirements</title>
|
||||||
<para>Hybrid cloud architectures introduce additional
|
<para>Hybrid cloud architectures are complex, especially those
|
||||||
complexities, particularly those that use heterogeneous cloud
|
that use heterogeneous cloud platforms. It is important to
|
||||||
platforms. As a result, it is important to make sure that
|
make sure that design choices match requirements in such a way that
|
||||||
design choices match requirements in such a way that the
|
the benefits outweigh the inherent additional complexity and risks.</para>
|
||||||
benefits outweigh the inherent additional complexity and
|
<para>Business considerations when designing a hybrid
|
||||||
risks.</para>
|
|
||||||
<para>Business considerations to make when designing a hybrid
|
|
||||||
cloud deployment include:</para>
|
cloud deployment include:</para>
|
||||||
<variablelist>
|
<variablelist>
|
||||||
<varlistentry>
|
<varlistentry>
|
||||||
@ -34,50 +32,43 @@
|
|||||||
<listitem>
|
<listitem>
|
||||||
<para>Revenue opportunities vary
|
<para>Revenue opportunities vary
|
||||||
greatly based on the intent and use case of the cloud.
|
greatly based on the intent and use case of the cloud.
|
||||||
If it is being built as a commercial customer-facing
|
As a commercial, customer-facing product, you must consider
|
||||||
product, consider the drivers for building it over
|
whether building over multiple platforms makes the
|
||||||
multiple platforms and whether the use of multiple
|
design more attractive to customers.</para>
|
||||||
platforms make the design more attractive to target
|
|
||||||
customers, thus enhancing the revenue
|
|
||||||
opportunity.</para>
|
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
<varlistentry>
|
<varlistentry>
|
||||||
<term>Time to market</term>
|
<term>Time-to-market</term>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>One of the most common reasons to
|
<para>One of the most common reasons to
|
||||||
use cloud platforms is to speed the time to market of
|
use cloud platforms is to improve the time-to-market of
|
||||||
a new product or application. A business requirement
|
a new product or application. For example, using multiple
|
||||||
to use multiple cloud platforms may be because there
|
cloud platforms is viable because there is an existing
|
||||||
is an existing investment in several applications and
|
investment in several applications. It is faster to tie
|
||||||
it is faster to tie them together rather than
|
the investments together rather than migrate the
|
||||||
migrating components and refactoring to a single
|
components and refactoring them to a single platform.</para>
|
||||||
platform.</para>
|
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
<varlistentry>
|
<varlistentry>
|
||||||
<term>Business or technical diversity</term>
|
<term>Business or technical diversity</term>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>Organizations
|
<para>Organizations leveraging cloud-based services can
|
||||||
already leveraging cloud-based services may wish to
|
|
||||||
embrace business diversity and utilize a hybrid cloud
|
embrace business diversity and utilize a hybrid cloud
|
||||||
design to spread their workloads across multiple cloud
|
design to spread their workloads across multiple cloud
|
||||||
providers so that no application is hosted in a single
|
providers. This ensures that no single cloud provider is
|
||||||
cloud provider.</para>
|
the sole host for an application.</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
<varlistentry>
|
<varlistentry>
|
||||||
<term>Application momentum</term>
|
<term>Application momentum</term>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>A business with existing
|
<para>Businesses with existing applications may find that it is
|
||||||
applications that are already in production on
|
more cost effective to integrate applications on multiple
|
||||||
multiple cloud environments may find that it is more
|
cloud platforms than migrating them to a single platform.</para>
|
||||||
cost effective to integrate the applications on
|
|
||||||
multiple cloud platforms rather than migrate them to a
|
|
||||||
single platform.</para>
|
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
</variablelist>
|
</variablelist>
|
||||||
|
|
||||||
<section xml:id="legal-requirements-hybrid">
|
<section xml:id="legal-requirements-hybrid">
|
||||||
<title>Legal requirements</title>
|
<title>Legal requirements</title>
|
||||||
<para>Many jurisdictions have legislative and regulatory
|
<para>Many jurisdictions have legislative and regulatory
|
||||||
@ -107,127 +98,134 @@
|
|||||||
</itemizedlist>
|
</itemizedlist>
|
||||||
<para>Examples of such legal frameworks include the data
|
<para>Examples of such legal frameworks include the data
|
||||||
protection framework of the European Union (<link
|
protection framework of the European Union (<link
|
||||||
xlink:href="http://ec.europa.eu/justice/data-protection/">http://ec.europa.eu/justice/data-protection/</link>)
|
xlink:href="http://ec.europa.eu/justice/data-protection/">Reform of data protection legislation</link>)
|
||||||
and the requirements of the Financial Industry Regulatory
|
and the requirements of the Financial Industry Regulatory
|
||||||
Authority (<link
|
Authority (<link
|
||||||
xlink:href="http://www.finra.org/Industry/Regulation/FINRARules/">http://www.finra.org/Industry/Regulation/FINRARules/</link>)
|
xlink:href="http://www.finra.org/Industry/Regulation/FINRARules/">FINRA Rules</link>)
|
||||||
in the United States. Consult a local regulatory body for more
|
in the United States. Consult a local regulatory body for more
|
||||||
information.</para>
|
information.</para>
|
||||||
</section>
|
</section>
|
||||||
|
|
||||||
<section xml:id="workload-considerations">
|
<section xml:id="workload-considerations">
|
||||||
<title>Workload considerations</title>
|
<title>Workload considerations</title>
|
||||||
<para>Defining what the word "workload" means in the context of a
|
<para>A workload can be a single application or a suite of applications that
|
||||||
hybrid cloud environment is important. Workload can be defined
|
work together. It can also be a duplicate set of applications that need to
|
||||||
as the intended way the systems will be utilized, which is
|
|
||||||
often referred to as a "use case". A workload can be a single
|
|
||||||
application or a suite of applications that work in concert.
|
|
||||||
It can also be a duplicate set of applications that need to
|
|
||||||
run on multiple cloud environments. In a hybrid cloud
|
run on multiple cloud environments. In a hybrid cloud
|
||||||
deployment, the same workload will often need to function
|
deployment, the same workload often needs to function
|
||||||
equally well on radically different public and private cloud
|
equally well on radically different public and private cloud
|
||||||
environments. The architecture needs to address these
|
environments. The architecture needs to address these
|
||||||
potential conflicts, complexity, and platform
|
potential conflicts, complexity, and platform
|
||||||
incompatibilities.</para>
|
incompatibilities. Some possible use cases for a hybrid cloud architecture
|
||||||
<para>Some possible use cases for a hybrid cloud architecture
|
|
||||||
include:</para>
|
include:</para>
|
||||||
<itemizedlist>
|
<variablelist>
|
||||||
|
<varlistentry>
|
||||||
|
<term>Dynamic resource expansion or <literal>"bursting"</literal></term>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>Dynamic resource expansion or "bursting": Another
|
<para>An application that requires additional resources is another
|
||||||
common reason to use a multiple cloud architecture is
|
common reason you might use a multiple cloud architecture.
|
||||||
a "bursty" application that needs additional resources
|
For example, a retailer needs additional resources
|
||||||
at times. An example of this case could be a retailer
|
during the holiday retail season, but does not want to build expensive
|
||||||
that needs additional resources during the holiday
|
cloud resources to meet the peak demand. The user might
|
||||||
selling season, but does not want to build expensive
|
|
||||||
cloud resources to meet the peak demand. They might
|
|
||||||
have an OpenStack private cloud but want to burst to
|
have an OpenStack private cloud but want to burst to
|
||||||
AWS or some other public cloud for these peak load
|
AWS or some other public cloud for these peak load
|
||||||
periods. These bursts could be for long or short
|
periods. These bursts could be for long or short
|
||||||
cycles ranging from hourly, monthly or yearly.</para>
|
cycles ranging from hourly to yearly.</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
</varlistentry>
|
||||||
|
<varlistentry>
|
||||||
|
<term>Disaster recovery-business continuity</term>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>Disaster recovery-business continuity: The cheaper
|
<para>The cheaper storage and instance management makes a good case for
|
||||||
storage and instance management makes a good case for
|
using the cloud as a secondary site. Using OpenStack public
|
||||||
using the cloud as a secondary site. The public cloud
|
or private cloud in combination with the public cloud for
|
||||||
is already heavily used for these purposes in
|
these purposes is popular.</para>
|
||||||
combination with an OpenStack public or private
|
|
||||||
cloud.</para>
|
|
||||||
</listitem>
|
</listitem>
|
||||||
|
</varlistentry>
|
||||||
|
<varlistentry>
|
||||||
|
<term>Federated hypervisor-instance management</term>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>Federated hypervisor-instance management: Adding
|
<para>Adding self-service, charge back and transparent delivery of
|
||||||
self-service, charge back and transparent delivery of
|
|
||||||
the right resources from a federated pool can be cost
|
the right resources from a federated pool can be cost
|
||||||
effective. In a hybrid cloud environment, this is a
|
effective. In a hybrid cloud environment, this is a
|
||||||
particularly important consideration. Look for a cloud
|
particularly important consideration. Look for a cloud
|
||||||
that provides cross-platform hypervisor support and
|
that provides cross-platform hypervisor support and
|
||||||
robust instance management tools.</para>
|
robust instance management tools.</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
</varlistentry>
|
||||||
|
<varlistentry>
|
||||||
|
<term>Application portfolio integration</term>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>Application portfolio integration: An enterprise
|
<para>An enterprise cloud delivers efficient application portfolio management
|
||||||
cloud delivers better application portfolio management
|
and deployments by leveraging
|
||||||
and more efficient deployment by leveraging
|
|
||||||
self-service features and rules for deployments based
|
self-service features and rules for deployments based
|
||||||
on types of use. A common driver for building hybrid
|
on types of use. Stitching together multiple existing
|
||||||
cloud architecture is to stitch together multiple
|
cloud environments that are already in production or development
|
||||||
existing cloud environments that are already in
|
is a common driver when building hybrid cloud architectures.</para>
|
||||||
production or development.<!-- In the interest of time to
|
|
||||||
market, the requirements may be to maintain the
|
|
||||||
multiple clouds and just integrate the pieces
|
|
||||||
together, not rationalize to one cloud environment, but
|
|
||||||
instead to --></para>
|
|
||||||
</listitem>
|
</listitem>
|
||||||
|
</varlistentry>
|
||||||
|
<varlistentry>
|
||||||
|
<term>Migration scenarios</term>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>Migration scenarios: A common reason to create a
|
<para>A common reason to create a
|
||||||
hybrid cloud architecture is to allow the migration of
|
hybrid cloud architecture is to allow the migration of
|
||||||
applications between different clouds. This may be
|
applications between different clouds. Permanent migration of the
|
||||||
because the application will be migrated permanently
|
application to a new platform is one reason, or another might be
|
||||||
to a new platform, or it might be because the
|
because the application requires support on multiple
|
||||||
application needs to be supported on multiple
|
platforms.</para>
|
||||||
platforms going forward.</para>
|
|
||||||
</listitem>
|
</listitem>
|
||||||
|
</varlistentry>
|
||||||
|
<varlistentry>
|
||||||
|
<term>High availability</term>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>High availability: Another important reason for
|
<para>Another important reason for
|
||||||
wanting a multiple cloud architecture is to address
|
wanting a multiple cloud architecture is to address
|
||||||
the needs for high availability. By using a
|
the needs for high availability. Using a
|
||||||
combination of multiple locations and platforms, a
|
combination of multiple locations and platforms, a
|
||||||
design can achieve a level of availability that is not
|
design can achieve a level of availability that is not
|
||||||
possible with a single platform. This approach does
|
possible with a single platform. This approach does
|
||||||
add a significant amount of complexity.</para>
|
add a significant amount of complexity.</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</itemizedlist>
|
</varlistentry>
|
||||||
<para>In addition to thinking about how the workload will work on
|
</variablelist>
|
||||||
|
<para>In addition to thinking about how the workload works on
|
||||||
a single cloud, the design must accommodate the added
|
a single cloud, the design must accommodate the added
|
||||||
complexity of needing the workload to run on multiple cloud
|
complexity of needing the workload to run on multiple cloud
|
||||||
platforms. The complexity of transferring workloads across
|
platforms. We recommend exploring the complexity of transferring
|
||||||
clouds needs to be explored at the application, instance,
|
workloads across clouds at the application, instance, cloud platform,
|
||||||
cloud platform, hypervisor, and network levels.</para></section>
|
hypervisor, and network levels.</para>
|
||||||
|
</section>
|
||||||
|
|
||||||
<section xml:id="tools-considerations-hybrid">
|
<section xml:id="tools-considerations-hybrid">
|
||||||
<title>Tools considerations</title>
|
<title>Tools considerations</title>
|
||||||
<para>When working with designs spanning multiple clouds, the
|
<para>When working with designs spanning multiple clouds, the
|
||||||
design must incorporate tools to facilitate working across
|
design must incorporate tools to facilitate working across
|
||||||
those multiple clouds. Some of the user requirements drive the
|
those multiple clouds. Some of the user requirements drive the
|
||||||
need for tools that will do the following functions:</para>
|
need for tools that perform the following functions:</para>
|
||||||
<itemizedlist>
|
<variablelist>
|
||||||
|
<varlistentry>
|
||||||
|
<term>Broker between clouds</term>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>Broker between clouds: Since the multiple cloud
|
<para>Since the multiple cloud
|
||||||
architecture assumes that there will be at least two
|
architecture assumes that there are at least two
|
||||||
different and possibly incompatible platforms that are
|
different and possibly incompatible platforms that are
|
||||||
likely to have different costs, brokering software is
|
likely to have different costs, brokering software
|
||||||
designed to evaluate relative costs between different
|
evaluates relative costs between different
|
||||||
cloud platforms. These solutions are sometimes
|
cloud platforms. The name for these solutions is
|
||||||
referred to as Cloud Management Platforms (CMPs).
|
Cloud Management Platforms (CMPs).
|
||||||
Examples include Rightscale, Gravitent, Scalr,
|
Examples include Rightscale, Gravitent, Scalr,
|
||||||
CloudForms, and ManageIQ. These tools allow the
|
CloudForms, and ManageIQ. These tools allow the
|
||||||
designer to determine the right location for the
|
designer to determine the right location for the
|
||||||
workload based on predetermined criteria.</para>
|
workload based on predetermined criteria.</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
</varlistentry>
|
||||||
|
<varlistentry>
|
||||||
|
<term>Facilitate orchestration across the clouds</term>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>Facilitate orchestration across the clouds: CMPs are
|
<para>CMPs are tools are used to tie everything together. Using
|
||||||
tools are used to tie everything together. Cloud
|
cloud orchestration tools improves the management
|
||||||
orchestration tools are used to improve the management
|
|
||||||
of IT application portfolios as they migrate onto
|
of IT application portfolios as they migrate onto
|
||||||
public, private, and hybrid cloud platforms. These
|
public, private, and hybrid cloud platforms. We recommend
|
||||||
tools are an important consideration. Cloud
|
using cloud orchestration tools for managing a diverse
|
||||||
orchestration tools are used for managing a diverse
|
|
||||||
portfolio of installed systems across multiple cloud
|
portfolio of installed systems across multiple cloud
|
||||||
platforms. The typical enterprise IT application
|
platforms. The typical enterprise IT application
|
||||||
portfolio is still comprised of a few thousand
|
portfolio is still comprised of a few thousand
|
||||||
@ -237,26 +235,28 @@
|
|||||||
(IaaS) and Software-as-a-Service (SaaS) providers and
|
(IaaS) and Software-as-a-Service (SaaS) providers and
|
||||||
offerings.</para>
|
offerings.</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</itemizedlist></section>
|
</varlistentry>
|
||||||
|
</variablelist>
|
||||||
|
</section>
|
||||||
|
|
||||||
<section xml:id="network-considerations-hybrid">
|
<section xml:id="network-considerations-hybrid">
|
||||||
<title>Network considerations</title>
|
<title>Network considerations</title>
|
||||||
<para>The network services functionality is an important factor to
|
<para>The network services functionality is an important factor to
|
||||||
assess when choosing a CMP and cloud provider. Considerations
|
assess when choosing a CMP and cloud provider. Considerations
|
||||||
are functionality, security, scalability and HA. Verification
|
are functionality, security, scalability and HA. Important tasks for
|
||||||
and ongoing testing of the critical features of the cloud
|
the architecture include the verification and ongoing testing of
|
||||||
endpoint used by the architecture are important tasks.</para>
|
critical features for the cloud endpoint.</para>
|
||||||
<itemizedlist>
|
<itemizedlist>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>Once the network functionality framework has been
|
<para>Decide on a network functionality framework and
|
||||||
decided, a minimum functionality test should be
|
design a minimum functionality test. This ensures
|
||||||
designed. This will ensure testing and functionality
|
testing and functionality persists during and after upgrades.</para>
|
||||||
persists during and after upgrades.</para>
|
|
||||||
</listitem>
|
</listitem>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>Scalability across multiple cloud providers may
|
<para>Scalability across multiple cloud providers may
|
||||||
dictate which underlying network framework you will
|
dictate which underlying network framework you
|
||||||
choose in different cloud providers. It is important
|
choose in different cloud providers. It is important
|
||||||
to have the network API functions presented and to
|
to present the network API functions and to
|
||||||
verify that functionality persists across all cloud
|
verify that functionality persists across all cloud
|
||||||
endpoints chosen.</para>
|
endpoints chosen.</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
@ -264,28 +264,27 @@
|
|||||||
<para>High availability implementations vary in
|
<para>High availability implementations vary in
|
||||||
functionality and design. Examples of some common
|
functionality and design. Examples of some common
|
||||||
methods are active-hot-standby, active-passive and
|
methods are active-hot-standby, active-passive and
|
||||||
active-active. High availability and a test framework
|
active-active. Development of high availability and test frameworks
|
||||||
needs to be developed to insure that the functionality
|
is necessary to insure understanding of functionality
|
||||||
and limitations are well understood.</para>
|
and limitations.</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>Security considerations include how data is secured
|
<para>Consider the security of data between
|
||||||
between client and endpoint and any traffic that
|
the client, the endpoint, and any traffic that traverses the
|
||||||
traverses the multiple clouds, from eavesdropping to
|
multiple clouds.</para>
|
||||||
DoS activities.</para>
|
|
||||||
</listitem>
|
</listitem>
|
||||||
</itemizedlist></section>
|
</itemizedlist>
|
||||||
|
</section>
|
||||||
|
|
||||||
<section xml:id="risk-mitigation-management-hybrid">
|
<section xml:id="risk-mitigation-management-hybrid">
|
||||||
<title>Risk mitigation and management
|
<title>Risk mitigation and management considerations</title>
|
||||||
considerations</title>
|
|
||||||
<para>Hybrid cloud architectures introduce additional risk because
|
<para>Hybrid cloud architectures introduce additional risk because
|
||||||
they add additional complexity and potentially conflicting or
|
they add additional complexity and potentially conflicting or
|
||||||
incompatible components or tools. However, they also reduce
|
incompatible components or tools. However, they also reduce
|
||||||
risk by spreading workloads over multiple providers. This
|
risk by spreading workloads over multiple providers. This
|
||||||
means, if one was to go out of business, the organization
|
means, if one was to go out of business, the organization
|
||||||
could remain operational.</para>
|
could remain operational. Heightened risks when using a hybrid
|
||||||
<para>Risks that will be heightened by using a hybrid cloud
|
cloud architecture include:</para>
|
||||||
architecture include:</para>
|
|
||||||
<variablelist>
|
<variablelist>
|
||||||
<varlistentry>
|
<varlistentry>
|
||||||
<term>Provider availability or implementation details</term>
|
<term>Provider availability or implementation details</term>
|
||||||
@ -293,9 +292,9 @@
|
|||||||
<para>
|
<para>
|
||||||
This can range from the company going out of business
|
This can range from the company going out of business
|
||||||
to the company changing how it delivers its services.
|
to the company changing how it delivers its services.
|
||||||
Cloud architectures are inherently designed to be
|
The design of a cloud architecture is meant to be
|
||||||
flexible and changeable; paradoxically, the cloud is
|
flexible and changeable; however, the cloud is
|
||||||
both perceived to be rock solid and ever flexible at
|
perceived to be both rock solid and ever flexible at
|
||||||
the same time.</para>
|
the same time.</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
@ -305,8 +304,8 @@
|
|||||||
<para>Users of hybrid cloud environments
|
<para>Users of hybrid cloud environments
|
||||||
potentially encounter some losses through differences
|
potentially encounter some losses through differences
|
||||||
in service level agreements. A hybrid cloud design
|
in service level agreements. A hybrid cloud design
|
||||||
needs to accommodate the different SLAs provided by
|
needs to accommodate the different SLAs the various clouds
|
||||||
the various clouds involved in the design, and must
|
involved in the design offer, and must
|
||||||
address the actual enforceability of the providers'
|
address the actual enforceability of the providers'
|
||||||
SLAs.</para>
|
SLAs.</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
@ -316,9 +315,9 @@
|
|||||||
<listitem>
|
<listitem>
|
||||||
<para>Securing multiple cloud
|
<para>Securing multiple cloud
|
||||||
environments is more complex than securing a single
|
environments is more complex than securing a single
|
||||||
cloud environment. Concerns need to be addressed at,
|
cloud environment. We recommend addressing concerns at
|
||||||
but not limited to, the application, network, and
|
the application, network, and cloud platform levels.
|
||||||
cloud platform levels. One issue is that different
|
One issue is that different
|
||||||
cloud platforms approach security differently, and a
|
cloud platforms approach security differently, and a
|
||||||
hybrid cloud design must address and compensate for
|
hybrid cloud design must address and compensate for
|
||||||
differences in security approaches. For example, AWS
|
differences in security approaches. For example, AWS
|
||||||
@ -331,13 +330,13 @@
|
|||||||
<listitem>
|
<listitem>
|
||||||
<para>APIs are crucial in a hybrid
|
<para>APIs are crucial in a hybrid
|
||||||
cloud environment. As a consumer of a provider's cloud
|
cloud environment. As a consumer of a provider's cloud
|
||||||
services, an organization will rarely have any control
|
services, an organization rarely has control
|
||||||
over provider changes to APIs. Cloud services that
|
over provider changes to APIs. Cloud services that
|
||||||
might have previously had compatible APIs may no
|
might have previously had compatible APIs may no
|
||||||
longer work. This is particularly a problem with AWS
|
longer work. This is particularly a problem with AWS
|
||||||
and OpenStack AWS-compatible APIs. OpenStack was
|
and OpenStack AWS-compatible APIs. The planning of OpenStack
|
||||||
originally planned to maintain compatibility with
|
included the maintenance of compatibility with changes in AWS
|
||||||
changes in AWS APIs. However, over time, the APIs have
|
APIs. However, over time, the APIs have
|
||||||
become more divergent in functionality. One way to
|
become more divergent in functionality. One way to
|
||||||
address this issue is to focus on using only the most
|
address this issue is to focus on using only the most
|
||||||
common and basic APIs to minimize potential
|
common and basic APIs to minimize potential
|
||||||
|
|||||||
Loading…
Reference in New Issue
Block a user