�ݺ�ߣ

Editor's Notes

• #17: Requester Pr døgn? Loglinjer pr døgn?
• #18: slettes
• #19: Ikke målestacken med - ELK!
• #21: Forklare skissen Last-balanserer sjekker om tjenesten er tilgjengelig, integrert i deployment En mikrotjeneste kjører redundant på 2 maskiner samtidig Database og meldingsbroker som sentrale infrastrukturkomponenter Haug med fagsystemer som integreres imot Nøkkelord Flat struktur, mikrotjenester kommuniserer direkte eller ved bruk av broker med hverandre «lightweight esb». Plattformen bruker ActiveMQ som broker
• #22: «Martin Fowler : You must be this tall to use microservices» Attraksjon på et tivoli Som beskriver modenhet på organisasjonen din på Rapid provisioning Basic Monitoring Rapid application deployment og en del ting til
• #23: Vi har en sterk devops kultur og bruker denne stacken (les opp teknologien og klikk etterpå) - Applikasjoner er skrevet i språk som kjører på jvm-en: java, skala og jruby Bruk også: Rapid provisioning Basic Monitoring Rapid application deployment og en del ting til
• #24: Til sammen har vi 68 virtuelle servere delt i 4 testmiljøer prod ut av dem kjører 20 produsjonsrelevante tjenester 18 virtuelle netter 3 virtuelle BigIP servere med tilsvarende adresser (tjenester[-test|-systest).oslo.kommune.no Intern sky med automatisert konfigurasjon Eneste manuell steg er å registrere en ny maskin på puppetmasteren Flere leverandør: en for levering av servere og en for nettverket, evry og datametrix - Vi må bestille tjeneste fra dem, godkjent fra UKE
• #25: Forklare implikasjoner av mikrotjenester En tjeneste / service / feature som kunden kan konsumere er del opp i flere mikrotjenester som må orkestreres En endring berører derfor også flere mikrotjenester Forklare konseptet featureteam - Fører til delte komponenter uten definert ansvar, men teamet har ansvar for funksjonen (folk koordinerer seg selvstendig) Vi er omtrent 60 utviklere delt i 2 team (pet og itas) avhengig av kunden. Internt har vi en del subteam - Scrum-ish prosess
• #27: Sitater fra teammedlemmer Kontekstswitching Support Saker på vent Flere oppgaver samtidig Man ser bare featuren men ikke den langsiktige utviklingen på komponenten Mangler eierskap til helheten
• #28: Last er ikke et problem Kompleksitet er i det tilfellet svaret til spørsmålet: «Hvilke tjenester berører endringen på X» Intern Ekstern Hvordan finner man det ut og hvordan kan man modellere det? I tillegg øker antall komponenter og integrasjoner stadig Database er en monolittisk tjeneste som hele plattform er avhengig av, det samme gjelder for brokeren Endringer kan ikke rulles ut uten å berøre de fleste av våre tjenester Greit med databasen med fallback og egen driftsorganisasjon Ikke greit med brokeren som er avhengig av en gitt kombinasjon av eksterne biblioteker (for de som som er techsavy: spring og camel) One size fits em all Forskjellige domener har ulike krav på responsetid, tenk batchjobber mot backend til en webapplikasjon Rammeverk introduserer avhengigheter som man ikke veldig lett kvittere seg med: Kjenne ingen som har flere versjoner av spring på classpathen Transaksjoner: ~80% av meldinger på bussen kan gjenskapes de restlige 20%ene må handtere transaksjoner riktig Kritikalitet betyr i vår sammenheng handtering av personsensitive data, skal dem gå gjennom den samme bussen, kryptert, ukryptert?
• #29: jhg tar over
• #33: Illustrasjon skal viser at domener er «selv-contained», dem er bygget på prinsipper av plattformen, men kan stå fritt (med unntak av apier til andre domener). Domener muliggjør en del interessante løsinger Interaksjon med systemer / komponenter som handterer data som er mer kritisk en våre Outsourcing teknisk (offentlig sky for data som er ikke kritisk) domener kan konkurranseutsettes, gir mindre aktører tilgang til plattformen Trenger bare å forholde seg til offenlige api-er av resten Størelsen av et domene: - Ingen svar, domene er en naturlig gruppering Vi ønsker oss at et team tar ansvar for et helt domene.
• #34: mkr tar over igjen (les opp teknologien og klikk etterpå) Når har blitt en PaaS-leverandør: Platform as a service (PaaS) is a category of cloud computing services that provides a platform allowing customers to develop, run, and manage web applications without the complexity of building and maintaining the infrastructure typically associated with developing and launching an app. Bruke litt tid for forklaring av: Meldingsløsning Support Service gateway Overvåkning Grensesnitt
• #35: Forklare implikasjoner endringer En tjeneste / service / feature som kunden kan konsumere må satt sammen av grensesnitter av andre domener eller funksjonalitet av domenet En endring berører derfor enden api-et til et annet domenet (må avklare med teamet) eller bare tjenester innenfor dette domenet Domeneteamet «eier» domenet og kan vedlikeholde den i henhold til langsiktige planer (lagt sammen med organisasjonen)
• #37: Vår antakelse: I henhold til Conways law, kommer domener til å gjenspeile organisasjonen i Oslo kommune, teammedlemmer kommer til å være domeneeksperter i enda større grad enn de er i dag, siden dem kan fokusere bedre på et mindre område. Kommunikasjonmønster mellom domener kommer til å gjenspeiler kommunikasjon mellom avdeler / virksomheter
• #38: Som en Paas leverandør er plattformen et domene i seg selv som må ta hensyn til sine kunder. For at domene-team kan fokusere på demmes applikasjoner leverer infrastrukturteamet «best practise» eller referanseimplementeringer
• #40: Domener har mulighet til å tilpasse referanseimplementeringer Hvordan da? Internall OSS modell
• #42: Disse teknologiene har vi som referanseimplementering og tilgjengelig for domener