Edits to the arch guide
1. Removal of unnecessary content 2. Rephasing of current content for clarity Change-Id: I02335fb4b0c80d7764b5e79e2317421ff86ec2bb
This commit is contained in:
asettle
parent
080330e951
commit
3d4f729b10
@ -9,57 +9,59 @@
|
||||
version="5.0"
|
||||
xml:id="methodology">
|
||||
<title>Methodology</title>
|
||||
<para>
|
||||
Creating and testing use cases is the best way to design a cloud
|
||||
architecture that best suits your needs.</para>
|
||||
<para>
|
||||
For example, if your goal is to develop a cloud for your company's e-commerce
|
||||
website, you need to plan for applications that will support thousands of
|
||||
sessions per second, variable workloads, and lots of complex and changing data.
|
||||
By identifying the key meters, 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>
|
||||
<para>
|
||||
Functional user scenarios are used to develop test cases to measure overall
|
||||
project trajectory. If you do not want to use an application to develop user
|
||||
requirements automatically, you will need to create requirements to build
|
||||
test harnesses and develop usable meters. Once the meters are established you
|
||||
can respond to changes quickly without having to set the exact requirements
|
||||
in advance. This creates ways to configure the system, rather than redesigning
|
||||
it every time there is a requirements change.</para>
|
||||
<para>
|
||||
It is important to limit scope creep. Ensure you address tool limitations
|
||||
for the requirements, 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>
|
||||
<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>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. This "lift and shift"
|
||||
<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
|
||||
"pets". They're lovingly crafted and cared for, the servers have
|
||||
names like Gandalf or Tardis, and if they get sick, someone nurses
|
||||
<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, on the other hand, servers are more like
|
||||
<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, 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
|
||||
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, so applications need to be designed in such a way that
|
||||
they can take advantage of those and other opportunities.</para>
|
||||
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
|
||||
@ -69,8 +71,8 @@
|
||||
<term>Structure</term>
|
||||
<listitem>
|
||||
<para>
|
||||
A large, monolithic, single-tiered legacy
|
||||
application typically isn't a good fit for the
|
||||
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
|
||||
@ -85,9 +87,9 @@
|
||||
<listitem>
|
||||
<para>
|
||||
Applications that depend on specific
|
||||
hardware—such as a particular chip set or an
|
||||
hardware, such as a particular chip set or an
|
||||
external device such as a fingerprint
|
||||
reader—might not be a good fit for the
|
||||
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
|
||||
@ -100,10 +102,10 @@
|
||||
<term>Connectivity</term>
|
||||
<listitem>
|
||||
<para>
|
||||
Self-contained applications or those that depend
|
||||
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
|
||||
you can work around these issues with custom network
|
||||
setup, but how well this works depends on the
|
||||
chosen cloud environment.
|
||||
</para>
|
||||
@ -123,6 +125,7 @@
|
||||
</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
|
||||
@ -130,7 +133,7 @@
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Be a pessimist: Assume everything fails and design
|
||||
backwards. Love your chaos monkey.</para>
|
||||
backwards.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Put your eggs in multiple baskets: Leverage multiple
|
||||
@ -151,12 +154,12 @@
|
||||
<listitem>
|
||||
<para>But not too paranoid: Not every application needs the
|
||||
platinum solution. Architect for different SLA's, service
|
||||
tiers and security levels.</para>
|
||||
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
|
||||
Do not short change the effort in analyzing and addressing
|
||||
data needs.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
@ -178,7 +181,7 @@
|
||||
<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.
|
||||
adapt to changing environments, faults, and workload volumes.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
@ -187,12 +190,12 @@
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Keep it loose: Loose coupling, service interfaces,
|
||||
separation of concerns, abstraction and well defined API's
|
||||
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
|
||||
software licenses, reserved instances, and similar costs can rapidly
|
||||
increase monthly usage charges. Monitor usage closely.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
Loading…
Reference in New Issue
Block a user