OPTIMERA STHLM! Martin Källström

[00:00:01] Speaker A: Hallå allihopa! Hörs jag bra eller? Först skulle jag vilja säga att nu hörs jag, eller hur? Det är jättekul att vara på en utvecklarkonferens. Det är så mycket skitsnack som pågår i andra delar av stan medan vi sitter här och har kul. Först skulle jag vilja fråga, hur många är det här som anser sig jobba på ett företag som använder

[00:00:26] Speaker A: molntjänster, upp med en hand. Och kan man då få också en snabb överblick på hur många som anser sig ha viss kompetens inom att jobba med molntjänster? Okej, så inte så jättemånga. Då kanske det kan vara så att jag faktiskt kan bidra med någonting. Det är jätteskönt. Och

[00:00:52] Speaker A: sen är det så att jag ska para ihop det här med att prata om skalbarhet och det är ett helt annat ämne egentligen, fast de hör ihop. Vad heter det här att jag inte har någon bild här? Är det någonting man kan göra åt? Det här funkar inte, eller? Den

[00:01:22] Speaker A: här bilden är en illustration. Vi ser ett tåg som har fått en ganska stor user base. Då kan man fråga sig, ett tåg, är det skalbart eller inte? Själva infrastrukturen, arkitekturen som ligger till grunden för ett tåg, är det skalbart eller inte? Och det är ju

[00:01:47] Speaker A: faktiskt därför man kan ju faktiskt lägga till fler vagnar när det kommer fler användare till tåget. Så man kan ju faktiskt lägga till i stort sett hur många vagnar som helst, därför att man kan lägga till lok också som drar de där vagnarna om det behövs. Om det blir riktigt, riktigt många användare. Det som däremot inte är så skalbart är perrongerna. De är ju så att säga gjutna i sten och längden på dem när

[00:02:12] Speaker A: man får fler vagnar än ången är stor så så så tar på något sätt slut. Det är lite grann som att man måste köpa ett server rack till och då kan man däremot fungera. Fundera på om ett tåg är det en bra metafor för en molntjänst eller inte? Skulle man kunna säga att SJs tåg är driftare i molnet

[00:02:38] Speaker A: och Det skulle jag säga att de inte är. För det är ganska mycket jobb att köpa in en ny vagn. Det är inte så att det sitter någon på SJ och bara klickar. Så kommer det fram fler och fler på spåret. Så jag tycker att det här tåget är ett jättebra exempel. De behöver skala upp det här tåget. Det är helt uppenbart. Men de har inte gjort det med en arkitektur som innebär att de bara kan klicka fram nya

[00:03:03] Speaker A: vagnar. Är det någon som tycker att den metaforen inte var extremt tydlig och bra? Så upp med en hand. En person. Bra, men det var egentligen allt jag hade att säga om molntjänsters skalbarhet. Jag kan i och för sig berätta lite om hur vi jobbar med molntjänster på Twingly också. Jag kan inte utge mig

[00:03:28] Speaker A: för att vara en expert på på skalbarhet med en expert på vad vi gör på Twingly för att skala våra tjänster. Det som hände på Twingly februari 2007 var att då hade vi, jag vet inte om ni vet hur Twingly startade. Behöver jag presentera lite grann vad vi gör och sådär? Vi har ju en tjänst för tidningar som innebär att de kan automatiskt

[00:03:54] Speaker A: länka tillbaka till bloggar. Det började vi utveckla exakt för fyra år sedan. Fyra tekniker som började i Linköping. Det vi gjorde var att vi utvecklade en widgetlösning dit vi publicerade bloggdata. Och så tänkte vi att den här skulle vi lägga på all världens nyhetssajter. Problemet var bara att då behövde vi hantera den kombinerade trafiken av

[00:04:19] Speaker A: alla de här nyhetssajterna. För vi var ingen mjukvaruproducent. Vi ville inte sälja en mjukvara som driftades utåt kunden. Utan det skulle vara en tjänst som kan man säga var driftat i molnet. Det skulle vara en molntjänst även om den terminologin inte fanns då så var det så vi tänkte. Vi fick först DN som kund och sedan SVD några veckor senare. Det

[00:04:44] Speaker A: var på hösten 2006. På våren 2007 började vi prata lite med DN. Ska ni inte ta och publicera er tjänst? Har köpt in nu. Ni ligger och betalar varje månad. De sa att det är några projekt som ligger före och sådär. Men vi ska snart publicera den. Sen sa vi samma sak till Svenska Dagbladet. Men vi var lite oroliga över att Svenska Dagbladet skulle lansera före DN. För DN hade ju faktiskt varit före med att signa upp. Så det skulle

[00:05:09] Speaker A: vara lite snopet för dem. Om det kom någon annan Twinglykund och var först i Sverige med att lansera Twingly. Så skrev Svenska Dagbladet i en blogg så här att snart kommer det hända roliga saker kring bloggvärlden här på sved.se. Och då fick DN panik och tänkte nu har SVD någonting liknande Twingly på gång. Och så la de ut sin tjänst och då såg SVD det och så la de ut sin anmälna Twingly, sin

[00:05:34] Speaker A: implementation. Så att både SVD och DN lanserade samma vecka, två dagar efter varandra. Båda hävdar att det var den andra tidningen som lanserade först. Men det sågs som en revolution för hela bloggvärlden för att plötsligt så demokratiseras media på det sättet att bloggarna nu kunde få uppmärksamhet från från tidningar så att det var vad som hände. Det här till exempel en en kille

[00:05:59] Speaker A: som heter Micke Barsik som var väldigt tongivande i bloggsfären då för för tre år sedan som skrev om hur hur bra tyckte Twingly var. Det var väldigt många som skrev om. Och sen har det där rullat på. Vi har nu inte bara DN och Svenska Dagbladet utan i stor mängd sajter. Det är 115 sajter som använder

[00:06:24] Speaker A: Twingly idag i tio länder runt om i Europa. Och det är små och stora. Och jag kan säga helt ärligt att vi driftar De här 115 kunderna, vi hanterar alltså de här sajternas sammanlagda trafik på exakt samma lösning som vi lanserade för tre år sedan som då klarade av DN och Svenskans sammanlagda trafik. Det

[00:06:50] Speaker A: här är inget svårt, det skulle vem som helst kunna göra och jag ska berätta hur. Det hade vi aldrig klarat av att göra om det inte fanns möjlighet att placera saker i molnet. Så då kör vi tillsammans cirka 300 miljoner visningar per månad av den där lilla widgeten som visar vilka

[00:07:15] Speaker A: blogglänkar som länkar till varje artikelsida. Är det någonting som är oklart av det hittills jag sagt, några frågor, så får ni jättegärna avbryta mitt i. Kan man fråga sig vad skalbarhet är för någonting? Jag

[00:07:41] Speaker A: tänker på skalbarhet ur de här tre aspekterna. Att för att en tjänst ska vara skalbar så ska det vara så att den. Den så att säga. Klara av att växa utan att arbete och resurser måste tillföras i allt större mängd när trafik

[00:08:06] Speaker A: och data växer. Man kan alltså tänka sig att en webbtjänst får väldigt mycket användare eller att den får väldigt mycket data att hantera. Det som ska hända då är att arbete och serverkapacitet inte ska slå i taket. Den mängd arbete och serverkapacitet som krävs för att drifta den här sajten. Det där kräver väldigt att man tänker till verkligen

[00:08:31] Speaker A: från början för att uppnå det där. För att om man bara bygger en tjänst som helt naivt som fungerar jättebra för en användare så innebär det inte alls att man bara kan öka kapaciteten genom att lägga till fler servrar. Utan då måste den förmågan finnas inbyggd från början. Och

[00:08:58] Speaker A: man kan också definiera skalbarheten genom att tänka på vad det inte är för någonting. Skalbarhet är alltså inte samma sak som prestanda som vi pratar om idag. Därför att en tjänst kan vara skalbar utan att sidorna laddar särskilt snabbt. För att den är skalbar innebär att när antalet användare ökar så kan

[00:09:23] Speaker A: jag behålla mina laddtider konstanta genom att lägga till servrar eller genom att köpa en större server. Det innebär alltså inte att laddtiderna för sidorna är snabba från början. Så prestanda och skalbarhet är två olika saker som man måste optimera för. Skalbarhet är inte heller hög tillgänglighet. Tillgänglighet

[00:09:48] Speaker A: innebär att sajten är driftad på ett sätt och uppbyggd på ett sådant sätt så att den fortsätter fungera oavsett vilka problem som uppstår 24 timmar per dygn, år ut och år in. Det är ett helt annat problem att lösa än vad skalbarhet är. Skalbarhet är inte heller någon viss teknologi eller plattform eller programspråk.

[00:10:14] Speaker A: Man kan inte säga att PHP är mer eller mindre skalbart än Java och inte att Java är mer eller mindre skalbart än .NET eller Python. Inte heller HTTP eller TCP eller Ajax eller Någon sådan teknologi kan sägas vara mer eller mindre skalbar än en annan. Däremot kan man använda olika teknologier för att skapa skalbarhet. Men det

[00:10:40] Speaker A: kräver fortfarande att man, om man nu vill bygga en skalbar applikation i PHP, så kräver det att man tänker på det när man bygger den. Att man konstruerar applikationen på ett sådant sätt så att man kan lägga till fler servrar för att växa. Eller så att när man lägger till en större server så drar applikationen nytta av att det finns mer datorkraft att tillgå. Det här är också väldigt

[00:11:05] Speaker A: viktigt att tänka på. Molntjänster ger inte automatiskt skalbarhet. Därför att om min tjänst är byggd så att den bara kan dra nytta av en server. Om jag lägger till en server till så finns det inget sätt som de här kan prata med varandra. Då spelar det ingen roll att jag i molnet har förmågan att kunna lägga till många servrar efter varandra. Utan om man ska drifta saker

[00:11:30] Speaker A: i molnet och har tanken att de ska vara skalbara så måste man bygga in det i arkitekturen från början så att arkitekturen vet om att det här är en applikation som driftas på flera servrar och som ska kunna dra nytta av det. När det tillkommer flera servrar. Däremot när man tänker

[00:11:55] Speaker A: kring applikationsdesign så kan man tänka kring alla de här tre komponenterna. Skalbarhet, tillgänglighet och prestanda. Det som är bra med att drifta tjänster i molnet är att man underlättar arbetet med att designa applikationen så att den Så att man optimerar de här tre egenskaperna. Kan

[00:12:20] Speaker A: vi få se en handuppräckning här? Hur många här anser sig som en del av sitt arbete ha i uppgift att förbättra skalbarheten av en applikation på jobbet? Upp med en hand. Och hur många jobbar med att förbättra tillgänglighet? Ungefär samma personer. Och sen då, hur många är det som jobbar med att förbättra prestandan

[00:12:46] Speaker A: av en applikation? Då ser vi att det är ungefär tre gånger så många som jobbar med prestanda som med skalbarhet och tillgänglighet. Och om man då tänker på de två olika sorters skalningar som jag nämnde innan, vertikal och horisontell. Är det någon som kan förklara skillnaden mellan vertikal och horisontell skalning? Har ni någon idé? Upp med en hand. När

[00:13:15] Speaker A: man tänker på vertikal skalning så tänker man så här. Vi behöver en ny server för vi har alldeles för många användare. Då köper vi en större server. Och när man får ännu fler användare så köper man en ännu större server och så slänger man den gamla. Och när man behöver få ännu fler användare så köper man en jättestor server och så slänger man den gamla eller använder den till, jag vet inte vad, ladda ner torrents med eller någonting.

[00:13:43] Speaker A: Och det där är, så att säga, kan man tänka på som webb 1.0 sättet att skala tjänster. Anledningen till att Det är så mycket mer attraktivt att skala horisontellt. Det vill säga, man börjar med en liten server och när antalet

[00:14:08] Speaker A: användare ökar så lägger man till en liten server till. Men när de byggt sin applikation så kan den dra nytta av två servrar som fungerar parallellt. Och när man behöver så lägger man till ytterligare servrar. Men man kan hela tiden behålla den befintliga arkitekturen. Det gör att varje inkrementellt steg så behöver man inte göra en jättestor investering. Investeringen blir inte större och större hela tiden. Anledningen

[00:14:36] Speaker A: till att man pratar mer och mer om horisontell skalning är att företagen som jobbar med webben blir mindre och mindre. Det går att köra webbföretag på CSN-pengar. Då är det väldigt attraktivt med horisontell skalning. Och med molntjänster. Däremot så betyder inte det att en helt modern, väldigt webb 2.0 inspirerad

[00:15:01] Speaker A: tjänst nödvändigtvis måste använda sig av horisontell skalning eller vara byggd för det. Det fanns en tjänst som hette Friendfeed.com. Hur många har hört talas om den? Ganska många. Som blev såld till Facebook som upptäckte att Deras användarbas fördubblades ungefär i samma takt som minne

[00:15:27] Speaker A: blev hälften så dyrt. Och de levde inte så länge innan de blev uppköpta. Det var bara över ett par år de kunde spåra den här trenden. Men för dem fanns det aldrig någon anledning att skala ut horisontellt. Att ta steget att bygga om sin applikation till att skala horisontellt. Därför att det fanns hela tiden resurser för dem att dubbla mängden minne

[00:15:52] Speaker A: efterhand som användarbasen dubblades. Därför att den här insatsen, investeringen att dubbla mängden minne i deras databasserver, den blev hela tiden... Efterhand som de behövde köpa dubbelt så mycket minne så blev minnet hälften så dyrt också. Så det var hela tiden en konstant nivå på den investeringen. Och det gör att man ska inte alls tänka på horisontell skalning

[00:16:17] Speaker A: som något tvång. Utan man kan mycket väl tänka på skalning som någonting man gör vertikalt. Det vill säga att behöver vi mer datorkraft så köper vi helt enkelt en större server. Det kan vara ett väldigt bra sätt att skala. Det kan vara väldigt billigt om man nu har ont om tid. Man kan lägga ner ganska mycket tid på att bygga

[00:16:43] Speaker A: en lösning som skalar horisontellt. Och är det så att man kanske aldrig får den där användarbasen som växer jättesnabbt så har man lagt ner all den här tiden i onödan. Det finns däremot en väldigt distinkt skillnad mellan de här två. Och det är att man med Några få undantag så är det så att om man ska drifta tjänster i molnet,

[00:17:09] Speaker A: som nu är ämnet för mitt föredrag, så fungerar vertikal skalning bara till en viss gräns. Därför att om man går till en molnleverantör som säljer servrar eller VPS:er eller computational units eller vad de nu säljer, beroende på leverantör. Så finns det oftast en

[00:17:34] Speaker A: ganska snäv gräns kring hur mycket mindre man kan få en sån och hur stora burkar de säljer. Så ska man skala i molnet så är det nästan alltid horisontell skalning som man måste bygga sin arkitektur för. Är det några frågor kring det? Så

[00:18:06] Speaker A: om man då tittar på skalbarhet i molnet. Om man har driftat sin tjänst till exempel på Amazon EC2 eller köpt VPS:er från svenska företag som MyCityCloud och Glesys och en rad företag. Och managed hosting från till exempel Rackspace.com och Slicehost

[00:18:32] Speaker A: och så vidare. Så är det väldigt enkelt att lägga till fler servrar. Så har man en applikation som är byggd för att så fort jag utnyttjat all serverkapacitet men behöver lite mer så kan man lägga till en enhet, en ny server för att lägga till Antingen datorkraft eller lagringsutrymme. Eller kanske bandbredd. Till

[00:18:58] Speaker A: skillnad från när man köper servrar så kan man inte bara skala upp det där utan man kan skala ner också. Vilket är en väldigt bra egenskap om det är så att man ska ta hand om trafiken kring ett event. Om man ska hosta någonting kring Melodifestivalen till exempel. Som jag ska visa exempel på att vi gjorde tidigare. Och det finns också, som jag skrivit på punkt nummer två här, möjlighet att

[00:19:24] Speaker A: använda API:er hos Amazon eller en rad olika hostingtjänster för att göra det här automatiskt. Så att man kan ha en webbapplikation som känner av i ett API att nu är prestandan på vår webbserver väldigt låg. Vi får långa laddningstider därför att det är så många användare som är inne på sajten just nu. Stort tillflöde av data. Att vi måste

[00:19:49] Speaker A: lägga till servrar. Då även om det är mitt i natten så kan man bygga en plattform som automatiskt expanderar antalet servrar och sen när de inte behövs längre ta bort dem igen. Och om man då tittar på där jag skrivit att endast horisontell skalbarhet är möjligt. Så åsidosätts

[00:20:15] Speaker A: det lite grann av den sista punkten där. Det finns också lösningar för elastisk datorkraft och lagring. Och vad elastisk datorkraft innebär är att man kan använda en tjänst där den tillgängliga datorkraften eller det tillgängliga lagringsutrymmet framstår som

[00:20:40] Speaker A: att det är obegränsat. Det vill säga, det läggs till nytt lagringsutrymme eller fler processorer automatiskt efterhand som det behövs fler. Det finns för väldigt speciella applikationer. Lagringsutrymme är den absolut enklaste saken att göra elastisk. Det finns väldigt

[00:21:05] Speaker A: bra exempel på till exempel Amazon S3. Många har talat om Amazon S3 här inne. Att man genom en tjänst får tillgång till det som framstår som oändligt lagringsutrymme med oändlig bandbredd. I själva verket är det inte så, men man säger att tjänsten är elastisk därför att det framstår så. Ju mer data man slänger på, desto mer utrymme får man tillgängligt. Sedan betalar man bara för

[00:21:31] Speaker A: exakt så mycket data eller lagringsutrymme man har utnyttjat. Och om man tittar på datorkraft så finns det också till exempel Rackspace.com har en speciell molntjänst som som om man har en applikation är någon som använt tittar på Rackspace.com. Jonas har du gjort det? Har du tittat på deras elastiska datorkraft tjänst om den kallas för en grid eller en

[00:21:56] Speaker A: någonting liknande? Lite grann. Då kan ni prata med Jonas om ni är intresserade av det där senare efteråt. Det är väldigt spännande. Man kan verkligen få känslan av att man sitter på världens största superserver för att det finns ingen mängd trafik i världen som den inte klarar av. Men då ställer det väldigt speciella krav på applikationen.

[00:22:22] Speaker A: Det kan inte vara vilken programkod som helst som körs där. Det är väl ganska snäva ramar, kanske till och med så att det måste vara statiska filer som bara ligger där. Men det får ni jättegärna titta på på Rackspace.com om ni är intresserade av en sådan tjänst som kan skala upp servicesidans prestanda automatiskt i oändlighet. Och om man tittar på tillgänglighet

[00:22:47] Speaker A: i molnet då. Tillgänglighet är precis lika viktigt som skalbarhet om man nu vill bygga Applikationer som man kan garantera för sina kunder eller användare att de finns i drift dygnet runt. Så är det generellt så att lagringstjänster i molnet har hög tillgänglighet. Det finns väldigt mycket man kan foka upp när man bygger en lagringstjänst

[00:23:13] Speaker A: och de har fokat upp det mesta och sedan fixat det redan. Så de har gått igenom den processen och det är väldigt bra så att man slipper det. Om man köper servrar i molnet eller lagring eller vad man än köper så ingår grundinfrastrukturen där. Man får allt det som står listat här och behöver inte betala extra för det i något serverhotell utan man betalar bara per enhet

[00:23:39] Speaker A: man köper oavsett om det är lagring eller datakraft. Man kan också skapa horisontell redundans. Vet ni vad den dansar för någonting? Och det är väldigt enkelt eftersom man nu kan lägga till fler servrar och bara betala för just det man använder. Det är så till och med att man man kan ha en

[00:24:05] Speaker A: en. Man kan ha servrar som har automatiskt failover så att när en server. Kanske kraschar och inte fungerar längre så kan en annan server startas upp automatiskt och ta över den kraschade serverns roll. Och lagringsutrymmet som det här datat finns på som servern använder kan finnas separat så att den nya

[00:24:30] Speaker A: servern kan börja använda det omedelbart. Om man tittar på prestanda i molnet så är det nästan är knepigast med molntjänster. Man kan väldigt enkelt öka prestanda om det är så. För det som händer oftast om en applikation blir överlastad är att prestanda sänks. Det

[00:24:56] Speaker A: vill säga att laddtiderna växer och antalet fel ökar i systemet. Om man då har byggt tjänsten så att den skalar horisontellt så kan man Tack vare att man har driftat sin tjänst i molnet så kan man lägga till fler servrar. Det där skulle vara jättebra om det inte vore så att många av de här molntjänsterna har ett visst overhead på roundtrippen

[00:25:23] Speaker A: till servrarna. Om man använder till exempel Google App Engine eller Amazon EC2 så kan det variera för att man inte får... Framstår som om de inte har placerat servrarna direkt mot nätet utan att det finns någonting däremellan som ibland förlänger roundtrippen till servrarna och kanske gör det oberäkneligt. Så att ibland är det bra, ibland dåligt.

[00:25:49] Speaker A: Och till exempel på Google App Engine så när man har lagt upp en server image där som ska svara på anrop så om den inte används, om det aldrig kommer några anrop så kommer Google avallokera den där och bara starta upp den när den behövs igen. Precis som när man startar ett program på datorn för att man ska läsa mejl eller något liknande. Då kan det bli en jättestor

[00:26:14] Speaker A: laddtid bara för att ladda upp den applikationen i minnet igen. Så om man har en applikation som inte används så ofta så kan man få jättestora laddtider. Från användarnas synpunkt sett. Där gäller det att om man nu ska använda molnet som för drift så gäller det att mäta och jämföra på olika leverantörer och jämföra och se om

[00:26:39] Speaker A: de laddtiderna man får är acceptabla. Roundtripen till servern. Och som det står här, metoden för att öka besanningen i molnet är att skala horisontellt. Det kan också göra med att man ser till att man får en gynnsam geografisk placering av servrarna. Om man använder Amazon för serverhosting så ska man se till

[00:27:04] Speaker A: att få de europeiska servrarna om det är så att man har användarbasen här i Europa. Här är då de målen emulatörerna som Twingly använder. Amazon S3 och EC2. Hetzner.de för Managed Service. Glesys för VPS:er. DNS:en har vi hos DNS Made Easy.

[00:27:30] Speaker A: Sen har vi serien från C-Networks. Och så håller vi just nu på att prata med My City Cloud. Som jättegärna vill att vi tittar på deras server. Så det gör vi. De här olika tjänsterna. Vad vi har funnit passar väldigt bra för våra applikationer. Det innebär inte att de är bäst för era. Däremot så är ni välkomna att titta på de här.

[00:27:56] Speaker A: Har ni några frågor kring de här leverantörerna så får ni jättegärna höra av er till oss. Så kan jag antingen svara på dem eller om jag inte kan så kan jag förmedla kontakten vidare till våra utvecklare. För vi vill väldigt gärna att kunskapsnivån lyfts kring sådana här tjänster. Så att fler använder dem så att de utvecklas baserat på efterfrågan. Jag tänkte visa

[00:28:21] Speaker A: hur vi använder de här tjänsterna i grova drag. Så här i väldigt grova drag fungerar Twingly Blogstream. Den här gubben med skägg är en bloggare. Vi kan kalla honom Jinge. Han publicerar sitt blogginlägg och pingar in det till Twingly som hämtar blogginlägget och stoppar in i

[00:28:46] Speaker A: vår sökmotor. För att publicera ut det här och för att klara den här stora trafikmängden som är den kombinerade trafikvolymen från alla de nyhetssajterna som använder Twingly, som är till exempel SVT, DN och Expressen. SVT och Sveriges Radio och i Norge Världens Gang och

[00:29:11] Speaker A: TV2 och ett hundratal andra sajter. Så publicerar vi det datat till Amazon S3 som är Amazons lagringstjänst i molnet. Amazon S3 är en elastisk tjänst som växer där man får tillgång till Synbart oändligt diskutrymme och synbart oändlig bandbredd. Den

[00:29:37] Speaker A: här fanns redan 2006, kanske till och med 2005. Vi anammade den för att vi såg inget annat sätt som vi till en låg kostnad skulle kunna klara av den här trafiken från Svenska Dagbladet och Dagens Nyheter som lanserade vår tjänst först. Så det vi gör är helt enkelt att vi publicerar JSON-filer och JavaScript-filer

[00:30:04] Speaker A: och bildfiler statiskt till Amazon och har en väldigt snabb uppdateringstakt där. Vilket gör att det framstår som att datat som går ut i tidningarna är dynamiskt fast det egentligen är statiskt lagrade filer. Och det har alltså en väldigt Stor fördel i att de här användarna,

[00:30:30] Speaker A: efterhand som det har vuxit och de har blivit fler, så har vi inte behövt förändra vår plattform någonting. Därför att Amazon ST har tagit hand om 100 procent av trafikökningen utan att vår plattform har behövt förändras någonting. Det enda som har förändrats är storleken på räkningen som Amazon skickar till oss varje månad. Och

[00:31:01] Speaker A: när den här bloggaren som vi väljer att kalla Jinge skickar in sitt blogginlägg, för det är oftast han som gör det, så lägger vi det på en kö och så har vi en en mängd olika servrar som hämtar det som vi kallar för tasks, alltså olika uppdrag från

[00:31:27] Speaker A: den kön och då går och hämtar hans blogginlägg och stoppar in i databasen. Det gör att vi kan lägga till fler servrar efterhand som antalet bloggar växer och vi behöver större och större kapacitet på indexeringssidan. Så kan vi lägga till fler servrar som hämtar bloggadresser

[00:31:52] Speaker A: från den här kön. Det innebär att vi på inhämtningssidan kan också skala horisontellt. Den delen har vi däremot inte i molnet, utan på helt egna servrar. Men den skulle lika gärna kunna vara på molntjänster, just eftersom vi har en kö som flera servrar kan hämta ifrån. Så kan vi skala upp indexeringssidan efterhand som det krävs bättre prestanda. Och

[00:32:18] Speaker A: om en sån här service skulle krascha genom att en disk går sönder till exempel så innebär det inte att hela indexeringen stannar för att det inte är beroende av en server utan det innebär bara att prestandan tillfälligt minskas med kanske 5 eller 10 procent just då. Om man tittar på tillgänglighet i den här lösningen så har ju Amazon en väldigt hög tillgänglighet.

[00:32:44] Speaker A: De har haft nedtid vid två tillfällen sedan 2006 när vi började använda dem. Medan våra servrar däremot för indexering har varit nere Väldigt mycket mer. Därför att vi är inte beroende av hundraprocentig

[00:33:10] Speaker A: upptid på dem för att leverera vår tjänst. För att det som krävs är att Amazon har hundraprocentig upptid på sin lagringstjänst. Och anledningen till att vi får ner tid kan antingen vara att saker kraschar och går sönder, vilket har hänt. Eller också att vi måste flytta server, vilket också har hänt. Eller byta serverkomponenter eller utföra någon typ av maintenance. Så i och med att vi har våra servrar,

[00:33:36] Speaker A: har publicerande system genom en molntjänst så får vi mycket, mycket större flexibilitet i vår driftssituation och inte alls lika höga krav på tillgänglighet som vi skulle haft om de här filerna hämtades direkt från våra egna servrar. Så det jag skulle säga är fördelarna med Amazon S3,

[00:34:02] Speaker A: det som står här, att vi kunde från början använda en tjänst som vi visste skulle klara all trafik vi slängde på den utan att klaga, utan att vi någonsin behövde åka och köpa fler servrar eller hantera frågor som var Nu går det inte att köpa en större server. Vad gör vi nu? Eller att vi inte hade råd. Vi

[00:34:27] Speaker A: får också väldigt hög tillgänglighet, men inte bara hög tillgänglighet utan också ett väldigt starkt varumärke i Amazon. De tillfällen när Amazon faktiskt har varit nere så har det varit i rubriker över hela världen därför att det har drabbat miljontals sajter, varav Twingly är en av de minsta säkert. Och den stora nyheten vid det tillfället är

[00:34:52] Speaker A: inte att Twingly är nere, utan att miljontals sajter är det. Så det är inte alls samma sak som om vi hade köpt bredband eller en lagringstjänst från Bahnhof som kanske är nere lokalt i Linköping då och då. Därför att då är det om den lagringen eller den tjänsten skulle vara nere så är det i vårt val av leverantör som vi har gjort fel. Eftersom vi valt en tjänst som inte går att lita på. Nu

[00:35:17] Speaker A: när vi har valt Amazon så är det ingen som kan klandra oss. För alla vet att Amazon är hundraprocentigt tillförlitligt. En annan fördel är att det är väldigt billigt vid små volymer. I början betalar man i stort sett nästan ingenting för lagringstjänster som Amazon S3. Nackdelar då. Det är en lagringstjänst,

[00:35:43] Speaker A: det är ingen leveranstjänst egentligen. Vilket innebär att det är långsamt och det är oberäkneliga laddtider tyvärr. Man kan inte veta om man får ner den där filen som man laddar ner på 100 millisekunder eller på en och en halv sekund. Och det är inte tänkt att man egentligen ska ladda filer därifrån. Ändå är det väldigt många tjänster som gör det. Både bildladdningstjänster och till exempel Twitter har vi i olika omgångar haft alla sina avatarer på Amazon S3. Och

[00:36:10] Speaker A: därför som det står i rött här nedanför så ska man placera ett CDN framför S3 om man ska ha tänkt använda leverans där man har krav på prestanda för att det är inte möjligt att garantera bra laddtider från Amazon S3. Och det är också så att när man kommer upp i stora volymer så inträffar två fenomen. Dels så börjar man upptäcka att det här är väldigt, väldigt dyrt helt plötsligt. Vi

[00:36:35] Speaker A: hade kunnat bygga en filserver som gör precis samma sak mycket billigare än Amazon S3 gör åt oss. Dessutom, när man har kataloger på Amazon S3 med hundratals miljoner filer så börjar det bli lite svårbearbetat för att de katalogerna inte är gjorda för det. Då börjar man komma in i uppdateringscykler där man måste

[00:37:01] Speaker A: ha specialkonstruktioner för att klara av att skala upp till väldigt mycket data eller väldigt många filer. Det finns exempel på någon utvecklare som gjorde en tjänst där han ville... Han la massor med jättestora datafiler, jag tror det var filmer, på Amazon S3. Sen visade det sig att han la upp så många

[00:37:26] Speaker A: att han började få väldigt dyra räkningar på på tusentals dollar i månaden på grund av att han hade använt mycket lagringsutrymme. Och sen satte de upp EC2 enheter för att börja deleta sådana filmer som han inte använde. Och det tog så lång tid att bara utföra deletekommandon att när han hade kört den här, kört en serverinstans en hel månad med bara deleta

[00:37:52] Speaker A: filer så hade han bara minskat. Kostnaden med 10 procent och den här minskningen var mindre än vad det hade kostat att ha servern som utförde deletningen. Så det finns problem när man börjar lägga upp väldigt stora volymer av data. Man får arbete som man kanske inte hade räknat med.

[00:38:18] Speaker A: Dessutom kan man inte på Amazon S3 få få någon support utan att betala för det som man kan på väldigt många hostingföretag. Vi betalar just nu 3000 dollar i månaden för Amazon S3. Om ni laddar ner den här powerpointen efter så kan ni se hur det är uppdelat på olika geografiska zoner och framförallt

[00:38:43] Speaker A: är det att vi har väldigt många requests. Jag tror vi hanterar Fyra miljarder filrequests i månaden och sånt där. Men totalt så betalar man för antalet requests, antalet gigabyte lagring. Vi använder väldigt lite för att det är väldigt många filer men väldigt små. Så vi har kanske en halv gigabyte data här. Men mot

[00:39:08] Speaker A: den halva gigabyte data har vi då fyra miljarder requests i månaden. För det betalar vi 3000 dollar ungefär. Det här skulle vi mycket billigare kunna hosta på en egen filserver. Jag är säker på att med bra cashmetodik så skulle man kunna sätta upp två redundanta servrar som klarar av den här trafiken. Bara leverera statiska filer som kanske

[00:39:34] Speaker A: kan driftas för 5000 spänn i månaden eller 10 000 i månaden. Inklusive serverkostnader. Men det är väldigt enkelt att ligga kvar med den här lösningen. Just eftersom det är sån trygg och säker hosting. Vi har fortfarande samma värde i att ha den här stora tryggheten. I den här lösningen. Och

[00:40:03] Speaker A: om man då ska Hantera hade det här varit grafen över användarna som accessar en tjänst som heter Twingly Live som ligger på live.twingling.com. Det här var kring Melodifestivalen när Aftonbladet ville lägga den här live tjänsten på sin första sida som har jättemycket trafik och vi var jätteglada

[00:40:29] Speaker A: under OS och Melodifestivalen. Det här är från mitten av februari till mitten av mars ungefär. Under OS hade Twing Live runt 80 000 besökare per dag, vilket vi tycker är jätteroligt med så mycket besökare. Sen körde Aftonbladet lite tester och började pumpa in tio gånger mer data, eller 500 000 besökare

[00:40:55] Speaker A: om dagen. Då blir det lite skrämmande. För att Twingly Live är nämligen så om ni tittar på live.twingly.com så använder vi de här long polling som dissades här tidigare. Och det är en teknik som fungerar jättebra. Det är ett hack. Eller rättare sagt en sammansättning av flera hack som man måste använda för olika browser. Men det

[00:41:20] Speaker A: används ändå av väldigt stora tjänster som till exempel meibo.com. Som har miljontals användare som sitter och chattar över MSN, ICQ och Skype via deras webbgränssnitt som använder långpolling för att få realtids interaktivitet. Likaså på Twinny Live så är det en Twitter Facebook ström som strömmar meddelanden kring ett event, till exempel eventet här

[00:41:46] Speaker A: idag. Kan ni se den på den här is.se/live? Och där kan ni kan ni. Då blir problemet att när det är som här hundratusentals personer som intresserar en sajt och när den sajten använder lång polling så innebär att varje besökare som inne på sidan ska

[00:42:11] Speaker A: ha en connection öppen mot mot den här sidan. Det är alltså inte bara att man gör en quest, utan man man. Man vill ha ett koppel öppet mot servern tills det kommer ny data. Det är det som kallas för longpolling. Det ställer helt nya krav på servern. Någonting som vi

[00:42:36] Speaker A: därför använde en sajt som heter Hetsner för att skala upp. Nu visar det sig att vi... När vi tittade på lösningen för att skala upp den tjänsten, Twingly Live horisontellt, så var det en för stor utmaning för att vi skulle kunna bygga det på en vecka som vi hade på oss. Vi tackade nej till Aftonbladet och sa att vi kan inte erbjuda er att ha den tjänsten på er framsida under Melodifestivalen.

[00:43:03] Speaker A: För att det är för mycket jobb på för kort tid. Vill inte göra det på en vecka, för då har vi noll tid på oss att testa efter att det är färdigbyggt innan det ska driftas. Så det tackar vi nej till. Men i princip så den principen som vi hade använt är ju helt enkelt att man har. Om man nu ska visa

[00:43:28] Speaker A: en realtidsström för en mängd användare så handlar det helt enkelt om att bygga en server, en infrastruktur där man kan lägga till fler servrar. Här visar jag tre servrar, men det skulle lika gärna kunna vara 300 då vid det tillfället man behöver väldigt mycket. Nu tror jag inte att 300 behövs. Det finns serverapplikationer som klarar tiotusentals samtidiga användare eller till och med hundratusentals samtidiga användare.

[00:43:58] Speaker A: Tillgänglighet skulle man då uppnå genom att låta användare som går mot en server som kraschar växla över till en än en av de servrarna som fortfarande fungerar. Och är det så att det är någon av er som är intresserade av den här typen av realtidsapplikationer där man strömmar data genom det som kallas för Comet

[00:44:23] Speaker A: som är alltså ett mer generellt begrepp för Ajax där servern pushar data. Om ni är intresserade av det så kommer vi att prata om det på en konferens som heter Disruptive Code i december. Jennifer är här och kan berätta mer. Vilket datum är det? 21-22 september, stämmer det? Så är det. Disruptive Code här i Stockholm som är en utvecklarkonferens

[00:44:48] Speaker A: med väldigt, väldigt mycket mer hands-on workshops än vi gör tid till här idag. Och då kan ni lära er verkligen programmerar den typen av tekniker som vi pratar om här. Fördelar med att ha datakraft i molnet på det här sättet är att man kan få hög tillgänglighet i och med att

[00:45:15] Speaker A: linor och servrar och elkraft och så vidare är redundant rakt igenom. Utan att man behöver ordna med det själv eller betala extra för det. Man kan skala upp och ner omedelbart med en knapptryckning eller till och med programmatiskt. Nackdelar med att ha servrarna driftade i molnet är att det kan kännas lite

[00:45:40] Speaker A: otryggt att inte kunna åka och klappa på dem. När man nu känner för det. Man kan inte prova så här. Men tänk om vi hade SSD diskar i istället. Då kanske vi skulle klara oss med två servrar istället för tio. Det finns inte den möjligheten att laborera på det sättet, utan man får nöja sig med en fix hårdvara och göra prestanda tester på olika leverantörer istället för att se vart man kan få ut mest kräm ur de

[00:46:05] Speaker A: burkarna man köper. Och sen så kan det vara problem med prestanda och med tillgängligheten till systemkonfiguration om det är så att man köper virtuella enheter som VPS:er till exempel. Det finns också krångel med lagring som man kan stöta på. Till exempel om man köper serverenheter så har man inga

[00:46:30] Speaker A: garantier för att de stannar uppe. Utan applikationen måste kunna leva med att de kraschar ibland och startar upp. Så data försvinner ur minnet och kanske till och med lagringen som finns på disk på den servern också försvinner. Då måste man ha en extern lagringsenhet också i molnet, men där servrarna hämtar data ifrån. Några

[00:47:00] Speaker A: problem vi har stött på. Jag behöver inte prata så jättemycket om dem, men det mesta har jag berört redan. Amazon S3 till exempel har väldigt oberäkneliga Laddtider. Det som kanske är mest intressant är det här längst ner. Det vi måste tänka på när vi betalar ganska mycket för molntjänster utomlands

[00:47:25] Speaker A: är att valutan fluktuerar ganska mycket. Har man budgeterat för ett visst belopp så kanske det blir jobbigt när svenska kronan faller 30 procent mot dollarn. Det där har vi balanserat upp genom att ha intäkter i utländsk valuta också. Det är jättebra. Det borde ni prova. Om ni har utgifter i utländsk valuta, se till att ni har intäkter i samma valuta. För

[00:47:50] Speaker A: då när kronan sjunker eller faller så förändras ju inte budgeten eftersom intäkterna balanseras mot kostnaderna om de är ungefär jämförligt stora. Så jag tror att vi har ungefär tio sekunder till frågor om det är om det är någon som är intresserad av det.

[00:48:13] Speaker B: Får jag så? Jag tror att den absolut vanligaste frågan jag fick på Twitter under den här stunden var varför du har jackan på dig och om du möjligtvis har en t-shirt där under. Ja, visst. Bra, tack! Vi kanske hinner med en fråga om det finns någon som vill fråga Martin någonting lite snabbt. Nej, men vad bra. Då har vi. Jo, där. Vad

[00:48:39] Speaker B: är det för plattform?

[00:48:42] Speaker A: Vad är det för språk vi byggt i? Vi bygger våra tjänster framför allt i dotnet, men sen har vi också lite Python, Perl, Ruby och Så driftar vi alltihopa på MSSQL, MySQL. Vi använder en sökmotor som heter Sphinx Search. Och provar

[00:49:09] Speaker A: nu lite olika Key Value Stores också. Så vi har en plattform som är väldigt bred. Vi väljer inte en teknologi utan vi väljer den open source mjukvara som passar bäst. Och så fogar vi ihop det med standardprotokoll så att allt kan prata med varandra ändå.

[00:49:27] Speaker B: Tack så mycket Martin. Jag tror att Ragnar vill komma upp och lämna en present.

[00:49:32] Speaker A: Varsågod. Nyhet från AOL här. Det är snabbt, lätt och roligt. Full internetaccess. All grafik laddas ner gradvis.

[00:49:43] Speaker B: Tack så jättemycket. Tack. Tack så mycket.