Add draft for service-vs-library pattern. #90
Conversation
service-vs-library.md
Outdated
| support. This poses a challenge when working across team boundaries: Escalation | ||
| chains may not be the same for errors happening in either team. Coupling | ||
| source code and deployment leaves the teams with the question of who is | ||
| responsible for on-call support in the event of errros. As a result teams are |
There was a problem hiding this comment.
typo: errros -> errors
|
This writeup is good, Isabel. |
| Decouple configuration and deployment pipelines from actual business logic. | ||
| Establish a second deployment of the service for the second team. | ||
|
|
||
| Treat the common base as a library that is used by both teams with shared code |
There was a problem hiding this comment.
The Patlet talks about deploying the same service in independent environments yet the solution talks about factoring out shared service code into a library, which becomes the focus of collaboration (not the service). I feel like these two sections of the document are incongruent with each other. Are the teams collaborating on the source code for a library or a service?
|
@NewMexicoKid Thanks for pointing out the typo. @rrrutledge You're right - these two are incongruent. I've changed the Patlet to be better in line with the proposed solution. Deploying the same service twice with zero modification would presume that deployments are standardised across teams. While this may be true in some cases, more likely than not independent teams will have different deployment environments. Thank you for pointing out that flaw. |
`erros` => `errors`
"interdependent" => "common". I think that "common" is a better word here since the idea is to have a single code base, rather than "interdependent" which signifies multiple code basis that are mutually dependent one on another.
| chains may not be the same for errors happening in either team. Coupling | ||
| source code and deployment leaves the teams with the question of who is | ||
| responsible for on-call support in the event of errors. As a result teams are | ||
| reluctant to join forces even if there is significant overlap in requirements. |
There was a problem hiding this comment.
Another way of getting around this problem is 30-day warranty. Could be good to mention that somewhere in this document.
|
@rrrutledge I didn't even know that committing to a branch suggested as PR would be possible for the maintainers of the original repository. Learnt something new there. Also, thanks for the corrections you included in your commits. |
|
@rrrutledge thanks for the approval. What does the remaining process for this pull request look like? |
lenucksi
added
the
📖 Type - Content Work
As requested in #89 this is a first draft of the service-vs-library pattern that I observed in DevOps teams.
Feedback, suggestions etc. welcome.