Community på Sveriges dataportal

@Maria_Dalhage

skapa en sida på NOSAD som heter Exempelkrav.

Nu hänger jag inte med, har sett att man kan begära behörighet att editera vissa sidor där men skapa egna sidor, hur och var? Har du något exempel?

Självklart behöver du info.klassa metadatan/metrik som produkten ska konsumera för att fungera. Men givet att den delen är godkänd...

Att få hjälp med att drifta en övervakningsplattform, att slippa övervaka övervakningsplattformen, ja, det finns fördelar med det.

Jag kommer att blotta min okunskap i juridiken här. Behöver ställa en del "dumma frågor", tur för mig att det inte finns "dumma frågor" då...

Produkter som Google Anthos och Azure Arc (med eller utan HCI Stack) har tagits fram för att stötta vid uppbyggnad av hybridmoln och låta kunden nyttja automation och övervakning m.m. som SaaS medan man (om man så vill) låter applikationskod och dess data ligga på de egna servrarna. Du släpper (iaf i teorin) bara iväg metadata (namn på applikationer och liknande), metrik och ev loggar till, säg, det amerikanska företaget.

Utan att gå allt för djupt på någon specifik produkt, har vi någon här som upphandlat någon liknande tjänst eller kikar på denna produktkategori?

Ex finns möjligheten att för ca 4-5000 kr/månaden få tillgång till en produktionsmässig kubernetesplattform i den egna VMWare-miljön. "Produktionsmässig": 3x control plane noder med 4vCPU och 3x worker noder med 4vCPU för applikationscontainers (valfri mängd RAM/disk givetvis, men debitering sker per vCPU).
Dessutom får du en "app store" (marknadsplats med - förhoppningsvis - kvalitetssäkrade och testade helm charts - operators) för en förenklad installation och - i teorin - förenklad förvaltning av en mängd olika OSS-projekt så som Postgresql, Jitsi videosamtalsplattform m.m. m.m. Uppe på det har du självklart god tillgång till proprietära add ons från molnleverantören som mycket väl kan vara väl värt den potentiella inlåsningen (low code plattformar, CI/CD produkter etc).

Det jag har hört är att bara det faktum att det finns en amerikansk part i målet och den ev förmågan för denna att överföra data från on prem-servrarna till företagets datacenter (även om produkten i sig inte ska göra detta) kräver att individuella avtals sluts kring att detta inte får/kan ske.

Det kanske finns en massa for-dummies-läsning i ämnet? Eller vad finns det för klokheter/erfarenheter här?

Gillar förresten hur
https://government.github.com/community/
genereras från xml i detta repo:
https://github.com/github/government.github.com/blob/gh-pages/_data/governments.yml

Men ok versionshanterad källdata på Gitlab/GitHub och någon client side JS app för att passa och presentera?

Och så smackar man på något JS-bibliotek för sök och filtrering?
Det låter ju lättförvaltat och med hyfsat human UX. Med reservation för att jag kan ha missförstått helt och hållet..

@jonass Hmm, nosad.se/tips parsar markdown från en wikisida på Gitlab? Ursäkta om jag är helt ute och cyklar...

Vi sitter idag med ett växande Excel-dokument för de krav som används vid upphandling. Vi har under en tid pratat om att API:fiera den. Jag handledde även ett projekt med en LIA-student för att bygga en prototyp med C#/dotnet core API. Vår kära student gjorde ett fantastiskt jobb men vi var inte riktigt framme i våra egna tankar i tid till LIA-perioden.

Nu är det hög tid att inspireras av er som gjort en liknande resa. Jag har ju svårt att tro att vi har jättemånga krav i vår egen lista som är helt unika för oss. Kanske någon enstaka punkt.

Jag har sett Umeås öppna dataportal. Och har sett någon diskussion om wikidata här på forumet men hade lite svårt att relatera det till vårt behov.

Var börjar vi? Utveckla ett eget REST API, nyttja något populärt ändamålsenligt projekt, nyttja en färdig produkt (SaaS, egen drift)?

@Maria_Dalhage Tror ni tänker helt rätt med öppna forum och med oinspelad tid under seminarier. Jag försöker själv förstå bättre varför frågor som känns självklara för mig inte ställs i god tid. Varför öppen källkod öht inte ens tas med som byggkloss.

Att fånga in frågor innan seminarier/workshops tror jag på. Ett sätt att fånga upp en och besvara allmänna frågor.

Jag har sett att vissa molnleverantörer börjar prata om kurerad open source (testad, kvalitetssäkrad, uppdaterad) och de har numera app stores som kan köras on prem (eller i molnet givetvis). Hur bra det funkar i praktiken kan jag inte svara på men jag tror att den här modellen kommer att bli populär. Snabbt och enkelt att direktupphandla och testa.

Och i den andra änden det här behovet av att lyfta blicken och få utifrånperspektivet, att få hjälp att se vilka utmaningar som vi delar med många andra org.

Bra seminarium om "Affärsmodeller och leverantörsaspekter kopplat till open source" idag. Och bra diskussioner. Tack för det!

Jag tror att inspelningen kommer landa bra hos flera hos oss.

Jag tänker - helt allmänt - att en stor orsak till lågt nyttjande av OSS är okunskap och att man som upphandlare förväntas vara den med koll på läget. Och den förväntan gör det bara svårare att säga att man inte vet eller hade koll på alternativa lösningar/angreppssätt.

Vi intalar oss att våra egna behov är helt unika och att vi behöver en unik lösning (vilket resulterar i anbud från den leverantör som bäst säljer in att de kan lösa dessa unika behov - vilket de självklart kommer att säga så övertygande som de bara kan).
Det vi behöver hjälp med är att se att våra behov ofta är ganska allmänna och att det finns generiska OSS-projekt som kan lösa dem. Och som konstaterades under seminariet så är några av de mest långlivade och framgångsrika OSS-projekten just de som löser mer generiska behov (OS, CMS, wiki, programmeringsspråk, containerplattform etc).

Men det är sällan ett enskilt OSS-projekt som löser behovet helt och fullt. Här behövs stödet från leverantörer och communityt att se möjliga integrationer mellan olika OSS-projekt (säg, en lösning för åtkomstkontroll - som sällan inkluderas out of the box).

offentligkod.se (som jag tidigare sett men inte riktigt tagit fasta på) är en superbra del i detta. Väldigt användbar för oss som redan är bekväma i termerna och OSS-communityt, tänker jag.

Vad jag letar efter är nog olika modeller för öppen, prestigelös, säljfri dialog om de lokala behoven och hjälp att se beröringspunkter med mer generiska behov i andra organisationer. Först därefter kan man vara redo att ta till sig tips om vilka OSS-projekt som utvecklats för att tillfredsställa dem behoven.
Det kan ju som bekant vara läskigt att ställa "dumma frågor" så här öppet på nätet och t.o.m. i en chatt under ett onlineseminarium. Allt på nätet är ju för evigt!

Så... jag vet inte om jag frågar efter ett anonymt reddit.com för offentlig sektor, men det kanske är just det jag gör...

@lfvjimisola Jag är övertygad om att vi har en stor potentiell målgrupp som söker efter DevOps 101. Grunderna utan djupdykningar i tekniken och avancerad utvecklingsmetodik.

En till viktig fråga som jag själv behöver hjälp med är hur man bygger upp en förvaltningsorganisation för DevOps-orienterat utvecklingsarbete. Gärna kopplat till en typisk PM3-organisation.

Jag är iofs övertygad om att vi också har en stor grupp som suktar efter djupdykningar och mer nischade diskussioner. Båda behövs. Men personligen så ligger fokuset mer på 101-nivån, det är där vi är i min egen org.

@Maria_Dalhage ...men vettigast är väl om vi pratar ihop oss och tar in feedback om vilken typ av innehåll som tros vara mest värdefullt.
Kan tänka mig att det är värdefullt att ägna en del tid åt frågor som

• Vad är DevOps och var kommer begreppet ifrån
• Vad hade vi innan?
• Praktiska exempel på DevOps-metodik
• Teknologier som ofta associeras med DevOps: öppen källkod, molntjänster osv
• Vad är DevSecOps

Själv är jag mycket nyfiken på att höra om just praktiska exempel från organisationer som i någon grad jobbar enligt dessa principer idag.

@Maria_Dalhage Kul och bra initiativ @lfvjimisola!

Jag kan absolut tänka mig att prata kring frågeställningar hos en organisation som tar sina första steg mot DevOps. Vi står inför att utforma uppdrag kring DevOps-etablering och är mitt i en omorganisation som formellt startas 2023. Jag ska höra runt lite här om vi kan sätta ihop något gemensamt. Prel.boka!

@Nina_Berlin Jo men det finns en hel massa best practice och tekniska förmågor som brukar förknippas med DevOps som jag tror på. Versionshantering av allt: kod, konfiguration, dokumentation, infra som kod m.m. Kontinuerlig integration (trunk based, med testautomation), kontinuerliga leveranser i pipelines som är förståeliga för både drift och utv (oavsett hur du bygger upp det tekniskt).

I slutändan vill vi leverera värde och vi vill att utvecklare/designers/UX får möjlighet att fokusera på affärslogik/användbara gränssnitt och att göra det iterativt med massor av actionable feedback från både driftsystem och användare (med mycket kontext). Sen behöver vi kunna byta kurs och pivotera vid nya insikter. Om vi gör det bäst i någon form av low code plattform, varför inte! Men jag tror mer på en mix av REST API:er uppepå plattformar som abstraherar underliggande infra (tänk serverless, även om begreppet används rätt slarvigt och kanske bara kan realiseras mha en ganska komplex Kubernetes-plattform om du behöver köra in prem, likt som många av oss ju måste).

Containers i sig är nyttigt för utvecklare för att få mer empati och förståelse för drift, med fördelar som att slippa "works on my computer" osv. Jag är själv rätt djupt insatt i Kubernetes och tycker att det har varit fantastiskt värdefullt att lära sig - både för att lära sig hur big tech & friends gör och att se hur folk mycket smartare än mig och med en helt annan skala än jag kanske någonsin kommer att vara i närheten av löser en hel del svåra problem. Och jag uppskattar verkligen alla barriärer som k8s tar bort när man väl kommit över inlärningströskeln. Så, om man inte kastar sig in i k8s och micro services för egen del, lär dig iaf vad det handlar om. Det är ett svindlande lyckat OSS projekt om inte annat! Även ekosystemet runt.

Hm.. stannar där för ikväll
Blir svårt att hålla sig inom ämnet Arbetssätt här

Mitt första inlägg här och jag vill höra mig för om hur det tänks och tycks kring DevOps och DevSecOps?

Jag har följt rörelsen under ett antal år som serverdriftare och utvecklare och har väl en del tankar och åsikter.

Några formuleringar om DevOps och DevSecOps:
Cloud Native Computing Foundation:
"En metodik där team tillsammans äger hela processen från systemutveckling till drift i produktion, därav namnet DevOps. . . . DevOps kräver att utvecklare och drifttekniker fokuserar på mindre komponenter (inte större funktioner) vilket leder till mindre överlämningar (en vanlig felkälla)."

Google Cloud:
“En organisatorisk och kulturell rörelse som syftar att öka takten på mjukvaruleveranser, förbättra tillgängligheten och pålitligheten för tjänster och att bygga ett delat ägarskap emellan intressenter.”

Department of Defense:
"DevSecOps är en samling aktiviteter och förmågor inom systemutveckling som kombinerar utveckling, säkerhet och IT-drift med syftet att göra leveranser säkrare och att korta ned utvecklingsprojektens livscykler. Ny funktionalitet, buggrättningar, säkerhets- och andra uppdateringar ska kunna ske oftare och på ett mer automatiserat sätt. Säkerhet appliceras i alla faser av utvecklingsprojekten."

DevOps är ju inget som ersätter Lean och Agile, men delar av det kan (potentiellt) hjälpa oss att jobba enligt Lean- och Agile-principer.

Den årliga State of DevOps Report som gjorts sedan 2014 menar att de bästa måtten för en organisations utvecklingskapacitet är:

1. Ledtid till release (från incheckad källkod till driftsättning)
2. Hur ofta driftsätter vi nya releaser
3. Tid det tar att återställa en tjänst (MTTR - Mean Time To Restore)
4. Hur ofta orsakar en förändring/release problem

Och det låter väl i alla fall sunt?

Jag läste boken Accelerate förra hösten (från initiativtagarna bakom rapporten) och skrev ner några meningar...

Några dåliga sätt att mäta utvecklingskapacitet i organisationer:

• Vad man använder för teknik. Det spelar en viktig roll men kultur och processer är viktigare föga förvånande, sedan kan verktyg hjälpa till i en kulturförflyttning

• Om man har en CAB-funktion. Det visade sig t.o.m. att många org som förlitade sig på mer flexibla processer som parprogrammering eller peer review ofta var bättre både på att leverera OCH tillgänglighet och stabilitet i drift

• Att mäta antal rader kod. Föga förvånande är det ett ruskigt dåligt mått. En lösning med 10 rader kod är - givetvis - ofta att föredra än samma lösning med 1000 rader kod (om den korta lösningen samtidigt är läsbar och inte för komprimerad). Det bästa är förstås om vi kan lösa ett problem helt utan kod eller genom att ta bort kod! Vem älskar inte att få radera kod ibland?

• Snabbaste leveranserna. Undvik att fokusera så mycket på det. Det kan leda till att team nedprioriterar samarbete med andra team för att det tar tid från kodknackning och leverans.

Undvik att belöna utvecklare för mängden mjukvara som levereras och att belöna driftteam för stabilitet. Det leder gärna till att utvecklare "kastar kod" på drift och drift sätter upp plågsamma processer för att förhindra förändring.
Vad ger det att ha en hög utvecklingskapacitet då? God förmåga att ta fram och bygga nya lösningar, anpassa sig till förändring, leverera värde till användarna, osv.

Man kom fram till att mått på utvecklingskapacitet bör fokusera på två nyckelaspekter:

• Maximal verksamhetsnytta
• Goda resultat, inte hur mycket det jobbas.

En bör inte uppmuntra att maximera mängden utfört arbete om det ändå inte hjälper organisationens mål (vad sa ni?! )
Därav är genuin förståelse för vision och mål så himla viktigt!

Något som inte är med bland dem måtten är tiden det tar att identifiera problem och att designa/ta fram potentiella lösningar. De kom fram till att det var många variabler i denna fas så att det var svårt att följa metodiskt (inte att det är mindre viktigt). Det är hög osäkerhet på estimat och resultat.
Det får bli en annan tråd en annan dag...

Hur ser ni på DevOps? Anammar ni denna lära? Tycker ni mest att det är ett nytt modeord på vad ni redan gjort i 3000 år? (vilken sorts vampyr är du?!)
Låter det som namnet på en hel massa produkter som leverantörer försökt sälja in för att lösa alla era problem?
Personligen tycker jag nog att det är på tok för mycket brus kontra signal. Men känner ändå att det finns mycket bra stoff här som jag gärna ställer mig bakom och drar nytta av. Som sagt, intressant att höra era tankar!