Community om cloud computing

Som man kunne læse forleden på Computerworld.dk, har CA Technologies lanceret et community site om cloud computing. At det er CA, der opretter sitet, er naturligvis mistænkeligt, alene af den grund, at de har omfattende interesser i cloud computing. Ser man bort fra ophavet, er det dog naturligvis interessant, at der er et sted på nettet, hvor cloud-brugere kan poste deres erfaringer, selvom det svarer nogenlunde til at anbefale bilmærker på tværs af kloden. Der er da heller ikke sket meget på sitet de første to uger, det har levet.

Der er enorme forskelle på, hvilke behov, den enkelte kunde har, og hvordan den enkelte leverandør – endda i det enkelte land – kan imødekomme disse behov, også selvom vi taler så generisk en platform, som cloud computing. Bevars, skal man bare bruge en Windowsserver, er der nok ikke stor forskel på, om man kommer fra Nigeria, Norge eller New Mexico. Men så snart, vi begynder at se på, hvad serveren skal bruges til, kommer forskellene frem.

Som vi har skrevet om tidligere (her og her bl.a.), er der stor variation mellem lovgivningen om databehandling og -opbevaring på tværs af landegrænserne, og dermed også mellem, hvilke vilkår hos leverandørerne, kunderne kan leve med. På den anden side er der naturligvis også helt enslydende spørgsmål, man stiller til en driftsleverandør, f.eks. hvor høj, deres faktiske oppetid er, og hvor let, det er at arbejde med deres managementplatform. Det sidste kan man naturligvis selv ‘komme uden om’, da de fleste også tilbyder command line værktøjer, hvorfor man kan bygge sig sit eget værktøj, hvis man synes. Men det er næppe der, ens cloud anvendelse starter.

Er man derimod en rigtig hård hund i cloud-verdenen, og har man brug for meget detaljeret ‘mikrostyring’ af ressourcerne, kan det f.eks. være interessant, hvor lang tid (målt i sekunder typisk), det tager at få en server i luften – og nedlægge en. På CAs community site kan man få en forsmag på, hvordan tværgående måleværktøjer kan komme til at se ud i fremtiden. Der er tale om en såkaldt ‘cloud sensor’, der – uden tvivl baseret på command line kald – måler svartiderne på en række services op til flere gange i timen.

Som det fremgår, er der bl.a. målinger af tre populære on-line e-mailplatforme (Hotmail, Gmail og Yahoo! mail), men også mere seriøse målepunkter som netop server create time og server destroy time, dog kun hos Amazon. Mange af leverandørerne er meget flinke til at offentliggøre deres oppetid og tilgængelighed, men det er nok i realiteten mere på mikroniveauet, at de vigtige forskelle mellem leverandørerne vil træde frem.

Spændende er det i hvert fald, at der begynder at dukke både communities og værktøjer op, som kan holde øje med cloud leverandørerne og deres services. Det er efter vores vurdering endnu et vigtigt skridt imod en modning af markedet, et lille nøk mere i retning imod version 2 af cloud computing.

3 kommentarer til “Community om cloud computing”

  1. Bjarne Schjølin siger:

    Indledningsvis: et fint initiativ.
    Jeg undrer mig over at Pactor indleder indlægget d. 24.5.2010 under ‘Drift, Leverandører’ (“Som man kunne læse forleden på Computerworld.dk, har CA Technologies lanceret …”) med en kritik af, at CA har oprettet et cloud-forum? Der er vel intet angribeligt i at de gør det, også selv om de har en egen interesse i at etablere et sådant site? Pactor har vel også en egeninteresse i at etablere et cloud-forum 🙂
    En anden kommentar: de ’seriøse målepunkter’ der henvises til i artiklen vedr. create/destroy-time for servere: er det særlig interessant for kunden at interessere sig for? SÅ hurtigt ændrer de færreste leverandørers services og efterspørgslen efter dem sig næppe, at det er antallet af sekunder der spiller en reel forretningsmæssig værdi. Det interessante er for mig at se, i hvilket omfang ofte isolerede cloud services er i stand til at blive leveret via en cloud-portal, hvor der er sikret sammenhæng mellem cloud-services. Det kræver testede og reelle datainterfaces mellem de isolerede services, med en harmoniseret SLA overfor kunden, der vælger en vilkårlig delmængde af de udbudte cloud-services. DET er en udfordring at skabe! Problemet med mange cloud-services er at de tilbydes som helt isolerede services. Skal der skabes sammenhæng mellem bare 2 forskellige services er det kunden der skal betale for interfacet! Og hvis servicen fra hver af de 2 cloud-leverandører koster 300 kr. pr. måned, så koster interfacet måske 50.000 kr. at udvikle! Eksempel: kunden ønsker at modtage service fra en cloud leverandør af et økonomisystem + supplere det med at modtage service fra en cloud leverandør af et fakturaflowsystem. De to services skal naturligvis kunne sende/modtage data for at det giver mening. interfacet skal kunden betale, for der er ofte ikke noget – og så opgiver kunden inden kunden er gået ind i cloud-verdenen med konklusionen om, at dette er hypet foilware, der ikke kan vælges fra skyen og sammensættes til en sammenhngende platform under forretningen! Det leder frem til, at cloud leverandørerne skal gå sammen i portaler, hvor der er sikret interface, så kunden uanset hvilke del-services der udvælges til at understøtte forretningen, så er interfacet i orden. Ska der interfaces til proprietære applikationer og databaser er det jo noget helt andet: så er der større forståelse for, at det skal specialudvikles.
    Mvh Bjarne Schjølin

  2. Bjarne Schjølin siger:

    Generelt: kommentar-vinduet er at for lille – man mister overblikket over sin kommentar-tekst, med mindre man skriver 2 liner :-)Får den åbnet i fuld bredde som den ovenstående tekst, og gør den minimum dobbelt så høj.
    Mvh Bjarne Schjølin

  3. ClausQ siger:

    @ Bjarne Schjølin

    Tak for dine indsigtsfulde og inspirerende kommentarer. Det var ikke intentionen at implicere urent trav hos CA Tech., men blot minde læserne om, at man skal gå til kilderne med passende skepsis, således naturligvis også til CloudWatch.dk!

    Du har ret i, at målepunkterne ikke er særligt interessante for de fleste kunder; jeg forventer blot, at der over tid vil blive udviklet applikationer, der dynamisk håndterer oprettelsen og nedlæggelsen af instanser/services for at optimere ressourceforbruget – noget, vi allerede kender fra f.eks. databaseverdenen i mere primitiv form – og kommer vi dér op i meget stor skala (jf. f.eks. Banedanmarks trafikinformationssystem), kan udsving mellem leverandørernes responstider måske gøre en forskel. Men derudover ser jeg frem til flere og mere anvendelige målepunkter i fremtiden!

    Jeg er meget enig i din betragtning omkring interfaces mellem services. Dette er en af de væsentligste årsager til, at vi kan risikere at opleve ‘vendor lock-in’ også i cloud computing. De fleste serviceudbydere stiller både IaaS og PaaS til rådighed, og har man købt ind på f.eks. en afviklingsplatform, tager man formentlig også datastorageplatformen med i købet. Her er interfacet simpelt og veldokumenteret. Men hvis du prøver at køre en applikation fra én platform-provider og storage fra en anden, kan det blive meget langhåret – og dyrt. Som med så meget andet it: hvis du blot bliver inden for leverandørens teknologistak/applikationsportefølje, fungerer alting fint, men hvis du vælger mix’n’match har du balladen – og i øvrigt ansvaret selv.

    Jeg tror ikke, vi i første omgang kommer til at se serviceportaler på tværs af leverandører; jo, hvis en tilpas stor leverandør, der ikke nødvendigvis har egne varer på IaaS- og PaaS-hylderne, beslutter sig for det, kan der komme noget anvendeligt, men overheadet til den leverandør for levering af ‘leverandøruafhængige’ services, vil det nok være svært at argumentere hjem i direktionslokalerne – så er det trods alt nemmere at bruge én leverandør (af gangen).

    Mvh, Claus Qvistgaard

Dansette