This epic is used to collect all issues related storage Altinn 1 and Altinn 2
Vurdere om arkitekturen for lagring av app-data (BLOB + microtjeneste) er optimal, og et mønster vi kan følge for nye produkter med lagring for melding, Altinn II arkiv og Altinn 1 arkiv. Om vi kjenner til svakheter på nåværende arkitektur for lagring av instanser i A3 så bør vi fikse det.
Dialogporten - alle "tjenesteprodukter" skal ha åpne APIer og integreres mot Dialogporten. Dette gjelder også dagens løsning. APIene bør "standardiseres".
Betaling og skalering - melding, altinn ii, altinn 1, etc skal skilles per TE, med egen BLOB pr TE. Som for Storage i dag. Dette gjør også ting skalerbart og isolert.
Det som lages MÅ kunne kjøre i sky og on-prem og lokalt, da det er sannsynlig av både melding, Altinn II arkiv og Altinn 1 arkiv vil kjøre både i Altinn og hos TE som ikke ønsker å gå i sky (dette er et generelt prinsipp i A3, men her er sannsynligheten veldig stor for at denne egenskapen vil tas i bruk)
Vi må avklare eierskapsforhold mellom utvikling av nye mikrotjenester/produkter som håndterer disse dataene og hva som Core skal gjøre.
Vi bør søke å få til en gradvis migrering av data
Punkt 2, "Dette gjelder også dagens løsning", er også viktig relatert til det å fjerne Cosmos, som jeg oppfatter at dere har på tapeten. Dialogporten vil i praksis erstatte en god del av det vi i dag benytter Cosmos til, så viktig at dette er planlagt og i synk.
Viktig at man ikke bare erstatter Cosmos med PostgreSQL, altså en rent teknisk greie, men at man også har det i mente at Dialogporten kommer inn og vil være APIene som SBS benytter for metadata
This epic is used to collect all issues related storage Altinn 1 and Altinn 2
Vurdere om arkitekturen for lagring av app-data (BLOB + microtjeneste) er optimal, og et mønster vi kan følge for nye produkter med lagring for melding, Altinn II arkiv og Altinn 1 arkiv. Om vi kjenner til svakheter på nåværende arkitektur for lagring av instanser i A3 så bør vi fikse det.
Dialogporten - alle "tjenesteprodukter" skal ha åpne APIer og integreres mot Dialogporten. Dette gjelder også dagens løsning. APIene bør "standardiseres".
Betaling og skalering - melding, altinn ii, altinn 1, etc skal skilles per TE, med egen BLOB pr TE. Som for Storage i dag. Dette gjør også ting skalerbart og isolert.
Det som lages MÅ kunne kjøre i sky og on-prem og lokalt, da det er sannsynlig av både melding, Altinn II arkiv og Altinn 1 arkiv vil kjøre både i Altinn og hos TE som ikke ønsker å gå i sky (dette er et generelt prinsipp i A3, men her er sannsynligheten veldig stor for at denne egenskapen vil tas i bruk)
Vi må avklare eierskapsforhold mellom utvikling av nye mikrotjenester/produkter som håndterer disse dataene og hva som Core skal gjøre.
Vi bør søke å få til en gradvis migrering av data
Punkt 2, "Dette gjelder også dagens løsning", er også viktig relatert til det å fjerne Cosmos, som jeg oppfatter at dere har på tapeten. Dialogporten vil i praksis erstatte en god del av det vi i dag benytter Cosmos til, så viktig at dette er planlagt og i synk.
Viktig at man ikke bare erstatter Cosmos med PostgreSQL, altså en rent teknisk greie, men at man også har det i mente at Dialogporten kommer inn og vil være APIene som SBS benytter for metadata
Starter opp videre arbeid med en workshop.