Platon produktstrategi 2024 - 2026

Platons produktstrategi har som hensikts å kommunisere og forankre retningen for Platon - Sikts utviklerplattform og kjøremiljø, og gi en oversikt over de viktigste prioriteringene og utfordringene vi står ovenfor i perioden 2024 - 2026.

• Versjon: 1.0 - 23. september 2024, denne versjonen er skrevet basert på både en intern prosess i Platon, og en involverende prosess med alle produktområdene i Sikt.

Mål og visjon

Platons visjon er: «Platon skaper Norges beste utvikleropplevelse».

Platon er Sikts felles utviklerplattform og kjøremiljø, og skal gi utviklerne på produktteamene en plattform som gjør det enkelt og attraktivt å jobbe med kontinuerlig utvikling i Sikt.

Platon er til for alle produktområder som har utvikling og eller drift av tjenester. Platon skal levere en lik plattform for alle team som dekker de fleste av produktområdenes behov. Der produktområder har særskilte behov, skal Platon tilby fleksibilitet som gjør det mulig for produktområdet å bygge egen funksjonalitet på toppen av felles plattform.

Gevinster

Platon skal gi Sikt følgende gevinster:

• Platon gjør utvikleren god: Bedre brukervennlighet og mer selvbetjening (DevEx - developer experience). Det aller viktigste målet med vår felles utviklerplattform er å fjerne friksjon og gjøre hverdagen som utvikler enklere. Dette oppnår vi med kombinasjonen av sømløse og automatiske integrasjoner mellom alle bestanddeler i plattformen kombinert med 100% selvbetjening. At det er attraktivt å være utvikler i Sikt, er viktig både for å beholde utviklere og for nyrekruttering. Automasjon og selvbetjening gjør også onboarding mye raskere både av nyansatte og ansatte på nye team.
• Platon legger til rette for kontinuerlig utvikling i Sikt: Kontinuerlig utvikling innebærer at produktteamene tar et helhetlig ansvar for applikasjonen i hele livssyklusen. For å gjøre «ops»-delen av «devops» så enkel som mulig, trenger vi en moderne utviklerplattform og kjøremiljø hvor produktteamene får de tilpassede «ops»-tjenestene som gjør det enklere å håndtere livssyklusen til en applikasjon.
• Platon gir bedre informasjonssikkerhet: Platon har kapasitet til å bygge inn automatiske sikkerhetsmekanismer i selve plattformen, som f.eks. container-scanning og monitorering av avhengigheter. I tillegg har vi oversikt over alle våre tjenester på en plass, og kan mer effektivt følge opp en sikkerhetshendelse, eller få oversikt over hvem som er berørt av en sårbarhet. Dette involverer et tett samarbeid mellom Platon og «intern sikkerhet».
• Harmonisere teknologi og infrastrukturvalg i Sikt: Det var ikke tre ulike utviklermiljøer som ble slått sammen til ett Sikt 1. Januar 2022. Det var et hav av ulik teknologi, infrastruktur, arbeidsmåter og kultur. Målet i Sikt er at alle samles på en felles utviklerplattform og kjøremiljø. Dette vil ha en harmoniserende effekt, selv om Platon tilbyr stor frihet i øverste del av teknologistacken. En felles plattform legger til rette for mer deling og samarbeid blant utviklere på tvers av divisjoner og produktområder. Det blir enklere for utviklere å bytte mellom team, når utviklerplattformen er den samme. Onboarding til et nytt team blir mye raskere når veldig mye er likt.
• Platon er kostnadseffektivt: Forventningene til en moderne utviklerplattform er høye, og det en betydelig jobb og utvikle og vedlikeholde en slik plattform. I tillegg er det nødvendig at kunnskap og erfaring med alle deler av plattformen er spredt på flere medlemmer av plattformteamet. Det er derfor med kostandseffektivt å ha en felles plattform, istedenfor mange ulike. Dette forutsetter riktignok at produktområdene til en viss grad tilpasser seg plattformen, for å unngå for mye sprikende funksjonalitet.

Kontinuerlig utvikling - fra «driftsavdeling» til «plattformteam»

Tradisjonelt har utvikling og drift vært adskilt i ulike team. Utviklerteamene utvilket nye versjoner av tjenestene, som deretter ble overlevert til en dedikert driftsavdeling for vedlikehold og som var ansvarlig for oppetid. Det var gjerne ganske lang tid mellom hver oppdatering, og driftsavdelingen hadde en stabil og forutsigbar hverdag. Hver oppdatering var gjerne også kombinert med mye manuell testing.

Denne tilnærmingen møter imidlertid utfordringer i lys av moderne programvareutviklingsmetoder. Med fremveksten av DevOps, plattformteam, og en kultur for hyppige oppdateringer – noen ganger flere ganger daglig – har landskapet endret seg betydelig. Plattformteamene representerer ikke en driftsavdeling i tradisjonell forstand. I stedet fokuserer de på å vedlikeholde og optimalisere plattformen som applikasjonene kjører på, mens selve applikasjonsdriften forblir utviklerteamenes ansvar. Dette krever en fusjon av utvikling og drift (DevOps), hvor teamene tar et helhetlig ansvar for både utvikling og drift av tjenestene.

For å maksimere nytten av denne modellen, er det kritisk med en klar og felles forståelse av ansvarsfordelingen mellom plattformteamet og produktteamene. En slik forståelse er avgjørende for å realisere de fullstendige fordelene ved å implementere en plattform som Platon.

Produktteam, som tradisjonelt har vært vant til en separasjon mellom utvikling og drift og som kanskje har støttet seg på eksterne partnere for drift av applikasjoner, vil oppleve en betydelig endring. Overgangen til en kultur for kontinuerlig utvikling og drift krever en strategisk tilnærming og må reflekteres i produktstrategiene for hvert enkelt område.

Strategiske prinsipper for Platon

Følgende strategiske prinsipper skal være førende for hvordan Platon velger å løse nye utfordringer og behov:

1. 100% Selvbetjening og automasjon, for å fjerne friksjon og gjøre hverdagen som utvikler enklere.
2. Hjelp til selvhjelp, Platon skal hjelpe produktteamene til å få best mulig utbytte av plattformen, men uten å gjøre arbeid som ligger til produktteamet. Platon skal heller aldri bygge inn applikasjonsspesifikk funksjonalitet i plattformen.
3. Eierskap til infrastrukturressurser. Absolutt alle infrastrukturressurser konsumert på Platon skal være tydelig registrert med en eiertilknytning til et produktområde. Gjerne produkt og team i tillegg, der dette er hensiktsmessig. Det skal også være synlig og kommunisert til produktområdene hvilke ressurser de har konsumert på Platon.
4. Isolasjon for økt sikkerhet. Som utvikler på et produktteam skal det ikke være noen mulighet for å påvirke eller endre andre tjenester, hverken tilsiktet eller utilsiktet. Dette er en viktig del av sikkerhetsmodellen til Platon.
5. Plattformlaget skal være tynt: Platon skal tilstrebe å bygge en robust og brukervennlig plattform med minst mulig funksjonalitet i plattformlaget. Det aller meste basisfunksjonalitet vil vi videreformidle fra underliggende skyleverandører, og funksjonaliteten og merverdien Platon legger til skal primært være knyttet til enklere bruk, integrasjon mellom plattformtjenestene og integrasjon med Sikt sin organisasjon og Sikt sine øvrige systemer.

Målgruppe og tjenesteportefølje

Platon er til for alle produktområder som har utvikling og/eller drift av tjenester. Allikevel er produktområdene ulike. I produktstrategien ønsker vi videre å dele inn produktområdene i følgende grupperinger:

1. Produktteam med egenutvikling og behov for kjøremiljø.
2. Produktteam med egenutvikling, som ikke har behov for kjøremiljø
3. Produktteam som ikke utvikler, men kun drifter applikasjoner eller systemer.

Målgruppe	Utviklerplattform	Kjøremiljø	Produktteam
1	Ja	Ja	Feide, SA, NVA, eduCSC, CNaaS-dev
2	Ja	Nei	Microdata
3	Nei	Ja	CNaaS, Analyseplattformen

Platon kan gjøre vår utviklerplattform tilgjengelig for kundene våre, men ikke med det første.

Platons mål er å først lykkes med en solid intern utbredelse og adopsjon, før vi tilbyr vårt interne kjøremiljø til kundene våre. Vi håper å kunne nå det målet, og inkludere tjenester ut mot våre kunder i neste strategiperiode.

Produktdifferensiering

Fra og med 1. januar 2025 ønsker å vi å differensiere tjenestetilbudet fra Platon i to produkter:

• Utviklerplattform
• Kjøremiljø

Dette gjøres primært for å kunne tilby en litt mer rettferdig kostnadsfordeling mellom produktområdene. Se mer under finansieringsmodell.

Produktportefølje

Tilbudet til Platon består av en lang rekke ulike verktøy og infrastrukturtjenester som er tilgjengelig for produktområdene. Disse verktøyene settes sammen og utvikles i tråd med behov og etterspørsel fra produktområdene. Nedunder følger en oversikt over de viktigste tjenestene som tilbys per nå fordelt på henholdsvis utviklerplattform og kjøremiljø. Gå til Platons dokumentasjon for en fullstendig oversikt.

Utviklerplattform

• Gitlab
• Gitlab pipelines
• Artifakthåndtering (artifactory, ECR)
• Sikkerhetsscanning (dependency track)
• Gitops (kommer senere)

Kjøremiljø

• Platon PaaS
• AWS konto
• Managed VM (Puppet, LDAP og mer)
• Overvåking (zabbix)
• Observabilitet / felles logging (humio, grafana, prometheus, loki, og tempo)
• Backup
• Managed database (RDS / postgresql)
• Managed S3
• HTTP sertifikater
• DNS
• E-mail
• HTTP Redirects
• Hemmelighetshåndtering (vault)
• Bruksstatistikk web (Matomo)
• Teknisk dokumentasjon (docusaurus)

Prosess for produktstrategi

Som endel av forankringen av Platons retning, men også for å få tilbakemeldinger på retning og behov produktområdene har så arrangerte vi tre fysiske heldags produktstrategi workshop.

• Bergen, 11. april 2024
• Trondheim, 18. april 2024
• Oslo, 22. mai 2024

Deltakerne var aktuelle produktområdeledere, seksjonsledere, tech-leads og noen andre nøkkelpersoner. Alle tre workshopene ble fasilitert av Ann Kristin fra Designlaben, og forberedt av Andreas, Yamuna, Ann Kristin og Anders.

Agenda for produktstrategi-workshopene var som følger:

• Introduksjon
• Platons retning (ved Andreas)
• Workshop del I: Tilbakemelding platons retning - i grupper
• Workshop del II: Open space

Platons retning

Platon har allerde stor fart og har allerede en retning som ble presentert for produktteamene. Denne retningen har blitt veldig mye tydeligere etter forberedelsene til workshopene, der Platon-teamet selv har reflektert og vurdert det de tror vil være den beste retningen for Sikt i strategiperioden. Dette ble presentert for deltakerne. Hensikten med dette var både å forankre Platons eksisterende retning, men også samle nyttige tilbakemeldinger som kan hjelpe oss å justere jursen der det er nødvendig.

Det er en overveldende positiv repons på retningen Platon har tatt, og det er bred enighet om at dette er riktig retning.

Samtidig fikk i mange nyttige tilbakemeldinger og noen bekymringer. Disse ble plukket opp i open space diskusjonene, hvor temaene ble diskutert grundigere i grupper.

Selv om det er bred enighet om retningen, er det mange tilbakemeldinger på at man ønsker mer støtte og flere tjenester fra Platon. Når dette ble diskutert, ble det klart at Platon ikke kan være i stand til å levere på alle forventninger med de nåværende ressursene, men blir nødt til å gjøre en tydelig prioritering. Det ønskes bedre kommunikasjon rundt hvilke prioriteringer som gjøres forløpende, for en tydeligere forventningsavklaring, og for at produktområder kan planlegge bedre deretter.

Open Space

Open space betyr at deltakerne spiller inn tema som skal diskuteres og gis tilbakemleding på, og deltakerne voterer over forslåtte teamer, og deltar i gruppearbeid på ønsket tema.

Temaene med flest voteringer, og som dermed ble diskutert var følgende:

Bergen:

• Hvordan kommer vi oss fra Azure til Platon?
• Hva ønsker vi oss fra Platon?
• Platon tett på produktteamene - hvordan?

I tillegg til temaene som kom opp i open space, har vi fått et notat fra utviklermiljøet i Bergen med konkrete ønsker og behov. Dette inkluderer følgende punkter:

• Platon bør redusere kompleksiteten ved bruk av kubernetes
• Platon bør automatisere tilgang til alle infrastrukturressurser. Noen av ressursene håndteres nå ved manuell bestilling. Det er også ønske om enklere og automatisert tilgang til flere AWS tjenester enn i dag.
• Platon bør rendyrke en sikkerhetsmodell hvor tjenester kommuniserer på private nett og hvor vi reduserer eksponeringen av tjenester til internett. Dette inkluderer å begrense tilgang til vårt database-cluster.
• Platon bør tilby en bedre og mer brukervennlig løsning for overvåking.
• Platon bør tilby en bedre løsning for observabilitet enn Humio.

Trondheim:

• Fleksibilitet versus standardisering: Her ble det diskutert betydningen av standardisering i arbeidsflyten og understreket at dette er avgjørende på flere områder, inkludert språk, utviklermiljø, logging, og backlogs. Det ble påpekt at når man avviker fra standardmetoden, er det viktig å ha velutviklede "templates" for å håndtere spesifikke behov og situasjoner effektivt. Videre ble det nevnt at for de som foretrekker serverless-løsninger, kan en Kubernetes-plattform oppleves som en nedgradering på grunn av den lavere abstraksjonen sammenlignet med serverless arkitekturer.
• Loggverktøy: Deltakerne uttrykte bekymring for utfasing av Humio og usikkerhet rundt hva som vil erstatte det. Flere team har avhengighet til Humio for avanserte dataanalyser, og det ble understreket at eksterne brukere fortsatt vil trenge tilgang til loggene. Behovet for visualisering av loggdata gjennom dashbord som gir oversikt, viser grafer, og lagrer ofte brukte spørringer, ble fremhevet som viktig for de fleste team. I tillegg ble rask respons og evnen til å søke i store datamengder trukket frem som kritiske faktorer for å opprettholde god ytelse. Enkelte deltakere understreket også viktigheten av å håndtere multi-tenancy effektivt, spesielt hvis den nye løsningen skal kjøres i skyen.
• Senke terskel: For å sikre en vellykket innføring av Platon, er det viktig å fokusere på effektiv onboarding, grundig opplæring og målrettet markedsføring. Hvert produktteam bør gjennomgå en bootcamp for å øke kompetansen rundt Kubernetes og DevOps. Platon-konsulenter bør være tilgjengelige for å bistå med opplæring og sikre at teamene forstår fordelene og kostnadsbildet knyttet til Platon. Det er også avgjørende å tydeliggjøre sammenhengen mellom Platon og Zenon, samt dele suksesshistorier fra team som har hatt positive erfaringer med Platon, for eksempel overgangen fra RT-on-prem til skyen.
• Måling og oversikt: Det ble fremhevet behovet for et oversiktlig dashboard for produktområdeledere som gir innsikt i aktiviteter i Platon PasS og i AWS samt informasjon om sikkerhet, inkludert sårbare systemer og tjenester. Kostnadskontroll ble også identifisert som kritisk, med fokus på skalering, elastisitet, prisutvikling og prediksjon, samt egresskostnader. Det ble etterlyst en detaljert kostnadsoversikt pr. team og produktområde, med mekanismer for å beskytte mot prisstigninger ved å alltid ha alternative løsninger tilgjengelige. Videre ble det påpekt viktigheten av tydeliggjøring av hva som ligger i AWS, Platon, on-prem, og Zenon, samt behovet for en sky exit-strategi. Det ble også etterspurt bedre kostnadsfordeling og rabatter, da dagens AWS-grensesnitt ikke alltid reflekterer disse.
• Samspill med Zenon: Det ble foreslått at løsningene bør være mest mulig like, med samarbeid mellom teamene Platon og Zenon for å sikre en enhetlig tilnærming. Deltakerne anbefalte at både grensesnittet og funksjonaliteten skal være ensartet, og at kontrollplanene bør være identiske. Videre ble det uttrykt et ønske om et nært samarbeid mellom Platon og Zenon for å oppnå disse målene.

Oslo:

• Hvordan gjør produktteam gode: DevOps-kultur og forbedring av utvikleropplevelsen (DevExp) ble flere nøkkelpunkter fremhevet. For å fremme effektiv kommunikasjon mellom teamene ble det anbefalt å bruke Slack som hovedkanal. Det ble også påpekt viktigheten av å etablere felles retningslinjer og rammeverk for alle produktteam, for å sikre en enhetlig arbeidsmetodikk. Kostnadstransparens ble trukket frem som en nøkkelfaktor, der det skal være tydelig hvilke ressurser utviklerne bruker, samt deres tilhørende kostnader. Videre må det være klart definert hva Platon tilbyr og ikke tilbyr, slik at teamene har realistiske forventninger. For å bruke Platon effektivt, må teamene få den nødvendige kompetansen, og det er viktig å identifisere hvilke ferdigheter som kreves. Til slutt ble det understreket hvor avgjørende det er å kontinuerlig måle utvikleropplevelsen for å evaluere fremdrift og gjøre nødvendige justeringer. Disse tiltakene vil bidra til et mer produktivt og tilfredsstillende arbeidsmiljø for utviklerne.
• Hvordan jobbe med brukerbehov: Først ble det understreket viktigheten av å koordinere behov, både ved å samle innspill fra ulike kilder, som produktområdeledere og utviklere, og ved å spille disse behovene inn til relevante parter. Å identifisere kritiske områder, samtidig som man opprettholder transparens og tillit, ble også nevnt som avgjørende for å bygge et godt samarbeid. Videre ble det påpekt at det er viktig å hjelpe teamene med å forstå sine egne behov bedre, samt behovet for å utvikle løsninger i samarbeid med andre i sektoren. For å kunne vurdere effekten og konsekvensene av ulike tiltak, er det nødvendig med innsikt i hvordan ressurser, inkludert økonomiske midler, blir brukt. God kommunikasjon var et annet sentralt tema, hvor man diskuterte hvilke kanaler som brukes til å dele informasjon. Til slutt ble suksesskriterier for prosjektene drøftet, for å sikre at man har klare mål og kan evaluere fremgang på en meningsfull måte.
• Kulturbygging på DevOps: Sikt tar en mer aktiv rolle i å forklare hvordan vi bygger DevOps-kulturen, inkludert diskusjoner på ledermøter for å sikre forståelse på tvers av organisasjonen. For å forbedre utvikleropplevelsen (DevEXP) er det viktig å forstå behovene til både teamene og brukerne. Platons veikart for Sikt skal også være en del av lederseminarene for å sikre en helhetlig innsats i byggingen av DevOps. Det ble vektlagt at det må være en tydelig "gylden sti" som viser hva man satser på, samt behovet for tettere oppfølging av teamene for å sikre fremdrift og kvalitet. God bruk av observabilitet og logger er sentralt, og Platon bygger videre kompetanse gjennom sitt "Center of Excellence". Det er også behov for klare veiledninger til teamene om hvilke kompetanseområder de bør utvikle.
• Hvilke tjeneste trenger vi egentlig fra Platon: Det ble identifisert flere viktige tjenester som trengs fra Platon for å forbedre plattformens funksjonalitet og sikkerhet. Dette inkluderer en asynkron meldingstjeneste, utvidet sikkerhetstesting som IAC-scanning, og bedre løsninger for release management og anomaly detection. Behovet for sikker lagring og håndtering av sensitive data, inkludert Cloud HSM, ble også fremhevet, sammen med tjenester for optimalisering av kostnader. I tillegg ble det påpekt behov for egne Kubernetes-clustere og håndtering av privilegerte identiteter.

Dagens bruk av Platon

Platon brukes på tvers av alle tre divisjonene i Sikt. Men produktområdene har ulik grad av bruk, og det er ulike tjenester som brukes.

Det er to produktområder som ikke har produktutvikler, og dermed heller ikke er i målgruppen til Platon. Dette gjelder:

• Administrasjonstjenester (UA)
• Lisenser og åpen tilgang (FK)

Det er mange produktområder som fortsatt har mange systemer som kjører på alternative kjøremiljø, og enda ikke migrert inn til Platon.

• Flere produktområder i FK (Bergen) har tjenester som kjører på Azure, og som ikke er migrert til Platon.
• Studieadministrasjon (UA) har mange systemer som fortsatt kjører på UiO IT-avdelingen sin infrastruktur, og enda ikke er migrert til Platon.
• Innenfor divisjon data og infrastruktur har flere produktområder mange tjenester fortsatt kjørende på on-premise infrastruktur av ulike grunner.

Migrering av tjenester fra en infrastruktur til en annen er krevende øvelse, og det er helt urealistisk at Sikts mangfold av ulike systemer og tjenester i en kan flyttes i en håndvending. Med bakgrunn i teknologimangfoldet og fragmentertingen i Sikts tjenesteportfølje, har vi grunn til å være svært fornøyde og stolte over den høye graden av adopsjon av Platon som allerede er oppnådd.

Oversikten over viser:

• Antall Gitlab-prosjekter tilknyttet produktområdet som har hatt aktivitet siste 90 dager.
• Antall Kubernetes namespaces per produktområde
• Antall AWS EC2 (virtuelle maskiner) per produktområde bestilt og levert av Platon. (her er datagrunnlaget mangelfult, kommer en oppdatering)
• Antall AWS kontoer per produktområde
• Antall databaser fra felles PostgreSQL cluster per produktområde
• Produktområder som har tatt i bruk henholdsvis Matomo, Artifactory, Humio og Observability 2.0

Merk: Arbeidet vårt med å trekke ut strukturerte bruksdata på tvers av alle de ulike systemene til Platon er relativt ferskt. Denne presentasjonen av bruksdata er derfor ikke komplett eller kvalitetssikret, men gir allikevel et lite innblikk i bruk av de ulike Platon-tjenestene på tvers av organiasjonen.

Sikt skystrategi

I Sikt ønsker vi at våre tjenester skal kjøre på offentlig skyinfrastruktur som førstevalg. Det er det mange grunner til, her noen av de viktigste:

• Bedre informasjonssikkerhet, både tilgjengelighet, konfidensialitet og integritet.
• En attraktiv arbeidsplass for yngre utviklere som ikke har erfaring med annet enn skyinfrastruktur, og som er tilvent arbeidsmåten og mange av fordelene i skyen.
• Vi ønsker at plattformteamet skal bruke mesteparten av sin tid på å lage gode tilpassede brukeropplevelser for Sikt-utviklere, og minst mulig tid på generell plattformdrift. For eksempel har vi migrert fra Kubernetes on-premise, til Kubernetes driftet på AWS EC2, og til Kubernetes på AWS EKS. Hvert steg har gitt oss en mye bedre tjeneste samtidig som mer av plattformdriften legges over på skyleverandøren, og kapasitet frigis til å bygge en bedre brukeropplevelse på plattformen.
• Offentlig sky tilbyr ekstrem grad av elastitet, hvor tilgjengelig kapasitet kan økes og reduseres med umiddelbar virkning i henhold til behov. Dette er gir oss kapasitet når vi trenger det, men er også med på å gjøre plattformen mer kostnadseffektiv, og redusert energiforbruk som er positivt bidrag til Sikts bærekraftsmål.
• Dagens utviklerteam forventer å konsumere plattformtjenester på et høyt funksjonelt nivå i teknologistacken. Det er nødvendig å begrense applikasjonsdrift-ansvaret til produktteamene til et minimum, og tilby høynivå tjenestegrensesnitt som gjør det mulig.

Det betyr at det blir en svært omfattende og krevende teknlogistack som må leveres, og samtidig er forventinger om profesjonalitet og informasjonssikkerhet skyhøye. Resultatet er at det enten blir veldig dyrt å levere dette selv, eller at man må gå på kompromiss med kvalitet.

Til tross for en velbegrunnet skystrategi, er dette en retning som kontinuerlig utfordres og problematiseres. Det to hovedtemaer som går igjen:

Utfordringer og usikkerhet

Til tross for en velbegrunnet skystrategi, er dette en retning som kontinuerlig utfordres og problematiseres. Det to hovedtemaer som går igjen:

Juridiske avklaringer rundt datalagring i tredjeland

Personvernlovgivning og juss rundt datalagring på tvers av landegrenser er svært komplisert, og mange virksomheter blir paralysert fordi de blir usikre på hva som er riktig å gjøre. Dette var ekstra tydelig i forbindelse med Schrems II-dommen.

Digital suverenitet og geopolitikk

Global uro, som krig, nasjonalisme og økonomiske nedgangstider påvirker forventninger om hvordan våre tjenester til norsk kunnskapssektor er rustet for store endringer og mer ekstreme unntakstilstander. Vi må lage grundige beredskapsplaner og forholde oss til nye initiativer som nasjonale skytjenester (etter NSM anbefaling).

Sikts tilnærming

Produktteamene i Sikt trenger en pålitelig og forutsigbar utviklerplattform og kjøremiljø. For å skape trygghet om dette har vi to tiltak:

Grundige juridiske avklaringer og personvernvurderinger

Platon har jobbet grundig sammen med Sikts jurister for en personvernvurdering og risikovurdering av Platon som kjøremiljø som gir oss trygghet i at vår måte å bruke AWS som skyleverandør på er gjort riktig og et godt fundament for Sikts tjenester.

Reduksjon av vendor lock-in

En reell bekymring med en infrastrukturplattform er at den gjerne er tilgjengelig over lang tid og dermed komplisert og dyrt å migrere vekk fra. Dette gjelder både sky og on-premise. Men blant annet for å redusere en eventuell exit-kostnad har Platon standardisert på kubernetes som grensesnitt for kjøremiljøet. Dette er et standardisert grensesnitt og det vil da være relativt enkelt å deploye en applikasjon til et annet kubernetes kjøremiljø på en annen infrastrukturplattform. Platon tillater allikevel høy-nivå AWS-tjenester med leverandørlåsing der det vurderes hensiktsmessig.

Uniformt kontrollplan med privat sky

Ved å gjøre vår on-premise infrastruktur (Zenon) så lik som mulig vår offentlige skyinfrastruktur, kan vi redusere kompleksiteten og kostnadene ved å drifte to forskjellige infrastrukturer. Et felles kontrollplan mellom Zenon og Platon gjør det også forholdsvis enkelt å migrere applikasjoner frem og tilbake mellom offentlig og privat sky. Dette setter oss i en bedre situasjon om ytre forutsetninger raskt skulle påvirke hvor vi kan kjøre tjenestene våre.

Valg av offentlig skyleverandør

De tre store leverandørene av skyinfrastruktur AWS, Microsoft Azure og Google Cloud er alle godt utviklede skyplattformer, og selv om hver og en av de har sine fordeler og ulemper vil alle tre i hovedtrekk kunne sies og være dekkende for Sikts behov.

Ved sammenslåingen til Sikt hadde vi stor bruk av AWS, noe bruk av Azure og liten eller ingen bruk av Google Cloud. Platonteamet har valgt å videreføre AWS som felles skyplattform for Sikt, og inntil videre forholder vi oss til en single-vendor strategi for utvikling og kjøretidsplattform. Det er sannsynlig at denne strategien utfordres med tiden, men da av spesialiserte behov hvor man vurderer «best-of-breed» for et veldig spesifikt område. Vi tror ikke single-vendor strategien utfordres på området generell utvilkingsplattform.

Synlighet og kommunikasjon

Platon iverksetter flere tiltak for å bygge tillit, sikre smidig samarbeid, og skape et transparent og kommunikasjonsvennlig miljø som som gjør det mulig for brukerne å utnytte plattformen på best mulig måte.

Kommunikasjonskanaler: Platon benytter dedikerte kanaler som Slack, interne fora (open office, workshops) der utviklere enkelt kan stille spørsmål, rapportere problemer og gi tilbakemeldinger. Plattformoppdateringer, nye funksjoner og kommende endringer deles åpent gjennom nyhetsbrev, utgivelsesnotater via Slack og i enkelte tilfeller via Teams. Dette holder brukerne informert, forebygger overraskelser og hjelper dem å tilpasse seg endringer.

Tilbakemeldinger: Platon oppfordrer aktivt brukerne til å gi jevnlige tilbakemeldinger om erfaringer, utfordringer og behov. Dette gjøres gjennom åpne fora, direkte samtaler og brukerundersøkelser.

Dokumentasjon og selvhjelp: Platon vedlikeholder omfattende bruker- og teknisk dokumentasjon, noe som gir brukerne mulighet til å løse problemer på egenhånd uten konstant avhengighet av plattformteamet.

Kunnskapsdeling: Det arrangeres workshops, webinarer og spørsmål-og-svar-økter for å lære opp brukerne i nye funksjoner og beste praksis. Dette sikrer at brukerne er velinformerte og kompetente i bruken av plattformen.

Kostnadstransparens: Platon arbeider med å tilby transparente oversikter over ressursbruk og tilknyttede kostnader. Dette gir team- og produktområdeledere innsikt i hvordan deres bruk av plattformen påvirker budsjettet, noe som fremmer ansvarlighet og bevissthet rundt forbruksmønstre.

Informasjonssikkerhet

I tillegg til produktteamene som er våre primære brukere, er også teamet «intern sikkerhet», ledet av CISO, en viktig målgruppe for Platon. For å kunne gjøre en god jobb, trenger intern sikkerhet gode verktøy og oversikt over kode, applikasjoner og infrastruktur på tvers av hele virksomheten. Disse verktøyene og denne oversikten er en viktig del av Platon sin tjenesteportefølje, og bidrar til at Sikt skal nå sine virksomhetsmål. Eksempler på tjenester fra Platon som er spesielt målrettet mot intern sikkerhet er: dependency track - som overvåker avhengigheter og sårbarheter i programvare, og Platon Dashboard som gir oversikt over all bruk av Platon.

Oppetid og beredskap

Platons mål er å tilby en robust og pålitelig plattform, med høy grad av redundans og høy tilgjengelighet. Platons kjøretidsplattform kjører i en høyredundant oppsett, hvor alle komponenter er replisert med failover på tvers av tre ulike availability zones. Dette betyr at mange ulike typer enkeltutfall ikke vil påvirke tilgjengeligheten til tjenestene eller bruken av Platon.

En stor del av kjøremiljøet i Platon er «managed by AWS», på et måte hvor AWS står ansvarlig for tilgjengligheten. Og oppetidsgarantier for enkelttjenester hos AWS er regulert i avtalene våre.

Det er allikevel enkelte typer utfall som kan kreve inngrip fra Platonteamet for å rettes. Platon har satt opp overvåking av både utviklerplattform og kjøremilø, med ulike typer alvorlighetsgrad. De mest alvorlige alarmene vil gå til Sikts servicesenter, som også har en bakvaktordning for å håndtere alvorlige utfall utenfor ordinær arbeidstid. Noen typer utfall kan håndteres av servicesenteret i henhold til driftsdokumentasjon. Om ikke vil servicesenteret kontakte personell fra Platonteamet som har den nødvendige kompetetansen. Platonteamet har ikke noen bakvarktordning, så det er ingen garanti for tilgjengelighet utenfor arbeidstid. Teammedlemmer som har anledning til å rykke ut utenfor arbeidstid vil få betalt overtid for dette. Platonteamet jobber veldig bevisst med å spre kompetansen på de ulike komponenene til flere i teamet, og har også en policy om at ingen skal være alene om å ha ansvar for en tjeneste. Dette ønsker sannsynligheten for at noen er tilgjengelig for å rykke ut ved alvorlige utfall.

Tjenester som kjører i Platon vil kunne ha utfall som skyldes applikasjonen, og det vil da være produktteamet som må rette feil ved utfall. Alle produktteam i Sikt, kan via Platon sette opp overvåking som gir alarmer til Sikts servicesenter ved utfall. Da er det viktig at produktteamene har god dokumentajson og avtale med servicessenter om hvordan utfall håndteres.

DevOps i Sikt

For mange team i Sikt, er overgangen til Platon en stor endring. En endring som krever både nye arbeidsmåter, nytt ansvar og ny kompetanse. At teamene lykkes med denne endringen er avgjørende for at Sikt skal kunne nå sine mål, men også for at Sikt skal få verdi ut av investeringen i Platon.

Platon vil ha sitt hovedfokus på å tilby en moderne utviklerplattform og kjøremiljø, og kan ikke ta det fulle ansvaret for den endringsprosessen som må skje i teamene. Det kan være interessant for Sikt at vi også har andre tiltak som hjelper teamene å lykkes med denne transformasjonen.

Strategiske valg

Kubernetes som uniformt - leverandøruavhengig kontrollplan

Platon har valgt Kubernetes som kontrollplan for å orkestrere vårt kjøremiljø. Kubernetes er svært utbredt, inkludert i offentlig sektor i Norge, og er det mest populære leverandør-uavhengige kontrollplanet for kjøremiljø.

Mange kjenner Kubernetes som en plattform for orkestrering av containere, men Kubernetes er en svært egnet plattform til å orkestrere alle mulige former for kjøremiljø. Med valget av Kubernetes så ønsker vi å oppnå to viktige mål:

• Kontroll og automasjon av kjøremiljø og alle konsumerte infrastruktur-ressurser blir lekende lett.
• Kontroll og automasjon av kjøremiljø blir leverandøruavhengig, og på den måten reduserer usikkerheten knyttet til innlåsing til enkeltleverandører. Det gjør også migrasjon til eller fra privat sky mye enklere.

Det er også et viktig strategisk valg at konfigurasjon av kjøremiljø for alle være applikasjoner er versjonert og lagret i git.

Som konkrete eksempler, vil flere av Platons tjenester, som i dag bestilles manuelt, kunne konsumeres automatisert via git, som f.eks. objektlagring i AWS og databaser.

Omforent kontrollplan med Zenon

Tre av våre produktområder innenfor DI har unntaksvis behov for noe on-premise infrastruktur. Dette er begrunnet i tjenester som må kjøre i nettet (som DHCP med mer), samt lagring av sorte (svært sensitive data).

Siden Zenon kun leverer kjøremiljø og lagring og ingen ytterligere støttetjenester, er det viktig at Zenon og Platon fungerer godt sammen. De fleste av Platons tjenester, med unntak av kjøremiljøet, vil være aktuelt å brukes i samspill med Zenon. Det er viktig at Platons komponenter er modulære nok at dette fungerer strømlinjeformet.

Større utviklingsoppgaver

Hvilke prioriteringer og hvilke større utvilingsoppgaver Platon jobber med til en hver tid er tilgjengelig på Platons veikart. Allikevel er det noen større utviklingsoppgaver som er så viktige at de fortjener en egen omtale.

Observabilitet 2.0

Formålet med oppgaven er å få innsikt i systemets sanntidsytelse for å sikre stabilitet, rask feilsøking og optimal ytelse. Platon bygger en observabilitetsløsning med Grafana-stack basert på Open-Telemetry standarder. Basert på innsiktene fra brukerbehovsworkshopen mener vi at Grafana-stack kan dekke mange av Sikts behov, selv om loggbruken er fragmentert i organisasjonen. Loggområdet er komplekst, og vi trenger mer erfaring for å vurdere om produktet møter alle krav.

Platon har startet piloter for å teste og samle innsikt:

• Studieadministrasjon (vår 2024)
• Dataforvaltning (høst 2024)
• Pilot med Feide for å teste ekstrem last
• Ønsker pilot med CNaaS og IAM/Mule
• Flere piloter med produktområder i 2025.
• Platon vil basere tiltak på erfaringene fra disse pilotene.

Kubernetes som et enkelt og komplett kontrollplan

Vi ønsker å kunne tilby tilgang til managed AWS ressurser via Kubernetes kontrollplanet, på en enkel og brukervennlig måte. I tillegg ønsker vi å gjøre bruken av Kubernetes enklere, ved å tilby enklere konfigurasjon av de typiske use casene i Sikt, via f.eks. SiktApp som en custom ressurs.

Multi-cluster

Vi skal forbedre mulighetene for isolasjon og sikkerhet mellom produktteamenes tjenester, og samtidig ha et effektivt, kostandseffektivt og driftssikkert kjøremiljø. Dette inkluderer bedre sikkerhet på nodene, og muligheter for å dele last på egne clustere eller virtuelle clustere.

Gitops

GitOps er en metode for å administrere tilstanden i et Kubernetes-cluster. Denne oppgaven går ut på å implementere GitOps, noe som kan føre til at utviklings- og plattformteam samarbeider smidigere, implementerer prinsipper for infrastruktur som kode, og utnytter versjonskontroll for å optimalisere sine kontinuerlige distribusjonsprosesser.

Effektiv og god tilgangsstyring

Sikt har ingen felles omforent modell for fingranulert tilgangsstyring til systemene våre. Dette er en forutsetning for den gode utvikleropplevelsen. God strukturert tilgangsstyring er en forutsening for selvbetjening og automasjon. Platon bruker allerede ulike former for grupper og tilgangslister, men vi blir nødt til å forbedre dette ytterligere. Platon vil gjøre dette på en måte som også kommer andre interne tjenester i Sikt til gode.

Finansieringsmodell

Platons finaniseringsmodell er enda ikke klar, men vil bli klar som en del av Sikts budsjettprosess for 2025 i løpet av høsten 2024. Videre tekst er kun en skisse basert på forberedelser til budsjettprosessen, og kan endres.

Måling og nøkkelresultater

Måling av utbredelse og bruk

Det er viktig for Sikt at utbredelsen av Platon øker, og at vi reduserer fragmenteringingen av infrasturktur, dobbeltarbeid og dobbeltkostnader. Derfor har vi et nøkkelresultat på Platons utbredelse.

Vi kommer tilbake til en definisjon av denne metrikken og hvordan vi måler den.

Måling av utviklertilfredshet

Et av de viktigste målene for Platon er fornøyde utviklere. Derfor har vi et nøkkelresultat på utviklertilfredshet.

Vi kommer til å gjennomføre fortløpende undersøkelser av utivklertilfredsehet, og mest sannsynlig ved bruk av geekbot eller tilsvarende via Slack.

Veikart

Platons veikart oppdateres kontinuerlig, og er tilgjengelig på Gitlab.