MAD — Microservices Architectures Dynamics

MAD is a discrete event simulator to study the dynamics of microservices architectures where each service encompasses several defensive mechanisms, such as timeout, autoscaling, throttling, back-off protocols, etc.

See the official documentation.

TODO

• Features
  • Services
    • Monitoring
      • Per operation
        • emission rate
      • current timeout
      • current back-off delay per 'partner'
      • incoming/outgoing rejection rate/count
    • Priority / Service differentiation
      • An algorithm that ensures fairness
    • Autoscaling
      • Delay before workers gets active,
      • Expose the metrics in use
    • Actions
      • Probabilistic switch statement, a la 'choice'
  • Clients
    • Multiple clients
    • Workload patterns
• Bug fixes
• Examples
  • SensApp example
  • Grafterizer example
  • Example for The Architecture Conference .NET microservice
• Tests
  • Test shutting down workers, they shall first complete there current task
  • Test that the simulation call back the display
  • Test for retry in an action list in the parser
  • Test timeouts that are activated after the call to send request (what happen if the request is assign to a worker right away?)
• Refactorings
  • A test factory shared among simulation test
  • Move the creation of workers from Service to the autoscaling strategy
  • Merge test_evaluation and test_interpreter
  • Merge throttling and Task pool into Bounded task pool
  • Autoscaling should read statistics from the monitor
  • Monitor should also account for worker counts
  • Events pushed by each state machine should be an enumeration (data-driven)
• Concepts ideas
  • Caching
  • Server side Proxy
  • Client side proxies / circuit breaker?
  • Message-Queue/PubSub?
  • Deamons as processes that would run periodically within a service

NEXT RELEASE CHANGE LOG

• Features
  • Copy the model into the output directory
• Bug Fixes
  • Fix worker that are not released when the triggering request as been discarded and that the emitted request succeed
  • Fix rejection that did not fail the 'parent' request
• Refactorings
  • Split acceptance tests into several files (commons, nominals, errors)