1. Erik Drolshammer Stig Lau Erik Erik Drolshammer
Sivilingeniør i Datateknikk
Jobbet med utvikling og arkitektur siden 2004.
Har jobbet på flere systemer med lignende problemstillinger som dette systemet tidligere.
Dvs. distribuerte systemer som integrerer med hardware-dingser.

2. Arkitekturerfaringer
Whydah
Arkitekturerfaringer
Steel blue whydah vidua

3. Agenda Hva er IAM, Whydah Arkitekturgjennomgang Whydah intro
«Micro service»-arkitektur
Inner
Integration
Outer

4. Forklare IAM
Autentisering – hvem er du
Autorisasjon – hva har du lov til å gjøre

5. Features User authentication & authorization Single Sign-On
Application authentication & authorization
Admin GUI
Admin API
High Availability & High Scalability
Features
Features

6. Hvor mange har laget en brukerdatabase eller innloggingsløsning?
Flere ganger?
Lei av å bygge brukerdatabaser
Enklere enn å de store, komplekse og kommersielle produktene.
Enklere enn å bygge selv.
Sikrere enn å bygge selv
Open Source
Lite nok til at man kan sette seg inn i og evaluere sikkerhetsløsningene.
CC BY-NC-SA 2.0,
CC BY-NC-SA 2.0

7. “Clear and consistent responsibility power all great architectures”

8. Single Sign-On made easy
Session control
The vault of users and applications
Ansvar per modul
Administration GUI
Administration APIs

9. Guts on the Outside
Inner architecture ” the implementation architecture of the microservices themselves” Outer architecture ”the platform capabilities you need to help all those simple little microservices (and their DevOps teams) work together to make good on the promises of flexible and scalable development and deployment.”
Gary Olliffe,

10. Characteristics of a Microservice Architecture
Componentization via Services
(Team) Organized around Business Capabilities
Products not Projects
Smart endpoints and dumb pipes
Decentralized Governance
Decentralized Data Management
Infrastructure Automation
Design for failure
Evolutionary Design
James Lewis
Martin Fowler

11. Characteristics of a Microservice Architecture
Componentization via Services
(Team) Organized around Business Capabilities
Products not Projects
Smart endpoints and dumb pipes
Decentralized Governance
Decentralized Data Management
Infrastructure Automation
Design for failure
Evolutionary Design

12. 1. Modulariserer med tjenester og ikke med biblioteker.
© 2005, 2006, 2007 by Bjørn Erik Pedersen
1. Modulariserer med tjenester og ikke med biblioteker.
libraries: components that are linked into a program and called using in-memory function calls
services: out-of-process components who communicate with a mechanism such as a web service request, or remote procedure call.
2. Utviklerne jobber med en eller flere tjenester.
Ikke med UI, database, osv.
OSS, snakker om produkter, ikke prosjekter.
© 2005, 2006, 2007 by Bjørn Erik Pedersen

13. Characteristics of a Microservice Architecture
Componentization via Services
(Team) Organized around Business Capabilities
Products not Projects
Smart endpoints and dumb pipes
Decentralized Governance
Decentralized Data Management
Infrastructure Automation
Design for failure
Evolutionary Design

14. Smart pipes ESB er et eksempel på smart pipes.
Har du en ESB, og bruker funksjonaliteten der, så er det nok ikke en micro service-arkitektur.

15. Robustness principle, aka. Postel’s law:
"Be conservative in what you send, be liberal in what you accept"
En tjeneste kan ha ett eller flere endepunkter.
Smarte endepunkter: bygger inn logikk inn i hver enkelt tjeneste i stedet for å samle logikken i en stor klump i midten et sted.

16. X Evolving Service Endpoint Consumer-Driven Contracts
Unngå XSD schemas og annen overdreven typing.
Løse kontrakter, String, String
Bruk XPATH, JsonPath for å hente ut det man er interessert i
ignorer alt annet.
REST, spesielt hypermedia-delen gir løs kobling mellom tjeneste og klienter. Godt eksempel på smart-endepunkt. Tjenesten har mye ansvar.
Consumer-Driven Contracts
Hypermedia as the Engine of Application State (HATEOAS)

17. Characteristics of a Microservice Architecture
Componentization via Services
(Team) Organized around Business Capabilities
Products not Projects
Smart endpoints and dumb pipes
Decentralized Governance
Decentralized Data Management
Infrastructure Automation
Design for failure
Evolutionary Design

18. Spring MVC
Spring IoC
Jetty
Jersey
Guice
Grizzly
Javascript
Python
Java
Jersey
Guice
Grizzly
Jersey
Spring IoC
Jetty
Angular
Spring MVC
Spring IoC
Jetty

19. Characteristics of a Microservice Architecture
Componentization via Services
(Team) Organized around Business Capabilities
Products not Projects
Smart endpoints and dumb pipes
Decentralized Governance
Decentralized Data Management
Infrastructure Automation
Design for failure
Evolutionary Design

20. Polyglot persistence
Hver tjeneste kan velge teknologi for persistering selv.
Kun UIB har persistens.
LDAP, SQL, Lucene
SecurityTokenService bruker Hazelcast for å dele tilstand mellom instanser i HA-oppsett.

21. Characteristics of a Microservice Architecture
Componentization via Services
(Team) Organized around Business Capabilities
Products not Projects
Smart endpoints and dumb pipes
Decentralized Governance
Decentralized Data Management
Infrastructure Automation
Design for failure
Evolutionary Design

22. ... skal Stig snakke mer om etterpå
Enterprise Maven Infrastructure
Provisjonering: Ansible + Amazon EC2
Automated deployment (wget, upstart, java –jar)
Automatic (automated + cron)

23. Enterprise Maven Infrastructure
Source code repository
EMI
Maven release for å få kontroll og sporbarhet på det som ble prodsatt.
Ebraminio
Continuous integration
Artifact repository

24. Provisjonering
Elastic Compute Cloud (EC2)

25. Automated deployment Bash script, pull based

26. Automatic deployment Job scheduler aka. Continuous delivery
Job scheduler
aka. Continuous delivery

27. Characteristics of a Microservice Architecture
Componentization via Services
(Team) Organized around Business Capabilities
Products not Projects
Smart endpoints and dumb pipes
Decentralized Governance
Decentralized Data Management
Infrastructure Automation
Design for failure
Evolutionary Design

28. Tjenester vil feile! Tjenester må kunne startes i vilkårlig rekkefølge
Retry-mekanismer hvis en tjeneste er utilgjengelig.
Håndtere feilsituasjoner
Robuste start/stopp-script
Saklig logging under oppstart
Logge inngående og utgående kall
Bruk log levels aktivt
Tjenester kan startes i vilkårlig rekkefølge.
Retries hvis en tjeneste ikke er tilgjengelig
Hysterix
Håndtere feilsituasjoner

29. Infrastruktur HTTPS overalt, alltid! Elastic Load Balancing Web proxy
Lastbalanserer
Discovery
Hazelcast for HA
Elastic Load Balancing
Web proxy
Lastbalanserer
Discovery
Hazelcast In-memory data grid
Elastic Load Balancing

30. Ett eksempel på hvordan fysisk infrastruktur kan se ut.
Kan selvfølgelig gjøres mye enklere.

31. Characteristics of a Microservice Architecture
Componentization via Services
(Team) Organized around Business Capabilities
Products not Projects
Smart endpoints and dumb pipes
Decentralized Governance
Decentralized Data Management
Infrastructure Automation
Design for failure
Evolutionary Design

32. db
domain
Forretning snakker om funksjonsområder, utviklere om teknologi/lag. Mismatch!
Tett kobling
Lav kohesjon
Spaghetti!
Måtte rydde for å finne ut hva som kunne trekkes ut!
----
web

33. REST, HATEOAS + ressurstankegangen hjelper

34. Når? Dele opp? Hvordan? Størrelse / når dele opp ulikt ansvar
ulik livsyklus
ulik SLA/kvalitetsegenskaper
skalering
forskjellige team
jobber på ulike data, ulike integrasjoner
Divide and conquer
Latin: Divide et impera
---
Public domain:

35. Erik Drolshammer erik@fjas.no @Sherriff1
Erik Drolshammer
@Sherriff1