Samarbejde, deling og digital udvikling i det offentlige.

OS2 arbejder på et pilotprojekt om etablering af en OS2cloud

Vi ønsker i OS2 at sænke barrieren for at komme i gang med open source og OS2s produkter, specielt for de kommuner der ikke i forvejen har kompetencer indenfor implementering, drift og udvikling af open source produkter. Det skal være nemmere at komme i gang med et OS2-produkt. Ved at fjerne nogle af de væsentligste barrierer for udbredelsen, nemlig kompliceret implementering og drift samt den modstand open source produkter kan møde i IT-afdelingerne, kan en OS2cloud være med til at gøre OS2-produkter til det enkleste valg. Formålet med en OS2cloud er at gøre det så nemt som overhovedet muligt for OS2s medlemmer at sætte et OS2-produkt i drift.

Derfor arbejder bestyrelsen og forretningsledelsen sammen med OS2-leverandøren Origo på et pilotprojekt om at etablere en OS2cloud. På sigt er det hensigten at driften af OS2cloud vil blive annonceret så andre kan byde ind.

Inden vi tager skridtet fuldt ud vil vi dels informere om hensigten, men også opfordre alle OS2-leverandører til at give Jeres mening til kende. Vi vil gerne have Jeres feedback på initiativet og sikre det rette fundament og spredning for en OS2cloud.

Dialogen tages i kommentarsporet eller ved at maile til OS2s forretningsleder Rasmus Frey, rafr@aarhus.dk.

Hvad er OS2cloud?

OS2cloud vil være en IaaS-cloud (Infrastructure as a Service) som I kender det fra f.eks. Amazon (AWS) og Linode, og giver mulighed for nemt og enkelt at starte servere op og provisionere storage. Med softwareplatformen Origo Compute etablerer vi en OS2cloud App Store, der giver medlemmer adgang til one click opsætning af Linux-, Windows servere samt OS2-produkter. OS2s produkter kan altså pakkes som virtuelle images (i qcow2-format), hvorfra servere kan startes med ét klik i OS2cloud, og stille en brugerflade til rådighed.

Hardwaren bag OS2cloud købes og ejes af OS2, driften af platformen indkøbes i pilotperioden af OS2 via leverandøren Origo Systems. Når et OS2-medlem aktiverer en serverinstans i OS2cloud faktureres medlemmet direkte alt efter ressource forbrug (antal cpu, ram mængde og storage mængde). Det er altså også OS2 medlemmets eget ansvar at sikre en eventuel databehandleraftale.

Virtuelle images som udvikles til OS2-produkter til brug i OS2cloud frigives som open source på linje med alle andre OS2-produkter.

OS2 vil i samarbejde med Origo Systems sikre, at løsningen er fuldt dokumenteret og står til rådighed for alle OS2s medlemmer. Derfor planlægger vi, som en del af initiativet, at involvere alle interesserede OS2-leverandører og klæde jer på til at kunne udnytte platformen samt sætte jer i stand til at pakke applikationer til brug i OS2cloud App Store.

Vi er bevidste om, at nogle OS2-leverandører potentielt mister noget omsætning fra hosting, men det skulle gerne mere end opvejes af øget brug af OS2s produkter.

Næste skridt

Vi vil gerne høre fra så mange som muligt inden d. 16/11 og vil herefter samle alt feedback og tage det med i vurderingen af OS2cloud projektets endelige form.

Dialogen tages i kommentarsporet nedenfor eller på mail direkte til OS2s forretningsleder Rasmus Frey, rafr@aarhus.dk. Vi ser frem til at modtage jeres input.

Kommentarer

Tak for invitationen på e-mail til at deltage i debatten :) Det er ikke så tit jeg skriver herinde ...

Det lyder umiddelbart som om OS2cloud initiativet skal behjælpe udfordringerne man som kommune har i forhold til at idriftsætte OS2's produkter. Her har jeg formentlig ikke tilstrækkeligt kenskab til de nuværende udfordringer man som kommune oplever - men det er der måske andre der kan svare på? :) Nu nævner I selv at OS2cloud skal ses som en IaaS der kan erstatte AWS - jeg kunne være interesseret I at høre hvorfor man ikke blot ønsker at benytte en eksisterende IaaS? Hvilket behov løser OS2cloud (og egne fysiske servere) som andre IaaS ikke løser bedre?

I forhold til teknologi synes jeg at man bør overveje at benytte noget der er mindre stateful end virtuelle maskiner som den mindste bestanddel. Her synes jeg man bør skæve til eksempelvis Docker containers og "container orchestration" systemet Kubernetes. Det gør det lettere at undgå "magiske opsætninger" og minimerer behovet for tekst der dokumenterer opsætningen.

Set fra en leverandør's synspunkt tænker jeg at et vigtigt ønske er at man kan få adgang til et driftsmiljø (helst via private/public-keys: Uden at skulle kende et password) og overtage fra en tidligere leverandør og at man samtidig ikke behøver at dokumentere alt for meget af sin opsætning som tekst, men istedet i konfigurationsfiler der kan checkes ind i projektets versionsstyrring.

Det var vist det bedste input jeg lige kunne komme på (:

Hej Kræn og Marius

Tak for jeres indspark - kom gerne med flere.
Først af alt - Docker vil blive understøttet fra dag ét.

Hele idéen med OS2cloud er at gøre det så enkelt som muligt, at få applikationer i drift, så vi vil meget gerne prøve at danne os et overblik over hvordan OS2-applikationer typisk distribueres i dag.

Det lyder som om en del af jer er interesserede i at pakke jeres applikationer som Docker-images, så naturligvis bliver det understøttet. Spørgsmålet er blot, om tilstrækkeligt mange OS2-applikationer allerede distribueres som Docker-images, eller om vi skyder over målet ved f.eks. at forlange det. Jeg tvivler på at vi på nuværende tidspunkt kan ignorere "almindelige" applikationer. Det kunne være rart med en indikation af, hvor mange OS2-applikationer der i dag er pakket som Docker-images, og hvor mange der ikke er. Her tænker jeg også på Windows-applikationer, hvor der ydermere er licenshensyn at tænke på.

Som I ved, er Docker en container-teknologi, og er som sådan jo nødt til at køre ovenpå et eller andet.
En del af grundlaget for OScloud er, at driften afvikles i danske datacentre med anvendelse af åben og dokumenteret teknologi. Af juridiske årsager, men også af den enkle grund at det er billigere og synes vi, mere tilfredsstillende.
Hvis vi selv vil køre ting, slipper vi ikke for jern :) Men - af mange årsager kører vi en hypervisor ovenpå dette jern, og containere indeni.
Når man f.eks. kører Docker-applikationer via Amazons ECS-tjeneste ender man også med en samling EC2-instanser. Virtualisering er nu engang af mange årsager kommet for at blive. Den hypervisor vi har valgt er KVM fordi det er den der er mest direkte integret med Linux-kernen.

Fra dag ét bliver det muligt, at starte en Docker-server op som en én-klik app. Hvis man har publiceret sin applikations Docker image til Docker Hub, kan man således blot starte det op med en enkelt 'docker run' kommando.
På sigt ønsker vi at bygge en Docker Machine driver, så man direkte fra sin lokale Docker Machine kan provisionere nødvendige ressourcer i OS2cloud og starte sine Docker images. Alle hænder er mere end velkomne til at bidrage hertil når vi går i gang.

Vi er desuden meget interesserede i at i høre fra dem af jer, der måtte have erfaring med Docker Swarm.

Vi glæder os til at komme videre med projektet.
Hvis nogle er interesseret i prisovervejelser, og hvorfor det ikke nødvendigvis er en fantastisk idé blot at køre hele Danmarks infrastruktur i AWS, så kig f.eks. her: https://www.origo.io/info/prischeck/?lang=da

OS2Cloud er et spændende og vigtigt initiativ, men jeg er ligesom Kræn overrasket over for den arkitektur der lægges op til.
Det vil uden tvivl være et stort skridt for mange kommuner at anvende open source strategisk, derfor ville det være en hjælp for beslutningstagerne, hvis den platform og leverandør der anvendes har størst mulig udbredelse og leverandørunderstøttelse.
En løsning kunne som Kræn påpeger, være en Docker orienteret arkitektur, som ikke har bindinger til platformen og det vil være en sikkerhed for mange, at kunne flytte containeren.

Glimrende initiativ. Blot skal man være opmærksom på, at der er OS2 løsninger som kører som én instans med mange kommuner som brugere - fx KITOS. Her handler det om at kunne skalere op til det antal kommuner der nu bruger produktet. Her er det vedlighold af applikationen der er central, således at man kun skal vedligeholde én instans.
Derfor er arkitekturen på en sådan cloud løsning vigtig. Der skal både være mulighed for 1 server-1 kommune men også 1 cluster-mange kommuner

Sider