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.
HVA GJØR DU NÅR FORRETNINGSVERDIEN ER STABILITET? – INNFØRING AV MIKROTJENEST...Arne Berner
Presentasjon på Software 2017 - Arkitektur i praksis.
La oss slutte å snakke om stabilitet men heller fokus på endringsrobusthet
En prat om delfiner og hvaler
Geodata har vært på AWS siden den spede begynnelse i 2008. Presentasjonen omhandler våre erfaringer og hvordan vi har benyttet AWS for å effektivisere vår utvikling av tjenester og løsninger.
HVA GJØR DU NÅR FORRETNINGSVERDIEN ER STABILITET? – INNFØRING AV MIKROTJENEST...Arne Berner
Presentasjon på Software 2017 - Arkitektur i praksis.
La oss slutte å snakke om stabilitet men heller fokus på endringsrobusthet
En prat om delfiner og hvaler
Geodata har vært på AWS siden den spede begynnelse i 2008. Presentasjonen omhandler våre erfaringer og hvordan vi har benyttet AWS for å effektivisere vår utvikling av tjenester og løsninger.
Maskinvare blir til ressurser, programvare blir til tjenester – vil kjøp av it-tjenester via ”nettskyen” i fremtiden bli like enkelt som å kjøpe strøm fra strømleverandøren? Hva får du nå, når egner alternativene seg best og hva gjør ErgoGroup på området? Direktør for strategi og forretningsutvikling i ErgoGroup, Jakob van der Hagen, kommer med konkrete eksempler på leveranser og erfaringer.
Intelecom deler erfaringer og viser eksempler på hvordan nye og
spennende løsninger kan lages i praksis. Det blir vist løsninger
og integrasjoner innen flere av våre løsningsområder.
Dell Solutions Tour 2015 - Neste generasjons Windows Server og System Center,...Kenneth de Brucq
Moderne driftsplattformer baseres på neste generasjons Windows Server og System Center, og på Dell Solutions Tour deler han de mest spennende nyhetene og nyttigste funksjonene.
Hva Og Hvorfor Arkitektur - 11. mai 2010, TrondheimEspen Johanson
Arkitektur – hvorfor, hva og hvordan?
Sjefsarkitekt Tore Stokkedal fra IBM presenterer nytteverdien av å ha et sterkt fokus på IT-arkitektur.
Han belyser hva industrien mener IT-arkitektur er, og hvordan arkitektrollen skal fungere med eksempler fra praktisk erfaring gjennom 10 år som sjefsarkitekt i ulike typer prosjekter.
Om foredragsholderen:
Tore Stokkedal er sertifisert IT-arkitekt gjennom Open Group og har bred erfaring som IT-arkitekt fra større infrastruktur- og applikasjonsutviklingsprosjekter. Han er for tiden sjefsarkitekt for IBMs outsourcingsvirksomhet i Norge. Tore er opptatt av hvordan arkitekturarbeid legger verdi til prosjekter og virksomheter, samt hvordan rollen IT-arkitekt skal utføres.
MIDA en løsning for forvaltning av oljetanker - Esri norsk BK 2014Geodata AS
Vann- og avløpsetaten (VAV) er tilsynsmyndighet for oljetanker i Oslo, og har i mange år forvaltet en oversikt over oljetankene som finnes i Oslo. Autoriserte firma utfører tilsyn med oljetankene, og status rapporteres til VAV, og mange dokumenter sendes mellom VAV, tankeier og rapporterende firma hvert år. Programvaren som har blitt brukt til denne forvaltningen har ikke blitt oppdatert regelmessig og dette har medført en arbeidshverdag med mye manuell punching av data, og ekstra arbeid. For snart to år siden bestemte vi at programvaren skulle byttes ut med et nytt og mer moderne verktøy.
Nøkkelfunksjonalitet
-Automatisk mottak av eksterne rapporter
-Analyse og rapportering med Geocortex Essentials
-Utfylling av brev
-Integrasjon med sakssystem
Beskrivelse
En første demoversjon ble utviklet av oss i GIS-utviklingsfunksjonen i VAV, og denne baserte seg på Silverlight API-et til ArcGIS Server. Etter hvert som utviklingen gikk videre, ble Geodata kontaktet og vi fikk utviklet en demoversjon til brukerkonferansen 2012. Etter denne demoen innså vi at for å få utnyttet teknologien og eksisterende programvare bedre, så var Geocortex Essentials det mest egnede verktøyet. Gjennom et samarbeid har vi og Geodata laget en tilpasset Geocortex Silverlight Viewer for denne applikasjonen. For å få en fungerende applikasjon, har det i tillegg til kartmodulen i Geocortex blitt utviklet en webservice integrasjon med arkivsystemet 360 fra Software Innovation, og en integrasjon med webskjema som er laget av KnowIT.
Hvilke erfaringer har vi gjort oss gjennom denne prosessen (spesielt med Geocortex) og hva ser vi for oss som veien videre? Hvilke utfordringer har dukket opp? Foredraget kommer også til å inneholde en rask gjennomgang av applikasjonen.
More Related Content
Similar to Skalering av store enterprise-systmer med API-first
Maskinvare blir til ressurser, programvare blir til tjenester – vil kjøp av it-tjenester via ”nettskyen” i fremtiden bli like enkelt som å kjøpe strøm fra strømleverandøren? Hva får du nå, når egner alternativene seg best og hva gjør ErgoGroup på området? Direktør for strategi og forretningsutvikling i ErgoGroup, Jakob van der Hagen, kommer med konkrete eksempler på leveranser og erfaringer.
Intelecom deler erfaringer og viser eksempler på hvordan nye og
spennende løsninger kan lages i praksis. Det blir vist løsninger
og integrasjoner innen flere av våre løsningsområder.
Dell Solutions Tour 2015 - Neste generasjons Windows Server og System Center,...Kenneth de Brucq
Moderne driftsplattformer baseres på neste generasjons Windows Server og System Center, og på Dell Solutions Tour deler han de mest spennende nyhetene og nyttigste funksjonene.
Hva Og Hvorfor Arkitektur - 11. mai 2010, TrondheimEspen Johanson
Arkitektur – hvorfor, hva og hvordan?
Sjefsarkitekt Tore Stokkedal fra IBM presenterer nytteverdien av å ha et sterkt fokus på IT-arkitektur.
Han belyser hva industrien mener IT-arkitektur er, og hvordan arkitektrollen skal fungere med eksempler fra praktisk erfaring gjennom 10 år som sjefsarkitekt i ulike typer prosjekter.
Om foredragsholderen:
Tore Stokkedal er sertifisert IT-arkitekt gjennom Open Group og har bred erfaring som IT-arkitekt fra større infrastruktur- og applikasjonsutviklingsprosjekter. Han er for tiden sjefsarkitekt for IBMs outsourcingsvirksomhet i Norge. Tore er opptatt av hvordan arkitekturarbeid legger verdi til prosjekter og virksomheter, samt hvordan rollen IT-arkitekt skal utføres.
MIDA en løsning for forvaltning av oljetanker - Esri norsk BK 2014Geodata AS
Vann- og avløpsetaten (VAV) er tilsynsmyndighet for oljetanker i Oslo, og har i mange år forvaltet en oversikt over oljetankene som finnes i Oslo. Autoriserte firma utfører tilsyn med oljetankene, og status rapporteres til VAV, og mange dokumenter sendes mellom VAV, tankeier og rapporterende firma hvert år. Programvaren som har blitt brukt til denne forvaltningen har ikke blitt oppdatert regelmessig og dette har medført en arbeidshverdag med mye manuell punching av data, og ekstra arbeid. For snart to år siden bestemte vi at programvaren skulle byttes ut med et nytt og mer moderne verktøy.
Nøkkelfunksjonalitet
-Automatisk mottak av eksterne rapporter
-Analyse og rapportering med Geocortex Essentials
-Utfylling av brev
-Integrasjon med sakssystem
Beskrivelse
En første demoversjon ble utviklet av oss i GIS-utviklingsfunksjonen i VAV, og denne baserte seg på Silverlight API-et til ArcGIS Server. Etter hvert som utviklingen gikk videre, ble Geodata kontaktet og vi fikk utviklet en demoversjon til brukerkonferansen 2012. Etter denne demoen innså vi at for å få utnyttet teknologien og eksisterende programvare bedre, så var Geocortex Essentials det mest egnede verktøyet. Gjennom et samarbeid har vi og Geodata laget en tilpasset Geocortex Silverlight Viewer for denne applikasjonen. For å få en fungerende applikasjon, har det i tillegg til kartmodulen i Geocortex blitt utviklet en webservice integrasjon med arkivsystemet 360 fra Software Innovation, og en integrasjon med webskjema som er laget av KnowIT.
Hvilke erfaringer har vi gjort oss gjennom denne prosessen (spesielt med Geocortex) og hva ser vi for oss som veien videre? Hvilke utfordringer har dukket opp? Foredraget kommer også til å inneholde en rask gjennomgang av applikasjonen.
Similar to Skalering av store enterprise-systmer med API-first (20)
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
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
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
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
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