Capitol nr.

4
Software as a Service (SaaS)

1.

Software as a Service
Software as a Service (SaaS) a aprut la finalul anilor 1990. n ultimii ani ai

exploziei Internet-ului, furnizori de servicii pentru aplicaii (ASP) cunoscui ncep s intre pe
pia cu promisiunea de a revoluiona peisajul aplicaiilor software enterprise. Aceste firme
ncepeau s livreze pachete de aplicaii software enterprise complexe printr-un model de
gzduire, n general fr sau cu puine pretenii asupra drepturilor intelectuale. n civa
ani multe dintre aceste firme au ieit de pe pia, i-au modificat modelele de business i
poziionarea, sau i-au redimensionat operaiile dup ce au euat s ctige suficient
momentum. Totui, un grup select din aceste firme ale primei i celei de-a doua generaii
SaaS a continuat s existe, oferind n general aplicaii specializate, proprietare tocmai
aceste firme au contribuit la creterea gradului de acceptare a soluiilor bazate pe servicii
ntre diverse companii. n particular, spaiul aplicaiilor CRM la cerere a aprut ca un hot
spot incipient, odat cu apariia unor companii precum Salesforce.com, RightNow
Technologies sau SalesNet, care au pavat drumul spre acceptarea i validarea noilor
modele de business n market.

Figura 4.1. O viziune asupra evoluiei modelelor de aplicaii i industriei IT.

Software as a Service (SaaS)

Software as a Service a redefinit efectiv modelul de deployare a aplicaiilor

software, de la aplicaii mpachetate cu taxe de licene transparente i implementri de
lung durat spre un model ce constituie o relaie mai dinamic, bazat pe servicii livrate
peste Internet i avnd n spate soluii pay-as-you-go. Aceast schimbare a schimbat
fundamental presupunerile, relaiile i parteneriatele ntre vnztorii de aplicaii software,
clieni i end-useri, precum i furnizori de servicii externi. SaaS modific dinamica i
definiia aplicaiilor software i a furnizorului de servicii, i aceste concepe ntr-o singur
entitate surs. Cumva diferit dect rolul jucat de sectorul modelului de outsourcing,
precum firme de procesare a listelor de plat precum ADP, sau modelul timesharing
aprut n anii 1970. n acelai timp, firmele SaaS au atins o mas critic i profitabilitate,
deoarece au de ctigat de pe urma transparenei sporite a ncasrilor i predictibilitii
costurilor, comparativ cu firmele ce practic modelul tradiional de furnizare a aplicaiilor
software de exemplu.
Dup perioada primelor dezvoltri i maturizrii, modelul SaaS a atins o rat nc i
mai mare de adoptare, ocupnd un rol semnificativ n redefinirea industriei software.
Astzi, impactul Software as a Service deja ncepe s se simt de ctre companii ce ncep
s resimt efectele performanei sporite i care contribuie semnificativ la dinamica
anumitor sectoare din industria software.
1.1. O serie de definiii
Modelul tradiional de Software
Aplicaiile software tradiionale se bazeaz pe un model avnd costuri directe de
liceniere mai mari i costuri cu suportul calculat n general anual. Funcii importante ale
pachetului sunt adesea oferite suplimentar n cadrul unor aranjamente de liceniere, pe
baza unor rennoiri anuale a contractului pentru actualizri i suport. Creterea numrului
de utilizatori poate conduce la creterea costurilor de baz ale pachetului, datorit
necesitii achiziionrii i deployerii de hardware i suport IT suplimentar. Costurile de
liceniere se bazeaz adesea pe metrici ce nu sunt neaprat direct legate de folosire (e.g.,
tipul de server, numrul de procesoare, etc.).

Un pachet tipic software enterprise necesit instalarea de hardware, servere,

furnizarea de soluii de backup i de comunicaie peste reea, pentru a putea s suporte
numrul de utilizatori n i n afara premiselor organizaiei.
O arhitectur de securitate este de asemenea taxat ca urmare a efortului cu
protejarea resurselor valoroase din partea unor accesri neautorizate. Aplicaiile software
tradiionale tind s fie puternic personalizabile. Dar aceast personalizare vine la pachet
cu costuri att financiare, ct i n termeni de resurse umane implicate. Toate activitile n
desfurare de mentenan i management a aplicaiei sunt furnizate de ctre clientul ce
instaleaz aplicaia n cadrul reelei proprii. Similar, clientul este cel responsabil cu
furnizarea securitii logice i fizice aplicaiilor, precum i cu furnizarea antrenamentului i
suportului necesar utilizatorilor finali. Arhitectural, modelul tradiional al aplicaiilor software
se consider a fi un model single-tenant.
Modelul On-Demand, Software-as-a-Service (SaaS)
Aplicaiile Software-as-a-Service (SaaS) la cerere se bazeaz pe o tax de
subscriere recursiv, i adesea pe un model pay as you go. Asta nseamn c toate
costurile pot crete odat cu creterea gradului de folosire a aplicaiei. n modelul SaaS
costurile sunt direct proporionale aadar cu folosirea (e.g. # utilizatori, # tranzacii, etc.).
Deployarea tipic a unei aplicaii SaaS nu necesit alt hardware i poate rula peste
infrastructura Internet deja existent. Cteodat sunt necesare modificri n cadrul
regulilor din firewall i efectuarea unor setri necesare pentru a permite rularea aplicaiilor
SaaS. O aplicaie SaaS poate fi configurat folosind API-uri, dar aplicaiile SaaS multiocupaional (eng., multi-tenant) nu pot fi complet personalizate.
Furnizorul SaaS i asum tot suportul, antrenamentul, riscurile legate de
infrastructur i securitate, n schimbul acestui cost cu subscrierea. Modelul de servicii
SaaS are ca scop livrarea unor aplicaii business anywhere, anytime, ceea ce necesit ca
furnizorul SaaS s angajeze echipe de suport dedicate i personal ce poate fi la dispoziia
clienilor finali repede. Odat cu personalul vine i rezervarea capacitii de a gestiona
creteri brute n ncrcare i utilizare, i s continue s ofere aceeai calitate a serviciilor
ntr-o manier continu, global i sigur. Din punct de vedere arhitectural, spunem c
modelul SaaS este un model multi-ocupaional.
Pe scurt, caracteristicile cheie ale unei aplicaii SaaS sunt:
1. Nu exist diferene ntre taxele de liceniere i cele de gzduire a aplicaiei.

Software as a Service (SaaS)

2. Aplicaia este livrat peste un browser web sau alt client thin.
3. Aplicaia este configurabil, dar nu customizabil.
Arhitectura Single-Tenant vs. Arhitectura Multi-Tenant
Cea mai important diferen arhitectural ntre modelul software tradiional i SaaS
const n numrul de ocupani (tenants) suportai de ctre aplicaie.
Single-Tenant
Modelul tradiional al aplicaiilor software e unul al unui ocupant izolat. Aceasta
nseamn c un client cumpr o aplicaie software pe care apoi o instaleaz pe un
server. Acest server ruleaz doar acea aplicaie i doar pentru grupul de clieni ai acelui
utilizator. Cele mai multe aplicaii software sunt vndute astfel conform unui asemenea
model.
Multi-Tenant
Modelul SaaS ncurajeaz o arhitectur cu mai muli ocupani. Aceasta nseamn
c infrastructura fizic suport backend este partajat ntre mai muli clieni, dar din punct
de vedere logic ea este unic pentru fiecare client. O bun descriere a acestui model
arhitectural este urmtoarea: Atunci cnd un utilizator al unei companii acceseaz
informaii despre clieni folosind aplicaia CRM pus la dispoziie conform modelului SaaS,
instana aplicaiei la care se conecteaz utilizatorul poate suporta i ali utilizatori din alte
duzini, dac nu chiar sute, de alte companii toate complet izolate de ali utilizatori.
Aceasta necesit o arhitectur care s maximizeze partajarea resurselor ntre ocupani,
dar care ns poate s diferenieze datele ntr-o manier securizat dac ele apain unor
clieni diferii.1
2.4 SaaS vs. ASP
Soluiile SaaS sunt foarte diferite de soluiile ASP (Application Service Provider), n
principal datorit a trei motive:

http://footheory.com/blogs/bennie/archive/2007/12/15/software-as-a-service-a-high-level-overview.aspx

1. Aplicaiile ASP sunt aplicaii tradiional single-tenant, dar gzduite de o a treia

entitate. Ele sunt aplicaii client-server avnd un front-end HTML adugat pentru a
permite accesul remote la aplicaie.
2. Aplicaiile sunt gzduite de entiti externe ce adesea nu au expertiz specific pe
acea aplicaie.
3. Aplicaiile nu sunt scrise ca aplicaii net-native. Ca rezultat, performana poate fi mai
slab, iar actualizrile aplicaiei nu sunt mai bune dect n cazul unor aplicaii autogestionate tradiionale.
Prin comparaie, aplicaiile SaaS sunt aplicaii multi-tenant, gzduite de o companie
ce are expertiz n aplicaii, i care sunt proiectate ca i aplicaii net-native ce sunt
actualizate dinamic on-going.
1.2. Evoluie
Piaa aplicaiilor SaaS a evoluat semnificativ n ultimii cinci ani, atunci cnd
conceptul a nceput s fie asimilat succesului aplicaiilor tip business process outsourcing
(BPO), application outsourcing & management, sau modelului timesharing (Figura 4.1).
Prima Generaie. ntre anii 1998 i 1999, furnizorii de aplicaii precum
USinternetworking i Corio au atras atenia cu un model de oferire de spaiu de gzduire a
aplicaiilor, oferind acces bazat pe Web aplicaiilor unor vendori majori de aplicaii software
enterprise, precum PeopleSoft, Siebel, SAP, Microsoft, Lawson, Broadvision i Ariba, pe
baza unor subscripii i nu a unor licene. Conceptul de nchiriere i gzduire a aplicaiilor
software s-a dovedit a fi atractiv pentru firmele de servicii i software IT, precum i
comunitii financiare: conform lui John Hagel, n Out Of The Box, acest sector a primit
aproximativ $3.6 miliarde n investiii de capital ntre 1999 i 2000, cu peste 2000 de
companii care au nceput s se autointituleze ASPs.2 Totui, o serie de factori, inclusiv
rata mic de cretere economic, reducerea cheltuielilor n IT, schimbrile n lumea
dot.com, dificultatea n atingerea scalabilitii i problemele legate de performan a ASP
au condus la dispariia multora dintre aceste companii. n particular, aplicaiile de clas
enterprise proiectate pentru liceniere ntr-o arhitectur client-server nu s-au dovedit
potrivite livrrii conform modelului on-demand, ceea ce a condus la o capcan a
personalizrii n ncercarea de a exploata eficiena aplicaie ntr-o dimensiune one-tomany. Aceste companii au avut de altfel de luptat mpotriva chiar acelor companii cu care
2

John Hagel III, Out Of The Box: Strategies for Achieving Profits Today and Growth Tomorrow Through Web
Services. Harvard Business School Press, 2002, p. 45.

Software as a Service (SaaS)

lucrau, deoarece nu furnizat noi produse, dar acionau mai degrab ca i canale pentru
gsirea de noi cumprtori pe piaa produselor software.
Ce-a dea doua generaie. Dup prima generaie, un grup de companii selecte a
continuat s existe pe piaa SaaS, avnd ca principal atu nlturarea micilor imperfeciuni
i validarea modelului de business cu o populaie de clieni finali din ce n ce mai receptiv
la schimbri. Majoritatea acestor companii erau deinute n mod privat i operau sub
radar pe piaa produselor software. Aceste companii construiau aplicaii complet noi,
bazate pe Web, ce adresau n mod direct importante funcii de business, furniznd un
return-on-investment cuantificabil i o puternic valoare adugat, adresnd n acelaii
timp funcii business specifice din puncte cheie, precum managementul relaiei cu clienii,
HR, serviciile de investiii i mesajerie.
Maturizarea conceptului Business. ncepnd cu a doua jumtate a lui 2003, a
existat o schimbare clar resimit ce a constat n re-ntrirea interesului n modelul SaaS.
Furnizorii SaaS raporteaz creteri ale numrului de utilizatori subscrii i creteri ale
vnzrilor, ceea ce dovedete un puternic interes n rndul companiilor i small-to-medium
enterprises (SMEs) deopotriv, precum i creterea recunoaterii i ctigarea ncrederii
n rndul utilizatorilor acelor aplicaii gzduite extern. Modele primei generaii au avut la
baz nchirierea unor produse software de renume de ctre companii medii, ce nu puteau
s suporte costurile asociate cu licenierea tradiional a produselor software sau s le
implementeze local. Multora dintre aceti utilizatori finali le lipseau, de asemenea,
resursele locale pentru a ine pasul cu peisajul n continu schimbare a domeniului ICT.
De atunci, acceptarea pe pia a unor astfel de modele a condus acest segment n piaa
de desfacere.
n anumite segmente de pia, companiile SaaS apar acum ca i competitori serioi
n faa comercianilor de produse software avnd un tier independent (ISVs), ceea ce
conduce la crearea unor efecte disruptive semnificative. Se crede astzi c aceast nou
generaie de furnizori SaaS a representat un moment crucial n evoluia ctre arhitectura
orientat pe servicii (SOA), compus din aplicaii Web-native i servicii Web bazate pe
XML - i care furnizeaz un nivel mai nalt de integrare i customizare dect era nainte
posibil. n plus, n aceast faz, SaaS creaz posibilitatea de oferire a chiar mai multor

funcii dect companiile rivale, prin furnizarea ctre utilizatori a unor actualizri i noi
release-uri mai frecvent, i fr complicaii legate de integrare.
1.3. Segmentare
ntr-un sens generic, definiia dat pn acum modelului software as a service
(SaaS) se refer la orice model construit pentru livrarea de acces ctre aplicaiile software
prin intermediul unei reele (fie el Internetul public sau alte intraneturi sau extraneturi
private). Aplicaiile stau ntr-un centru de date extern, unde sunt meninute de ctre un
furnizor de serviciu, iar clienii le pot accesa remote prin intermediul unor browsere Web i
servere Web din back-end. Modelul de business SaaS este prezis de un model de livrare
one-to-many sau multi-tenant, n care aplicaia este partajat ntre mai muli clieni,
furniznd un nivel minim de customizare a aplicaiei pentru evitarea unor costuri mari cu
implementarea i integrarea.

Software as a Service (SaaS)

Figura 4.2. Modelul de livrare a serviciilor multi-ocupaional, conform paradigmei Software as a Service.

Figura 4.2 furnizeaz o imagine simplificat a acestui concept, dei se tie astzi c
modelul accept n realitate i un numr de alte alternative. O premis cheie a acestui
model este aceea c organizaiile SaaS investesc n tehnologie, hardware i servicii suport
n locul clienilor. n schimb clienii pltesc conform paradigmet pay-as-they-go, n funcie
de un abonament i un Service Level Agreement (SLA) ce asigur clientul de furnizarea
unui nivel specificat de performan i disponibilitate, i care furnizeaz companiei SaaS o
relaie de lung-durat cu proprii clieni.
Exist cteva tipuri distincte de companii n sectorul SaaS. n cele ce urmeaz
facem o incursiune mai detaliat n acest subiect i prezentm segmentarea propus de
IDC3 n urmtoarele categorii distincte:
1. Application Service Providers (ASPs): Companiile din acest segment gzduiesc
i gestioneaz aplicaii software mpachetat i furnizeaz acces la distan ctre
acestea. Costurile de obicei constau din licene unice i taxe de instalare
(semnificativ mai mici dect costurile de liceniere n cazul produselor software
tradiionale), precum i abonamente periodice, taxe pentru gzduire i mentenan,
adesea stabilite la un interval de timp precum per lun de zile. Aceste costuri pot fi
modificate pentru a reflecta parametrii de folosire ai aplicaiei n termeni de numr
de utilizator, numr de hituri, sau alte metrici. Exemple de companii tip ASP sunt
USinternetworking, Corio, Surebridge sau NetASPx.
2. Web-native Applications: O poriune n cretere a peisajului SaaS este
reprezentat de acest segment, ce const din aplicaii proprietare construite special
pentru instalare i livrare peste arhitectura Internet. Mai puin costisitoare i mai
rapid implementate dect aplicaiile software enterprise tradiionale, aplicaiile Web
sunt n general create pentru a rezolva o anumit problem de business. Modelul
de costuri const adesea ntr-un ir recursiv de pli, ce combin taxarea tip
liceniere cu taxele pentru gzduire. Diferena major const n faptul c aplicaiile
sunt proprietare, bazate pe Web, i optimizate pentru un mediu partajat tip 'one-tomany'.

From IDC report #31267 U.S. Software as a Service 2004-2008 Forecast by Delivery Model,May 2004.

3. Hosted Web Services Applications: Const din categoria componentelor

software Web auto-descriptive, servicii Web ce reprezint o pia n cretere n
domeniul SaaS. Serviciile pot fi utilizate pe baza unui model standalone, sau n
combinaie cu alte componente de aplicaii, pot fi gzduite de o companie extern
sau de ctre un departament IT din cadrul organizaiei care acioneaz n acest caz
ca un furnizor de servicii. Nu exist o schem principal de costuri asociat cu
Serviciile Web.
Cteva detalii legate de nomenclatur: se face o distincie ntre companiile ce
gzduiesc aplicaii third-party i vnztorii ce livreaz propriile produse software peste
Internet, folosind termenul proprietary software as a service pentru a ne referi la cei din
urm (care alctuiesc categoriile 2 i 3 anterior descrise). Deoarece vnztorii de SaaS
proprietar genereaz cel mai mare momentul pe pia astzi, merit s ne concentrm
atenia pe dezvoltrile acestor companii ntr-o seciune urmtoare.

Figura 4.3. Comparaie ntre 2 modele: Application Outsourcing & SaaS Business Model.

1.4. Regulile n modificare ale comportamentului n industria software

Modelul SaaS reprezint o re-transformare complet a metodelor tradiionale de
vnzare i livrare a produselor software. Aceast redefinire schimb scopul i relaiile
economice dintre vnztori i utilizatori. Diferenele principale ntre companiile tradiionale
i cele axate pe SaaS poate fi cel mai bine ilustrat prin cele trei categorii prezentate n
Figura 4.4:

Software as a Service (SaaS)

Modelul de Business. Dup cum s-a precizat, modelul SaaS este destul de diferit
de modelul de liceniere prin aceea c toate costurile de liceniere i servicii (mentenana
de exemplu) sunt acum nlocuite de abonamente periodice tip 'all-in-one' tipic lunar sau
pe baz de numr de instalri. Dezavantajul const n aceea c firmele bazate pe modelul
SaaS au ctiguri directe semnificativ mai mici, dar ctigurile de lung durat pot fi mai
bine prevzute datorit relaiei bazate pe furnizarea de servicii.
Ca o consecin, adevrata msur a succesului sau valorii unei companii SaaS nu
este neaprat legat de creterile n ctiguri, dar mai degrab este reprezentat de
metrici legate de noile achiziii de clieni, rata reteniei clienilor, predictibilitatea i
vizibilitatea fluxurilor de ctiguri.
Costurile cu ctigurile. Semnificativ diferit de modelul ISV, companiile SaaS
necesit mai puine ctiguri cu serviciile directe datorit timpului rapid de dezvoltare i
livrrii peste infrastructuri Web deja existente. Muli ISV opteaz pentru parteneriate cu
integratori de sisteme pentru furnizarea de servicii profesionale i implementare. Pe de
alt parte, companiile SaaS investesc n customer service i n activiti de training,
account management i activiti tip application support i management, ce includ
operarea reelelor pentru asigurarea livrrii cu succes a aplicaiilor, furnizarea pn la
virtual 100% uptime n termeni de performan.
Costurile de operare. O zon a diferenelor clare ntre companiile ISV i cele tip
SaaS const n abordarea legat de activitile de R&D, vnzare i marketing. Un ISV
suport n mod tipic mai mult cod, pentru mai multe medii tehnice (client/server, Webbased, etc.), precum i livrarea conform modelului single-tenant ce trebuie meninut
conform acordurilor cu clienii. Pe de alt parte, companiile SaaS i bazeaz tehnologiile
pe cod nativ Web, unic, ce este capabil s suporte mai muli utilizatori conform unor medii
multi-tenant, cu partajare ntre aplicaii. Rezultatul final este acela c companiile SaaS pot
scdea costurile cu R&D odat cu fiecare achiziie de noi clieni. n plus, companiile ISV
impun costuri pentru actualizrile produselor software, mentenan i au adesea noi cicluri
de release-uri de noi produse software la fiecare doi sau trei ani; pe de alt parte,
companiile SaaS furnizeaz actualizri software gratuite, includ mentenan i suport n
relaia bazat pe furnizarea de servicii i suport mai multe i mai frecvente release-uri i
actualizri software. n termeni de volum de vnzri i abordri de marketing, exist de

10

asemenea diferene notabile ntre cele dou abordri. Deoarece companiile ISV suport
un model bazat pe servicii directe i implementri cteodat mai scumpe dect taxele de
liceniere, companiile mari de consultan i IT au aliai i parteneri naturali n dezvoltarea
de aliane legate de vnzri i canale indirecte de furnizare.
Pe de cealalt parte, companiile SaaS necesit mai mult creativitate n abordrile
legate de vnzri i marketing, deoarece alianele i canalele tradiionale impun dificulti
unice datorate relaiei economice diferite pentru integratorul de sisteme. Astfel, multe
companii SaaS au investit n mai multe canale indirecte ctre market (parteneri industriali,
aliane legate de infrastructur, OEM, VAR, etc.), precum i n construirea de canale
directe de vnzare.
n final, companiile SaaS gestioneaz tradeoff-ul i conflictele impuse de creterea
rapid ce necesit investiii semnificative n mai multe canale de vnzare i
marketing, opus canalelor stabile de cash ce necesit mai mult rbdare vizavi de
ateptri, deoarece achiziia clienilor necesit o perioad de timp semnificativ mai
lung.

Figura 4.4. Diferenele fundamentale ntre companiile ISV i cele SaaS.

11

Software as a Service (SaaS)

1.4. Valoarea modelului Software as a Service

Deoarece aceast pia s-a dezvoltat de-a lungul mai multor ani, adoptarea a
evoluat i ea ntr-un ritm similar.

n ncarnarea original a modelului de gzduire a

aplicaiilor, motivaiile pentru contractarea unui furnizor de servicii ascundeau adesea

motivaiile legate n realitate de relaia tip outsourcing: costuri mai predictibile i o abilitate
crescnd de focusare pe competenele de baz, cu accentuarea expertizei unui furnizor
de servicii specialist. Aceste principii de baz sunt de fapt destul de similare valorii
modelului SaaS n care o relaie cu costuri reduse, bazate pe pay-as-you-go, furnizeaz
unor organizaii mici i mijlocii o suit de aplicaii enterprise similare acelora disponibile
unor organizaii din Global 1000, precum i o relaie la nivel de servicii cu furnizorul ce
asigur o valoare real. Sunt cteva valori care au condus la astfel de relaii:
Costuri mai mici cu achiziia produselor software prin nlocuirea unor modele de
costuri cu taxe mari, directe pentru liceniere, cu unele mai mici, bazate pe abonamente. O
astfel de abordare n modelul de costuri mut o mare parte din cheltuielile companiei de la
costuri fixe ctre unele variabile, crescnd flexibilitatea structurilor i a modelelor de
costuri.
Uurina n implementare i timpul mai rapid de aducere pe pia sau valorii,
odat cu deployul ce necesit mai puin de trei luni pn produsul iese pe pia, compartiv
cu cele de la ase pn la 18 luni din modelul tradiional. Focusul pe deployment st pe
antrenarea utilizatorului final i acceptare, deoarece clienii nu trebuie s instaleze sau s
menin servere, echipament de reea, produse de securitate sau alte echipamente
hardware.
Reducerea riscurilor cu investiiile n tehnologie i un mai mare ROI datorit
comiterii de resurse i nivelelor diferite de completixate. Clientul evit riscul de a se
confrunta cu costuri ascunce, precum suportul i costurile de mentenan, actualizrile,
riscurile de acceptare din partea utilizatorilor, etc. Muli furnizori de resurse on-demand
sunt capabili s furnizeze un punct de pn la ase luni sau mai puin pn la care se
angajeaz s scoat aplicaia pe pia.
Eliberarea resurselor interne prin reducerea cheltuielor cu personalul IT intern
necesar gestionrii aplicaiilor, a actualizrilor, activitilor de meninere a performanei.

12

Includerea ntregului ciclu de dezvoltare al aplicaiei, pornind de la

deploymentul iniial pn la suportul permanent, mentenana, actualizrile ce asigur o
aliniere complet a intereselor cu cele ale companiei SaaS strns legat de succesul
aplicaiei deployate. n consecin, companiile SaaS redefinesc relaia cu clienii prin
gestionarea aplicaiei i a relaiei cu clientul de-a lungul ntregului ciclu de folosire a
acesteia.
Suportul continuu i actualizrile transparente odat cu noile capabiliti i
functionaliti, actualizri, suport pentru clieni i alte servicii operative incluse n modelul
de costuri incrementale.
Partajarea riscurilor n relaia cu clienii, ce necesit o relaie diferit cu vnztorul
ce rezult ntr-o execuie mai flexibil i mai previzibil a produsului software. La fel de
important ns, compania SaaS partajeaz riscul execuiei aplicaiei, deoarece furnizorul
SaaS are de asemenea de ctigat de pe urma succesului aplicaiei (i a ctigului
ncrederii clienilor implicit n repsectiva soluie SaaS), astfel nct relaia este
bidirecional.
Noi funcionaliti i performan mbuntit a aplicaiei odat cu companiile
ce primesc un feedback important din partea clienilor pe baza relaiei rezultate din
folosirea serviciilor. Adesea interaciunea cu utilizatorii finali n mediul de execuie al
aplicaiei determin urmtoarele prioriti vizavi de noi actualizri sau repararea unor
anumite probleme n cadrul infrastructurii suportate de vendorul SaaS. Un difereniator
critic este acela c noi revizii ale produselor sunt efectuate mai frecvent de la de trei
pn la patru ori pe an, cteodat chiar i mai mult comparat cu un release la fiecare 12
sau 18 luni n cazul modelului tradiional. n consecin, furnizorii SaaS pot rafina n mod
continuu produsul prin oferirea de noi release-uri ale acestuia, pentru a aduga
funcionalitatea impus de clieni i care s poat fi folosit de toi clienii aplicaiei
partajate n cadrul modelului multi-ocupaional. Majoritatea noilor release-uri ale aplicaiei
pot fi efectuate de-a dreptul peste noapte, ceea ce conduce la un disconfort minimal
pentru utilizatori.
Un Total Cost of Ownership (TCO) mai mic datorit costurilor datoare licenierii,
implementrii, particularizrii, mentenanei, actualizrilor i suportului hardware, toate
avnd la baz modelul de provizionare a serviciilor la cerere. n primul an TCO-ul poate fi
de cinci pn la zece ori mai mic, majoritatea ctigurilor rezultnd din eliminarea integrrii
i particularizrii proiectelor (a se vedea i Figura 4.5). Aadar perioada de amortizare

13

Software as a Service (SaaS)

este cel mai adesea scurtat. Lipsa unor oportuniti de implementare impune o serie de
constrngeri speciale asupra companiilor SaaS ce urmresc crearea de parteneriate i
aliane cu firme de renume de consultan ce urmresc piaa serviciilor. n timp ce e dificil
cuantificarea costurilor ascunse, modelul SaaS se bazeaz cu precdere pe un model al
costurilor directe de o mai lung durat. Funcionalitatea aplicaiei i abilitatea acesteia de
a adresa necesitile reale ale utilizatorilor rmn factori importani n oricare decizie
relativ la cheltuielile cu tehnologia. Acestea fiind spuse, e important de neles c toate
costurile i succesul operrii aplicaiei reprezint factori cruciali n evaluarea aplicaiilor
gzduite versus liceniere.

Figura 4.5. Total Cost of Ownership (TCO) mai mic.

Mergnd un nivel mai departe cu aceti factori, totui, companiile SaaS puternice i
bazeaz succesul n mare parte i pe abilitatea de reconciliere a tensiunilor dintre cele
dou pri ale oricrui business cu alte cuvinte, pe transformarea procesului de achiziie
a produselor software ntr-o relaie de lung-durat bazat pe servicii. Aceast abilitate
este exact ceea ce face ca modelul SaaS s fie preferabil n locul modelului tradiional.
Figura 6 ilustreaz acest concept, prezentnd modul n care livrarea produsului software
ca i serviciu conduce la captarea celor mai bune aspecte din fiecare model.

14

Figura 4.6. Convergena dintre Software i Serviciu n modelul SaaS.

2. Deployarea SOFTWARE AS A SERVICE

Furnizorii SaaS au fost capabili s se impun att n cadrul unor companii mari ct
i n cazul unor SME-uri. Dei e nc devreme s tragem concluzii finale, companiile SaaS
au penetrat cu succes pn acum n special aplicaiile funcionale (soluii punctuale
precum resurse umane, mesagerie, etc.) i piaa aplicaiilor enterprise (CRM, aplicaii de
procurement, etc.). n plus, o parte dintre aceste companii au descoperit succesul n cazul
managementului informaiei, aducnd lumea on-demand n spaiul funcionalitii de
management analitic i de coninut (a se vedea Figura 4.7).
Conform estimrilor noastre noastre, momentul SaaS va continua s prevaleze n
aceste sectoare n viitorul apropriat. Nivele software prezint o serie de provocri ce nc
sunt adresate de modelele mai tradiionale de deployare i outsourcing. Totui peisajul se
schimb n mod constant, cu diverse companii celebre ce ofer astzi deja soluii bazate
pe furnizarea de servicii, precum Keynote Systems, Mercury Interactive, Symantec i
VeriSign. Aadar, ne putem atepta ca pe viitor situaia s devin complet favorabil
integrrii aplicaiilor n infrastructuri bazate pe servicii i tranziiei ctre arhitecturi complet
orientate spre servicii (SOA).

15

Software as a Service (SaaS)

Figura 4.7. Enterprise Software Infrastructure.

2.1. Argumente Cheie n Favoarea Aplicaiilor SaaS

Exist mai multe argumente n favoarea aplicaiilor SaaS, dar sunt patru argumente
cheie ce recomand cu adevrat aplicaiile SaaS:
1. Making the IT budget go further
2. No underestimation of people services
3. SaaS allows better growth management
4. Accountability of the SaaS vendor
Making the IT Budget Go Further
Primul argument n favoarea aplicaiilor SaaS este chiar acela c SaaS furnizeaz
un beneficiu direct i cuantificabil peste modelul software tradiional.
ntr-o organizaie tipic bugetul cu IT-ul este cheltuit n trei mari domenii:

Software. Programele i datele pe care organizaia le folosete pentru procesare.

Hardware. Staii desktop, servere, componente de reea i dispozitive mobile ce

furnizeaz utilizatorilor acces la infrastructur.

16

Servicii cu oamenii. Oamenii i instituiile ce asigur operarea continu i

disponibilitatea sistemului, inclusiv echipa suport intern organizaiei, serviciile cu
consultan profesional i reprezentanii companiilor care vnd produsele.
Dintre acestea trei, produsele software sunt cel mai mult legate de managementul

informaiei, care este pn la urm scopul final al oricrei organizaii IT. Hardware-ul i
serviciile cu oamenii, dei componente vitale i importante ale mediului IT, sunt
considerate instrumente pentru atingerea scopului final pentru c ele fac posibil
producerea software-ului ce are ca scop final managementul efectiv al informaiei. Altfel
spus, orice organizaie ar aduga funcionaliti software fr extra hardware dac ar
putea, dar nici o organizaie nu ar aduga hardware fr o nevoie anticipat de adugare
a unui software n paralel.
ntr-un mediu IT dezvoltat n jurul produselor software, majoritatea bugetului este
tipic cheltuit pe hardware i servicii cu oamenii, lsnd o mic parte a bugetului disponibil
pentru chiar produsele software.

Figura 4.8. Bugetul tipic al unui mediu de dezvoltare software.

Conform acestui model, bugetul software este cheltuit n principal cu copiile

liceniate ale aplicaiilor business la cheie i produsele software particularizate. Bugetul
hardware este folosit cu precdere pe staii de lucru desktop i mobile pentru utilizatorii
finali, servere pentru gzduirea datelor i aplicaiilor i componentelor de reea care le
conecteaz pe toate acestea mpreun. Bugetul pentru serviciile profesionale suport
echipa necesar pentru deployarea i suportul software i hardware, precum i
consultanii i resursele necesare pentru dezvoltare ca suport pentru proiectarea i
construirea sistemelor particularizate.

17

Software as a Service (SaaS)

Figura 4.9. Buget tipic pentru un mediu SaaS.

ntr-o organizaie ce se bazeaz pe SaaS, alocarea bugetului cu IT-ul arat

diferit. n acest model vnztorul SaaS gzduiete aplicaiile critice i datele
asociate acestora pe servere centrale, n locaia vnztorului, i suport
componentele hardware i software prin intermediul unei echipe suport dedicate.
Acest aspect elibereaz organizaia client de responsabilitatea de a suporta
produsele software gzduite i de a cumpra i menine resursele hardware
necesare pentru acestea. Mai mult, aplicaiile livrate peste Web sau prin intermediul
unor clieni smart plaseaz mult mai puin efort pe staia edsktop dect n cazul
aplicaiilor tradiionale ce necesit instalare local. Rezultatul final este acela c un
procent mai mare al bugetului IT este disponibil pentru software, tipic sub forma
unor abonamente ncheiate cu furnizorii SaaS.
Dar nu cumva acest rezultat este doar o iluzie? Pn la urm, un procent al
costurilor cu abonamentele pltite unor vendori SaaS pentru software trebuie pltite pentru
hardware i servicii profesionale mai departe de ctre vnztor. Rspunsul const n
arhitectura multi-chiria de care am vorbit i n economia la scar mare pe care acest
model arhitectural o ofer. Un vnztor SaaS cu un numr de x clieni abonai la un singur
serviciu software gzduit central permite vnztorului servirea tuturor clienilor acestuia
ntr-un mediu consolidat. De exemplu, o aplicaie SaaS instalat ntr-o ferm cu balansare
a ncrcrii compus din cinci servere poate suporta uor 50 de clieni de dimensiune
medie. Aceasta nseamn c fiecare client va fi responsabil doar de o zecime din costul

18

unui server. O aplicaie similar instalat local poate necesita ca fiecare client s dispun
de un ntreg server dedicat aplicaiei chiar poate mai mult de unul, dac balansarea
ncrcrii i disponibilitatea crescut sunt necesiti.
Aceasta reprezint o potenial surs de salvare a costurilor, comparativ cu modelul
tradiional. Pentru aplicaiile SaaS construite pentru a scala, costurile cu operarea pentru
fiecare client vor continua s scad pe msur ce noi clieni sunt adugai. Pe msur ce
acest lucru se ntmpl, furnizorul va dezvolta soluii multi-gzduire, ceea ce conduce la
oferire de calitate crescut la un cost mai mic.
Aadar, chiar dac costurile cu hardware-ul i serviciile profesionale ale vnztorilor
SaaS sunt reale, clienii pot obine n final funcionaliti software mai bune pentru acelai
buget IT.

Figura 4.10. Buget tipic pentru un mediu SaaS.

No Underestimation of People Services

Cel de-al doilea argument n favoarea deployrii aplicaiilor SaaS const n costurile
subestimate cu oamenii asociate cu rularea local a aplicaiilor software tradiionale.
Calcularea costurilor reale cu serviciile cu oamenii nu este un lucru uor de fcut, i ca un
rezultat acest aspect este adesea omis din analizele TCO. Compania specializat n
consultan META Group a determinat c n mediul economic actual, chiar cele mai mic
ctiguri cu costurile sunt considerate a elibera investiiile n IT ce ar putea fi aplicate
tehnologiei sau n alte pri din cadru organizaiei. Companiile nu mai au luxul de a se uita
doar la cheltuielile asociate cu hardware i software, ci sunt datorare s examineze
deciziile de achiziii de-a lungul ciclului de producie i modul n care proprii oameni i
cheltuie timpul servirii aplicaiei. n timp ce companiile au neles i ncep s analizeze din
ce n ce mai ndeaproape costurile cu software, hardware, dar i costurile legate de
19

Software as a Service (SaaS)

personal, ultimele nu sunt ntotdeauna examinate ndeajuns de ndeaproape. Examinarea

tuturor acestor factori cheie ca un ntreg i a modului n care ei au un impact asupra
costului total de tip total cost of ownership (TCO) a devenit obligativitate n rularea unei
organizaii eficiente.4

Figura 4.11. Costurile cu personalul asociate cu rularea unor produse software de conferin n locaia
clientului.

Gartner Inc, o firm de analiz global, estimeaz c mai mult de 75% din bugetul
IT este folosit pentru meninerea i rularea sistemelor existente i infrastructurii software5.
n plus, Gartner crede c tocmai clienii pot cheltui cu pn la de patru ori costul licenelor
lor cu produsele software pe an pentru a deine i gzdui propriile aplicaii6.

Messaging Total Cost of Ownership: Microsoft Exchange 2003 and Lotus Domino in Small and Medium
Organizations, META Group, July 2004
5
Timothy Chou, The End of Software, SAMS Publishing, 2005, page 6
6

Timothy Chou, The End of Software, SAMS Publishing, 2005, page 7

20

Figura 4.12. Costurile cu personalul reprezint cea mai mare parte din costul total, n cazul unor aplicaii
pentru email i groupware.

Un alt punct de vedere vine din partea Microsoft, care n 2002 declara n Wall
Street Journal: cumprarea iniial reprezint cel mai adesea doar 5% din costul total al
deinerii i meninerii unui program.7 IDC, o alt firm de consultan i analiz global, a
ajuns la o concluzie similar n urma analizei industriei de conferine Web. Compania a
determinat, astfel, c cheltuierile ascunse cu personalul pot fi de pn la 70% din costul
total rulrii aplicaiilor software n locaia clientului8.
Companiile par s neleag n mod instinctiv acest aspect, mai ales c majoritatea
au decis s comercializeze ntr-un model de outsourcing aplicaiile de conferin audio
ctre companii precum AT&T, Verizon, Intercall sau BT.

7
8

Microsoft Wages Campaign Against Using Free Software, The Wall Street Journal, December 9, 2002
Robert Mahowald, Do Service Providers Deliver Value and Reduce Enterprise Costs?, IDC, 2003

21

Software as a Service (SaaS)

Datorit experienei extinse pe care companiile o au cu aplicaii de e-mail i

groupware, economia din spatele acestor servicii este destul de bine cunoscut. O serie
de rapoarte arat c tocmai costurile asociate cu personalul pentru aceste aplicaii
software tradiionale sunt, la un nivel minim, aproximativ 2.5 ori, i pot ajunge i pn la de
7.5 ori peste costurile asociate cu software-ul (inclusiv mentenana acestuia); valorile tipice
asociate cheltuielilor cu personalul sunt ntre 5 i 7 ori peste cele asociate cu software-ul i
mentenana de-a lungul unei perioade de trei ani de exemplu9.
SaaS Allows Better Growth Management
Cel de-al treilea argument este acela c aplicaiile SaaS cresc odat cu creterea
organizaiei i business-ului. Companiile nu trebuie s ia decizii asupra tipului de aplicaie
restricionat de dimensiunea i necesitile acesteia pentru execuie. Dimpotriv,
companiile pot lua decizii n acest sens strict pe baza propriilor necesiti business.
Datorit economiei de scar oferit de arhitectura multi-tenant, companiile SaaS pot
furniza organizaiilor aplicaii avnd diverse nivele vizavi de utilizatorii acestora. Pentru a
explica acest lucru, vom folosi modelul de liceniere al utilizatorului numit. Un model de
liceniere al utilizatorului numit nseamn c doar un anumit utilizator are dreptul s
foloseasc aplicaia. De exemplu, dac o companie are 100 de angajai ce au nevoie de
acces la o anumit aplicaie, ar trebui s cumpere 100 de astfel de licene diferite, cte
una pentru fiecare utilizator.
Compania nu are nevoie ca absolut toi utilizatorii s foloseasc respectiva aplicaia
n acelai timp. Cu un model tradiional de software, compania ar trebui s instaleze
infrastructur hardware pentru a suporta aplicaia i a putea antrena angajaii din IT s o
foloseasc, menin i eventual depaneze dac e nevoie. n cele mai multe cazuri nu are
sens ca acea companie s suporte n acelai timp mai mult de 5-10 utilizatori. Ca rezultat,
compania achiziioneaz 100 de licene pentru aceti maxim 10 utilizatori.
n cazul aplicaiei SaaS, nu exist necesitatea instalrii de infrastructur hardware
sau antrenare a utilizatorilor. Aceasta nseamn c acea companie poate ncepe direct cu
achiziionarea doar a 5-10 licene, i s cumpere alte licene suplimentare eventual dac e

MultiMedia Communications, A Detailed Analysis of On-Premise vs. Service Provider Costs and Risks,
WebEx Communications, 2005

22

nevoie ulterior. Ca rezultat, aplicaia SaaS este mai adecvat necesitilor moderne de
costuri ale unei companii.
Mai exist un studiu de caz important pentru flexibilitate. Companiile care trec prin
tot felul de achiziii i fuziuni n special au o mare problem n alinierea infrastructurii IT pe
msur ce modificrile apar. Pot dura luni de zile pentru instalarea resurselor hardware i
a reelei nainte ca utilizatorii dintr-o nou locaie s aib acces la serviciile folosite n toate
celelalte locaii. Aceast problem este mai redus n cazul aplicaiilor SaaS, deoarece tot
ce e necesar este o conexiune Internet, un browser i credenialele pentru pornirea
aplicaiei.
Accountability of the SaaS Vendor
Cel de-al patru argument este acela c companiile SaaS au un control mai bun
datorat modelului de preuri bazat pe abonamente. Clienii SaaS pot exercita un control
mai bun asupra vnztorilor dect n cazul modelului tradiional. Clienii SaaS ptesc un
abonament recurent strict pe durata termenului agreat cu respectivul furnizor. Furnizorii
SaaS sunt i ei supui termenelor lunare agreate prin Service Level Agreements (SLA), i
sunt financiar motivai s menin cerinele suport i operaionale adecvate. Furnizorii de
software tradiionali sunt pltii direct printr-o tax de liceniere n schimb. Aceasta
nseamn c ei au puine obligai odat ce aplicaia software este instalat.
Ca un rezultat, exist un control mai bun al furnizorilor SaaS dect n cazul
comercianilor de produse n varianta tradiional. Dac un serviciu SaaS nu funcioneaz
corect, clienii, prin simplu act al retragerii de la plat i exercitarea SLA-urilor, pot avea o
influen mai mare asupra furnizorilor SaaS pentru a furniza corecii aplicaiei dect n
cazul modelului tradiional.

3. Software- as- a- Service (SaaS) i AWS

Dup cum s-a prezentat, Software- as- a Service (SaaS) este practic un model de
livrare a aplicaiei ce permite utilizatorilor utilizarea de soluii software direct peste Internet.
Modelul de costuri SaaS se bazeaz cel mai adesea pe abonamente pltibile lunar, funcie
de chiar resursele folosite de utilzator sau o tax fix repetabil al un interval tipic de o
lun sau chiar un an. Furnizorii SaaS sunt atrai de Amazon Web Services (AWS)
aceasta reprezentnd o platform ideal pentru business-ul SaaS propriu al acestor
companii deoarece modelului de costuri bazat pe resursele folosite din AWS i
posibilitatea redimensionrii resurselor la cerere se aliniaz perfect cu modelele de costuri

23

Software as a Service (SaaS)

i operare presupuse de SaaS. Prezentm n cele ce urmeaz o serie de aspecte de

business i tehnice urmrite n instalarea unui produs SaaS pe AWS. Pe parcursul
expunerii, vom prezenta comparaii cu mediile alternative de business, bazate pe colocalizare i gzduire conform modelului tradiional.
3.1. Aspecte de business
SaaS prezint un numr de probleme unice comparativ cu modelul tradiional de
producere a aplicaiilor software. n special furnizorii sunt forai s in cont de:
Gestiunea fluxurilor financiare
Modelele de costuri bazate pe abonamente, prin contrast cu modele de liceniere
continu, nu au o zon de ctiguri mare, direct, ce apare odat cu achiziionarea de noi
clieni. Clienii pltesc taxe mai mici, recurente, de-a lungul intervalului de timp stipulat n
contract. Atunci cnd se alege o platform gazd aceasta este o diferen ce trebuie luat
n considerare. Mediile tradiionale necesit mari investiii iniiale de capital necesare
producrii infrastructurii necesare, nainte ca mcar un singur client s fi fost atras.
Previzionarea cererii naintea folosirii devine o activitate necesar n acest caz, ceea ce
conduce la dou riscuri legate de business: dac business-ul va merge mai bine dect se
ateapt atunci numrul de servere previzionate s-ar putea dovedi insuficient pentru noii
clieni care mai i pltesc. Pe de alt parte, dac se supra-estimeaz cererea final, se
ajunge la sub-folosirea resurselor, costuri de operare fixe prea mari i, nu n ultimul rnd,
la creterea timpului necesar pentru recunoaterea unor fluxuri pozitive financiare pentru
un anumit client (a se vedea i figura de mai jos).
AWS permite furnizorilor evitarea cheltuielilor cu deinerea serverelor sau operarea
centrelor de date. Serviciile AWS permit furnizorilor SaaS adugarea sau nlturarea de
resurse dup necesiti, pe baza unor necesiti n timp-real ale propriilor soluii de
business. Acest aspect reduce semnificativ riscul de previzionare i mbuntete poziiile
fluxurilor de cash prin aceea c sunt pltite doar resursele ce sunt necesare. Serviciile
AWS pot fi consumate fr contracte privind un minim de utilizare sau angajamente de
lung durat, ceea ce ajut furnizorii s realizele o flexibilitate maxim pentru propriile
operaii de business.

24

Tranziia necesar pentru trecerea de la modelele tradiionale ctre modelele pe

baz de abonamente este pn la urm favorabil clienilor unei companii, care ajung
astfel s foloseasc costuri mai predictibile.

Figura 4.13. Comparaie ntre centrele tradiionale de date i AWS.

Suport redus cu platforma

Un model de livrare al serviciilor bazat pe SaaS permite unui ISV s-i dedice
resursele ctre dezvoltarea tehnologiei ce conduce la o mai mare inovaie i diferenierea
soluiilor de restul pieei. Cu un model computaional client-server distribuit, utilizatorul are
responsabilitatea construirii platformei necesare suportrii aplicaiei business. Prin urmare
exist un numr mare de posibile configuraii pe care un ISV trebuie s le certifice nainte
de a-i putea suporta clienii. S considerm de exemplu cazul unui ISV care are 10
produse, ce trebuie s suporte 10 diferite configuraii de platforme posibile (e.g., Windows
XP rulnd SQL Server pe 32 de bii, Windows 2008 rulnd SQL pe 64 de bii, RHEL rulnd
un Oracle pe OVM, un alt RHEL rulnd MySQL pe VMWare, etc.). De fiecare dat cnd un
update este disponibil pentru unul dintre produsele companiei, el trebuie testat pe fiecare
dintre cele 10 platforme diferite certificate de companie. Un update pentru toate 10
produsele software este echivalent cu 100 de variaii diverse ce trebuie testate i suportate
simultan. Modelul de livrare SaaS permite unui ISV eliberarea cheltuielilor cu tot acest
suport, i permise companiei s se focusese mai degrab pe o singur platform
suportat.
Creterea vitezei de vnzare i a satisfaciei clientului
Internetul a introdus un numr de soluii n vieile noastre personale i profesionale.
Una dintre acestea const chiar n reducerea valorii n timp. Dac vorbim de accesarea de
filme, muzic, cumprarea unei maini, descrcarea unei cri, Internetul a condus la

25

Software as a Service (SaaS)

revoluionarea modului n care clienii percep satisfacia vizavi de gratificarea instant.

Precum Cloud Computingul, SaaS permite unui ISV furnizarea acestui nivel instant de
gratificare ctre proprii clieni, precum i ctre echipele de vnzare i partenerii de
business. Totul se ntmpl astzi mai repede i cu rezultate mai bine previzionate. Astzi
directorul de vnzri al unei companii nu mai trebuie s atepte patru sptmni pentru ca
un client s achiziioneze hardware, licene de sistem de operare i spaiu n centrul de
date, dup care s instaleze i configureze aplicaia business i abia apoi s nceap
evaluarea soluiei astfel achiziionate. Realitatea e c tocmai Cloud Computingul permite
unor ISV-uri livrarea de software ntr-o manier cu adevrat la cerere. Reducerea ciclurilor
cu vnzarea de la luni la zile, reducerea timpului (i implicit a costurilor aferente) clientului
de la luni la zile, toate acestea sunt avantaje furnizate.
SaaS permite unui ISVN controlul ciclului de upgrade a produselor software. n
multe cazuri, utilizatorul final este circumspect n a migra ctre noile versiuni ale unui
produs software, tocmai datorit nesiguranei asociate cu efectuarea acestei operaii.
Acest aspect are un impact asupra ISV-ului. Clienii care nu execut operaiile de upgrade
au nevoie de suport pentru platforme legacy. Cu SaaS clientului i sunt ascunse detalii
legate de instalarea, configurarea, acitivile de backup i actualizare ale produselor
software. Prin urmare compania ISV poate s efectueze activiti de actualizare n mod
continuu a produselor software, iar utilizatorul final primete ntotdeauna cele mai noi
feature-uri, precum i pe cele mai sigure i mai performante, odat cu noile versiune ale
aplicaiei software.
Suportul pentru produsele i arhitecturile existente
AWS este unic n abordarea sa de a oferi o soluie IaaS complet orientat spre
utilitate. Deoarece AWS furnizeaz blocuri de construcie discrete ale acestei infrastructuri
computaionale de nivel sczut, companiile ISV pot folosi software i arhitecturi existente
i muta simplu ctre AWS cu un efort de re-inginerie i re-construire arhitectural limitat.
Pentru ca un furnizor SaaS s beneficieze din avantajele financiare ale unui model SaaS
el trebuie s ajung s obin amortizarea costurilor rezultate din cheltuielile cu mutarea
ntr-o alt infrastructur. Aceasta necesit rularea sistemelor la cel mai mare grad posibil
de utilizare. O companie ISVN nu i poate n general permite s dedice resurse hardware
fiecrui client i rula acele sisteme sau resurse la o utilizare de, s spunem, doar 20%.

26

Alternativa const n regndirea arhitecturii, n multe cazuri rescrierea de cod de la zero,

ceea ce evident impune cheltuieli mari. Sau, scrierea de software nou care s integreze n
final ceea ce ofer nivelul PaaS. Sau, integrarea n AWS pentru a obine beneficiile
economice ale arhitecturii multi-ocupant, fr rescrierea aplicaiei software deja existente.
Dup cum s-a precizat anterior, AWS permite unui ISVN trecerea uoar ctre noul mediu
n care fiecare client pltete exact costul cu infrastructura pe care o folosete n final.
Gestionarea timpului de uptime
O infrastructur IT fiabil i disponibil necesit ca un furnizor SaaS nu doar s
menin soluii de stocare fiabile i dispozitive de backup, dar i ca acesta s opereze o
reea fiabil folosind dispozitive de reea redundante, conexiuni de tranzit i conexiuni
fizice ntre centre de date. n plus fa de backup i reea fiabil, furnizorul SaaS trebuie s
aibp o soluie testat i funcional pentru disaster recovery. Aceasta include deployarea
datelor i aplicaiilor de-a lungul mai multor centre de date fie folosind software reziliant
la defecte, fie folosind diverse abordri mai tradiionale de genul hot/cold standby. Pentru
a oferi cu adevrat un nivel realist de disaster recovery, toate centrele de date i serverele
incluse trebuie s fie utilizate constant; dac acestea stau ntr-o stare idle, e aproape sigur
c ele nu vor funciona la nivelul dorit odat cu activarea dintr-o stare cu un cold start.
Furnizorul SaaS trebuie s in cont att de costuri ct i de complexitatea asigurrii
redundanei atunci cnd evalueaz soluiile deployate. AWS include toate acestea n
costurile minimale de folosite i permite clienilor s efectueaz simplu activiti precum
deployarea de servere n oricare regiune a lumii (de la coasta de est a USA pn n
Singapore). n cadrul unei regiuni, un ISV poate mai departe furniza disponibilitate
propriilor aplicaii prin deployarea de mai multe servere n cadrul mai multor Zone de
Disponibilitate, ceea ce ofer abilitatea de a rmne rezilient n faa mai multor posibile
tipuri de defecte, inclusiv cele naturale sau system failures.
Furnizarea unui mediu sigur de execuie
Un alt cost direct pentru un furnizor SaaS atunci cnd execut aplicaii este legat de
asigurarea confidenialitii, integritii i disponibilitii unor date critice de business.
Exemple ale costurilor aferente securitii pentru un furnizor SaaS includ cheltuielide
capital cu dispozitive de securizare a reelei, licene cu produse software de asigurare a
securitii, parteneriatul cu o organizaie specializat n servicii de securitate, costurile
asociate cu evaluarea soluiilor de securitate, necesitile de securitate fizice, smart carduri pentru controlul accesului, etc. Pentru a furniza securitate i intimitate end-to-end n

27

Software as a Service (SaaS)

Cloud, AWS construiete servicii conform celor mai bune practici i norme din domeniul
securitii, i documenteaz clar modul n care dezvoltatorii pot folosi corect aceste
aspecte. Clienii AWS pot folosi avantajul soluiei Amazon de a furniza o infrastructur
computaional fiabil i sigur pe scar larg. Pentru mai multe informaii legate de
soluiile AWS de securitate putei consulta i materialul Amazon Web Services: Overview
of Security Processes10.
Costurile cu operarea
AWS trece n cadrul furnizorilor ca o soluie de scdere a costurilor de operare, la
scara de operare oferit de Amazon. n plus fa de costurile legate de servere, putere i
infrastructura de reea, costurile legate de personal sunt de asemenea incluse. Aceasta
include costurile cu echipele de gestiune a infrastructurii IT necesare pentru
managementul acestor resurse hardware eterogene i tot ciclul de furnizare a resurselor,
operarea centrelor de date, mutare, scalarea i gestiunea creterilor fizice a resurselor de
operare, etc. toate acele lucruri pe care serviciile AWS le realizeaz n numele
furnizorilor SaaS.

10

aws.amazon.com/security

28

Figura 4.14. O arhitectur tradiional de aplicaie Web.

Arhitectura SaaS peste AWS

Arhitecturile SaaS sunt adesea variaii ale modelului clasic tip Three-tier Web
Application (figura de mai jos prezint acest model). Prioritile pentru proiectare sunt
legate adesea de fiabilitate, securitate, disponibilitate, performan i costuri. Pentru a
ilustra acele best practices pentru deployarea acestui model pe AWS vom prezenta nti
arhitectura Web tradiional.

Aplicaia Web tradiional

Figura 4.14 prezint un exemplu clasic de arhitectur tradiional de gzduire a
unei aplicaii Web scalabil.Aceast arhitectur Web tradiional este construit n jurul a
trei nivele ce separ arhitectura de prezentare, aplicaie i nivelul de persisten. Aceast
arhitectur a fost proiectat cu scopul de a scala prin adugara de noi resurse n cadrul
nivelelor de asigurare a persistenei sau aplicaiei, i are inclus caracteristica de

29

Software as a Service (SaaS)

performan, redundan la defecte i disponibilitate. S vedem acum cum se mapeaz

aceast arhitectur pe serviciile Cloud disponibile n AWS.
Arhitectura Cloud AWS pentru gzduirea de medii SaaS
Figura 4.15 prezint i cazul unei arhitecturi clasice Web (similare celor pe care cei
mai muli furnizori SaaS se bazeaz astzi).

Figura 4.15. Un exemplu de arhitectur Web suportat n AWS.

3.2. Componente cheie ale arhitecturii de gzduire a aplicaiei Web n AWS

Prezentm n continuare componentele cheie ale acestei arhitecturi de gzduire a
unei aplicaii Web n AWS i modul n care acestea difer de cazul arhitecturii tradiionale.
Edge caching
Edge caching, o tehnic folosit pentru a mbunti performana sistemului de
companii precum Akamai, Limelight sau n serviciul Cloudfront al Amazon11, nu difer
semnificativ atunci cnd folosind infrastructura Cloud AWS. Orice soluie existent, de

11

http://aws.amazon.com/cloudfront/

30

fapt, ce respect modelul Web tradiional ar trebui s funcioneze la fel inclusive pe Cloudul oferit de AWS. O opiune suplimentar furnizat totui de AWS const n folosirea
serviciului Cloudfront pentru edge caching, n cazul aplicaiilor ce folosesc Elastic IP (a se
vedea cursul anterior).
Migrarea unei aplicaii Web ctre AWS necesit modificri la nivelul DNS-ului. AWS
furnizeaz un serviciu de management DNS, numit Route 53, dar dezvoltatorii tot trebuie
s cear explicit un numr de IP-uri Elastice (adrese IP statice ce pot fi asignate n mod
dinamic unor instane EC2 ce ruleaz). Un nou cont AWS poate cere cinci astfel de adrese
IP Elastice pentru nceput, dar poate cere mai multe dac e nevoie. Dup cum se poate
observa n Figura de mai sus, aceste adrese IP pot fi asignate unor Entry Points publice
ale aplicaiei Web, i se pot configura intrri DNS ctre aceste adrese. Catalogul de nume
de domenii folosit pentru cumprarea numelui de domeniu furnizeaz un mecanism simplu
pentru setarea acestei liste de adrese IP i tot traficul de intrare va fi, ntr-o manier roundrobin, balansat ntre aceste adrese IP elastice nregistrate.
Control accesului
Diferit de un model de gzduire Web tradiional, n AWS nu exist un firewall de
grani care s controleze traficul ntre centrul de date. De fapt, fiecare staie EC2 are un
firewall local ce poate fi configurat pentru a specifica modul de acces. Acest lucru se
realizeaz prin intermediul aa numitelor Grupuri de Securitate, ce permit specificarea de
protocoale, porturi i IP-uri surs ce pot trimite trafic ctre staiile EC2. Grupurile de
securitate pot chiar referenia alte grupuri de securitate sau pe ele nsele pentru a limita
accesul la staii EC2 ce sunt n anumite clustere. De exemplu, n cadrul arhitecturiii AWS
de gzduire a unei aplicaii Web, clusterul de servere Web ar putea permite accesul doar a
oricrei staii peste TCP ce folosete oricare dintre porturile 80 sau 443 (HTTP i HTTPS),
i ar putea permite accesul din partea grupului de securitate Application Server pentru un
management dierct al staiei. Clusterul Application Server, pe de alt parte, ar putea
permite accesul doar dinspre grupul de securitate Web Server pentru gestiunea cererilor,
i din partea unei anumite subreele peste TCP pe portul 22 (SSH) pentru management
direct al staiei. n acest model personalul de ntreinere s-ar putea loga direct pe serverele
aplicaiei din reeaua intern a companiei i apoi accesa clusterele din alte servere de
aplicaii.

31

Software as a Service (SaaS)

Balansara ncrcrii ntre clustere

O resurs comun n cadrul gzduirii aplicaiilor Web este reprezentat de prezena
unui load-balancer. n Cloudul AWS nu exist resurse de reea, ceea ce reprezint i
motivul pentru care arhtiectura AWS de gzduire a aplicaiei Web are o instan EC2 ce
ruleaz un load balancer software. Furnizorul are de asemenea opiunea de a se integra
cu Serviciul Amazon de Elastic Load Balancing, ce distribuie automat trafic de intrare al
aplicaiei ntre mai multe instane Amazon EC2. Elastic Load Balancing are capabilitatea
de a detecta instane cu probleme din cadrul unui pool i reruta traficul n mod automat
ctre instane funcionale, pn cnd instanele cu probleme sunt restaurate. Clienii pot
activa Elastic Load Balancing din cadrul unei singure Availability Zone sau de-a lungul mai
multor zone pentru a obine performan chiar mai consistent.
n mod alternativ, clienii pot deploya propriile soluii de balansare a ncrcrii, sau
pot folosi dintremai multe pachete disponibile pentru a obine aceast capabilitate. Cele
mai comune soluii constau n folosirea HAProxy12, care e disponibil gratuit i care
furnizeaz mai multe opiuni de configurare a serverului Web i balansrii ncrcrii n
cazul serverelor de aplicaii. Aceasta reprezint o instan n cadrul arhitecturii Cloud
AWS, deoarece acesta ofer abilitatea de a folosi noi staii dinamic provizionate sau
nlturate n mod dinamic. AWS include de altfel i suport pentru auto-scalare, balansare a
ncrcrii i monitoriozare13.
Gsirea altor staii gazd i servicii
O alt modificare fa de arhitectura de gzduire a aplicaiilor Web tradiional
const n ceea c cele mai multe staii au asignate adrese IP n mod dinamic. Doar acele
staii din Cloud-ul AWS avnd IP-uri elastice (EIP) vor avea endpoint-uri predictibile pentru
comunicaiile peste reea. O soluie simpl la aceast problem const n meninea
centralizat a configuraiei staiilor i a endpoint-urilor serviciilor de reea necesare.
Deoarece cele mai multe arhitecturi de aplicaii Web conin un server de baze de date,
care e tot timpul pornit, acesta poate fi folosit i ca repository pentru stocarea acestei
configuraii. Folosind acest model staiile nou adugate pot cere lista de endpoint-uri
12

http://haproxy.1wt.eu/

13

http://www.allthingsdistributed.com/2008/10/using_the_cloud_to_build_highl.html

32

necesare pentru comunicaie bazei de date, ca parte a procesului de bootstrapping.

Locaia bazei de date poate fi furnizat ca parte a datelor transferate n timpul lansrii
instanei.
Suportul de cache n cadrul aplicaiei Web
Orice soluie de cache software din cadrul arhitecturii aplicaiei Web existent
trebuie s fie modificat pentru mutarea n cadrul Cloud-ului AWS. Simpla construire a
unei instane EC2 cu soluiile cache este suficient pentru a permite aceast facilitate n
Cloud. Nivelul de cache al aplicaiei Web poate fi astfel efectuat, i i n acest caz
configuraia centralizat gestionat n cadrul bazei de date poate ajuta aplicaia i servere
s descopere resursele cache corecte.
Configuraia bazei de date, backup i failover
Multe aplicaii Web conin anumite soluii de asigurare a persistenei, i adesea
acest lucru se realizeaz prin intermediul unei baze de date. AWS include suport pentru
un numr mare de soluii de baze de date, inclusiv pentru MySQL, Oracle, SQLServer i
DB2. Nu doar c aceste pachete de baze de date ruleaz pe staii EC2, dar ele includ de
asemenea soluii de liceniere ce suport Cloud, ceea ce rezolv multe dintre problemele
de liceniere din jurul produselor baze de date. Precum n modelul de gzduire tradiional,
soluiile de baze de date din Cloud ar trebui s includ instane master i slave pentru a
suport activiti de backup i failover. Clienii AWS pot folosi o serie de modele
master/slave i de replicare pe instanele EC2, incluznd mirroring pentru copiile read-only
i transferul logurilor pentru instanele slave offline. Adesea aplicaiile Web au soluii
specifice de backup i modele de fault tolerance, ns sunt multe anse ca toate acestea
s poat fi uor folosite ca atare i n Cloud-ul AWS. Dup cum se prezint n arhitectura
AWS de gzduire a aplicaiei Web, folosirea mai mult Zone de Disponibilitate (AZ) pentru
un al doilea slave responsabil pentru failover se recomand pentru maximizarea
disponibilitii bazei de date. Folosirea celei de-a doua zone de disponibilitate este similar
cu a avea un al doilea centru de date de backup, deoarece fiecare AZ este separat
complet pentru a asigura o disponibilitate maxim. Un alt aspect de luat n considerare
atunci cnd rulm mai multe baze de date pe EC2 const n disponibilitatea discurilor
pentru toleran la defecte i persisten. Se recomand ca bazele de date ce ruleaz pe
AWS EC2 s foloseasc volume Elastic Block Storage (EBS), care sunt similare unor
soluii de stocare n reea pentru rularea instanelor EC2. Pentru instanele EC2 rulnd o
baz de date, toate datele bazei de date, logurile i soluiile temporale de stocare ar trebui

33

Software as a Service (SaaS)

s fie pstrate n volume EBS, care rmn disponibile chiar dac baza de date gazd se
defecteaz. Aceasta permite rezolvarea unor scenarii de failover precum lansarea unor noi
instane EC2 n cazul defectrii unor staii, iar volumele EBS pot fi simplu ataate noilor
instane pentru a permite bazei de date s reia din punctul n care s-a produs defectul.
Volumele EBS furnizeaz automat mirror ntr-o variant de baz, ceea ce conduce la
creterea disponibilitii. Este de asemenea recomandat folosirea concatenrii mai multor
volume EBS pentru creterea performanei IOPS pentru staiile ce menin baza de date.
Deoarece nivelul bazei de date reprezint o component stabil i care trebuie s ofere
disponibilitate n cadrul arhitecturii Web, ea poate fi folosit i pentru stocarea i gestiunea
configuraiei arhitecturii Web n cadrul AWS. n cadrul Cloud-ului AWS, staiile i serviciile
pot fi aduse n picioare i nlturate la cerere, iar adresele de reea nu sunt cunoscute
apriori lansrii aplicaiei, ceea ce necesit ca staiile s se bazeze pe comunicaia ntre
gazde folosind un serviciu de configuraie specializat.
Amazon ofer de asemenea un Relational Database Service (Amazon RDS), ce
faciliteaz setarea, operarea i scalarea unei baze de date relaionale n Cloud14. Serviciul
furnizeaz capacitate redimensionabil ntr-o manier cost-efficient, cu administrarea
automat a activitilor bazei de date, eliberarea focusului spre aplicaie i business mai
degrab dect pe astfel de activiti.
AWS ofer de asemenea serviciul SimpleDB (SDB), ce furnizeaz un serviciu de
baz de date simplu, cu garanii de disponibilitate i toleran la defecte, pentru
interogarea i indexarea datelor ce nu necesit o schem fix. SimpleDB poate fi o soluie
de nlocuire a bazelor de date n cazul managementului informaiei de configurare pentru
arhitecturi Web ce nu au un nivel stabil de persisten.
Stocarea i salvarea datelor
Exist numeroase opiuni n Cloud-ul AWS pentru stocarea, accesarea i salvarea
aplicaiilor Web i a datelor acestora. AWS Simple Storage Service (S3) furnizeaz o
soluie de stocare fiabil pentru pstrarea fiierelor avnd o dimensiune de pn la 5GB.
Aceasta este o soluie perfect pentru salvarea de obiecte relativ statice, precum date

14

http://aws.amazon.com/rds

34

grafice sau media. S3 suport servicii de cache prin intermediului serviciului CloudFront. n
plus, instanele EC2 pot avea volume Elastic Block Storage (EBS) ataate, ce pot aciona
ca discuri locale pentru execuia instanelor EC2. EBS este perfect pentru date ce trebuie
accesate la nivel de blocuri de date i care necesit persisten n afara instanelor ce
ruleaz, precum n cazul partiiilor de baze de date i logurilor de aplicaii. n plus, n afar
de faptul c ofer persisten, copiile volumelor EBS pot fi salvate n S3, ceea ce poate fi o
soluie pentru salvarea unor instane ce ruleaz pentru conservarea strii serverelor.
Volumele EBS pot avea o dimensiune de pn la 1 TB, i mai multe volume EBS pot fi
concatenate pentru a oferi volume chiar mai mari, avnd o performan IOPS mrit.
Soluii RAID folosite mpreun cu volume EBS sunt deosebit de utile ca baze de date ce
ruleaz n EC2, deoarece ofer fiabilitate i performan prin intermediul tehnicii de
concatenare a mai multor volume. O alt caracteristic folositoare a concatenrii
volumelor EBS este aceea c ele pot fi folosite pentru crearea mai multor volume EBS
pentru ataarea la mai multe instane ce ruleaz.
Auto-scalarea
Una dintre diferenele cheie ntre arhitectura Web AWS i modelul tradiional de
gzduire este reprezenta de abilitatea de a scala dinamic aplicaia Web la cerere, pentru
a face fa unui trafic mrit sau n scdere. Curent, rmne la latitudinea dezvoltatorului
aplicaiei Web gestiunea aplicaiei Web. Un model de efectuare a funciei de scalare
const n utilizarea gazei ce ruleaz baza de date pentru scalare. Dac baza de date
deine de asemenea datelor de configuraie, atunci acest aspect permite unui singur host
s scaleze ntreaga flot de resurse i actualizarea propriei configuraii. Auto-scalarea
poate fi uor realizat prin intermediul API-ului EC2, ce permite lansarea, terminarea i
inspectarea instanelor. Declanarea scalrii flotei st complet la latitudinea dezvoltatorului
de aplicaiei, dar un model simplu ar putea s se baze la fel de bine pe fiecare dintre
diverse staii gazd (e.g., servere Web, balansoarele de ncrcare, servere de aplicaii,
etc.) s raporteze propria ncrcare i alte statistici de performan ctre o component de
monitorizare rulnd pe un server baz de date. Aceast component ar putea apoi s
adauge sau s nlture servere pe baza disponibilitii i ncrcrii acestora. De exemplu,
daca serverele Web raporteaz o utilizare CPU peste 08%, atunci un server suplimentar
Web ar putea fi repede instalat i apoi aduga gazdei pe care ruleaz balansorul de
ncrcare. Odat ce serverul Web rspunde corect verificrilor de URL provenite de la
balansorul de ncrcare, acesta ar putea prelua locul acestuia n rotaia ncrcrii, astfel
nct viitoare cereri pot fi acum service de acest nou instalat server Web. Aceeai
35

Software as a Service (SaaS)

capabilitate poate fi folosit pentru gestiunea unor scenarii de defectare. De exemplu,

dac componenta de monitorizare primete actualizri ale strii din partea Load Balancer
#1, atunci Load Balancer #2 poate fi reconfigurat pentru adugarea de gazde n spatele lui
Load Balancer #1 pentru o perioad de timp. Odat ce o nou gazd a fost instalat
pentru nlocuirea lui Load Balancer #1, atunci Load Balancer #2 poate fi din nou
reconfigurat pentru a avea setul original de gazde.
Gestiunea defectelor cu AWS
Un alt avantaj cheie al folosirii AWS comparativ cu gzduirea Web conform
modelului tradiional const n aceea c disponibilitatea unor zone de disponibilitate uor
de gestionat ce permit dezvoltatorului aplicaiei Web accesarea mai multor centre de date
pentru instalarea de staii virtuale. Dup cum se poate observa n arhitectura AWS de
gzduire, se recomand mprtirerea unor staii EC2 de-a lungul mai multor zone AZ,
deoarece aceasta furnizeaz o soluie uoar de a face aplicaia Web tolerant la defecte.
n timp ce sunt cteva modificri arhitecturale semnificative ce trebuie asigurate pentru
migrarea unei aplicaii Web existente n Cloud-ul AWS, exist o serie de mbuntiri
asupra scalabilitii, fiabilitii i costurilor ce pot fi asigurate direct odat cu utilizarea
Cloud-ului AWS.
Consideraii arhitecturale suplimentare
Atunci cnd migrm ctre Cloud-ul AWS exist o serie de diferene cheie fa de modelul
de hostare tradiional. n seciunea anterioar au fost prezentate o serie de consideraii
cheie ce trebuie cunoscute atunci cnd instalm o aplicaie Web n Cloud. n continuare
prezentm o serie de modificri arhitecturale cheie ce trebuie avute n vedere atunci cnd
dorim mutarea unei aplicaii n Cloud.
Nu exist instalaii de reea
n Cloud-ul AWS nu exist reele ce pot fi deployate. De exemplu, firewall-uri, rutere i
balansoare de ncrcare pentru aplicaiile AWS nu pot sta pe dispozitive fizice cel mult
ele pot fi adresate folosind soluii software. Exist o serie de soluii de calitate pentru
fiecare dintre aceste probleme, fie c ele constau n soluii de load-balancing (e.g.,
HAProxy) sau stabilire a conexiunii peste VPN (e.g., OpenVPN). Asta nu reprezint
neaprat o limitare a ceea ce poate fi rulat n Cloud-ul AWS, ci mai degrab o modificare
36

arhitectural ce trebuie inclus n aplicaia Web dac se dorete n final utilizarea acestor
dispozitive.
Firewall-uri
Dac n modelele mai tradiional era suficient folosirea unui DMZ i comunicaia
open ntre staii rulnd n acelai mediu, AWS impune un model de securitate mai strict,
conform cruia fiecare staie este complet securizat. Unul dintre paii n planificarea unei
instalri AWS const n analiza traficului ntre staii i a porturilor ce trebuie s stea
deschise. Grupurile de Securitate din cadrul EC2 pot fi create pentru fiecare tip de staie
din arhitectur, i pot fi folosite o serie de modele de securitate pentru a permite accesul la
minim ntre staiile componente ale arhitecturii.
Mai multe centre de date disponibile
Zonele de Disponibilitate din EC2 trebuie gndite sub forma mai multor centre de
date. Ele sunt separate logic i fizic i mpreun furnizeaz un model uor de folosit pentru
deployarea aplicaiei de-a lungul mai multor centre de date aspect necesar pentru
asigurarea disponibilitii i fiabilitii.
Dinamicitatea staiilor disponibile
Probabil cea mai important mutare n modul n care putem gndi arhitectura
aplicaiei AWS const n aceea c gazdele EC2 trebuie considerate ca fiind efemere i
dinamice. Orice aplicaie construit pentru Cloud-ul AWS nu trebuie s asume c o staie
va rmne ntotdeauna disponibil i c tim c orice date locale (ce nu rezid n volume
EBS adic) vor fi pierdute odat cu apariia oricrui defect. n plus, atunci cnd o nou
staie este pornit nu putem face nici un fel de presupunere asupra adresei IP sau locaiei
acesteia n cadrul unui AZ. Aceste aspecte foreaz gndirea unei configuraii mai flexibile
i o abordare solid a pasului de bootstrapping a staiei, tehnici critice pentru construirea i
rularea unei aplicaii scalabile i tolerant la defecte.
Abordri pentru gestionarea arhitecturii multi-ocupant
Aspectul arhitectural fundamental ce trebuie considerat cnd proiectm aplicaia
SaaS const n decizia asupra modului de lucru n modelul multi-ocupant. O posibilitate de
gestiune a acestui model const n folosirea virtualizrii ca un mecanism pentru separarea
modulelor aplicaiei. O alt opiune const n construirea unei aplicaii ce are un strat de
separare logic a datelor construit la fiecare nivel arhitectural.

37

Software as a Service (SaaS)

Urmtoarea diagram prezint strategia pentru provizionarea unui mediu separat

SaaS pentru fiecare client, ce ia n considerare practicile anterior prezentate:

Aceast abordare are sens pentru o aplicaie SaaS ce va fi construit din

subsistemele unei aplicaii existente single-ocupant sau un software mpachetat. Este uor
de folosit virtualizarea n AWS pentru crearea unor aplicaii SaaS separate provizionate
per client. n funcie de dimensiunea i necesitile fiecrui client, acestea pot fi uor
compensate printr-o micro-instan EC2 ce gzduiete ntreaga aplicaie, sau un grup de
mai multe instane EC2 pentru fiecare client.
Dac aplicaia SaaS este construit de la zero, are sens crearea unei singure
aplicaii ce are caracterul multi-ocupani integrat n fiecare nivel al arhitecturii. Aceast
abordare va conduce la o utilizare mai eficient a resurselor disponibile i va permite o mai
mare flexibilitate n operarea infrastructurii. ns dezavantajul const n faptul c
aboradrea impune dificulti de proiectare i implementare. Urmtoarea diagram prezint
aceast abordare:

38

3.3. Construirea unei applicaii peste Salesforce.com

CODA este o companie software ce a activat n sectorul produselor financiare
software mpachetate sub forma serviciilor nc din anii 1970. Compania s-a aliat cu
organizaii precum HP, Digital Equipment Corporation i IBM. n plus, compania a folosit
noile platforme ce au aprut (produsele sale au fost adaptate de la staii mainframe pn
la arhitecturi client-server de-a lungul timpului).
La un moment dat CODA a vzit avantajul mutrii n domeniul SaaS. Mutarea pe o
nou platform s-a bazat pe un plan ambiios de a face pentru produsele financiare ceea
ce Salesforce.com a reuit s fac pentru produsele CRM. n special s-a apreciat
potenialul SaaS ca o metod de a construi relaii cu clienii mai rapid dect prin vnzrile
realizate cu produsele software instalabile local. nainte de a se decide s foloseasc
sForce (platforma de dezvoltare a Salesforce.com), compania a efectuat o analiz a
costurilor vs. beneficii.

39

Software as a Service (SaaS)

Cea mai mare problema consta n scrierea codului de la zero i totul n cadrul
companiei. Managementul dezvoltrii a realizat c ar trebui s scrie cod pentru un mediu
multi-ocupant ce ar necesita civa ani de munc pentru a conduce la crearea unor servicii
corecte.
Deoarece nu au putut justifica astfel de cheltuieli i costurile impuse pentru
dezvoltare, dezolvatorii CODA s-au focusat pe o serie de aspecte legate de client, precum
procesele specializate din diverse alte domenii. Dar, spre deosebire de alte companii mai
mici ce au construit peste sForice, CODA este o companie mai mare ce servete alte
companii medii. Salesforce.com are nevoie de CODA la fel de mult precum CODA are
nevoie de ei. Salesforce.com avea nevoie s dovedeasc piaei c propria platform ar
putea suporta o asemenea aplicaie major. Aplicaia companiei CODA e de asemenea n
acord cu o asemenea relaie ce ar putea conduce la salvarea de timp i bani. Aa c, la
scurt timp, CODA a scris propria aplicaie folosind limbajul similar Java al celor de la
Salesforce.com, limbaj numit APEX. Prin urmare, compania a migrat definitiv pe platforma
Salesforce.com cu aceast mutare. Din perspectiva marketingului, mutarea a constituit n
final un plus, i asta i pentru c Salesforce.com a ajutat compania CODA s acceseze o
pia compus acum inclusiv din clienii vechi ai platformei Salesforce.com.

Bibliografie
[Armbrust2009] M. Armbrust, A. Fox, R. Griffith, A. D. Joseph, and R. Katz, Above the
Clouds: A Berkeley View of Cloud Computing, UC Berkeley Reliable Adaptive
Distributed Systems Laboratory White Paper, 2009.
[Assuncao2009] M. D. de Assuncao, A. di Costanzo, and R. Buyya, Evaluating the cost
benefit of using cloud computing to extend the capacity of clusters, in Proceedings
of the 18th ACM International Symposium on High Performance Distributed
Computing (HPDC 2009), Munich, Germany, 2009, pp. 141 150.
[Buyya2009] R. Buyya, C. S. Yeo, S. Venugopal, J. Broberg, and I. Brandic, Cloud
computing and emerging IT platforms: Vision, hype, and reality for delivering
computing as the 5th utility, Future Generation Computer Systems, 25:599 616,
2009.

40

[Rittinghouse2009] J. Rittinghouse, J. Ransome, Cloud Computing: Implementation,

Management and Security, Editia 1, Ed. CRC Press, 2009.
[Sotomayor2008] B. Sotomayor, K. Keahey, and I. Foster, Combining batch execution and
leasing using virtual machines, in Proceedings of the 17th International Symposium
on High Performance Distributed Computing, 2008, pp. 87-96.
[SaaS2006]

Software-as-a-Service

Executive

Council,

Software-as-a-Service;

Comprehensive Look at the Total Cost of Ownership of Software Applications, A

White Paper, September 2006.
[Amazon2010] Amazon Web Services, Software- as- a- Service (SaaS) on AWS, Business
and Architecture Overview, White Paper, September 2010.
[SIIA2004] SIIA, Software Division & Tripletree, Software as a Service: Changing the
Paradigm in the Software Industry, White Paper, July 2004.

41