Afgelopen week werden wij op kantoor vereerd met het bezoek van Werner Vogels, cto van Amazon en een soa-expert bij uitstek. Enorm interessant om te leren hoe en waarom een bedrijf van soa uiteindelijk de core business heeft gemaakt. Elke pagina binnen de Amazon.com site is het resultaat van tientallen services die elk in een onderdeel van de pagina voorzien. Waarom is gekozen voor deze methode?
Vanuit een infrastructuurperspectief is het voordeel dat er per component geschaald kan worden. Dit kan op basis van de vraag naar dat specifieke component. Kostentechnisch veel interessanter dan een volledige monolithische applicatie te schalen. Aangezien de gehele architectuur service oriented is, kan er bij bepaalde functionaliteiten voor gekozen worden om deze ergens anders in te kopen (bijvoorbeeld advertentiefunctionaliteit bij Google). Daarnaast heeft deze aanpak als voordeel dat onderhoud en beveiliging van services veel eenvoudiger verloopt. Bij het constateren van bugs worden deze op één centraal punt opgelost, hetzelfde geldt voor beveiligingsfouten.
Amazon heeft op een gegeven moment besloten soa commercieel uit te buiten en niet zonder succes. Veel van Amazon's zelf gebruikte services zijn tegen een fee-per-usage-methode te gebruiken. De mogelijkheden zijn legio; onder andere storage, virtual computers, logistieke processen en betalingsfunctionaliteit. Infrastructuur voor componenten moet worden ingericht op basis van verwachte pieken. Door deze componenten als services te huren, of door gebruik te maken van bijvoorbeeld virtuele systemen waarop dergelijke componenten weer draaien, kan er praktisch investeringsloos worden gebouwd.
Nu rest alleen de vraag: wie gaan het durven om externe services als bedrijfskritische componenten in een architectuur op te nemen?
Eelco van Beek
Managing director
IC&S Group
Externe services hebben zeker toekomst, alles wat niet heel specifiek voor een organisatie is kan als externe service worden ingekocht, als je daarbij alles dubbel uitvoert met failover faciliteiten dan moet het zelfs voor bedrijfskritische componenten mogelijk zijn een dergelijke architectuur te gebruiken op termijn.
Hiervoor is wel standaardisatie nodig van functionaliteit zodat je functies makkelijk kan uitwisselen.
Mee eens, leuk begin is natuurlijk al CPU as a service. Op die manier kun je dynamisch schalen naar behoefte. Voor de ‘oude’ wereld erg interessant voor bijv. batch jobs. Voor de ‘nieuwe’ wereld is een omgeving volledig dynamisch in te zetten waarbij je per gewoon per daadwerkelijke CPU cycle afrekent.
Amazon loopt inderdaad voorop wat betreft SaaS achtige dienstverlening. Onlangs heeft Gartner nog voorspeld dat tegen 2012 een kwart van de applicaties ontwikkeld worden volgens het SaaS model. Ik verwacht dat als eerste de activiteiten van ondersteunende processen extern afgenomen gaan worden. Voor core business processen zal men altijd de volledige controle willen behouden. Wellicht kan het pas als de SaaS dienstverlening commodity is geworden.
Zie ook http://adi.atosoriginblog.nl