Vendor locking har blitt en slags moralsk panikk i utviklingsmiljøer. Ikke bind dere til Azure. Ikke bruk noe for tett knyttet til Microsoft. Men hvor farlig er det egentlig?

Nylig var vi nødt til å skrive om innloggingsflyten i et av våre interne systemer. Der vi tidligere hadde brukt en slags Frankensteins monster av implicit grant flow og noen andre småting fra andre flyter, flyttet vi over til cookie-basert BFF pattern med authorization code flow og proof key for code exchange (PKCE).

Kodebaser blir sjelden komplekse over natten. Det skjer gradvis, gjennom små valg vi tar hver dag. Litt ekstra abstraksjon her, et interface der, en pakke som virker fornuftig i øyeblikket.

Sondre tok oss gjennom hvordan OAuth og OpenID Connect fungerer når man skal implementere Authorization Code Flow.

Jeg opplever stadig oftere at arkitekturvalg i systemutvikling styres av problemer som kanskje kan oppstå om fem eller ti år. Vi designer for ekstrem skalerbarhet, høy last og komplekse scenarioer lenge før det finnes reelle behov for det. Ofte skjer dette på bekostning av å løse de faktiske problemene vi har her og nå.

Det er ikke mange banebrytende endringer, men de få nyhetene som faktisk kommer har likevel potensial til å forbedre måten vi skriver, organiserer og tester kode på.

Denne artikkelen av Adrian Brenne viser steg-for-steg hvordan du bruker både system- og bruker-tilordnet Managed Identity for å sikre tilgang til tjenester som Azure Storage og Key Vault med minimal risiko og maksimal effektivitet.

Dette var personlig min aller første konferanse. For å være helt ærlig visste jeg ikke helt hva jeg kunne forvente. Er det som en bedriftspresentasjon der JetBrains er bedriften? Hvorfor drar man egentlig på konferanse?