Denne artikel stammer fra det trykte Computerworlds arkiv. Artiklen blev publiceret den CTO d. 3. november 2006.
Werner Vogels Først forsker i distribuerede systemer. Nu øverst teknisk ansvarlig for Amazon.com.
Den store, lidt kraftige mand i Århus Musikhus har lige holdt et langt indlæg om Amazon.coms forretning og den underliggende tekniske platform.
Anledningen er den årlige udviklerkonference JAOO, som afholdes af det danske softwarefirma EOS. Der blev talt meget forretningsmodel samt forretningspartnere og ikke så meget teknik. Det er dog ikke fordi taleren, Werner Vogels, er en marketing-droid, der ikke kender teknologien. Tværtimod.
Som forsker på Cornell University i New York stod han i spidsen for en række forskningsprojekter, der undersøgte skalerbarhed og robusthed i store distribuerede it-systemer.
I januar 2005 fik han brug for at omsætte sin forskning til virkelighed, da han blev øverste tekniske chef for Amazon.com. Han gik fra det måske lidt beskyttede forskermiljø til en øretævernes holdeplads, hvis Amazon.com af den ene eller anden årsag er utilgængelig for de mange millioner aktive brugere.
Han virker dog ikke bekymret. Ganske som Amazons website virker Werner Vogels robust. Han er ikke ukendt med den kommercielle verdens krav og var blandt andet medstifter af firmaet Reliable Network Solutions i 1997. Men rollen som CTO hos Amazon er den absolut største i sin karriere.
I en no-nonsense-stil ridser han udviklingen af Amazon.com's it-infrastruktur op:
- I 1995 bestod Amazons teknologiske platform af en hjemmelavet applikationsserver og en database som backend. Amazon.com var én stor monolitisk applikation. Ret tidligt var det en udfordring at få databasen til at skalere. Den blev hurtigt en flaskehals, fortæller Werner Vogels.
Der gik mange år, hvor det var en daglig kamp at få Amazon.com til at levere ordentlige svartider til den voksende skare af Amazon-brugere.
- Der var fokus på at få databasen til at fungere ordentligt, samtidig med at den skulle indeholde stadig flere kunder, flere produkter, flere ordrer og understøtte stadig flere sprog. I 1999 gik Amazon over til at anvende HP's Superdome, der virkelig skulle kunne skalere. Det løste dog ikke problemerne, siger han.
Det var først, da Amazon.com begyndte et redesigne hele arkitekturen bag websitet, at problemerne med skalerbarhed, tilgængelighed og performance for alvor blev løst. Redesignet baserede sig på services.
- Det var en servicerevolution. En serviceorienteret arkitektur var den eneste måde at udvikle software-komponenter hurtigt og uafhængigt af hinanden. Med serviceorientering mener vi, at data indkapsles i forretningslogik, og den eneste adgang til data foregår gennem et offentligt serviceinterface. Der er ingen direkte adgang til databasen fra applikationerne, og deling af data mellem de forskellige services er heller ikke tilladt, siger Werner Vogels.
Ifølge Werner Vogels var servicerevolutionen med til at forandre Amazon fra at være en applikation til at blive en teknologisk platform, hvorpå der kan bygges et hav af forretningsmodeller og applikationer.
- Hvis vi kun solgte vores egne ting, ville vi være en applikation. Men folk kan genbruge vores teknologi og udvikle deres egne webshops, der trækker på vores services, siger Werner Vogels.
Den serviceorienterede arkitektur er i dag livsnerven for Amazon.com. Dels er den interne tekniske infrastruktur hos Amazon.com bygget op af services, dels anvendes webservices til at give tusindvis af tredjepartsudviklere adgang til Amazons platform og på den måde udvide forretningsmulighederne for Amazon.
Werner Vogels skønner, at der i dag er en million små og store websites, der anvender Amazons webservices til at vise bogoplysninger, priser og andre oplysninger fra Amazon frem på deres egne websites.
Den øverste chef for Amazon, Jeff Bezos, har, trods det store antal websites, der anvender Amazons web- services, kaldt dem for "det gemte Amazon". Werner Vogels gør sit for at få Amazons webservices frem i lyset.
- Vi gør services og vores data tilgængelige via Amazon Web Services e-commerce-services. Det er gratis for udviklere at anvende webservices-interfacet, og de kan bygge deres egne applikationer ovenpå. Der er omkring 150.000 af den slags udviklere, og det er vigtige kunder for os, siger Werner Vogels.
E-commerce-services er blot en af 10 forskellige hovedgrupper af web-services, der er tilgængelige for udviklerne.
- Vi tilbyder SOAP- og REST-interfaces til vores kunder. REST-interfacet anvendes som regel af PHP-applikationer, mens SOAP anvendes af Java og .Net-applikationer. Vi har ikke haft brug for hele WS-*-stakken. Vi bruger dog WSDL (web services description language, red.) som beskrivelsesformat for services. Vil vi tilbyde flere WS-standarder? Kun hvis vores kunder beder om det og det har de ikke gjort, siger han og tilføjer, at WS-security nok vil blive anvendt i Amazons infrastruktur.
Werner Vogels vil helst undgå de mange WS-*-standarder, som WS-ReliableMessaging og WS-Notification. Ikke fordi han mener, at standarderne er dårlige, men fordi han foretrækker at holde tingene simple.
- Hvis du skal kunne skalere, skal du holde det simpelt, siger han.
Det er en sætning, Werner Vogels gentager et par gange i løbet af vores samtale.
Skalerbarhed og robusthed var nogle af nøgleområderne for Werner Vogels forskning, og det har han ført med til Amazon. For at opnå de to vigtige egenskaber for Amazons website sværger han til simpelhed.
For meget kompleksitet gør det sværere at øge systemets kapacitet, så det kan håndtere en forøgelse af brugerforespørgsler. Simple systemer er nemmere at skalere til en voksende brugermængde.
Samtidig betyder stor kompleksitet, at et system bliver mindre robust. Det øger risikoen for fejl og kan betyde, at systemet går ned. Noget som ikke må ske for en forretning, der er hundrede procent afhængig af sin tilstedeværelse på nettet.
Werner Vogels er dog realistisk i sit forhold til drømmen om det perfekte website, der aldrig fejler. Det eksisterer ikke.
- Amazon.com fejler hele tiden. Det kan være fejl i alt fra memory-chips over en server til et helt datacenter. Det er ikke interessant, hvor mange gange der er nedbrud. Det er interessant, hvor lang tid et nedbrud varer. Hvis vi har et udfald på et par sekunder, betyder det ikke så meget, som hvis udfaldet måles i timer. Vi bygger så vidt muligt autonomi ind i vores arkitektur. Enhver komponent skal helst være i stand til at træffe uafhængige beslutninger og må ikke være afhængige af andre, siger han.
Med et serverantal, der skal tælles i titusindvis, har Amazon nogle ganske særlige udfordringer. Normalt har man eksempelvis et testmiljø, der afspejler et produktionsmiljø, hvor nye services og applikationer kan prøvekøres, inden de slippes løs. Det kan Amazon ikke.
- Vi ikke bare kan bygge et testdatacenter, der minder om vores produktionsdatacenter. Test i et meget stort distribueret miljø er en kæmpe udfordring. Vi har også udfordringer, når det handler om udrulning af software og indhold. Der er ingen nemme løsninger, siger Werner Vogels.
En hjælp er at holde alting så simpelt som muligt.
- Hvis du virkelig vil have databasen til at performe, skal du anvende den som persistent store og ikke andet. Hvis din database ikke vil skalere, så vil resten af applikationen heller ikke. Vær sikker på, at databaselaget holdes på et simpelt niveau. Hvis du introducerer kompleksitet vil det ikke kunne skalere, når du prøver at tilføje nye servere, siger han.
Af samme grund har Amazon valgt såvidt muligt at standardisere databaselaget. Her er Oracle førstevalg.
- Hvis du virkelig skal fintune datalaget og sørge for skalerbarhed, så er det godt at basere sig på én type af databaser. Oracle leverede den første kommercielle database til Linux, så vi kører Oracle og så Berkeley DB (som blev købt af Oracle i starten af året, red.), siger Werner Vogels.
Amazon anvender Red Hat Linux som operativsystem. På applikationsserversiden er der friere spil.
- Vi er rimeligt agnostiske. Vi har bygget vores egen applikationsserver. Vi har Tomcat. Et par enkelte steder anvender vi JBoss, siger han.
Da jeg spørger, om Amazon så bruger Enterprise Java Beans (EJB), reagerer Werner Vogels voldsomt.
- Oh no, EJB is evil, man, skraldgriner Werner Vogels, mens han med to fingre gør korsets tegn for at holde det onde væk.
- Nej, EJB er ikke nødvendigvis ondt, men generelt er der få ting, som skalerer rigtig godt og er robust. Der er generelt mere kompleksitet i transaktions-managere og EJB.
Faktabokse:
Blå it-bog
2005: Vice President og CTO hos Amazon.
2003: Forskningsleder på Cornell Universitet.
1997: CTO og medstifter af Reliable Network Solutions.
1994: Ph.d. fra Vrije Universitet i Amsterdam.
1989: Ingeniøruddannet fra Haagse Hogeschool i Haag.
Amazons udvikling
Udviklingsgruppen, der har skabt en ny service, sætter den i produktion og vedligeholder den. Udviklerne behøver ikke at bruge et bestemt udviklingssprog, men skal kunne levere et serviceinterface til deres program.
C++ og Java er de mest udbredte programmeringssprog sammen med Perl.Ruby begynder at vinde indpas.
Der anvendes ikke PHP på Amazon-platformen, men mange tredjepartsudviklere bruger PHP til at programmere op mod Amazons webservices.
Web-services
Amazon har i år frigivet en række webservices, der illustrerer, at Amazon ikke kun er en boghandel, men en teknologisk platform.
Amazon har længe tilbudt adgang til Amazons E-commerce Service, der giver adgang til Amazons data. I marts begyndte Amazon også at tilbyde storage som webservice. Amazon lagde ud med S3, simple storage service, der tilbyder en simpel key/value-storage som Berkeley DB. Der er ingen låsnings- eller transaktionsfaciliteter.
En anden storageservice er SQS (simple queue service), der tilbyder en købaseret lagringsmulighed.
E-commerce, S3 og SQS er tre af i alt 10 webservices-grupper, som Amazon stiller til rådighed.
Læs mere på http://tinyurl.com/yfs6th
REST og SOAP
REST er enkleste form for webservices og er grundlæggende data, der sendes over http. Data kan være i XML eller i rent tekstformat.
Simple object access protocol (SOAP) tilføjer et beskedlag i XML-form. SOAP-beskeder består af en header og en body. Headeren benyttes af mange WS-*-specifikationer til at transportere protokolspecifikke data. Ofte sendes SOAP-beskeder over http, men er ikke bundet til http.
Billedtekst: simpelhed Werner Vogels er åbenlys tilhænger af det gamle it-mundheld: Keep it simple. Her på JAOO-konferencen i Århus. Foto: Mai Skou Nielsen
OriginalModTime: 02-11-2006 14:43:59
