Skip to main content

Support by Taskforce Team

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​

Found a taskforce team that builds up the required knowledge and later support the microservice teams to catch up. The goal of the team is to first develop an idea of how to be fully responsible for a microservice (e.g. by using established patterns or conducting experiments), and then convey the idea and set an example.

In migration scenarios, we found operational topics to be particularly relevant. Thus, the taskforce team can emerge from a previous operation team.

When conveying the idea to the other teams, they should support them with their microservice(s). They have to pay attention not to overload the microservice teams with the amount of new knowledge. Certain aspects like providing a production-like testing environment or operating the services themselves can be managed by the taskforce team globally in order to reduce the microservice teams' overload.

Due to the fast moving technical progress, it makes sense keep the taskforce team alive even after overcoming the knowledge gaps. They should be at the state of the art and further introduce knowledge required for the future.

Maturity​

Proposed, requires evaluation.

Sources of Evidence​

LN43:

  • Good middle ground: have operations team in the beginning which still responsible of production
    • teams have time to adopt that they own the codebase
    • When comfortable => gradually take over the production responsibility of their service

LM45:

  • Context: interviews and insights from multiple cases on technologies and sw quality in MSA
  • C4-S7
    • DevOps team implemented CI/CD pipelines
    • later onabort, DevOps team integrated into existing development teams
  • C5-S8
    • During migration, there are separate ops and DevOps teams in close collaboration with dev teams
    • interpretation: these teams only exist for the migration

Interview A:

  • Challenges: change culture, build up knowledge
  • Especially operations: automation, test env
  • Introduced "DevOps" team
    • Goal: convey the idea and set and example
    • Support teams to gain full responsibility over dev lifecycle
    • Explain it over and over again
    • "Don't teach your men to build a ship, teach them the yearning for the world instead"
  • Helped to bridge the gap "dev vs ops": experiences together
  • Learning by doing: containers
    • Also books
  • ~2 years technologically in front of dev teams
    • Danger to lose devs with too much progress
    • Thus the support to make it work
  • Founded by head of development => founded team
  • Sentiment towards the DevOps team:
    • interested, but also critically

Interview B:

  • DevOps doesn't mean there can't be an operation department
  • Has to provide monitoring possibilities

Interview F:

  • Infrastructure / release management team
    • watch over standards being adapted: e.g. automated tests, build infrastructured, CI, deployment
    • building the binary did the microservice team and unit tests
    • things after that up to deployment by release management team
  • Context: get competencies into the team
    • basic knowledge in microservice team about security and operation
    • for advanced features: some consultant, e.g. security expert sitting next to lead architect
      • also reviewed these specific aspects