I förra inlägget talade jag lite om vad molnteknik innebär och om IaaS, PaaS och SaaS. Dessutom nämnde jag fyra huvudområden som särskilt intressanta:

1. Skalbar och billig hosting (IaaS)

2. Möjligheten att snabbt skapa ett lätt serverlager för RIA med befintliga PaaS-tjänster

3. Affärsmöjligheter med SaaS

4. Bygga bättre applikationer snabbare och billigare med bra PaaS-tjänster

Låt oss titta lite på vad jag menar i detalj:

1. Skalbar och billig hosting

Denna typ av nytta är tämligen uppenbar. Om IaaS på moln är billigare (det är det oftast idag) än att köpa “vanlig hosting”, varför göra något annat? Med en IaaS-lösning kan man ju dessutom skala upp med några musklick. Vad finns det egentligen för argument som talar emot en sådan lösning? Det som oftast brukar lyftas fram är säkerhetsrisker – vågar jag anförtro åt Microsoft/Google/Amazon att handha min data och kan jag leva med att det kommer vara åtkomligt över Internet? Vidare – är erbjudandena jämförbara? Om jag köper hosting från en “vanlig” hostingleverantör får jag ju felsökningsexpertis, övervakning och hårdvarusupport.

Nå, kalla mig naiv, cynisk eller luttrad – jag påstår att felsökning bäst görs av utvecklare, övervakning/statistik/loggning av en stor IaaS-leverantör och hårdvarusupport inte alls (virtualisering!). När det gäller säkerhet tror jag dessutom att riskerna med molnlösningar gärna överdrivs. Jag ser egentligen inte varför jag ska misstro Amazon mer än vilken hostingleverantör som helst och vi pratar knappast om att flytta de system vi behöver ha fysiskt frånkopplade från Internet till molnet. Tvärtom brukar akilleshälen säkerhetsmässigt vara mänskliga rutiner och handhavanden och skillnaden är knappast särskilt stor i det avseendet mellan alternativen ovan. Möjligen borde en IaaS-lösning lättare kunna stå emot DoS-attacker eftersom temporär storskalning är ett alternativ.

Kommer då verkligen Googles/Amazons/Microsofts paket att hota idag etablerade hostingpartners? Vi får väl se, men en annan faktor att ta med i beräkningarna är hur aktörer som Microsoft och Google säkerligen kommer utforma sina utvecklingsmiljöer så att de hänger ihop med hosting. Ett klick i Eclipse eller Visual Studio och så är man igång. För att inte tala om varför du ska använda tjänster genom Microsofts Live Services eller söka data genom Googles egna sökspråk. Lycka till att hitta en annan hostingleverantör som kan erbjuda det.

2. Möjligheten att snabbt skapa ett lätt serverlager för RIA

Nyligen hade vi en kund som skulle göra en grafiskt avancerad flashapplikation med spel och tilltalande interaktionsdesign. Men det fanns också ett behov att spara lite speldata och hämta listor över resultat från olika länder. Små snabba utsökningar helt enkelt. Med traditionell webbteknik hade man behövt

a) Definiera format för datautbyte (i XML/JSON)

b) Exponera webbservices eller REST-liknande tjänster

c) Bygga ett datalager som kan persistera objekten och göra utsökningar enligt kriterier

d) Hantera säkerhet och åtkomst till data och funktioner

e) Utreda lastkrav och kravspeca en hostingmiljö

f) Hitta en hostingleverantör som uppfyller kraven

g) Deploya applikationen

Utgår man däremot från en färdig skalbar PaaS-tjänst med datalagring, rättighetssystem och REST-sökningar är det bara en fråga om en spec till Flashleverantören. Visst förenklar jag en aning, men faktum är att kostnaden minskar dramatiskt för att ta fram lösningen. Med PaaS-tjänster som också utvecklas med nya kundprojekt kommer plattformarna bli mer och mer kompetenta och fler och fler projekt kommer kunna se det mesta löst i en redan utrullad applikation. Man kan redan idag återvinna kod och komponenter, men för att verkligen minska kostnaderna i a) – e) ovan behövs återvinning på en högre nivå.

3. Affärsmöjligheter med SaaS

Med lite tekniska begrepp på plats kan man fundera på övergripande trender i webb- och mobilvärlden. Med SOA, mobilt internet och den alltmer vanliga attityden att inte göra allt själv ser framtiden för SaaS ljus ut. Inte bara ljus – SaaS-tjänster som använder andra SaaS-tjänster som i exempelvis mashuptjänster blir vanligare och vanligare. För att vara konkret – jag kan hyfsat lätt göra en Salesforce-site som använder Google Maps och kopplar in en kommunikationskanal från Google Wave för att styra min Twitter som också syns på Facebook. Konsekvensen blir att Molnet (Internet) blir mer sammanvävt när tjänsterna använder varandra. Mer och mer sammanvävning kommer kräva och framtvinga enklare och snabbare integrationsmöjligheter. Och om integration blir lättare kommer tjänsteinriktad arkitektur kunna användas mer. Det blir lätt och affärsmässigt fördelaktigt att skapa små tjänster som bara gör en sak, men gör den bra – lite som en komponent i dagsläget. Vi kan ex. göra rena systemfunktioner som bildomskalning och -konvertering på molnet, eller bild- och videospelare i Flash som en mjukvarutjänst. Återanvändning kan fungera på en högre nivå än genom dagens komponenter.

Mashups och återanvändning på hög nivå kommer att bli mer vanligt, vilket betyder att det också blir viktigare att hålla koll på vilka tjänster som finns. Teknikbyråer måste inte bara  prioritera omvärldsbevakning än högre utan också komma till rätta med en helt ny typ av problem. Låt oss ta ett exempel: idag publicerar kanske en redaktör ett pressmeddelande via ett CMS på sitt företags hemsida, med bilder och filer inlänkade från funktioner i CMS:et. Möjligtvis exporteras detta pressmeddelande via RSS till en nyhetssajt och i bästa fall tittar redaktören efter någon timme hur pressmeddelandet ter sig på nyhetssajten. Men om vi tar de här SaaS-principerna på allvar och tillåter oss att blicka framåt en aning – varför ska redaktören nöja mig med funktioner för bilder och filer i CMS:et? Det finns ju utmärkta bildfunktioner hos Splashup och Flickr. Kan CMS:et erbjuda en förhandsvisning på nyhetssajten innan publicering? Hur är det med länkar och beroenden mellan tjänster? Förstör hon något om hon tar bort sidan? Här finns onekligen affärsmöjligheter att skapa bättre tjänster och tillägg för en webbteknikbyrå.

4. Bygga bättre applikationer snabbare och billigare med bra PaaS-tjänster

Det här inlägget har hitills handlat rätt mycket om teknisk återanvändning – den industriella princip som möjliggör mer kvalitet till mindre kostnader. Låt mig få ta en liten avstickare till bilbranschen som jag lånar från David Chapell: 1905 gick var och en till sin lokala bilhandlare och beställde sin bil. Det skulle vara specialutformade strålkastare, kromdetaljer på egenutvalda ställen och kundanpassade detaljer till höger och vänster. Sen kom en viss Ford (inte Harrison) och vände upp och ner på världen – “Välj vilken färg du vill bara den är svart”. Poängen var initialt att fler hade råd med bilen, men naturligtvis också att det gick att producera oändligt mycket bättre bilar i alla avseenden när det fanns ordentlig teknisk återanvändning (med specialiserade underkonsulter). En detalj som inte ska glömmas i industrialiseringsprocessen är också gemensamma standarder för alltfrån hjulupphängning till spänningsnivåer till bilstereon.

Nu tillbaka till mjukvaruvärlden. Parallellen är uppenbar: jag menar att vi befinner oss på 1905 års nivå. Vilket leder oss in till frågan varför vi i så fall inte kommit längre med teknisk återanvändning trots ca 40 års integrationsarbete med klasser, bibliotek, dll:er, komponenter, assemblyn och tjänster. Ett tappert försök är förstås att i Fords anda göra som Google Apps: “Gör vilken webbplats du vill bara den innehåller enkelt innehåll och ser ut som vår standardmall”, men fint eller flexibelt blir det i dagsläget inte. Låt oss titta på ett annat exempel:

Låt oss säga att jag vill ta fram en webbshop. Jag kan förstås utgå från en befintlig – kanske en open-source-variant. Eller så kan jag köpa en tjänst som hos starweb.se och anpassa min webbutik så mycket som deras system möjliggör. Oavsett vilket vill jag kanske ha andra delar på min sajt med spännande funktioner, och så vill jag kanske använda ett bra CMS för att administrera övrigt innehåll. Mina produkter finns idag redan i en databas på egna servrar och som används av några butikssystem. Dessutom säljer jag kanske produkter som tjänar på en häftig 3D-visning i Flash och det vill jag ha på hemsidan. Sen vill jag att andra ska komma åt mina produkter via XML över REST för tredjepartstjänster. Men jag vill ju också ha modern HTML som är anpassad till moderna krav på tillgänglighet och SEO. Dessutom kanske det vore fint med en lite anpassad vy för iPhone/Android. Och jag vill inte låsa in mig i något konstigt teknikhörn! Borde inte det gå ganska lätt att göra – någon vecka eller två? Tyvärr vet alla som har implementerat webb att så inte är fallet.

Problemet är helt enkelt att alla inte riktigt är överens om hur man bygger webb. Hur ska man kunna ha en rigorös policy för HTML om de komponenter man köper styr HTML-renderingen. Svaret blir att allt får anpassas och då går konsultklockan. Vi är fortfarande en ganska bra bit från helt separerad återanvändning, där olika delar gör sin specialiserade del och all arkitektur är standardiserad. Tills dess kommer konsulter sälja många timmar på att göra liknande saker om och om igen. Men PaaS är ett steg på vägen i rätt riktning. Vi ska inte heller glömma tekniker som CSS 3, REST, HTML 5, funktionella språk, javascriptramverk som jQuery m.m.. Men i slutändan handlar PaaS mycket om att vi utvecklare ska lämna tekniska beslut till Microsoft, Google m. fl. Vi kommer inte kunna styra över detaljer i hur loggning görs i webbservrar, hur databaser ska klustras, hur url-strategin ser ut för att REST-exponera vår datamodell – kanske i slutändan inte ens hur HTML renderas. Och det är något bra! PaaS via moln innebär lite lite mer enhetligt svart, men i förlängningen mycket bättre och billigare webb!