Overgangsløsning

[erikhag1]

Users view

Title: Kunne fortsette å kjøre på eksistende versjon av løsningen i en overgangsperiode
User role(s): Kunde
Users value statement(s):
Ved å ha muligheten til å fortsette å kjøre på den eksisterende versjonen av løsningen i en overgangsperiode, sikrer vi en smidig migrering uten å forstyrre daglig drift. Dette reduserer risiko for driftsavbrudd, gir teamene tid til å tilpasse seg nye funksjoner og endringer, og sikrer at kvaliteten på våre tjenester forblir konstant mens vi beveger oss mot en oppdatert og forbedret teknologisk plattform.

Vendors view

Description

High level features (capabilities):

• Støtte eksisterende versjon av løsningen i en overgangsperiode

Additional information

TBD

User stories

Beta Give feedback

1. Implementere støtte for Overgangs-API i Altinn 2 #211
   11 of 11
   kind/feature product/formidling +2
2. Implementere overgangs-API i Altinn 3 #212
   2 of 2
   kind/feature product/formidling +2
   
3. Etablere IP-filtering mellom Altinn 2 og 3 for overgangsløsning #249
   1 of 3
   kind/user-story product/formidling +2
4. Behov for å knytte flere systemer til en bruker for å understøtte leverandørbytter og overgang. #234
   product/formidling +1
5. Opprette Formidlingstjeneste og Maskinporten klient til bruk av test av overgangsløsning #264
   kind/user-story product/formidling status/draft +3
   
6. Implementer filsøk #165
   kind/user-story +1
   
7. Brøytetesting av overgangsløsning #309
   kind/user-story product/formidling +2
   
8. Dokumentasjon av overgangsløsning #312
   kind/documentation product/formidling +2
   

Work items

Beta Give feedback

1. Analyse - beskrive endringer i Altinn 2 som følge av konsept (B2/3/4) for overgangsløsning #175
   product/formidling +1
   
2. Analyse - api som understøtter migrering #134
   2 of 2
   good-first-issue product/formidling +2
   

   
3. Minst mulig arbeid og kostnader ved overgang til nye løsninger og grensesnitt for formidlingstjenesten #76
   4 of 9
   kind/epic product/formidling role/customer status/draft +4
   
4. Implementere bruk av manifest-fil for Overgangsløsning i Formidling #550
   kind/feature-request product/formidling +2
   

Item attributes

Note: Automatically updated properties, not intended for change by you;)

Issue type: epic
Concept no: 15
Stage: Migration
ArchiConceptID: id-4639432829714218a9ce0da3cfba4850
GithubIssueID: I_kwDOIwEQMM5vYMsd

[erikhag1]

Samspill mellom Altinn2 og Altinn 3, f.eks. for å frikople migreringsløpet for mottaker vs. avsender

[RagnarFatland-Avanade]

@CWO79 @erikhag1 som avtalt legger jeg inn kommentar her rundt de alternativene vi diskuterte.

Edit; Etter @CWO79 sin kommentar la jeg til nytt pkt A, resten rykket da ned.

En generell utfordring er å få alle eksisterende brukere av formidlingstjenesten over på ny plattform innen eksisterende Altinn 2 plattform skal skrus av.
B og C løser ikke dette problemet direkte men gjør det mulig med mer fleksibel migrering, Alternativ D er massivt merarbeid men kan i teorien gjøre tjenesten tilgjengelig etter Altinn 2 er skrudd av.

Listet i anbefalt rekkefølge;

Alternativ "A" Begge løsninger i parallell, isolert fra hverandre.

• Begge løsninger kjører i parallell, uten noen kontakt med hverandre.
• Man migrerer enkelt-formidlingstjenester til ny løsning kontrollert etter avtale
• Krever god koordinering mellom Tjenesteeiere og alle sendere/mottakere på de aktuelle tjenestene
• Enkelte parter kan fungere som "brems" for resten av brukerne av en gitt tjeneste, og dermed føre til at produksjons-setting går tregt og man ikke når realistisk bruk/last før sent i perioden.
• Setter et press på at alle brukere må over på A3 løsningen innen A2-Shutdown.

Alternativ "B" Begge løsninger i parallell med Bro/Synkronisering på tvers

• Man bygger den nye løsningen i separat infrastruktur, men med nok fellestrekk i prosessen til at man kan kjøre en forsendelse via enten A2 eller A3.
• Batch-Sync-jobb som kjører på Altinn 2-plattformen som synkroniserer forsendelser mellom A2 og A3.
• Eget API-endepunkt hostet i A3 som Kun Sync-jobb benytter; IP-Filtrert, dedikert båndbredde.
• Det må være en mapping mellom A2-formidlingstjenester og A3-formidlingstjenester der synk skal være mulig.
• Ingen nye brukere tillates på A2-formidlingstjenester.
• Når en forsendelse opprettes eller endres i en av løsningene, synkroniseres endringen på tvers.¨
• Data lagres begge steder, noe som medfører duplisering.
• Noe tidsforsinkelse før hendelser reflekteres på annen plattform.
• Man kan bruke regelsett slik at man kun kjører synkronisering for enkelte formidlingstjenester/avsendere/mottakere for å redusere unødvendig dobbelt-lagring.
• Dette vil gjøre det mulig for en miks av brukere på både gammel og ny versjon av tjenesten, noe som kan gjøre det lettere å planlegge migrering siden man ikke må ta "hard switch" som i Alternativ A.
• Setter fremdeles et press på at alle brukere må over på A3 løsningen innen A2-Shutdown, men det blir mulig å gjøre dette mer gradvis siden man kommuniserer på tvers.

Alternativ C: "Fasade"-løsning.

• Krever som Alt B at ny prosess i stor grad kan kjøres som gammel.
• Altinn 2 API'ene reduseres til fasader/skall som kun kaller videre til Altinn 3 API.
• Autentisering/Autorisasjon kan være utfordring; man må nok fremdeles benytte A2 sin stack videre, spesielt for de systembrukere og autentiseringsmetodene som ikke støttes i A3.
• Setter fremdeles et press på at alle brukere må over på A3 løsningen innen A2-Shutdown, men det blir mulig å gjøre dette mer gradvis siden man kommuniserer på tvers.

Alternativ D: "Emulert Altinn 2"-løsning.

• Bare aktuell dersom man må støtte A2-APIene etter at A2 er tatt ut av drift:
• Det bygges et API som benytter A2-kontraktene, men som er bygd på toppen av A3-stacken og hostes i cloud.
• Vil kreve en del merarbeid for dra ut nødvendige A2 autensiering/autorisasjons-komponenter og hoste disse sammen i cloud, mest sannsynligvis med kraftig redusert funksjonalitet slik at det kun løser nødvendige behov for Formidlingstjenesten.
• Kan kombineres med B/C,

[CWO79]

Hei Jeg savner et alternativ som handler om at vi kjører Altinn 2 og Altinn 3 i parallell, uten å lage overgangs api (altså noen av de alternativene du ha skissert opp) Så kan vi heller bruke ressurser mer hensiktsmessig på å hjelpe tjenesteeier over på nytt API. Enig? Fra: Ragnar Fatland ***@***.***> Sendt: torsdag 21. september 2023 19:31 Til: Altinn/altinn-broker ***@***.***> Kopi: Wold, Camilla Marie Røsholm ***@***.***>; Mention ***@***.***> Emne: Re: [Altinn/altinn-broker] Kunne fortsette å kjøre på eksisterende versjon av løsningen i en overgangsperiode (Issue #74) [ Ekstern e-post ] @CWO79<https://github.com/CWO79> @erikhag1<https://github.com/erikhag1> som avtalt legger jeg inn kommentar her rundt de alternativene vi diskuterte. Uansett tilnærming er det fare for at det fører til at implementering av ny versjon blir nedprioritert. Her ser jeg få tilnærminger som ikke gir for mye overhead. Listet i anbefalt rekkefølge; Alternativ "A" Bro/Synkronisering * Man bygger den nye løsningen i separat infrastruktur, men med nok fellestrekk i prosessen til at man kan kjøre en forsendelse via enten A2 eller A3. * Batch-Sync-jobb som kjører på Altinn 2-plattformen som synkroniserer forsendelser mellom A2 og A3. * Eget API-endepunkt hostet i A3 som Kun Sync-jobb benytter; IP-Filtrert, dedikert båndbredde. * Det må være en mapping mellom A2-formidlingstjenester og A3-formidlingstjenester der synk skal være mulig. * Ingen nye brukere tillates på A2-formidlingstjenester. * Når en forsendelse opprettes eller endres i en av løsningene, synkroniseres endringen på tvers.¨ * Data lagres begge steder. Ulemper er duplisering av data, og noe tidsforsinkelse før hendelser reflekteres på annen plattform. Man kan bruke regelsett slik at man kun tillater dette for enkelte formidlingstjenester/avsendere/mottakere for å redusere unødvendig dobbelt-lagring. Dette vil gjøre det mulig for en miks av brukere på både gammel og ny versjon av tjenesten, noe som kan gjøre det lettere å planlegge migrering siden man ikke må ta "hard switch". B: "Fasade"-løsning. * Krever som Alt A at ny prosess i stor grad kan kjøres som gammel. * Altinn 2 API'ene reduseres til fasader/skall som kun kaller videre til Altinn 3 API. * Autentisering/Autorisasjon kan være utfordring; man må nok fremdeles benytte A2 sin stack videre, spesielt for de systembrukere og autentiseringsmetodene som ikke støttes i A3. C: "Emulert"-løsning. Bare aktuell dersom man må støtte A2-APIene etter at A2 er tatt ut av drift: * Det bygges et API som benytter A2-kontraktene, men som er bygd på toppen av A3-stacken og hostes i cloud. * Vil kreve en del merarbeid for dra ut nødvendige A2 autensiering/autorisasjons-komponenter og hoste disse sammen i cloud - Reply to this email directly, view it on GitHub<#74 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/A5N7QGKMFGGAYEEW2A6HQLDX3R2TTANCNFSM6AAAAAA4AQTWEY>. You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>

[leogasnier]

Hva med A3 api som kjører mot A2 backend frem til trafikk er flyttet og så foreta svitsj på backend tjeneste for tjeneste @RagnarFatland-Avanade ? Så litt som alt. A uten at en tjeneste må kjøre på 2 backends samtidig? Ser for meg at vi da kan skaffe oss noe frihet mtp. hvordan vi bygger A3 løsning, samtidig som det kan fungere for A2 i en overgangsperiode. (løses med felter i kallet).

Vil gjerne at dere utdyper og tegner ut litt pr alternativ med fordeler og ulemper og reflekterer litt på workload for oss, brukerne.
Test dem på Mikkelsen og andre teamarkitekter som har kommet lengre enn oss. Presenter så på åpent møte 11 okt. og juster ift. innspill så beslutter vi når jeg er tilbake fra ferie :)

[leogasnier]

Tittel på denne epic-en er kanskje også litt misvisende. Tror beskrivelsene av alternativene bør inn her: #134

[RagnarFatland-Avanade]

@leogasnier jeg kan sette opp det alternativet du nevner, men gitt at tidslinjen vår i stor grad er styrt av at RRR i A3 må bli klart, så vil vi mest sannsynlig bli ferdige med mesteparten av A3-stacken før vi kan begynne å kjøre reell trafikk gjennom de APIene, så da tjener vi ikke så mye på å bruke A2 backend.

Motsatt retning av at A2 benytter A3 backen har jeg skissert som alternativ, men det er selvfølgelig nyanser i hvordan disse alternativene kan implementeres.

På generelt basis tror jeg det er best å unngå å endre for mye på A2-løsningen, man har gjort mye der gjennom årene for å tweake Formidlingstjenesten, så derfor tenkte jeg at vi beholdt separasjon så mye som mulig.

Men jeg tar ny runde og strukturerer om og tester ut mot andre folk før jeg legger det inn i #134.

[CWO79]

Det er #74 som er epic og #134 som er god-first-issue Fra: leogasnier ***@***.***> Sendt: fredag 22. september 2023 14:28 Til: Altinn/altinn-broker ***@***.***> Kopi: Wold, Camilla Marie Røsholm ***@***.***>; Mention ***@***.***> Emne: Re: [Altinn/altinn-broker] Kunne fortsette å kjøre på eksisterende versjon av løsningen i en overgangsperiode (Issue #74) [ Ekstern e-post ] Tittel på denne epic-en er kanskje også litt misvisende. Tror beskrivelsene av alternativene bør inn her: #134<#134> - Reply to this email directly, view it on GitHub<#74 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/A5N7QGJUSUGHSOLGHHLEUEDX3V73JANCNFSM6AAAAAA4AQTWEY>. You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>