henrik knopper bloghoved

Mail i skyen?

Jeg faldt lige over en klumme i australske ITwire hvor skribenten sagde at hvis ikke man seriøst overvejede at flytte sin mail i skyen risikerede man at blive hægtet af.

Han havde 5 argumenter som jeg lige repeterer:
1) Alle andre gør det
2) Lokale servere
3) Generation Y forlanger det
4) Billigt - nogen gange gratis
5) God mulighed for at komme af med Lotus Notes

Hvis det er den slags argumenter der afgør om man flytter sine data i skyen så er jeg alvorligt bekymret.

I min verden er data hjerteblod. Det giver man ikke til hvem som helst. Min egen liste over overvejelser der kunne tale for eller i mod ville i hvert fald indeholde:

a) I skyen adskilles mine data fra min værste konkurrents data af et password. Er det nok?
b) I min Notes / Exchange+Sharepoint farm har jeg X små applikationer som gør livet lettere for mine brugere. Hvordan skal disse opgaver løses fremover?
c) I skyen kan og vil mine data - i anonymiseret form - blive brugt som grundlag for alskens optimeringer, målretning af reklamer, adfærdsmåling og den slags. Vil jeg sælge den slags informationer om mig selv og mit firma' Får jeg nok betaling for det'
d) I skyen har alle nøjagtig samme muligheder for at behandle deres data. Hvordan giver det mig en konkurrencemæssig fordel?

Misforstå mig ikke, skyen som vi ser den i dag giver fantastiske muligheder og peger som teknologi langt ind i fremtiden.

Jeg er bare helt sikker på at når verdens CIO'er vågner op til dåd, så vil ejerskab af data, inkl. de rå data, blive en nøgleparameter igen.

Og så vil vi se cloud-in-a-box fra alle store virksomheder.

En propritær sky hvorfra de tilbyder samarbejde om - eller med udgangspunkt i - deres egne data på deres egne præmisser.

Eller får pengene der spares i næste kvatalsregnskab fortsat lov at bestemme?

Kommentarer (6)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Jesper S. Møller

Lad os lige tage tingene i rækkefølge, så:

Argumenterne 1 og 4 er jo det samme - omkostninger.

Argument 2 er risikospredning. Hvis du er en lille virksomhed vil en serverfejl koste dig dyrt i tabt arbejdsfortjeneste, (uanset om du har en fungerende backup), eller sikring imod det vil koste dyrt i driftsaftaler. Sandsynligheden for at Google eller andre har én server blandt tusinde, der kører, er bare højere.

Argument 3 lyder lidt spøjst, men kan vel ses i en udviklingsmæssig sammenhæng, hvor dominansen fra de store leverandører (tidligere IBM og nu Microsoft) stille er på vej ud. Eksempel: Pånær specialiserede områder som f.eks. spil er Windows ikke længere krævet i en normal "corporate" verden -- takket være åbne snitflader, virtualisering og rigelig båndbredde (til f.eks. Fjernskrivebord/Citrix). Generation Y forventer derfor frit valg i en anden grad end deres ældre kolleger, ligesom de tilsvarende er klar til at tage mere ansvar for deres egen produktivitet. For funktionærer er PC'en er ikke længere en del af et produktionsapparat som skal følge virksomhedens standardmål på linje med et samlebånd, den er et personligt produktivitetsredskab på linje med en kuglepen. Fleksibiliteten er m.a.o. en mulig konkurrenceparameter i kampen om kandidaterne.

Argument 5 holder hele vejen!!! (ok, det er en personlig præference, eller snarere dis-præference)

Min du overser et par ting også (set fra tilfældet Google Apps):

a) Om sikkerhed: Ved Google Apps kan du (i betalingsudgaven) sætte en valgfri SAML identity provider foran, så kan du selv vælge hvor mange OTP'er og VPN dimser du vil have foran. Tager du noget Amazon kan du jo vælge frit (OpenVPN styrer)

b) Google Apps Script er måske din ven, og der er rigtig mange fornuftige API'er til de forskellige data services.

c) I betalingsudgaven af Google Apps er der ikke reklamer (med mindre du slår dem til!), men muligheden for statistisk analyse af dine data er selvfølgelig til stede.

d) Hvordan stiller det dig dårligere at du har muligheden for at lægge dine data andetsteds? Ellers er der AWS / EC2 / RDS, så kan du bare analysere løs, uden at skulle føre kabler i gulvet selv.

Det er ikke én løsning (egen server i kælder) imod én anden (Google's server i gratisudgave) -- det er et spektrum af forskellige muligheder indimellem disse ekstremer, og der er masser af muligheder for at finde en løsning, der passer ens behov. Hvad med f.eks.: http://developer.amazonwebservices.com/connect/entry.jspa?externalID=323...

Når alt dette er sagt så udgør Google Apps en concentration af risiko, ingen tvivl om det, som også blev illustreret af Twitter-lækkene. Men dette læk var nu også supereksemplet på de risici man løber hvis man ignorerer grundlæggende sikkerhedsråd. http://techcrunch.com/2009/07/19/the-anatomy-of-the-twitter-attack/

  • 0
  • 0
#2 Normann P. Nielsen

Umiddelbart faldt jeg lige over:

" a) I skyen adskilles mine data fra min værste konkurrents data af et password. Er det nok?"

Næsten alle de steder jeg har arbejdet med/ved, arbejder med osv. er webmail kun sikret via username/password - mens man bygger datacentre, seperate brugernavne for admin kontoer osv osv..

Det har altid undret mig at nærmest alle fra chef og nedefter bare accepterer det som en "standard" at deres mail kun er beskytte med username/password. - Og username er jo typisk ret nemt at finde, så er der passwordet tilbage; og er chefen lidt af en travl ting, så har han jo typisk sat "never expires" på sin konto etc; trods alle formaninger...

Så hvor sikre er vores data (eller en delmængde heraf) anyway...

  • 0
  • 0
#3 Anonym

Henrik

Du har hel ret i at de 5 argumenter er desideret stupide - de kunne for dens sags skyld fremføres om OS/2 i dag med omtrent samme lødighed.

Men istedet for at diskutere enten/eller, bør man erkende at mange processer vil blive cloud-understøttet.

Spørgsmålet er hvordan man isolerer de enkelte transaktioner så cloud ikke blive et single-point-of-failure.

Dvs. i stedet fro at diskutere om hele din mailboks skal i cloud med tynde terminaler (aldrig i livet, så er du totalt blotlagt), så bør man se på hvilke services som skal ligge klient-side og hvilke som kan følge den enkelte mail ud i infrastrukturen.

  • 0
  • 0
#4 Henrik Knopper

Først en præcisering: Argument 2) refererer til lokale servere placeret i et hostingcenter i samme land som dig, ikke at det er dine egne servere. Det referer til at f.eks. Google i dag har datacentre i mange lande og som udgangspunkt lægger data i det land der er tættest på dig.

Dernæst: a) Det kan godt være at jeg kan sætte en valgfri SAML identity provider op som ekstra beskyttelse, men giver det garanti for at der ikke er andre der ved en fejl kan komme i mine data? Det mener jeg ikke.

c) Jeg tænkte ikke på reklamer til mig, men på at udbyderen har alle muligheder for at høste mønstre i mine data og min adgang til dem som grundlag for målretning af services, reklamer m.m. til andre. Problemet i det er at langt de fleste vil se det som en god service og bekymre sig mindre om privacy. Så egentlig gik mit spørgsmål på om man får betaling for den privacy man ofrer?

d) Ofte er det jo ikke kun data man lægger i skyen, men en service man benytter hvor skyen også tilbyder de værktøjer man bruger til at manipulere data. Salesforce.com er et godt eksempel på dette. Mit spørgsmål gik på om man kan få substantiel konkurrencemæssig fordel når alle bruger de samme værktøjer?

  • 0
  • 0
#5 Jesper S. Møller

(Jeg kan nu forstå at du specifikt med "could" mener hostede slutbrugerapplikationer á la SaaS, ASP, whatever, ikke f.eks Amazon EC2, hvor man selv styrer boksene)

Præcisering taget ad notam. Kan dog ikke se at det trækker fra eller lægger til.

Ad a: Jeg kan godt se at der er problem igennem den koncentration af risiko der kommer med stordriften, til gengæld overlades driften så til folk som har en ganske pæn track record. Mere åbenhed ønskes fra leverandørerne i hvordan de f.eks. funktionsadskiller.

Ad c: Enig.

Ad d: Nej, det kan du vel ikke, ligesom du ikke kan få en konkurrencemæssig fordel ved at bruge samme selv-hostede mailsystem eller samme operativsystem. Men det er vel også sjældent at man kan høste i både pose (stordrift) og sæk (differentiering). Og så er der jo også API'erne.

  • 0
  • 0
#6 Anonym

Ad a) SAML beskytter ikke databasen mod den som hoster den, den som omgår perimetersikkerheden eller den som finder blot et lille hul i SAML-illusionen (SSO ligger alle æg i samme kurv).

As b) Sammenstillinger hører hjemme på klienten - only. Ellers er knudepunktet et single-point-of-failure og sikkerheden umulig (f.eks. Borger.dk)

Ad c) Pas på ordet "privacy" - det bliver en skraldespand for en masse meget konkrete problemer som gemmes væk i noget abstrakt. Nej, du er ikke mere betalt for det end slaven er det fordi han får mad og logi.

Start med erkendelsen af at uden "privacy" har du ingen forhandlingsstyrke - du er blotlagt og den stærke vælger strategien overfor dig.

Det gælder specielt virksomheder, som reelt forærer ikke bare deres kundedatabase men salgsoversigter, pipeline og en masse content/udviklingsarbejde til den som vil betale mest med Google som aktiv hæler.

ydermere gælder det ikke kun den som tilvælger Google, men også alle dem som de interagerer med og som IKKE har tilvalgt Googles datamisbrug.

Ad d) Stordriftsfordelene kan distribueres, selvom tilpasning selvfølgelig koster og kun sker hvis der er værdi ved det.

Problemet er omvendt - lige så snart du er låst ind i det centrale, så kan du ikke differentiere eller beskytte din konkurrenceevne. Du er blevet underleverandør til Google - det er ikke dig som bør betale Google, men Google som bør betale dig.

  • 0
  • 0
Log ind eller Opret konto for at kommentere