Cloud Application Decisions

yompmulligrubsInternet και Εφαρμογές Web

31 Οκτ 2013 (πριν από 4 χρόνια και 6 μήνες)

140 εμφανίσεις

White Paper

Cloud Application Decisions

Identifying the
factors that influence Application behaviour in the Cloud





What’s the probl em?


Infrastructure deci si on


Managed Servi ce
deci si on



The behavi our of cl oud envi ronments may be si gni fi cantl y di fferent to the i nfrastructure servi ces that are provi ded i n a
typi cal Datacentre. Organi sati ons seek the benefi ts of cl oud wi thout i ncurri ng the cost of si gni ficant change to the appl i cat
Archi t
ecture. However, movi ng Appl i cati on Servers wi thout assessi ng the di fferences i s a hi gh
ri sk approach.

The Cl oudConveyor deci si on tree may be used to i denti fy the best servi ce based not onl y on the future servi ce cost but the
costs to transform.

Thi s p
aper i denti fi es the key i nfrastructure factors that i nfl uence appl i cati on behavi our i n the cl oud.

Thi s paper has been
produced as i t supports the Cl oud Conveyor outcomes that Servi ce Provi ders can match agai nst.



cale up or scal
e out.

Some appl i cati on components are desi gned to functi on i n a scal e up model. Thi s i mpl i es that as they grow more and more
resource needs to be added to the operati ng system that i s supporti ng that component. Cl oud (and vi rtual i sed) envi ronments
tend to

have l i mi ts on the abi l i ty to scal e up a node. The archi tecture trend i s to scal e appl i cati ons out rather than up. The
i mpact however i s that mul ti pl e i nstances then need to work together as a team and addi ti onal technol ogi es are requi red to
manage the te
am (see l oad bal anci ng).


In part rel ated to the scal e up or scal e out paradi gm some appl i cati on components may have demands for compute
performance that exceed what i s avai l abl e i n the cl oud. Other key performance factors i ncl u
de the Storage Performance and
the Network l atency between appl i cati on components (see synchronous repl i cati on).

Layer 2 Networking.

Some organi sati ons may have i mpl emented
what i s someti mes referred to as stretch l ayer 2 networks between datacentres.
Thi s capabi l i ty i s typi cal l y constrai ned by di stance and as a resul t i t i s not common for cl oud envi ronments to support thi s
(they mostl y operate wi th Layer 3 routed networks ra
ther than l ayer 2 swi tched).


White Paper

Cloud Application Decisions

Identifying the
factors that influence Application behaviour in the Cloud



Unl ess the enti re subnet i s mi grated i ts l i kel y that the i ndi vi dual servers that mi grate wi l l need to change IP address whi ch

has a hi gh i mpact to fl ushi ng out dependenci es el sewhere. One such dependency i s the handl i ng of re
covery i n the event of a
datacentre fai l ure. Stretch l ayer 2 networks enabl e the server to retai n i ts IP Address and as such i n a recovery scenari o th
i mpact i s much l ess. In a Cl oud recovery scenari o a server movi ng between cl ouds wi l l need to change IP


Server cl usteri ng technol ogi es
requi re that mul ti pl e servers have access to shared storage. Thi s i s someti mes referred to
as the Quorum; the physi cal presentati on of the storage may vary from Di rect Attached Storage (DAS)
to a Storage Area
Network (SAN).

Vari ants on thi s approach i ncl ude servers shari ng access to a Server that acts as a wi tness to confi rm that
servers are operati onal (known as a Fi l e Share Wi tness); the wi tness i s typi cal l y Network Attached Storage (NAS) or

addi ti onal Server wi th a Fi l e Share.

Whi l e some cl oud provi ders may support operati ng system cl usteri ng the trend i s to move towards appl i cati on l evel
cl usteri ng. Thi s approach removes i nfrastructure dependenci es whi ch l eft unchecked woul d hi nder cl ou
d mobi l i ty.

Service Registration &

Vi rtual l y al l applicati ons have dependenci es on other servi ces. It i s i ncreasingly i mportant to avoi d referri ng to servers vi
a the
TCP/IP address. Vari ous technol ogi es and processes may exi st to
handl e the management of IP addresses. In a cl oud
envi ronment these processes and technol ogi es may change but the ul ti mate goal i s that cl oud servers regi ster automati cal l y
i n an appropri ate ful l y qual i fi ed DNS Zone. =

Appl i ca
ti on Archi tects shoul d al so consi deri ng abstracti ng even further and uti l i si ng a
Domai n
Name Al i as for each servi ce.
Thi s
approach reduced compl exi ty when repl aci ng servers wi th a new i denti ty or scal i ng the number of servers i n a team.
Servi = &

Reverse Proxy Name Masking

One of the features of a Reverse proxy i s to mask the real name of an i nternal servi ce. Thi s i s especi al l y used for i nbound
communi cati ons from the Internet.

= Servi

In an opti mal
archi tecture

the reverse proxy uti l i ses the DNS servi ce and may conti nue to functi on wi th cl oud resources
subject to connecti vi ty and appropri ate name resol uti on. It may be that the desi gn of the reverse proxy i nfrastruc
ture needs
to change to enabl e cl oud adopti on.

Load Balancing

Where more than one server i s supporti ng a servi ce
a l oad bal ancer i s used to di stri bute the traffi c appropri atel y. Vari ous
technol ogi es and processes exi st. One of the factors on the archi tect
ure i s the handl i ng of change as servers are added or
removed from the servi ce; i f a new server i s not added to the l oad bal ancer then i t i s of no use. Another factor i s the
moni tori ng and handl i ng of fai l ure; i f a server has fai l ed i t i s i mportant that tr
affi c i s no l onger sent to i t and as such i t shoul d
be removed from the l oad bal anci ng rul es. The effecti ve moni tori ng of fai l ure and the resul ti ng orchestrati on of l oad
bal anci ng rul es i s very i mportant.

Active / Passive

White Paper

Cloud Application Decisions

Identifying the
factors that influence Application behaviour in the Cloud



From a cl oud servi ce del i very per
specti ve the handl i ng of acti ve/passi ve confi gurati ons needs careful pl anni ng. From an
Infrastructure standpoi nt an Acti ve / Passi ve confi gurati on shoul d be handl ed as i f the servers are al l operati onal and
avai l abl e to accept appl i cati on traffi c. The Acti
ve Server i s respondi ng to al l Appl i cati on Servi ce requests whi l e the Passi ve
node may be supporti ng none or a subset (such as repl i cati on of data). Vari ous mechani sms exi st to i denti fy whi ch server i s
pl ayi ng the acti ve rol e from Load Bal anci ng Rul es to t
he regi strati on of Servi ce records wi thi n DNS. In any event the
handl i ng
of change of the acti ve server needs to be factored i n to the operati onal processes and i n an opti mal model i s orchestrated.


Database Archi tectures have evol ved si
gni fi cantly over recent years, i n part to handl e the scal ing demands, bi g data and al so
cl oud depl oyment. Mi grati ng an exi sti ng database servi ce to a cl oud envi ronment i s probabl y not the opti mal approach. The
Database Servi ce wi l l normal ly span mul ti ple S
ervers and Mul ti pl e Si tes. In typi cal database architectures onl y one server wi l l
accept wri te operati ons whi l e many wi l l support read. The defi ni ti on of the wri tabl e server needs to be portabl e to handl e
fai l ure to the server or i ts si te.

Many vendors a
re creati ng database servi ces that are desi gned (and someti mes are del i vered) from cl oud envi ronments.

Database Replication

In Database Archi tectures where one server i s accepti ng wri te operati ons these changes need to be repl i cated to any other
that are avai l able to support read operati ons. There are several approaches to repl i cati on but these typi cal l y rel ate to
the desi red i ntegri ty of the data i n the event of fai l ure. Synchronous repl i cati on approaches force the appl i cati ons to wai t
unti l a po
si ti ve acknowl edgement i s recei ved that the data has been wri tten to the repl i ca. Asynchronous approaches wi l l
acknowl edge the wri te even i f there i s no guarantee that i t has been wri tten to the repl i ca.

Authentication and Authorisation

There are many use cases wi thi n the real m of authenti cati on and authori sati on that need to be consi dered. These i ncl ude the
end user, the support user,
server access control, systems management
tool s and i ntra appl i cation communi cati ons. It can be

that most organi sati ons wi l l have systems i n pl ace for these

use cases today and the chal l enge i s to support the
cl oud pl atform whi l e mi ni mi si ng the changes to exi sti ng systems.

Network Security

Exi sti ng appl i cati ons may have been desi gned on the basi s that communi cati ons between appl i cati on components occurs
over a secured network. When movi ng some components to a cl oud envi ronment the changes to
underl yi ng network
transport may requi re that
the appl i cati on communi cati on
s are

secured (or that a secure tunnel be provi ded to emul ate the
exi sti ng securi ty of the appl i cati on).

Security Zone Routing

If the appl i cati on communi cati ons are such that a routed TCP/IP connecti on from the corporate netw
ork to the cl oud server
i s requi red then thi s i s a si gni fi cant el ement of the archi tecture. Thi s wi l l i mpact the securi ty zone desi gn, the technol ogi
used to secure the network and the adverti si ng of routes across the organi sati on.

Reverse Proxy and NA

White Paper

Cloud Application Decisions

Identifying the
factors that influence Application behaviour in the Cloud



Exi sti ng appl i cati ons may operate behi nd a Nat Gateway or Reverse Proxy. Thi s i s typi cal l y done i f publ i c i nternet addresses
are not used on the appl i cati on server. The Infrastructure that i s provi di ng thi s functi on i s another candi date for change of


target server i s to be depl oyed i nto the cl oud.

White Paper

Cloud Application Decisions

Identifying the
factors that influence Application behaviour in the Cloud





Server Templates and Layering

Most IT organi sati ons wi l l have a set of steps that they fol l ow (manual or automated) that add software and confi gurati on
i tems to the standard versi on that i s suppl i ed from the manufacturer.

In a cl oud context thi s acti vi ty i s sti l l requi red but the
asi s on automati ng these steps i s more i mportant. Ideal l y a templ ate wi l l be created that matched the appl i cati on
requi rements as cl osel y as possi bl e wi thout dependenci es on addi ti onal software packages bei ng added.

Server Personalisation

Server Images an
d Templ ates do not typi cal l y have an Identi ty. Server Personal i sati on i s a common process to gi ve the newl y
bui l t server some standard characteri sti cs (Server name, IP Addresses and Li cenci ng are typi cal i tems to personal i se). These
processes need to be ad
apted to conti nue worki ng for servers that are bui l t on the cl oud pl atforms.

and Data

The approach to Server recovery shoul d be part of an overal l Appl i cati on Archi tecture that i s desi gned to achi eve the
busi ness Recovery Poi nt and Recover
y Ti me objecti ves i n the event of a fai l ure. From a cl oud perspecti ve the
abi l ity to

rapi d
scal e and repl ace
servers needs to be eval uated
. There wi l l al ways be a requi rement to recover Stateful servers i n the event
of data corrupti on or l oss so a recove
ry method i s needed regardl ess.

There are two use cases that need to be
consi dered i n the event or a stateful server recovery. These i ncl ude recovery to the
same l ocati on to handl e a l ocal fai l ure/corrupti on and recovery to a di fferent l ocati on for broade
r fai l ure scenari os.

Server Rebuild

Statel ess servers are good candi dates to rebui l d i n the event of fai l ure but the practi cal i ty depends on the compl exi ti es
wi thi n other systems. It i s typi cal l y not best practi ce to rebui l d a server wi th the same i denti t
y as a fai l ed one. If thi s
gui dance i s fol l owed i t wi l l depend on the maturi ty of supporti ng systems to swap out the ol d i denti ty wi th the new one. Thi s

l ack of maturi ty can l ead to server recovery bei ng a preferred mechani sm.

Service Monitoring

Moni tori ng Servi ces may be used to tri gger ti ckets or i nci dents to the Servi ce Management tool s. When desi gni ng
Appl i cati ons for hi gher avai l abi l i ty and usi ng mul ti pl e servers i t i s good practi ce to defi ne these servers as part of a serv
i ce
group. Thi s can

i nfl uence changes (avoi di ng changes to al l parts of the servi ce at the same ti me) and can al so avoi d unwanted
servi ce al arms i f a component has fai l ed but the servi ce i s sti l l operati onal.