Naming of the Service vs. Library pattern

[spier]

While discussing some improvements to the Service vs. Library pattern (details in #353), @robtuley and I spoke about the naming of the pattern. Would a different name make it easier for the readers to understand the pattern?

Repeating some info from the PR below.

From me (@spier):

If you were to name this pattern, how would you call it?
I am asking because the pattern describes an approach that I might call "Library over Service" or "Separate Service Deployments" or "InnerSource with separate deployments".
I don't see the pattern really describing a comparison of InnerSource projects in both release approaches (Library + Service) but rather only focusing on the Library approach.

From @robtuley:

I also find the pattern name confusing, for similar reasons to yourself by the sounds of it.
"Service vs Library" sounds like 2 patterns being compared, this pattern is "Library" but that term doesn't describe this pattern well to me personally because it is applied more widely in our context.
I'd call this pattern "Separate Team Deployments" or maybe "By Use Deployments", and like your suggestion of "Separate Service Deployments".

[spier]

@robtuley while writing up this issue, I re-read the Palet again.

Below I am repeating and formatting the Patlet a bit differently, to show what I mean more clearly:

Teams in a DevOps environment may be reluctant to work across team boundaries on common code bases due to ambiguity over who will be responsible for responding to service downtime.

The solution is to realize that often it's possible to

• either deploy the same service in independent environments with separate escalation chains in the event of service downtime
• or factor a lot of shared code out into one library and collaborate on that.

So maybe I misunderstood this pattern all this time.
Does this pattern in fact propose two separate solutions for the same problem?
I don't see a clear distinction between these two in the Solutions section, so maybe that's where my confusion comes from.

@MaineC maybe you can help us out here?

[robtuley]

I re-read the Palet again [snip]

I see what you mean... and that is indeed 2 different ways to approach the same underlying problem. I guess it comes down to how different these 2 approaches really are -- if they are different enough it is probably 2 patterns; if it is more of a implementation detail about the engineering practices in different orgs it should be kept together?

In my own view these are 2 different patterns that can reference each other in the see also; it feels like there is enough to say about both the "Shared Library" type approach, and the "Separate Service Deployments" approach to justify this. Libraries are popular to inner source due to their inherent shared-ness so having a top-level pattern that focuses on this mechanic for sharing seems sensible.

In terms of having a thing, you can either:

1. Thing is a library, and shared via direct code dependency inclusion in other services.
2. Thing is a service, and shared via a published artefact for per-team deployments.
3. Thing is a service with a centralised deployment so shared via it's interface.

All 3 are InnerSource-able, I'm not really sure whether this is 3 patterns, or 1 pattern discussing the pros/cons of each approach.

[jsampson1]

Hi folks, I'm new to the community and want to chime in here because "Service vs. Library" stood out to me as a confusing title when I was reading through all the patterns. I agree that Sebastian's "Separate Service Deployments" is a clearer title for the pattern that the page focuses on. Building on Rob's "things," though, I wonder if there are a few orthogonal concerns entangled here: "how the thing is released," "how the thing is used," and "how the thing is hosted."

I'm not sure how all the following points turn into patterns. Does each of the three lists deserve a pattern? Does each of the individual options deserve a pattern? Does each sensible combination of options deserve a pattern?

How the thing is released:

• Just source code
• Compiled library to depend upon
• Packaged executable ready to run

Note: All InnerSource projects have the source code available, so this isn't either-or.

How the thing is used:

• Pure library linked into other components
• Program run directly by users (CLI or GUI)
• Hosted service accessed via API
• Hosted application with web-based UI

Note: Even if the thing is a hosted service or application, there will also often be a client library or other tools for accessing it, which can themselves be in any of the modes above.

How the thing is hosted:

• One shared instance for whole company
• A few shared instances for different needs
• Many separate instances for independent teams

Note: Since all InnerSource projects have the source code available, users always have the option of deploying their own instances, regardless of the host team's primary mode. For example, our company has a couple of large, shared Concourse instances that many teams use for their continuous builds, but there are several teams that run their own Concourse instances in order to have greater control over resource constraints.

[spier]

In my understanding a Pattern describes "a solution to a problem". I think it could also be multiple solutions for the same problem? Maybe @NewMexicoKid can help us out with his knowledge on pattern semantics here?

The problem that the current pattern is looking to solve:

Teams in a DevOps environment may be reluctant to work across team boundaries on common code bases due to ambiguity over who will be responsible for responding to service downtime.

If I were to rephrase that I might say:

We want to enable maximum code-level collaboration, while removing any ambiguities about who is on-call for what.

In that sense the library approach gets rid of this issue in an obvious way. A library cannot have downtime :) Just like with an open source library, an InnerSource library is just used/included in another thing that is then deployed. So if that thing goes down, even if that was caused indirectly by said library, the team owning the thing would naturally knows that it is them themselves who have to respond to the on-call alerts for their service.

If the piece that teams want to collaborate on is a deployable service, then they can solve the issue in two ways:

• deploy multiple instances of the service, each team on-call for one of them

WIP - will need to finish this later as I am just typing in my phone 😄

[jsampson1]

Teams in a DevOps environment may be reluctant to work across team boundaries on common code bases due to ambiguity over who will be responsible for responding to service downtime.

That's a very nice problem statement. There are perhaps still two sides to it: A receiving team may want to accept contributions without being responsible for the contributing team's service reliability and resources; or a receiving team may want to reuse a service without relying on the host team for service reliability and resources.

There's an interesting interplay between this and 30 Day Warranty, which is already mentioned in the "See Also" section. But whereas the current text says that it's a different solution, they're really complementary, because regardless of whether there's one shared deployment or many separate ones, the receiving team could ask the contributing team to be responsible for fixing bugs that arise in any of the deployments due to the change.

[robtuley]

In my understanding a Pattern describes "a solution to a problem". I think it could also be multiple solutions for the same problem?

I'm following this thought with some interest as it's helping me understand what a pattern is. In my mind it was the other way round: a pattern is a solution that would address at least one but possibly many problems.

i.e.

• "do this", it is known to help with x, y and z.
• or if I had a problem, there might be a few different options ("patterns") of how to solve it.

[spier]

@robtuley I think it depends on how big or small you define the scope of the problem.

The risk for any pattern is for it to become too big. In the worst case the scope grows towards solving "how to do InnerSource". Therefore I think that a pattern is easier to implement, when it is focused on a specific relatively small problem. As an analogy, you could think about this similarly to a user story of a development team: The smaller it is, the easier it is to focus.

Another advantage of a pattern with a smaller problem scope is that the reader can decide quickly "do I have this problem" by reviewing Problem + Context. And if they don't have that problem they can just move on and ignore the pattern.

However it is still true, that for the same Problem, there could be different solution.
So in theory that could be even multiple patterns, offering different solutions for the same problem (we don't have examples of such patterns yet). Personally I would rather have multiple blocks in the Solutions section of the pattern, each block describing one solution to the problem.