Gæstebloggen

QCon New York - 1. del

Min dækning af QCon lægger ud med nogle indtryk fra mandag formiddag, som blev skudt i gang med en velkomst og en præsentation af de forskellige spor. Derefter lagde Khawaja Shams fra NASA Jet Propulsion Laboratory (JPL) ud med en udmærket gennemgang af nogle af de myter, som bruges om cloud computing (i særeleshed PAAS og IAAS tilbud, som f.eks. Amazon AWS og Windows Azure), i Mythbusters-stilen.

Er Cloud-produkterne virkelig:

  • mere usikre end at have sit eget serverrum (Busted)
  • mindre pålidelige (Busted)
  • ude af stand til at konkurrere med egentlige supercomputere (Busted)
  • kun Amazon AWS (Busted, selv Windows Azure kan køre Linux nu)
  • i stand til at skalere uendeligt (Busted - men praktisk talt ubegrænset)

JPL har over de senere år flyttet rigtig mange af deres "computing"-behov til cloud'en, og taleren var fuld af gode war stories om elasticiteten i cloud-løsningen. Har man tænkt cloud ind ens applikation fra starten kan man komme rigtig langt i særligt skalérbarhed. Men: Der ér også et loft, hvilket han demonstrerede ved starte virtuelle maskiner på AWS ved at dreje på en hjemmebygget Cloud Control gadget til stor latter fra salen.

Illustration: Jesper Steen Møller

Cloud Control 2.0 er baseret på et Phidget kit.

I den seriøse ende har NASA mulighed for at starte tusindvis af instanser under AWS og kan derved få supercomputerkraft til få hundrede dollars i timen og derved få videnskabelige data frem til forskerne meget, meget hurtigt, med langt mindre investereringer. Mon ikke Amazon har sørget særlig godt for en kunde som NASA?

På QCon giver tilhørerne feedback ved at aflevere røde, gule eller grønne sedler: Keynoten fik en grøn seddel for en indlevende præsentation af udfordringer som er de færreste forundt, men som Khawaja fik gjort både underholdende og relevant. Et eksempel er håndtering af patches: I det "klassiske" datacenter: Er du sikker på at alle dine servere har alle de seneste patches? I Skyen tænker man ikke enkeltmaskiner - instanser af et bestemt image: Du sørger for patches er lagt på det image, der startes, og så kan du med et enkelt API-kald checke at alle dine instanser kører det seneste image, og kan slukke for dem som ikke gør. Det kender jeg ihvertfald nogle driftsfirmaer, der kunne lære noget af.

Næste præsentation, jeg hørte - 'Taking Time Seriously' - kunne ikke leve op til den gode start. Indlægget skulle præsentere anvendelsen af Haskell i "den rigtige verden", hvor afviklingshastighed, deadlines og udviklerens produktivitet er vigtig.
Ironisk not startede taleren med at bruge nogle minutter på at få fler-monitor opsætningen til at fungere til præsentationen, hvorefter han spildte lidt mere tid på et par fortællertekniske gimmicks, herunder Müller-Lyer illusionen, for at sælge ideen om at funktionel programmering er mere intuitiv end vi frygter: Ikke overraskende var pointen at den programmeringsteknik, man lærer først, farver opfattelse af "intuitiv".

Mandens pointe var, at for komme "i flow" er det meget værdifuldt at tingene fungerer intuitivt og at komme af med al den "accidental complexity" som f.eks. C biblioteker giver -- fordi tid skal tages seriøst, at der var en del nyere Haskell forbedringer, der muliggør hurtigere udvikling (eksempelvis udsat typecheck)

Imens kom han forbi forskellige emner såsom det senest fundne MySQL sikkerhedshul (som ville være fundet ved strengere typecheck), brugen af QuickCheck til at skrive tests i Haskell (frem for at nøjes med at håbe at dine unit tests kommer omkring i hjørnerne), og introduktion af typer til at markere rollen af data inde i et bibliotek, samt at Haskells strengbehandling ikke er så langsom, som den engang var. Det virkede bare ikke sammenhængende på nogen måde, som en turistguide på vej igennem byen, forklarerende til højre og venstre, men med en sæk over hovedet, så han ikke vidste hvor han var. Og hans konklusion: "Haskell passer meget godt for mig, men måske ikke for dig?"

En rød seddel blev givet for et fuldstændig rodet og usammenhængende præsentation af en taler som sagtens kunne have gjort det bedre. Behøver jeg at skrive at han gik over tiden?

Del 2

Kommentarer (3)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Steen Eugen Poulsen

Når du har flere "point of failure", så kan du da ikke buste at sikkerheden er dårligere.

Når du sætter en computer et sted, så skal folk havde fysisk adgang til den for at bryde sikkerheden.

Når du så smider den på Internettet så har du en router, firewall, ISP og alle de andre maskiner mellem dig og den anden ende der kan brydes ind i. Så det kan da aldrig blive bedre eller den samme sikkerhed.

Når du vælger cloud er det altid et spørgsmål om at forringe sikkerheden for at spare penge.

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

NASA JPL havde haft samme indgangsvinkel - "tør vi det?" - og havde startet deres cloud-anvendelse med applikationer, som gerne skulle ud til så mange som muligt, f.eks. undervisningssites. Men så var de gået videre derfra: Pointen er at du er nødt til at overveje - helt overordnet: Hvem stoler du på?

I det klassiske serverrum "i kælderen" stoler du både på din fysiske sikkerhed, på dine vagtfolk hvis du har den slags, på dine sysadm'er og andre, der har severadgang, på udviklere, på operativsystemet, firewalls og på hardwareleverandørerne -- og på at du har designet sikkerheden ordentligt. Ved cloud-deployment flytter du en del af (men langt fra al) denne tillid fra en leverandør til en anden, men du får måske også noget igen i form af bedre fysisk sikkerhed.

Og så er cloud altså ikke det samme som "tilgængelig på internettet". Du vælger selv om du har et public net-interface på, du har stadig både hypervisorens firewall og instansens egen interne firewall og du kan hos f.eks. Amazon med Virtual Private Cloud (VPC) vælge at lukke helt af for andet end den VPN tunnel du sætter op imellem dit netværk og din virtuelle netværk hos dem.

Men et andet forhold er også i spil: De fleste klassiske driftscentre i DK - også dem, der gemmer på de der "for-vigtige-til-at-komme-ud-af-landet"-data, kan nås igennem et par lag af VPN og fjernadgang: En persistent, fokuseret angriber med tid, penge og viljen til at bruge f.eks. vold kan komme igennem disse typer af beskyttelse på den ene eller anden måde: Det er menneskerne, der er det svage led hér.

Jeg vil derfor mene det er lidt mere nuanceret end sikkerhed vs. pris.

Der er jo andre fordele end pris, nemlig tid. Som Khawaja Shams sagde det: Hvis du har en beregning som tager 100 timer på én maskine eller 1 time på 100 maskiner, så koster det det samme at køre det parallelt, men din forsker har 99 timer mere til at analysere resultaterne og skrive sit paper.

  • 2
  • 0
#3 Gert Madsen

"Ved cloud-deployment flytter du en del af (men langt fra al) denne tillid fra en leverandør til en anden"

Det er ikke et rigtigt argument.

Hele grundlaget er, hvilken lovgivning og myndigheder som dine data er placeret under. Hvis ikke det er brugbart, så kan det være ligegyldigt om leverandøren er grøn eller blå - og til en hvis grad også om der er lås på døren til serverrummet. Og afhængig af data's værdi, er kryptering også ligegyldigt her. Kryptering er jo i praksis et spørgsmål om tid, før data er tilgængelige. Og hvis myndigheder kan tage en kopi af dine data, så har de jo tid nok.

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