Skip to main content

Experiments

Context​

Microservices are being adopted. Each microservice is managed by exactly one team. The team is responsible for the whole life cycle of their microservice(s). Microservices require the introduction of many new technologies like containers and cluster managers, or using different programming paradigms like workflow choreography instead of workflow orchestration.

Problem​

  • Lack of knowledge and experience in development teams how to do microservices
    • e.g., how to split microservices, how do implement distributed architecture, how to do DevOps, ...

Solution​

Allow and budget experimentation phases.

The road towards the required knowledge inherently necessary for microservices should be walked step by step. A problem-oriented learning will make sure that the right and relevant topics are tackled. It may start with how to use containers as deployment artifacts, over how to use paradigms as asynchronous reactive programming, up to how to use service meshes. Although education programs can give you a good vision of what is laying ahead, some experiences have to be made in practice.

The advantage of such an incremental learning is the deep knowledge on the sides made, also by failures and hitting dead ends in experiments. Although this kind of learning is more expensive than following a clear plan, it might pay off in the end since the acquired knowledge will help to have a clear grasp of the situations coming in the future. Making experiences together will help to close the potentially existing gaps between roles like dev and ops.

Maturity​

More data required (only 3 sources).

Sources of Evidence​

Interview A:

  • Need to make experiences together
  • Closed the gaps between dev and ops
    • making experiences together
    • lowering the pain
    • removed the bashing between roles/teams
  • Literature only helps to certain point
    • hand on the hot stove plate
  • Dedicated experiment phases to build up the required knowledge
  • Process: agile => without a real plan
    • problem-oriented: one step at a time
    • painful, costly, retrospectively without a plan
    • still happy they did it that way
      • failures (literature, experiments) led to a deeper knowledge in the end
      • much knowhow on the sides

Interview B:

  • "das muss man einfach im Kleinen lernen"
  • experiment, grow into it
  • especially in Java context: grow into the asynchronicity

Interview D:

  • Context: establish a failure culture
  • Chaos Engineering: test in a controlled environment how system reacts to certain scenarios
    • Let's shutdown that service and see how it reacts
    • Interpretation: this is also a type of experiment that allows building knowledge on how a distributed system reacts