Please enable JavaScript.

Coggle requires JavaScript to display documents.

Rodrigue Schaefer: From monolith to microservices about some of the…

- - - - business logic in db (store procedures) :open_mouth:
      - all access via store procedures (no direct access to db) :scream:
- - - - a lot of coordination needed between teams for developing and releasing a feature
        
        waiting for the next "release train"
  - - - => bug density increases and
      - => system complexity increases
    - - => rigid processes were adopted (everything tightly controlled to reduce variance as much as possible)
      - => this kills innovation (everything on the same tech stack, etc)
  - - - hiring problems, retention issues: difficult with finding people wanting to work on this old platform
      - not attractive to young talents
      - slow onboarding and fear to change anything
- - - - no time lost with fear of breaking someone else' part
  - - - each team can act on its own, define its delivery process, its technological stack
      - every team can have an idea, develop it, deploying and operate it
    - - strategical alignment to be all on the same page
        
        Alignment is made with OKR
        
        the company define its objective for the year
        
        then each department take these objectives and come up with their own
        
        then the teams do the same
    - - give support to engineers to get better at what they want to be good at
      - we want excellent engineers, so we need to help them develop and grow
      - Positive psychology is helping here
        
        Old psychology: helping sick people
        
        Positive psychology: make normal people more happy
        
        (see
        Six factor Model of Psychological Well being)
- - - - dev
      - test
      - operations
- - - - defines a vision of the architecture we want to have
        
        loosely coupled services, resilience, REST as the main style to design API, ...
        
        written down into a booklet and given to everybody
    - - get feedback and opinions by others
    - - looking at new technologies, technologies we don't want to see, experimental stuff, etc.
      - share this knowledge publicly
    - - we took some of the best engineers to work together to create a blueprint of how the new microservices platform could look like
        
        (they created a prototype of the core domain functionality in a dozen of microservices, message queues,...)
      - this ain't no ivory tower architecture
        
        just an idea presented to the teams to take what they found useful and go from there
- - - - with this router they can do A/B testing or canary releases
      - this way Zalando can still use "legacy functionalities" served by the monolithic application, and migrate smoothly and incrementally to a new microservice architecture
      - the routes can be changed dynamically via API, at runtime!
- - - - he/she also has a bigger picture of what the company is trying to achieve, can connect teams, and check that communication and alignment are in place
  - - - => which means lots of calls on the layout service
      - => which means lots of calls to endpoints
      - => which means lots of calls to microservices
      - => which means each service has to authenticate via IAM
      - scaling is really hard
  - - - this ends up in the user's browser
      - slows down the page load time
      - may create conflicts and incompatibilities between adopted frameworks
  - - - your service is too big
      - you have too many services