Skip to content

Cleanup Service vs Libary pattern #354

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Sep 13, 2021
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
26 changes: 8 additions & 18 deletions patterns/2-structured/service-vs-library.md
Original file line number Diff line number Diff line change
Expand Up @@ -23,26 +23,16 @@ reluctant to join forces even if there is significant overlap in requirements.

## Context

Teams are working in a micro-services environment.

They are organised in full functional DevOps teams: Each team is responsible for
their contributions end-to-end, including maintenance, on-call and customer
support.

A team is tasked with providing a service to their downstream customers that is
fairly similar to an existing service built by another team.
* Teams are working in a micro-services environment.
* They are organised in fully functional DevOps teams: Each team is responsible for their contributions end-to-end, including maintenance, on-call and customer support.
* A team is tasked with providing a service to their downstream customers that is fairly similar to an existing service built by another team.

## Forces

Organisational escalation paths may be different for each of the teams.

Members of each team may be unwilling to answer on-call support for errors that
do not affect their own downstream customers.

Severity levels for the same types of errors may be different across team
boundaries due to different SLA definitions per team/customer relationship.

Teams may have different security or regulatory constraints governing their deployments.
* Organisational escalation paths may be different for each of the teams.
* Members of each team may be unwilling to answer on-call support for errors that do not affect their own downstream customers.
* Severity levels for the same types of errors may be different across team boundaries due to different SLA definitions per team/customer relationship.
* Teams may have different security or regulatory constraints governing their deployments.

## Solutions

Expand Down Expand Up @@ -83,7 +73,7 @@ Related to this pattern is the [30 Day Warranty](30-day-warranty.md) pattern tha
## Known Instances

* Europace AG
* Flutter Entertainment: A [Flutter InnerSource application](https://innersource.flutter.com/start/setup-ci/) has a shared code "service" repository with cross-team contribution and CI pipeline to build and publish a shared release artefact. Each adopting team has a "deployment config" repository defining their own deployment. This is driven by varying regulatory requirements, service and incident management practices and infrastructure skillsets in different areas of the business.
* Flutter Entertainment: A [Flutter InnerSource application](https://innersource.flutter.com/start/setup-ci/) has a shared code "service" repository with cross-team contribution and CI pipeline to build and publish a shared release artefact. Each adopting team has a "deployment config" repository defining their own deployment. This is driven by varying regulatory requirements, service and incident management practices and infrastructure skill sets in different areas of the business.

## Status

Expand Down