DotnetMinorNotes

• Architectuur
  • Architecton
  • Vroeger vergeleken met bouwwereld
  • Architectuur beslissingen
    • Wat?
    • Wie?
    • Waarom?
    • Hoe?
• SOA
  • Het idee
  • Service bussen
    • Hoe werkt het?
    • Soorten servicebus
    • Producten
  • Voordelen
  • Nadelen
• Web scale IT
  • Toolbox
    • Microservices
    • CQRS
    • Event Driven Architecture
    • Event sourcing
    • Actor model
    • Polyglot X
    • BASE / NoSQL
    • Domain driven design
  • Services
    • Type services
      • Front end services
      • Integration service
      • Capability oriented service
      • Data oriented service
      • Process oriented service
    • Communicatie soorten
      • Events
        • Wanneer events?
      • Commands
        • Wanneer commands?
    • Services bepalen
      • Wel splitsen
      • Niet splitsen
• Microservices vs SOA
  • Eventual consistency
    • CAP Theorem
      • SOA
      • Web scale

Architectuur

Architecton

• Archi = baas
• Tecton = timmerman
• Dus: Baas van timmermannen

Vroeger vergeleken met bouwwereld

In de IT kan je opnieuw beginnen als iets omvalt. In de bouwwereld niet (Refactoren van een huis kan niet)

Architectuur beslissingen

Wat?

Beslissingen die wel heel erg duur zijn om later nog aan te moeten passen

Wie?

De architect

Waarom?

De architect heeft genoeg ervaring om dit te kunnen weten

Hoe?

Eerst kijken wat deze applicatie nodig heeft

• Moet die 24/7 beschikbaar zijn?
• Moet die heel veel gebruikers aan kunnen?
• Moet die heel stabiel zijn?
• Moet die berekeningen met 100% zekerheid uit kunnen voeren?
• Valideren
  • Walking skeleton maken
    • User stories zorgvuldig kiezen
      • Architectureel significante use cases / user stories
• Van de ene naar de andere architectuur komen
  • Strangulation pattern
    • Oude warboel beschouwen we als 1 blokje van de nieuwe architectuur
    • Als er iets aangevuld moet worden of bijgebouwd moet worden, haal je dit stukje uit de oude warboel en bouw je het in de nieuwe architectuur

SOA

Service Oriented Architectureel

Het idee

• Services niet meer aan elkaar knopen, maar aan een servicebus knopen
• Services zijn min of meer autonoom met eigen database
  • Data service (zorgpolis service)
  • Processing service
  • Front end service
  • Integration service
    • Koppeling tussen het systeem en de buitenwereld

Service bussen

Hoe werkt het?

• Hardware met een beetje software
  • Bijvoorbeeld Biztalk
    • Slepen van componenten
      • If/else blok
      • Service
      • XML bericht specificeren
• Canonical schema
  • Overkoepelend alles omschrijvend schema
    • Hoe de gegevens van een persoon eruit zien
  • Alle berichten in de servicebus gaan via het canonical schema
• Locator

Soorten servicebus

• Zware servicebus
  • Veel logica in de servicebus
    • Polissen van mevr willemsen
      • Naar de persoons service voor nummer
      • Naar andere service voor …
      • Etc..
  • Veel proces kennis
• Lichte servicebus
  • Nog steeds een canonical schema
  • Nog steeds een locator
  • Proces informatie niet in de servicebus, maar in een process service
    • Voordeel
      • Maakt niet meer uit welke servicebus je hebt. Het enige wat die doen is berichten doorsturen
      • Geen middleware meer nodig

Producten

• Oracle service bus
• Tibco service bus
• MS Biztalk
• IBM

Voordelen

• Minder connecties onderhouden
  • Als alle blokjes met elkaar verbonden zijn, onstaan er veel meer lijntjes

Nadelen

• Service kan offline zijn waardoor systeem op zijn gat ligt
  • Gebruiker vraagt: Doe mij alle boeken over SOA’s
  • FE stuurt bericht naar catalogus service
  • Catalogus service stuurt berichtje terug met alle boeken
  • Als catalogus service offline is kan de front end niets meer
• Canonical schema blijft niet zo’n goed idee te zijn
  • Als over de hele organisatie beschreven zou zijn hoe cursussen eruit zien kan er geen onderscheid gemaakt meer worden tussen cursussen en cursusinstanties

Web scale IT

• Set van patterns die de grote jongens gebruiken, heeft Gartner ‘Web scale IT’ genoemd
• Het kan niet zo zijn dat doordat 1 systeem faalt, de rest van het systeem het niet meer doet
• Agile approach
• Continuous delivery

Toolbox

Microservices

SOA, maar dan met een event bus in plaats van een service bus

CQRS

Command Query Responsibility Segregation

Event Driven Architecture

• Message based architecture is gevoelig voor het offline zijn van componenten
• Eventbus werkt met events. Er is dit gebeurd, er is dat gebeurd, …
  • Events komen in event queues terecht
  • Later als de service weer online komt, handelt deze alle wachtende events af voor zijn service
• Meer loosely coupled

Event sourcing

Data niet meer opslaan als data, maar als series van events. Dit heeft ook weer toepassing op bijvoorbeeld de CQRS structuur

Actor model

Frameworks als Akka.NET, MS Orleans, e.d.

Polyglot X

Per service kiezen hoe je de service inricht

• Eigen programmeertaal
• Eigen platform
• Eigen database
• Eigen architectuur

BASE / NoSQL

• Basic Availability
• Soft-state
• Eventual consistency

Domain driven design

• Boek door Eric Evans
• Design baseren op de realiteit
• Vaak gebruikt voor complexe problemen

Services

Type services

Front end services

Bijvoorbeeld een MVC website en krijgt vaak een database met alle artiekelen, zodat het niet uitmaakt of de boeken service offline is (zie CQRS)

• In gedenormaliseerde vorm
• NoSQL
• Fungeert als cache

Integration service

Communicatie met de buitenwereld

Capability oriented service

Een service die suggesties doet voor welke boeken je moet kopen

Data oriented service

Heeft als taak om data te bewaren voor een langere tijd en dit deelt met anderen

Process oriented service

Bijvoorbeeld een polis aanvraag service

• Er moeten gegevens ingevuld zijn
• Controleren of er al een polis afgesloten is
• BKR check doen

Communicatie soorten

Events

• One-way / Fire & Forget
• Voltooid tegenwoordige tijd
  • ‘Declaratie verwerkt’
  • ‘Declaratieverzoek ingediend’
• Immutable
• Vertellen WAT er veranderd is

Wanneer events?

• Loosely coupled
• Broadcast
• High availability

Commands

• Request - Response
• Gebiedendewijs
  • ‘Verwerk declaratie’

Wanneer commands?

• Reactie nodig
• Bevestiging nodig
• 1 specifieke target

Services bepalen

Wel splitsen

• Altijd aan vs niet altijd aan
  • Als een taak maar 1 keer in de paar maanden uitgevoerd moet worden, kan er voor deze taak een aparte service gemaakt worden. Moet de taak uitgevoerd worden, wordt er een Azure VM gestart, wordt de taak uitgevoerd en wordt de VM weer weggegooid
• Communicatie met extern systeem
• Traag veranderend vs snel veranderend
• Data oriented vs process oriented
• Bounded context domain verschillen als het om verschillende dingen gaat
• 1 verantwoordelijkheid, 1 taak

Niet splitsen

• 1 frontend voor gebruikers
• Minder communicatie nodig
• Minder werk
• Minder complex
• Minder kosten
• Minder keys over database grenzen

Microservices vs SOA

• Microservices architecture is een evolutie van SOA
• Meeste SOA principes zijn nog steeds relevant
• SOA services handelen hele domeinen af waarbij microservices een specifieke business functionaliteit afhandelen
  • Focus op gedrag in plaats van data
• Data duplicatie is niet erg in Microservices
  • Er bestaat geen canonical schema

Eventual consistency

Wordt BASE genoemd. Dit is min of meer het tegenovergestelde van ACID

BASE

• Basic Availability
• Soft-state
• Eventual consistency

ACID

• Atomicity
• Consistency
• Isolation
• Durability

CAP Theorem

Driehoek met Consistency, Availability and Partition Tolerance (replicatie mogelijkheden)

SOA

Combinatie van Consistency en Partition tolerance

Web scale

Combinatie van Partition tolerance en Availability