96dcda0406
To unify the directory structure used inside the DocBook directories all image files should be located inside a directory called 'figures'. Change-Id: I5cbdfdee7c8c9137158607994f91e65a022fc799
284 lines
14 KiB
XML
284 lines
14 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 magic of the cloud is that it can do anything. It is both robust
|
|
and flexible, the best of both worlds. Yes, the cloud is highly flexible
|
|
and it can do almost anything, but to get the most out of a cloud
|
|
investment, it is important to define how the cloud will be used by
|
|
creating and testing use cases. This is the chapter that describes the
|
|
thought process behind how to design a cloud architecture that best
|
|
suits the intended use.</para>
|
|
<mediaobject>
|
|
<imageobject>
|
|
<imagedata contentwidth="4in" fileref="../figures/Methodology.png"/>
|
|
</imageobject>
|
|
</mediaobject>
|
|
<para>The diagram shows at a very abstract level the process for capturing
|
|
requirements and building use cases. Once a set of use cases has been
|
|
defined, it can then be used to design the cloud architecture.</para>
|
|
<para>Use case planning can seem counter-intuitive. After all, it takes
|
|
about five minutes to sign up for a server with Amazon. Amazon does not
|
|
know in advance what any given user is planning on doing with it, right?
|
|
Wrong. Amazon's product management department spends plenty of time
|
|
figuring out exactly what would be attractive to their typical customer
|
|
and honing the service to deliver it. For the enterprise, the planning
|
|
process is no different, but instead of planning for an external paying
|
|
customer, for example, the use could be for internal application
|
|
developers or a web portal. The following is a list of the high level
|
|
objectives that need to be incorporated into the thinking about creating
|
|
a use case.</para>
|
|
<para>Overall business objectives</para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Develop clear definition of business goals and requirements
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Increase project support and engagement with business,
|
|
customers and end users.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
<para>Technology</para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Coordinate the OpenStack architecture across the project and
|
|
leverage OpenStack community efforts more effectively.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Architect for automation as much as possible to speed
|
|
development and deployment.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Use the appropriate tools for the development effort.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Create better and more test metrics and test harnesses to
|
|
support continuous and integrated development, test processes
|
|
and automation.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
<para>Organization</para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Better messaging of management support of team efforts</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Develop better cultural understanding of Open Source, cloud
|
|
architectures, Agile methodologies, continuous development, test
|
|
and integration, overall development concepts in general</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
<para>As an example of how this works, consider a business goal of using the
|
|
cloud for the company's E-commerce website. This goal means planning for
|
|
applications that will support thousands of sessions per second,
|
|
variable workloads, and lots of complex and changing data. By
|
|
identifying the key metrics, such as number of concurrent transactions
|
|
per second, size of database, and so on, it is possible to then build a
|
|
method for testing the assumptions.</para>
|
|
<formalpara>
|
|
<title>Develop functional user scenarios</title>
|
|
<para>
|
|
Develop functional user scenarios that can be used to develop
|
|
test cases that can be used to measure overall project
|
|
trajectory. If the organization is not ready to commit to an
|
|
application or applications that can be used to develop user
|
|
requirements, it needs to create requirements to build valid
|
|
test harnesses and develop usable metrics. Once the metrics
|
|
are established, as requirements change, it is easier to
|
|
respond to the changes quickly without having to worry overly
|
|
much about setting the exact requirements in advance. Think of
|
|
this as creating ways to configure the system, rather than
|
|
redesigning it every time there is a requirements
|
|
change.
|
|
</para>
|
|
</formalpara>
|
|
<formalpara>
|
|
<title>Limit cloud feature set</title>
|
|
<para>
|
|
Create requirements that address the pain points, but do not
|
|
recreate the entire OpenStack tool suite. The requirement to
|
|
build OpenStack, only better, is self-defeating. It is
|
|
important to limit scope creep by concentrating on developing
|
|
a platform that will address tool limitations for the
|
|
requirements, but not recreating the entire suite of
|
|
tools. Work with technical product owners to establish
|
|
critical features that are needed for a successful cloud
|
|
deployment.
|
|
</para>
|
|
</formalpara>
|
|
<section xml:id="application-cloud-readiness-methods">
|
|
<title>Application cloud readiness</title>
|
|
<para>Although the cloud is designed to make things easier, it is
|
|
important to realize that "using cloud" is more than just firing up
|
|
an instance and dropping an application on it. The "lift and shift"
|
|
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
|
|
"pets". They're 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, on the other hand, 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, naturally will suffer outages, lost data, or
|
|
worse.</para>
|
|
<para>There are other reasons to design applications with cloud in mind.
|
|
Some are defensive, such as the fact that 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, so applications need to be designed in such a way that
|
|
they can take advantage of those 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 isn't 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,
|
|
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. Love your chaos monkey.</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.
|
|
Don't 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 so on can rapidly
|
|
increase monthly usage charges. Monitor usage closely.
|
|
</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</section>
|
|
</section>
|