Techintervju: Hansang Bae i Riverbed

Hva blir det neste store innen nettverksteknologi? Vi har snakket med Hansang Bae i Riverbed om nettverksoptimalisering, ytelse, SDWAN og mye mer.

Teknologiselskapet Riverbed har siden oppstarten i 2002 rukket både å bytte navn (fra NBT – Next Big Thing) og å bli ett av de raskest voksende teknologiselskapene med omsetning i milliardklassen. Og det i Silicon Valley – hvor mindre enn 3% av bedriftene rekker å bli 10 år.

Hansang Bae er Chief Technology Officer i Riverbed, og vi har tatt en prat med han.

Hansang Bae

Hva er din bakgrunn, Hansang?

– Jeg kommer opprinnelig fra Citigroup, selskapet bak det man oftest assosierer med Citibank. Jeg startet å arbeide med det som i dag heter Riverbed allerede i 2003 – lenge før de lanserte Steelhead som deres første produkt på markedet i 2005. Siden 2006 valgte vi å installere teknologien til Riverbed gjennom min tidligere arbeidsplass (Citibank – nå City) etter godt forarbeid sammen med utviklingsteamene.

Det er verd å nevne at alle produktene til Riverbed er installert i City, så jeg har vært heldig som har kunnet ha førstehåndserfaring med produktene før jeg begynte for Riverbed fra et sluttbrukers ståsted. Slik jeg ser på det er det en styrke å ha kjennskap til produktene fra et forbrukerståsted nå som jeg også forholder meg til markedet vel som utviklingsgruppen.

Hva vil du si er den største fordelen til Riverbed ovenfor sine nærmeste konkurrenter, jeg tenker da spesielt ettersom du har erfaring som bruker og ikke bare ansatt i Riverbed?

Jeg tror den beste måten å beskrive det på er at Riverbed er en typisk oppstartsbedrift, men som nå omsetter i milliardklassen. Riverbed er det som blir omtalt som en enhjørning og grunnen til dette er at mindre enn 3% av oppstartsbedriftene i Silicon Valley som overlever de første ti årene. Av de som faktisk overlever er det svært få av disse som vil oppnå en omsetning på over en milliard dollar.

Det jeg vil frem til med dette er at Riverbed oppleves fremdeles den dag i dag som et oppstartsselskap hva prosesser, utvikling og kunderelasjoner angår. Som nevnt har jeg en bakgrunn fra City og dette med prosesser er noe jeg kjenner godt igjen fra denne bransjen. Det som oppleves som svært rigid og til og med vanskelig i mange bedrifter har en langt enklere og jordnær tilnærming på ting enn større organisasjoner og tradisjonelle teknologiselskaper en gjerne støter borti.

 Så det du sier er at du som kunde av Riverbed har større innflytelse på produktutviklingsgruppen og mulighet for å kommunisere med utviklere enn tradisjonelle IT-selskap?

Det er riktig.

This is Riverbed

 Hva er fordelene fra et kundeperspektiv, hvorfor skal kundene velge nettopp Riverbed?

Noen ganger er det små detaljer som ved første øyekast gjerne ikke virker som det viktigste, men noe av det jeg opplever fra bedrifter vi samarbeider eller konkurrerer med er at alle kan utvikle noe. Sett sammen kompetente mennesker og gi dem tilstrekkelig med ressurser og tid så vil nærmest hvem som helst kunne lage et godt produkt og dette produktet kan gjøre nærmest hva du enn måtte ønske.

Det ikke alle leverandører tenker på er de daglige kravene som stilles til systemet. Altså det som foregår på dag-til-dag-basis. Det er svært krevende og komplisert å vedlikeholde og oppdatere et produkt som angår kjernen av virksomheten din – altså nettverket ditt. Noen ganger kan det være de små tingene som å ta et eksisterende datanett og implementere vår teknologi på dette, mens andre ganger er det hvor enkelt det er å vedlikeholde produktet når det er installert.

Andre signifikante detaljer er varsling. Varsler systemet oppdager problemer eller utfordringer, eller varsler det først når ting virkelig begynner å svikte deg og brukerne av infrastrukturen opplever problemer?

Relatert til dette – og en av de tingene jeg virkelig liker personlig – er APIer. En av de tingene jeg gjentar til utviklerne er at de ikke skal bli forelsket i det grafiske grensesnittet til systemet de utvikler. Hvorfor? Fordi det finnes en kunde der ute som vil ha et unikt scenario som ønsker å gjøre det på hans eller hennes egne måte – tilpasset kundens eget behov – og dersom vi ikke har APIene kan ikke kunden gjøre disse tilpasningene. Så vårt mål hos Riverbed er å ha et veldig solid API slik at kunden kan se dataene hvor de ønsker å se det, på den måten de ønsker å se det og når de ønsker å se det.

Kort oppsummert så vil alle kunder kunne skape sitt eget instrumentbord, eller dashbord om du vil, med de dataene som betyr noe for dem på en enkel og hurtig måte.

riverbed_wan_optimalization

 For kunder som ønsker innsikt eller bedre forståelse av produktene. Hva er dine to beste måter å demonstrere Riverbed sine produkter?

Riverbed har to store kategorier vi opererer innenfor, og det er optimalisering og synlighet. Det er i hovedsak gjennom optimalisering og da spesielt tradisjonell WAN-optimalisering de fleste kjenner oss for. Innenfor optimalisering har vi både WAN-optimalisering, men vi har også et produkt vi kaller “fusion” som opererer på lagringsnivå. Med synlighet mener jeg feilsøking og overvåkning.

Det vi som oftest gjør er at vi har et scenario hvor vi har en applikasjon som ikke fungerer som den skal, den er treg eller ustabil men jeg aner ikke hvorfor. Feilen kommer og går og jeg aner ikke hvor jeg skal begynne feilsøkingen. Slike problemstillinger er relativt vanlig og vi pleier å imøtekomme dem på to forskjellige måter. Vi har en tjeneste innenfor våre synlighetsverktøy (for ordens skyld, Hansang legger til at den i USA kalles 911 – men at dette ikke er det samme som nødnummeret). Vi har kalt tjenesten for dette fordi når et problem oppstår er det i kundens største interesse i å utbedre feilen fortest mulig.

Hvis du ser på enkelte selskaper som eksempelvis BlueJet, flyselskapet og hvor mange flykanselleringer som har oppstått som følge av at datasystemet har gått ned, eller noe så spesielt som helsemyndighetene i USA eller Obamacare som det ofte blir omtalt, lenge kunne vi bare  legge til åtte brukere om gangen fordi systemet aldri var stresstestet. Det tok mange uker med feilsøking og feilretting.

Den andre er forsinkelser. Noe som overrasker meg er at noe om ble oppdaget over for over femti år siden hva ytelse angår, fremdeles er noe mange mennesker glemmer. Vi er blitt så vant med at smarttelefoner og andre enheter vi bærer med oss bare skal virke, men det fungerer ikke så bra når du er i Australia. Australia er tross alt langt unna, det bare er slik, og selv om brukere gjerne sitter i Australia og benytter en tjeneste over store distanser er dette ikke noe som blir utprøvd. De fleste utviklere tester lokalt og de debugger produktet lokalt, gjerne på et eget LAN eller et WAN hvor de har full kontroll på begge ender. Etter testing og grunnleggende feilretting rulles så applikasjonen ut på global skala.

Det som alt for ofte hender da er at økosystemet ikke matcher testmiljøet og ting slutter å fungere. For å si det slik, helvete kan fort bryte løs og du får frustrerte og oppgitte brukere på telefonen etter bare noen øyeblikk. Utfordringen da er hvis utviklerne sier at produktet fungerer fint – feilen må ligge eksternt eller lokalt hos brukeren. Prøv å gjør disse tingene fra Singapore, India eller et annet avsidesliggende sted fra datasenteret og se hvordan ting fungerer.

Det vi gjør er at vi fjerner forsinkelsen. Det er dette WAN-optimalisering gjør.

For å oppsummere dette for deg, så er fremgangsmåten gjerne at Office 365 eller SharePoint Online er ikke så responsivt eller rask som den burde være. De sender en ticket til oss, problemet blir løst og de ansatte kan igjen være produktiv fremfor å sloss mot et tregt eller ustabilt nettverk.

Riverbed

 Hva ser du for deg at er “det neste store”? Det jeg tenker på spesielt er historien til Riverbed som ble grunnlagt under navnet “The next big thing” – hva er det neste store innen nettverksteknologi?

Det neste store innen nettverksteknologi ser vi for oss at vil bli dominert av SDWAN (software defined WAN). Per dags dato er software defined networking enda et buzzord og det er ikke så mange om klarer å dra nytte av teknologiene. Det er komplekst, det finnes for mange forskjellige standarder og ting oppleves ikke som helhetlig. Du kan jo selv se hvordan IPv6 har blitt utbredt. Det høres fint ut, men det er ikke så mange som har tatt seg bryet med å implementere dette enda.

SDWANs oppgave for bedriften er å spare penger samtidig som det sørger for at applikasjonene går raskere og mer stabilt. Det som er med denne typen teknologi er at enhver nettverksadministrator forstår nytteverdien til denne typen teknologi og løsninger og vi ser at holdningen til bransjen er i ferd med å endres i forhold til disse produktene.

Som nevnt har jeg en bakgrunn innen finansindustrien hvor det i hovedsak er to måter å tenke utnyttelse på – den ene er P&T (profitt og tap) og den andre er kost-senter. Kost-senter er den tradisjonelle tankegangen hvor jeg som leverandør leverer en tjeneste og blir betalt av leverandøren. Hva og hvordan de gjør ting er ikke så interessant bare nettverket er på plass. Motsetningen til dette er profitt og tap-tankesettet er grunnleggende annerledes hvor det jeg gjør blir vurdert som litt bedre enn hva alle andre gjør vil jeg ha en profitt på dette, samtidig som dersom jeg leverer en dårligere tjeneste, vil jeg tape på det.

SDWAN vil kunne gi dette tankesettet til infrastruktur og jeg skal gi deg et eksempel – trolig det mest innlysende. Se for deg internett som datatransportør framfor en kostbar nettleverandør. Det å kunne benytte en tradisjonell internettforbindelse for dataoverføring og applikasjonsstyring er langt rimeligere enn egne WAN og MPLS (Multiprotocol Label Switching). Internett har en langt større pålitelighet enn bare en privat leverandør kan gi, og alt som skal til for å øke påliteligheten er en redundant linje fra en annen ISP.

network_communication_worldwide

 Du har nevnt at du kan optimalisere hastigheten mellom lokasjonen og datasenteret med en hastighet av mellom 10 og 90% økning i ytelsen. Hvordan har dette seg?

Scenarioet vi ofte ser er at noen sender en epost, la oss si at jeg sender deg en PowerPoint-fil og jeg ber deg om å fullføre denne for så å poste denne online for meg. I utgangspunktet spiller det ingen rolle om dette er et epost-vedlegg eller ikke, for oss er dette bare bits og bytes. Det spiller ingen rolle at det er en PowerPoint-fil, ei heller at den kom som et epost-vedlegg.

Det vi gjør, er at vi skaper et symbol for kjente mønstre, eksempelvis PowerPoint, slik at vi sender symboler som representerer denne store filen og siden vi kjenner protokollen på disse går dette fortere. Det som da skjer er at totalmengden av data som må overføres reduseres og det føles som at du arbeider lokalt.

Det vi ofte gjør hos potensielle kunder som er usikker er at vi implementerer denne teknologien og lar dem få prøve det ut. Den store overgangen kommer når den blir fjernet. Det er da brukerne virkelig legger merke til forskjellen. Med på kjøpet får kundene en ekstra gevinst: Telemetri, de kan se hvilke brukere og data som er mest aktiv og hvor disse befinner seg. Det å ha hurtige klienter og kraftige datasentre hjelper kun dersom du får tingene til å snakke sammen på en effektiv måte.

 Du nevnte symboler og blokker med data når du nevnte PowerPoint, er dette en teknologi lik det vi har sett i deduplisering på lagringssiden?

Det er riktig, og det er ganske likt.

Likevel er det noen vesentlige forskjeller. Med deduplisering oppnår man fort femti prosent kompresjon. Vi har i de fleste av våre tilfeller rundt nitti prosent besparelse ettersom vi har patentert en egen måte å dele opp disse blokkene ned til åtte byte. Det er altså svært detaljert. Svært mange av løsningene du finner ellers er relativt store, men vi forholder oss til små biter.

Se for deg at du arbeider med en fil, og enten du eller noen andre endrer navnet på denne filen, så vil dette ikke være dekket av en typisk cache-server og hele filen må lastes på nytt. Det vi gjør et at vi tar de bits og bytes som er endret og på en størrelsesorden på åtte byte er dette rikelig til å kunne dekke inn noe så enkelt som bytte av navn.

black_cloud_network

 Hva mener du er den viktigste forskjellen som gjør Riverbeds filosofi unik i denne sammenheng?

Det viktigste er likevel å få med seg at det å flytte pakker, altså transportere pakker med data. I det store og hele er det ingen som bryr seg om dette lengre, det man bryr seg om er applikasjoner så vi i Riverbed flytter applikasjoner og ikke pakker. Det vi gjør er at vi jobber mot å være en kantrouter, noe som vil konkurrere mot Ciscos nest største virksomhetsområde: kantroutere. Det finnes millioner av de tradisjonelle routerene rundt om i verden, men verden forandrer seg.

Ta for eksempel IP-adresser, ingen bryr seg om IP-adresser. Om jeg ønsker tilgang til Office 365, så tenker jeg ikke så mye på hvilken IP-adresse denne tjenesten har. Alt jeg vil ha er tilgang til applikasjonen. Det vi gjør hos Riverbed er å tilpasse vår teknologi slik at vi forstår de applikasjonene som transporteres i skyen og med denne kjennskapen kan vi dermed route applikasjoner uten å tenke på IP-adresser.

Kort oppsummert så er det dette som er kjernen i vårt budskap. Hvor tradisjonell nettverkstankegang har vært slik at applikasjoner har blitt tvunget til å følge et strikt nettverksoppsett, vil man i fremtiden se mer til applikasjonsstyrte nettverk. På denne måten vil man også kunne styre applikasjoner som skal ha prioritet over applikasjoner som er langt mer triviell. Ta for eksempel tale eller videotelefon over ordinær websurfing og at dette blir routet på applikasjonsnivå fremfor portnivå som i dag.

Dersom en bedrift bruker en milliard på oppgradering av nettverksutstyret, men brukeren fremdeles er misfornøyd, så har du feilet. Det spiller ingen rolle hvilke switcher eller aksesspunkt du har. Det handler om hvilke applikasjoner du benytter deg av, hvor disse er og hvordan de er satt sammen.

Se for deg en misfornøyd bruker legger ut en bemerkelse av sin misnøye av tjenesten vil dette kunne få katastrofale følger for selskapet dersom ballen begynner å rulle, og svært mange store selskaper er redd for akkurat dette. Samtidig så har disse bedriftene gjerne kontroll på datasenteret, på programvaren, men gjerne ikke på nettverket hos kunden eller sluttbrukeren. Dette er her programdefinert nettverk vil kunne utgjøre den store forskjellen.

Kommentarer