Skalering av store enterprise-systmer med API-first
•Download as PPTX, PDF•
0 likes•1,026 views
Oslo kommune har over mange år bygget opp et stort felles applikasjonshotell og integrasjonsplattform ved hjelp av mikrotjenester. De kjører nærmere 200 mikrotjenester og er i stadig vekst på grunn av stor politisk satsning på digitale tjenester. Utviklerne jobber etter DevOps-prinsipper på grunn av alle de mange parallelle leveransene til alle kommunens 40 virksomheter. For å skalere plattformen med tanke på antall utviklere, utvidet last, økt mengde parallell aktivitet samt økte krav til time-to-market endrer kommunen nå både overordnet arkitekturmålbilde og strategi for utvikling av nye tjenester. Foredraget vil gi innblikk i veien frem til dagens situasjon, nåbildet og fremtidig målarkitektur. Foredraget er primært for CTO/CIO, arkitekter og tekniske prosjektledere. Speakers: Speakers Jan Henrik Gundelsby CTO, Knowit Objectnet Jan Henrik er CTO i Knowit Objectnet. Han har 20 års erfaring med teknologi på JVMen. Har de siste årene syslet mye med applikasjonsdrift, mikrotjenester og DevOps sentralt i Oslo kommune. En ivrig lettvekts-fantast som forsøker å jobbe mot smidige arkitekturer og løsninger. Markus Krallinger Systemutvikler- og arkitekt, Knowit Objectnet Markus er systemutvikler- og arkitekt i Knowit Objectnet. De tre siste årene har han jobbet med applikasjonsdrift - og JVM-utvikling på Oslo kommunes mikrotjenesteplattform. Akkurat nå er han sentral i planleggingen av Oslos fremtidige integrasjon- og applikasjonsplattform som arkitekt.
Recommended
Recommended
More Related Content
Similar to Skalering av store enterprise-systmer med API-first
Similar to Skalering av store enterprise-systmer med API-first (20)
Skalering av store enterprise-systmer med API-first
- 1. Skalering av store enterprise-systemer med API-first Oslo City OS
- 4. City OS Sentral meldingsplatform for Oslo kommune
- 6. City OS
- 8. 2014 2010 2012 2008Ingen prosess Prosess og organisasjon ITIL og DevOps Bimodal Autonome team 2016 2003 … Flat struktur Antall utviklere - 60 Antall komponenter - 190
- 10. 2014 2010 Fowler James Lewis et.al. 2012 2008 Johannes Brodwall (BBS) Arkitektur- overgang Mikrotjenester
- 12. Arkitektur Teknisk plattform Prosess og organisasjon Status på plattformen
- 17. Organisasjon i feature-team Prosess og organisasjon
- 18. Skaleringshindringer • For stor kodebase, for små team • «Jeg forstår ikke denne tjenesten» • «Hva endrer seg når jeg endrer X» • «La oss heller legge til Y» • Ansvarlighet på de delte komponentene Prosess og organisasjon
- 19. Tekniske utfordringer • Kompleksitet • Database • Monolittisk broker • «One size fits em all» • Hastighet • Rammeverker • Transaksjoner • Kritikalitet av data Teknisk plattform Arkitektur
- 20. Arkitektur Teknisk plattform Prosess og organisasjon APIer som skaleringsverktøy
- 22. API management • Dokumentert • Tilgangstyrt (nettverk og bruker) • Begrenset til en kvote • Overvåket og tilbyr laging av rapporter Teknisk plattform
- 23. Domener i API-first • Naturlige gruppering av mikrotjenester • Forretning, trafikk, krav til hastighet … • Ikke for stor, tanken er å ha et domene per team Prosess og organisasjon
- 24. Arkitektur- overgang Fra mikrotjenester til API-first Team I (intern) Team II (intern) Team X (ekstern)
- 26. Målbildet: Organisasjon i domeneteam Prosess og organisasjon
- 27. Infrastruktur et også et domene Prosess og organisasjon
- 29. Internal open source modell Prosess og organisasjon 1 2 Team I trenger feature1 Hvis team II ikke kan levere det tidsnok, så kan team I lage endringen 2 Endringer er merget upstream?
- 30. Viktige egenskaper ✤ “If you build it you run it” ✤ “Standardization without central control” ➡ Mer byråkrati ➡ Krav på API-design øker
- 31. Eksempel på et APITeknisk plattform
- 32. Gevinster • Domener er lettere å forstå enn hele plattformen • Muliggjør outsourcing av domener • Kommunikasjon mellom domener er standardisert • Tilrettelegge til en heterogen plattform • Broker og database mindre monolittisk Arkitektur Prosess og organisasjon Teknisk plattform
- 34. Utgangspunkt (2003-2009) AS-IS (2009-2016) TO-BE (2017+) Monolitt Mikrotjenester API-first (ITIL) DevOps Autonome team Lisensiert og lukket Open Source Desentralisert Arkitektur Teknisk plattform Prosess og organisa sjon
Editor's Notes
- Requester Pr døgn? Loglinjer pr døgn?
- slettes
- Ikke målestacken med - ELK!
- 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
- «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
- 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
- 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
- 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
- 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
- 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?
- jhg tar over
- 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.
- 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
- 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)
- 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
- 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
- Domener har mulighet til å tilpasse referanseimplementeringer Hvordan da? Internall OSS modell
- Disse teknologiene har vi som referanseimplementering og tilgjengelig for domener