PROSJEKTMANDAT PROSJEKTINFORMASJON PROSJEKTBESKRIVELSE. * Prosjektnavn Prosjektnummer Research lab

Transkript

1 Utarbeidet av: Gurvinder Singh, Andreas Solberg, Kristin Selvaag og Hildegunn Vada Sist oppdatert: Godkjent av: Dato for godkjenning: PROSJEKTINFORMASJON * Prosjektnavn Prosjektnummer Research lab * Tilknytning til andre prosjekt og/eller program UH-sky * Oppdragsgiver Prosjekteier Prosjektleder UH-sky styringsgruppe Kristin Selvaag Hildegunn Vada * Seksjon/koststed * Prosjekttype U40 Strategi og innovasjon EKSTERN PROSJEKTBESKRIVELSE * Bakgrunn UH-sky har som visjon at virksomhetene i norsk UH-sektor skal få gevinster av skyteknologi gjennom effektive og sikre løsninger for en felles portefølje av skytjenester. Et ønsket scenario er en selvbetjent markedsplass for UH-sektoren, der sektoren både er brukere (konsumenter) og leverandører (produsenter) av skytjenester. Kommersielle skytjenester vil også kunne være eksponert på markedsplassen, gjerne med merverdi tilført av skymegleren. Mangfold, tilgjengelighet og fleksibilitet er adjektiver som brukes for å beskrive hvorfor skytjenester er attraktive. Disse egenskapene gjør at mange velger skytjenester litt ukritisk, og gjerne overser viktige aspekter som f.eks. jus, sikkerhet, og samhandling med eksisterende portefølje. Lokal IT har ikke mulighet til å levere samme egenskaper i samme tempo mht. utvikling, tilgjengeliggjøring og videreutvikling, til tross for at brukere foretrekker en lokal eller nasjonal tjeneste. Et langsiktig målbilde for UH-sky er å utvikle et økosystem med tjenester fra produsenter og for konsumenter, og at det gjøres i felleskap og samarbeid, av og for sektoren. Flere verktøy som forskere etterspør, f.eks Wordpress, RStudio og Jupyter Notebook kan implementeres innenfor et sektorinternt økosystem der autentisering, sektorsammenheng (kontekst), jus, sikkerhet og samhandling med sektorinterne løsninger er ivaretatt. Det er en krevende operasjon å klargjøre dem for et slikt økosystem så lenge institusjonen ikke har et etablert rammeverk og regime for å ivareta slike oppgaver, raskt. Det blir en ny og tung oppgave hver gang det kommer en forespørsel, og brukeren velger andre løsninger som er mindre sikre, men mer tilgjengelige. Skyteknologi med skybaserte infrastrukturplattformer, containere og verktøy for orkestrering av applikasjoner, kan utvikles som et miljø der IT-avdelinger eller forskere, kan gjøre attraktive opensource verktøy tilgjengelig, raskt og på en forsvarlig og gjenbrukbar måte. I et slikt miljø kan flere verktøy gjøres tilgjengelig raskt, basert på maler (templater). Templatene kan gjenbrukes for hver ny Utkastnummer mal: 2.20 Mal utarbeidet:

2 tjeneste, og de kan gjenbrukes av andre institusjoner. UH-sky har foreslått eksperimentering og praktisk bruk som virkemiddel for å øke sektorens modenhet mht. skytankegang. Det er et av flere tiltak for skyifisering som ble behandlet og godkjent i styringsgruppen for UH-sky i januar Utvikling av kompetanseteam f.eks. på skyteknologi var et annet tiltak for skyifisering som ble anbefalt. Underlag for behandlingen i styringsgruppen var et notat om cloudification (skyifisering). Ett tiltak som er foreslått i notatet er Researchlab, der UH-sky ønsker å bygge kompetanse og demonstrere muligheter med framtidsrettet skyteknologi i samarbeid med sektoren, slik at kompetanse, kunnskap og løsninger kan gjenbrukes. Dette er tenkt som et første steg i for å realisere det langsiktige målbildet beskrevet over. ResearchLab som tiltak for skyifisering Containerteknologi er et område som er i rask utvikling og ser ut til å gi store forbedringer når det gjelder framtidsrettet bruk av skybasert infrastruktur. Kubernetes er en tjeneste som gjør det mulig å abstrahere ulikheter mellom ulike infrastrukturløsninger slik at de oppfører seg likt når det gjelder å sette opp applikasjoner. Kubernetes kan kjøre på en hvilken som helst underliggende skybasert infrastruktur, og også på såkalt bare metal, dvs. uten operativsystem eller virtualiseringslag. Dette muliggjør en løsning der sluttbrukeren sømløst kan sette opp eller flytte en applikasjon mellom underliggende infrastruktur uten å måtte ta hensyn til den underliggende infrastrukturen. Applikasjoner kan dermed plasseres på infrastruktur avhengig av ulike kriterier, som for eksempel lokalt på egen institusjon, i Norges, eller mest mulig kostnadseffektivt og med tilnærmet uendelig kapasitet. Slik kan mangel på kapasitet, oppgaver som berører sensitive data, redundans over flere datasentere, samt bedre utnyttelse av tilgjengelige ressurser, håndteres enklere. En slik utnyttelse og forvaltning av skybasert infrastruktur, kombinert med orkesteringersverktøy og rutiner kan utgjøre en plattform for skytjenester som gir forskere de verktøyene de ønsker, raskt og med egenskaper som er attraktive både for forskerne og for ansvarlige for juridiske, sikkerhetsmessige og integrasjonsmessige aspekter. Utkastnummer mal: 2.20 Mal utarbeidet:

3 Figur 1: Figuren viser hvordan ulike infrastrukturløsninger (f.eks. Safespring, UH-IaaS og public cloud) kan benyttes sømløst ved hjelp av en føderering mellom ulike Kubernetes-klynger. Det hele kommer til nytteverdi for sluttbrukere gjennom en felles markedsplass ( AppStore ). Man kan se for seg at ulike brukergrupper får tilgang til ulik underliggende infrastruktur avhengig av deres rolle (student, forsker, ansatt), deres institusjonstilhørighet etc. Figur 2: Et tenkt scenario som viser hvordan man kan tilgjengeliggjøre infrastruktur fra ulike leverandører (her også Sigma2) i en felles markedsplass for å forenkle sluttbrukeropplevelsen. Sigma 2 sitt NIRD-prosjekt går ut på å bygge opp Kubernetes-klynger for Sigma2-formål. Man kan tenke seg at de to klyngene til høyre (NIRD Tromsø og NIRD Trondheim) kun nås for forskere som er autorisert i Sigma 2-systemet. Figur 3: Et annet scenario går ut på at man i sektoren trenger flere markedsplasser pga. ulike behov for finansiering/markedsføring etc. Den samme teknologien vil likevel være aktuell, og man kan gjenbruke de Utkastnummer mal: 2.20 Mal utarbeidet:

4 samme applikasjons-templatene på tvers der det er aktuelt. * Formål Å bygge erfaring, kunnskap og kompetanse som kan videreføres for å nå et langsiktig målbilde om en selvbetjent og fleksibel markedsplass som sektorens skymegler forvalter. Markedsplassen skal formidle skytjenester fra produsenter, gjerne fra sektoren i tillegg til kommersielle, og for brukere (konsumenter) i hele sektoren. * Prosjektmål Innen 15.november 2017 skal prosjektet utvikle en plattform som anvender virkemidler som containerteknologi, skybasert infrastruktur, abstraheringstjenester og utviklerkompetanse. Plattformen vil demonstrere en markedsplass der skytjenester til støtte for forskning formidles til sektoren, gjerne også fra sektoren, på en rask, fleksibel og forsvarlig måte. Plattformen vil også demonstrere hvordan utvikling og sektortilpasning av applikasjoner ved én virksomhet kan gjenbrukes av resten av sektoren, og hvordan sektoren kan opptre både som produsent og konsument av tjenester og underliggende infrastruktur. Innen 1.juli 2017 skal prosjektet demonstrere med en pilot hvordan tjenester som f.eks. Jupyter Notebook og samarbeidsverktøy kan formidles til forskere på institusjoner i hele sektoren. * Eventuelle avgrensninger Jupyter Notebook og Rstudio (eller andre applikasjoner som demonstreres) skal ikke tilbys som produksjonstjenester. * Er prosjektet knyttet opp mot UNINETTs og/eller det enkelte selskaps strategi og/eller handlingsplan? JA * Prosjektets tilknytning, eller mangel på tilknytning, til UNINETTs og/eller det enkelte selskaps strategi og/eller handlingsplan. Prosjektet er et tiltak i tråd med Programbeskrivelsen for UH-sky og hovedområdet Infrastrukturplattform. * Antatt dato for gjennomført planleggingsfase (B2)? Antatt dato for avslutning av prosjektet (B4)? PROSJEKTETS OVERORDNEDE PRIORITERING Prioritering innenfor fire faktorer for prosjektet, der 1 er høyeste prioritet. *Ferdigtidspunkt *Kostnad *Omfang Kvalitet Utkastnummer mal: 2.20 Mal utarbeidet:

5 RETNINGSLINJER FOR PROSJEKTARBEIDET Krav til styring av prosjektet Krav til dokumentasjon Rapporteringskrav Krav til prosjektmetodikk Prosjektet styres iht. "Rutiner for styring og oppfølging av UH-sky" vedtatt i styringsgruppemøte 4. mai 2016 Iht. til UNINETTs prosjektmetodikk med evt. tilpasninger til programmets styringsform hvis nødvendig. Iht. til "Rutiner for styring og oppfølging av UH-sky" UNINETTs prosjektmetodikk skal ligge til grunn, med evt. tilpasninger til programmets styringsform hvis nødvendig. RESSURSPLANLEGGING OG BUDSJETT RESSURS- OG BUDSJETTESTIMAT HELE PROSJEKTET (B1-B4) Antall Arbeidstimer Ca timepris (hvis relevant) Total Timekostnad (Hvis relevant) Direkte kostnader Total kostnad KOMMENTARER TIL RESSURS- OG BUDSJETTESTIMAT HELE PROSJEKTET (B1-B4) *Kommenter usikkerheten til estimatene Prosjektet er et utviklingsprosjekt noe som innebærer usikkerhet rundt faktiske aktiviteter og resultater, samt omfang. Estimatene er usikre. Kommenter eventuelt personressurser for resten av prosjektet Dataporten, automatisering og integrasjon: 200 t Containerteknologi, erfaringer fra tidligere prosjekter i regi av IoU, Sigma2 og Glenna: 250 t Prosjektledelse: 150 t Utvikling, integrasjon underliggende infrastruktur, testing, etc: 600 t UiB: 150 t UiO: 150 t Direktekostnader (underliggende infrastruktur, deltakelse workshop/konferanse): kr * Finansieringskilder UH-sky ( * )ANNEN VIKTIG INFORMASJON Utkastnummer mal: 2.20 Mal utarbeidet:

6 Gjennom et prosjekt kalt Data analysis as a Service (DaaS) har UNINETT fått erfaring med ulike container-teknologier. Særlig Kubernetes peker seg ut som en god løsning. Kubernetes er basert på åpen kildekode, og er en tjeneste som gjør det mulig å sette opp eller flytte applikasjoner mellom ulik underliggende infrastruktur, det være seg on-premise, hybride løsninger eller store offentlige skytjenester. Kubernetes-klyngene skal kjøre på UNINETT PaaS 2.0 (Safespring), UH-IaaS, Amazon AWS og Microsoft Azure. En slik løsning muliggjør også en mer automatisk integrasjon med Dataporten. Dette vil forbedre sluttbrukeropplevelsen og forenkle brukeradministrasjon for tjenesteleverandørene. Administrativt ansatte og forskere kan på denne måten lage egne templater for applikasjoner og sette dem opp på en slik Kubernetes-løsning. Dette gjør det også mulig å begrense hvilke typer infrastruktur sluttbrukerne kan sette opp applikasjoner på, avhengig av hvem de er, hvilken rolle de har og hvilken institusjon de er tilknyttet. *OVERORDNET RISIKOVURDERING Windowsstøtte for containere og Kubernetes er foreløpig i en tidlig fase og under rask utvikling. Det kan medføre en utfordring når det gjelder å kjøre Windows-applikasjoner i Kubernetes-klyngene. Risiko knyttet til at vi får mindre tid fra nøkkelpersoner. Utkastnummer mal: 2.20 Mal utarbeidet: