Rigtig meget varm luft!

Jeg kan jo lige så godt komme i gang, for jeg ved at de næste 6 måneder kommer til at byde på masser af 'cloud service' opmærksomhed fra min side. Der har været rigtig meget skriveri om emnet, men der har været mange 10.000 fods betragninger og meget lidt konkret.   I denne post vil jeg lægge mig i baghjulet på de højtflyvende betragtninger, men samtidigt forsøge at blive mere konkret. Det kommer formentlig til at tage et par indlæg, men det skal nok komme.

Den tidligste introduktion til emnet var forbeholdt grids og clusters og var mest til rå regnekraft i akademiske miljøer eller pålidelighed i transaktioner på relationelle databaser. Dette er også en del af cloud computing, men den del spår jeg til at blive forsvindende lille i de kommende år når snakken falder på cloud computing. Derfor kan jeg lige give en kort indledning med min egen introduktion til emnet.

Taksonomi  Der er 3 beskrivelser, som dækker de fleste applikationer der stilles til rådighed som cloud services i dag:

• *Den komplette service (Finished service)* - Online svar på 'off-the-shelf-packaged-software'. Autonome applikationer, som kan servicere en forretningsproces. Det mest basale eksempel er mail serveren (incl. mulighed for browser adgang).

• *Den tilhørende service (Attached service)* - Er typisk en service uden autonomi, men istedet tilknyttet en komplet service eller et andet stykke software (og i nogle tilfælde til en bestemt soft-/hardware kombination). Eksempler kunne være udvidet spam og antivirus service til mail serveren fra før. Uden en mail server vil den service ikke eksistere. Et andet eksempel er Windows update servicen, som uden Windows klienten ikke har berettigelse som en selvstændig service.

• *Byggeklods servicen (Building block service)* - Ofte generiske services, som er 'hjælper'-funktionalitet til andet software, services, hardvare osv. Kan f.eks beskæftige sig med storage, struktureret storage, workflow, routning, transformation, kryptering .... eller bare generel 'computing'.

  Det vil ofte ske at man kommer til at bruge karakteristika fra 2 eller alle 3 for bedst at beskrive en service, men meningen med denne taksonomi er også kun at det give et fælles referencepunkt til samtale.

Der er ingen tvivl om at vi alle, enten har eller kommer til at stifte bekendskab med 'Den komplette service' og 'Den tilhørende service' i både vores arbejds- og privatliv. En af grundene til dette er naturligvis den grad af distribution som en applikation dagligt må indgå i (ingen applikation er en ø!). 

Arkitekten og udvikleren Derimod bliver det nok kun arkitekten og udvikleren, som får direkte kendskab til de 'Byggeklods services',  som inden for de sidste par år har fundet vej til et endpoint på internettet.

Jeg kan bedst beskrive en 'Byggeklods service' ved at tage udgangspunkt i en applikation som de fleste IT professionelle har bygget på et eller andet tidspunkt: Web applikationen. Denne kan indeholde et sæt af egenskaber som vi alle sikkert har overvejet: lagdeling (n-tiers), data persistens, data strukturerering, data model, forretningslogik, præsentation, administration, AuthZ, AuthN ... osv.

Ideelt set vil jeg gerne bruge 'Byggeklods services' til at implementere egenskaber på de enkelte lag i min applikation.  Ikke fordi jeg er for doven til selv at kode det (jow, måske også derfor). Heller ikke fordi jeg skal have genbrug for enhver pris. Nej, mest fordi jeg er sikker på at der er andre i denne verden, der er bedre til at gøre det end jeg og at dette via 'Byggeblok services' kan udnyttes i min applikation.

Ydermere giver det mig en god mavefornemmelse at jeg kører på platform og teknologi, som er optimeret til at levere disse services. Det vil sige systemer og hardware, som er testet til at køre pålideligt, konsistent og tilgængeligt.

Vigtigst af alt er dog at jeg kan udnytte 'Byggeklods services' i forbindelse med etableringen af en web applikation med den agilitet jeg implicit får stillet til rådighed. Specielt det forhold at jeg ikke behøver at forholde mig til setup (og drift) af soft- og hardware for at komme hurtigt i gang og lave iterationer i udviklingsprocessen.

Det var en hel del varm luft, som kom ud af den post. I fremtidige posts vil jeg blive mere konkret og vise et eksempel på hvordan man kan tage en 'Byggeklods service' ind i en traditionel web applikation, startende i datalaget.