205 lines
10 KiB
XML
205 lines
10 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<!DOCTYPE section [
|
|
<!ENTITY % openstack SYSTEM "../../common/entities/openstack.ent">
|
|
%openstack;
|
|
]>
|
|
<section xmlns="http://docbook.org/ns/docbook"
|
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
|
xmlns:xlink="http://www.w3.org/1999/xlink"
|
|
version="5.0"
|
|
xml:id="methodology">
|
|
<title>Methodology</title>
|
|
<para>The best way to design your cloud architecture is through creating and
|
|
testing use cases. Planning for applications that support thousands of
|
|
sessions per second, variable workloads, and complex, changing data,
|
|
requires you to identify the key meters. Identifying these key meters,
|
|
such as number of concurrent transactions per second, and size of
|
|
database, makes it possible to build a method for testing your assumptions.</para>
|
|
<para>Use a functional user scenario to develop test cases, and to measure
|
|
overall project trajectory.</para>
|
|
<note>
|
|
<para>If you do not want to use an application to develop user
|
|
requirements automatically, you need to create requirements to build
|
|
test harnesses and develop usable meters.</para>
|
|
</note>
|
|
<para>Establishing these meters allows you to respond to changes quickly without
|
|
having to set exact requirements in advance.
|
|
This creates ways to configure the system, rather than redesigning
|
|
it every time there is a requirements change.</para>
|
|
<important>
|
|
<para>It is important to limit scope creep. Ensure you address tool limitations,
|
|
but do not recreate the entire suite of tools. Work
|
|
with technical product owners to establish critical features that are needed
|
|
for a successful cloud deployment.</para>
|
|
</important>
|
|
|
|
<section xml:id="application-cloud-readiness-methods">
|
|
<title>Application cloud readiness</title>
|
|
<para>The cloud does more than host virtual machines and their applications.
|
|
This <emphasis>lift and shift</emphasis>
|
|
approach works in certain situations, but there is a fundamental
|
|
difference between clouds and traditional bare-metal-based
|
|
environments, or even traditional virtualized environments.</para>
|
|
<para>In traditional environments, with traditional enterprise
|
|
applications, the applications and the servers that run on them are
|
|
<emphasis>pets</emphasis>.
|
|
They are lovingly crafted and cared for, the servers have
|
|
names like Gandalf or Tardis, and if they get sick someone nurses
|
|
them back to health. All of this is designed so that the application
|
|
does not experience an outage.</para>
|
|
<para>In cloud environments, servers are more like
|
|
cattle. There are thousands of them, they get names like NY-1138-Q,
|
|
and if they get sick, they get put down and a sysadmin installs
|
|
another one. Traditional applications that are unprepared for this
|
|
kind of environment may suffer outages, loss of data, or
|
|
complete failure.</para>
|
|
<para>There are other reasons to design applications with the cloud in mind.
|
|
Some are defensive, such as the fact that because applications cannot be
|
|
certain of exactly where or on what hardware they will be launched,
|
|
they need to be flexible, or at least adaptable. Others are
|
|
proactive. For example, one of the advantages of using the cloud is
|
|
scalability. Applications need to be designed in such a way that
|
|
they can take advantage of these and other opportunities.</para>
|
|
</section>
|
|
|
|
<section xml:id="determining-whether-an-application-is-cloud-ready">
|
|
<title>Determining whether an application is cloud-ready</title>
|
|
<para>There are several factors to take into consideration when looking
|
|
at whether an application is a good fit for the cloud.</para>
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term>Structure</term>
|
|
<listitem>
|
|
<para>
|
|
A large, monolithic, single-tiered, legacy
|
|
application typically is not a good fit for the
|
|
cloud. Efficiencies are gained when load can be
|
|
spread over several instances, so that a failure
|
|
in one part of the system can be mitigated without
|
|
affecting other parts of the system, or so that
|
|
scaling can take place where the app needs
|
|
it.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
<varlistentry>
|
|
<term>Dependencies</term>
|
|
<listitem>
|
|
<para>
|
|
Applications that depend on specific
|
|
hardware, such as a particular chip set or an
|
|
external device such as a fingerprint
|
|
reader, might not be a good fit for the
|
|
cloud, unless those dependencies are specifically
|
|
addressed. Similarly, if an application depends on
|
|
an operating system or set of libraries that
|
|
cannot be used in the cloud, or cannot be
|
|
virtualized, that is a problem.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
<varlistentry>
|
|
<term>Connectivity</term>
|
|
<listitem>
|
|
<para>
|
|
Self-contained applications, or those that depend
|
|
on resources that are not reachable by the cloud
|
|
in question, will not run. In some situations,
|
|
you can work around these issues with custom network
|
|
setup, but how well this works depends on the
|
|
chosen cloud environment.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
<varlistentry>
|
|
<term>Durability and resilience</term>
|
|
<listitem>
|
|
<para>
|
|
Despite the existence of SLAs, things break:
|
|
servers go down, network connections are
|
|
disrupted, or too many tenants on a server make a
|
|
server unusable. An application must be sturdy
|
|
enough to contend with these issues.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
</section>
|
|
|
|
<section xml:id="designing-for-the-cloud">
|
|
<title>Designing for the cloud</title>
|
|
<para>Here are some guidelines to keep in mind when designing an
|
|
application for the cloud:</para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Be a pessimist: Assume everything fails and design
|
|
backwards.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Put your eggs in multiple baskets: Leverage multiple
|
|
providers, geographic regions and availability zones to
|
|
accommodate for local availability issues. Design for
|
|
portability.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Think efficiency: Inefficient designs will not scale.
|
|
Efficient designs become cheaper as they scale. Kill off
|
|
unneeded components or capacity.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Be paranoid: Design for defense in depth and zero
|
|
tolerance by building in security at every level and between
|
|
every component. Trust no one.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>But not too paranoid: Not every application needs the
|
|
platinum solution. Architect for different SLA's, service
|
|
tiers, and security levels.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Manage the data: Data is usually the most inflexible and
|
|
complex area of a cloud and cloud integration architecture.
|
|
Do not short change the effort in analyzing and addressing
|
|
data needs.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Hands off: Leverage automation to increase consistency and
|
|
quality and reduce response times.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Divide and conquer: Pursue partitioning and
|
|
parallel layering wherever possible. Make components as small
|
|
and portable as possible. Use load balancing between layers.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Think elasticity: Increasing resources should result in a
|
|
proportional increase in performance and scalability.
|
|
Decreasing resources should have the opposite effect.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Be dynamic: Enable dynamic configuration changes such as
|
|
auto scaling, failure recovery and resource discovery to
|
|
adapt to changing environments, faults, and workload volumes.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Stay close: Reduce latency by moving highly interactive
|
|
components and data near each other.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Keep it loose: Loose coupling, service interfaces,
|
|
separation of concerns, abstraction, and well defined API's
|
|
deliver flexibility.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Be cost aware: Autoscaling, data transmission, virtual
|
|
software licenses, reserved instances, and similar costs can rapidly
|
|
increase monthly usage charges. Monitor usage closely.
|
|
</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</section>
|
|
</section>
|