Kan man bygge en forretning på Cloud computing?
Jeg deltog for nyligt i Microsofts arkitekturforum om SaaS og var specielt interesseret i at forstå, om det stadig er hype og måske aldrig bliver forretningsmæssigt attraktivt eller der nu begynder at komme realiteter bag begrebet og det vil få en forretningsmæssig indflydelse.
Kort om SaaS
Udtrykket cloud eller skyen kommer fra den måde, man plejer at illustrere internettet på.
Konceptet bag SaaS er simpelt og attraktivt. Frem for at købe en softwarelicens til en applikation såsom ERP, CRM og installere denne software på individuelle maskiner, indgår en virksomhed en aftale om at bruge applikationen, der er driftet af virksomheden, der udvikler og sælger softwaren.
Det giver køberen større fleksibilitet med hensyn til kapacitetsudsving, mindre hovedbrud til at vedligeholde softwaren og hardwaren samt et mindre kapitalbehov da afregning ofte vil ske efter forbrug og ikke ved installation.
En speciel service der tilbydes i skyen, er computerkraft der udbydes via internettet og betales efter forbrug, bliver også kaldt IaaS (Infrastructure as a Service). Google, Amazon og andre tilbyder denne computerkraft-service. Microsoft annoncerede på konferencen deres Azure
Min skepsis
Jeg har hidtil været skeptisk, da det har været vanskeligt for SaaS-leverandører at tilbyde konkurrencedygtige services. Men efterhånden som:
- Nye software-design og leverance-modeller tillader at flere instanser af en applikation kan køre samtidigt i et fælles miljø, så SaaS-leverandører nu kan dele en applikation på tværs af mange virksomheder.
- Båndbredde-prisen er faldet og tillader at alle kan købe den nødvendige båndbredde til at køre applikationer on-line og
- jeg vurderer, at selve forretningsmodellen med månedlige afgifter frem for køb af softwarelicenser, vedligeholdelse-kontrakter og dyre opgraderinger vil være attraktive for mange virksomheder.
er jeg blevet nysgerrig efter, om vi snart kan se attraktive tilbud som SaaS.
Jeg blev overbevist
De to cases e-conomic og Podcastmachine overbeviste mig om, at en forretningsmodel baseret på skyen er en realitet i dag og flere mindre virksomheder udnytter i dag mulighederne.
e-conomic leverer regnskabssystem som en service via internettet og har flere tusinde virksomheder i Norden og England, der bruger e-conomic som regnskabssystem.
PodcastMachine har en strategi om, at de vil arve mest muligt og anvender Amazon?s cloud service og diverse software-produkter tilgængelig som SaaS (bl.a. e-conomic og Skype). De har ikke en server installeret.
PodcastMachine har meget få faste omkostninger og deres variable omkostninger er næsten alene afhængig af deres kunders indkøb hos dem. Altså en forretningsmodel som ikke kræver store investeringer upfront, hvor deres omkostninger og kapacitet er tæt knyttet til udsving i omsætningen og de kan fokusere på deres kerneforretning ikke administration
Nytilkomne til en industri har 30 procents omkostnings- og effektivitetsfordel
I min research til min bog fandt jeg tibage i 2004 over en analyse, der viste at indtrængningsbarrieren til en industri, er reduceret på grund af den konstant forøgede effektivitet, som nye it-løsninger giver og den lettere adgang til kunderne, som internettet har medført.
Analysen vurderer, at nytilkomne til en industri ofte har 30 procents omkostnings- og effektivitetsfordel i forhold til eksisterende virksomheder, fordi nybyggede systemer er optimeret til den moderne leverancekanal. Ineffektivitet og ufleksibilitet vil derfor straffe virksomheder hårdere.
Med fremkomsten af realistiske forretningsmodeller indenfor cloud computing, vil nytilkomne der udnytter disse muligheder have endnu større omkostnings- og effektivitetsfordel i forhold til eksisterende virksomheder, der ikke udnytter disse muligheder for øget fleksibilitet.
Fokus på læring og afprøvning
Budskabet er ikke, at man skal kaste alt over bord og straks kaste sig over mulighederne i skyen. Men hvis man ikke begynder at overveje hvordan virksomheden kan udnytte skyen, vil man mangle væsentlig viden og erfaring, når det blive mainstream.
Dette helt tilsvarende, at man i de seneste år har skullet fokusere på at opbygge erfaring og afprøvning af services muligheder for forretningen. I de næste par år er det skyens muligheder for forretningens behændighed og konkurencesituation, der skal forstås og afprøves
Kommentarer (13)
Som jeg så det (jeg var også til seminaret, som i øvrigt var ret spændende - tak til René Løhde!) havde Podcastmachine godt nok lagt deres applikation i skyen men, men, men:
Pt. er skyen temmelig vendor-specifik. Hvis podcastmachine skal flytte til en anden udbyder skal hele deres applikation kodes om, formodentlig fra bunden. Med andre ord er deres applikation svinebundet til Amazons programmeringsmodel, for den kan ikke flyttes en meter hvis Amazon bliver for dyre / ustabile / utroværdige at have som partner.
Cloud computing som "min applikation kan køre hvor jeg vil" er altså ikke specielt moden endnu. Du opnår en løsere kobling til leverandøren ved at købe en fysisk server som du så kan flytte rundt mellem forskellige leverandører.
Men det er smart at podcastmachine kan justere deres server-forbrug dynamisk i løbet af 1-2 minutter. Fx kan deres applikation afgøre om det er på tide at installere en ny instans af en server eller om der skal nedlægges en.
Helt afgørende for en forretning som podcastmachine er den utroligt lækre fleksibilitet i forhold til omkostningerne – de behøver ikke at bruge én krone som de ikke allerede har tjent. Det er hér at utility computing (som vel egentlig burde være overskriften på podcastmachine's strategi) gør den store forskel.
-
0 -
0
Jeg mener ikke platformen er så umoden som Peter antyder, og vi bliver formentligt aldrig fri for at skulle binde os til noget platform specifikt. Det er lidt som at sige at man skal mulighed for at migrere fra MySQL til en SQL server uden at kode noget om - det kommer aldrig til at ske. Heldigvis!
-
0
-
0
Njoo, sammenligningen holder ikke helt, Daniel - i tilfældet Amazon er du både bundet til programmeringsmodellen ("MySQL") OG til at have det kørene hos én bestemt leverandør.
-
0
-
0
Hej Peter,
Er det egentlig et kriterie for cloud computing at du dynamisk kan skifte leverandør af computerkraft.
Hvis det er et succeskriterie vil det tage lang tid. For det første skal leverandørene opnå enighed om behov for standarder, derefter skal de vedtages og implementeres i et antal versioner før vi kan snakke om fuld interoperabilitet
Henrik
-
0
-
0
Bindingen er vel til den måde, man kontrollerer sine instanser på.
Selve ens kernefunktionalitet (i PodcastMachines tilfælde en transcoding infrastruktur) kører på en Linux-instans, der kan instantieres alle steder. Ja, man kan sågar mounte imaget lokalt på sin Linux-maskine som var det ethvert andet image. Det er lidt ligesom at rulle sin egen distro.
Der findes p.t. en Open Source-implementation af Amazons API. Initiativet hedder Eucalyptus: http://eucalyptus.cs.ucsb.edu/
Hvis man ellers har designet sit system ordentligt, burde man ret hurtigt kunne flytte sin Amazon-baserede applikation over på Eucalyptus-baseret infrastruktur. Men cloud computing fritager desværre ikke én fra at tænke lagdeling i applikationsdesign. Øv! :-)
-
0
-
0
Peter: Hvorfor er det, du mener at man binder sig til Amazon, hvis du vælger at afvikle applikationer host dem? (Jeg antager, at du tænker på Amazon's EC2 / Elastic Compute Cloud produkt?)
Så vidt jeg kan gennemskue, er det - bortset fra detaljer omkring kernen - en ganske almindelig Linux, du får, hvis du vælger at køre Linux hos dem. (Ved ikke, hvordan det er mht. Windows.) Diskene er naturligvis virtuelle, men det er de alligvel mange andre steder alligevel, grundet SAN-teknologi.
Det er klart, at hvis du begynder at benytte dig af særlige features såsom S3 storage, binder du dig til...ja S3. Og det samme med nogle af Amazon's andre applikationer såsom deres kø-applikation. Men som Daniel siger, så er dette et problem ret almindeligt ved valg af hjælpesoftware.
Google's sky synes umiddelbart mere "lukket", idet deres python's I/O skal foregå på en lidt speciel måde, så vidt jeg husker. Men så er det vel heller ikke værre end at udskille særlige forhold vedr. dette til udskiftelige komponenter i design'et af éns applikation.
Jeg er enig i, at man skal vare sig for at overse nye bindinger, som måtte komme med skyerne. Men din reaktion lyder lidt "jeg-er-bare-imod" agtig.
-
0
-
0
Det er det samme som altid. Jo mere du vil have jo hårdere binder du dig. På det punkt er skyen ikke specielt revolutionerende, men det heller ikke pointen med den.
jeg synes det er en interessant debat, og det er ligefør jeg mener vi bør sætte os ned, spise en pizza og snakke om hvordan man kan udnytte skyen og hvad man skal passe på.
-
0
-
0
Hej Henrik, nej det er vel ikke et kriterium for cloud computing at man kan skifte leverandør lige så let som man kan bestille flere kørende instanser.
På den anden side skal vi så bare være opmærksomme på at skyen ikke er så luftig igen – der er nogle bindinger. De bindinger vil påvirke vores business-cases. Hvilken it-revisor vil fx synes det er herligt at en forretnings overlevelse er betinget af at en specifik driftsleverandør ikke går konkurs? Eller ændrer deres prispolitik? Eller oppetid? eller… Så det er ikke bare fordi jeg er imod, som Troels gætter på.
Når jeg siger umoden er det fordi at selvom selve applikationerne kan afvikles rimeligt ensartet og måske med lidt arbejde kan porteres fra en udbyder til en anden, så er der pt. væsentlige begrænsninger i modellen. Der er fx ganske få applikationer der kan klare sig uden en eller anden form for relationel database og dét tilbyder hverken Amazon eller Google (gør andre?). De tilbyder en database-model hvor man stort set kun kan gemme (key, value) tupler hvilket ikke er nok for de fleste applikationer.
Mit gæt er podcastmachine er et af de mere sjældne eksempler, hvor en applikation kan nøjes med et filsystem.
Men igen, det kan skyldes at vi som udviklere ikke er vant til at tænke i højt paralleliserbare applikationer der bruger køer og hvor data ikke er afhængige af relationel integritet – måske skal vi bare vende os til det og så smide en del af de "gamle" design-tanker ud hvis vi vil bruge de cloud-designmønster som tilbydes pt.
-
0
-
0
Peter skrev:
"Der er fx ganske få applikationer der kan klare sig uden en eller anden form for relationel database og dét tilbyder hverken Amazon eller Google"
Hvorfor skulle man ikke kunne køre en relationel database i en EC2-instans?
-
0
-
0
Intet problem - den kan bare ikke tale med andre instanser (som jeg har forstået det) og så er du jo sådan set lige vidt. Der er typisk brug for en fælles database på tværs af instanser.
Om en fælles databasefil placeret på filsystemet er en mulighed er et åbent spørgsmål - mit gæt er at skrivninger i en fil fra flere instanser nok ikke er en mulighed i det setup.
-
0
-
0
Running databases on Amazon EC2:
http://aws.amazon.com/ec2/running_databases/#Relational
Og fra http://aws.amazon.com/ec2/ :
Amazon EC2 provides web service interfaces to configure firewall settings that control network access to and between groups of instances.
-
0
-
0
Peter,
Det underbygger vel også min påstand om at vi skal bruge de næste par år på at lære og forstå mulighederne for forretningen (også om forretningen selv skal tilbyde SaaS i skyen). Det er næppe de forretningskritiske applikationer, der står i første række.
Jeg tror også så meget på markedskræfterne at hvis der er et behov så bliver det opfyldt. Vi er stadig i et tidligt stadie så teknologierne skal modnes og erfaring skal opbygges. Men jeg er overbevist om at den rigtige brug af skyen bliver en væsentlig konkurrenceparameter
-
0
-
0
Hej Troels,
Du har helt ret i at det er muligt at køre en fuld relationel database i skyen f.eks i en virtualiseret instans hos Amazon.
Men som Peter også siger så vil det være en instans som er ansvarlig for f.eks tilstand på andre instanser. Det er et forholdvis vigtigt single-point-of-failure som virksomheder selv skal overvåge og sørge for kører.
Når det er tilfældet begynder et argument for at bruge cloud computing at falde, man har stadig fordelen ved ikke at skulle købe og vedligeholde hardwaren, men man har stadig alle de administrative problemer med at have en database.
En anden grund til at hverken Google, Amazon eller Microsoft har en relationel database i deres cloud setup er skalering i driftmiljøet i de store datacentre.
For at forretningen kan køre rundt laves et gigantisk cluster af RDBMS på markedets absolut billigste diske - udfra devicen, når disken alligevel fejler på et tidspunkt så kan vi lige så godt købe de billigste.
For at få så stor fleksibilitet i hardware platformen - diske ind og diske ud konstant - er det vigtigt at man i det øverste "customer facing" niveau har så høj en abstraktion så muligt. Så det Peter beskrive som name/value adgang i en abstraktion for at få så effektivt et driftsmiljø så muligt - så abstraktionen er den kamel man må sluge for at få uendelig skalerbarhed.
I Microsofts cloud DB har jeg hørt rygter om at prissætningen vil blive differentieret hvis man som kunde har specielle krav til partition på disk, datacenter eller geografi.
Jeg har tidligere skrev om hvordan et API for en cloud DB kunne se ud her: http://www.version2.dk/artikel/8163-laeg-data-i-skyen
I tilfældet Podcastmachine kan jeg forstå, på Magnus og Mik fra Podcastmachine, at de ikke bruger database, som storage, men i stedet benytter sig af en kombination af Amazons Message Queue + S3. Det betyder i princippet at Podcastmachine kun har lock-in til deres cloududbyder på "køen" i driftsmiljøet.
I det adminstrative setup er det en ganske anden historie :-)
Men jeg er også mega imponeret af Podcastmachine!!!
-René
-
0
-
0
