Mindful of Size MS can be rewritten in 2 weeks - rule of thumb identify bounded context, incrementally see if this can be split down further until granulrity ist right too corse -> monolith -> tight coupling -> change ripples through slows done development

            identify bounded context and sepearte into microservices

too granular -> too many ms, with artificial split -> communication overhaead find a balance ! Allways follow the domain

Pull over Push A --> data --> B (A pushes to B) A <-- data <-- B (B pulls A) which to choose

inversion of dependency (data flow direction -> dependency direction) depedency determine the degree of coupling thight coupling increases time to market

pushing: needs to handle consumer unavailable remember last event processed by consumer collect feedback from consumer be aware of new consumers push the next event when the consumer is back -> thight coupling

pulling: b needs to handle unavailability of a b needs to remember last event processed -> easier, because b is processing the data gracefully degrade features (in case of unavail a) request next event when a is back

from resilience and error handling pov -> pulling is better

preference for pulling in detail: Seperation of Events and Resources event contains only id and a reference to a resource but NO SNAPSHOT of the resource

    consumer reads the resource and decides wheather to precess it
    
Sep of Resources and Events allow changing of Resources (Attributes)

Sep. Advantages: Filter, no noise

Events are published as a ordered sequence but often only last state is relevant

Processing of Events must be idempotent

Protocols over Products! - Software upgrades can introduce breaking changes -> big bang updates//teams can not be technical independent API is only allowed way to communicate [REWE versteht Events als (Teil-)API]

When (not) to pull pulling is great for automated processing of event streams BUT pushing can be ok for one-off events, manual error handling and occasional events

Incremental releases is good practice also with data

choreography over orchestration

two styles of coordinating ms orchestration -> mastermind service -> tells everybody else what to do

choreography -> respond to events -> loose coupling
    -> loose coupling
    -> conceptual easy to understand
    -> works well with asynchronous communication
    -> hard to test and debug
    Is it worth it?
    
Luckily middle way: High level orchestration and bilateral choreography

One Service:
    ... owns the status of a key resource and emits events
    ... delegates tasks to other services that respond to events

Fully distributed model: No single source of truth Good to have single source of truth

Useful to have templates for ms

extracting codes to librarys

drawback: if you extract template before everything is settled -> copy 'n' paste; inconsistence

use before reuse, try to template, but only when template is stable enough; only for small teams

Secrets are required for trust anchors -> no plain text nowhere (opposite is the case, secrts stored every where) -> hard to detect if and how they have been leaked -> Deployment chain have to know secrets (single point of attack) -> how to get secrets to the infrastructure

first thing: store secrets on one place -> easier to manage -> easier to keep track of

seconst step: encrypt the secrets -> now all together in a safe place

third step: -> a service that serves the secrets once on startup, afterwards is not allowed anymore

Component security

componentes: dokcer, npm, sshd ...

good: don't reinvent the wheel re-use tried and tested code integration

bad: not directly under your control no bill of materials, not vetted mostly no licenses check will make up 95% of the code you run

ugly: run with the same privileges as your code are rarely updated contain vulnerabilities

Ask yourself: are your applications dependencies up to date will they remain up to date as the time goes on how would you find out when they arent how would you fix that

Automate!

Consumer driven contracts

Aervice A depends on Service B

If B changes it's API this can break A B breaks the contract

Consumer driven contracts are tests (high level integration tests) that help: finding broken contracts evolving APIs

Team A is writing these tests Team B is running these tests CDCs detect API breakages that otherwise would go undetected

Alternatives: Using integration tests environment high complexity often waste of time and money

CDCs works best in closed communities - not applicable to public api