Tie patterns to use cases

[tmcclell]

An idea that came out of Standards working group would be to tie patterns to Use cases for publication. Discuss process?

[holanita]

Noted @tmcclell will put this on the agenda when project calls are resumed.

[markus-gsf-seidl]

I personally would like to see more levels in terms of abstractness. I tried to formulate one point here #217 and I think this could be another aspect or level of abstraction.
Currently we have a topic (Cloud, AI, Web) and Tags. We have a bunch of patterns that have the same intention, but map to different technologies (for example CPU utilization in cloud, k8s, vm, ...)

In the end it the things that we have currently as pattern would be the lowest (or almost lowest) level, and we have a better hierarchy above this.

[jawache]

You used a really interesting term there @markus-ntt-seidl "intention". I'm seeing that used multiple times in multiple places now, esp. in the kubernetes space. You describe the intents of your workload

I'm starting to suspect that we are trying to give advice to the wrong categories, and we should be giving advice for types of workloads instead of types of domains.

E.g. break down "machine learning" into the traits of what makes a machine learning workload different from say a "web server" workload and then a pattern is for a particular type of workload trait.

So perhaps a traits for a machine learning workload is:

• High CPU
• High Mem
• Low Network Traffic
• Latency Insensitive

And traits for a web server workloads is:

• Low CPU
• Low Mem
• High Network Traffic
• Latency Sensitive

And then our patterns might be against those categories, e.g. patterns for:

• Low CPU
• High CPU
• Low Mem
• High Mem
• High Network Traffic
• Low Network Traffic
• Latency Sensitive
• Latency Insensitive

Because that's what really matters, when we say machine learning for instance we are just assuming your machine learning system is high cpu and low network, it might not be, those are just the assumption we are making. And the advice we are giving in a pattern is more based on the traits for different types of workloads.

[markus-gsf-seidl]

Thanks for your thoughts, @jawache (this also includes an answer to #217 (comment) )

It is difficult to find the "right" structure, but our current track needs to be revised IMHO.

The pattern books I've read had a problem statement and then a solution to that problem in form of a pattern. Even if Singleton or "Event-Driven Consumer" are simple from a nowadays point of view, they might only have reached this because of writing it down in a more lengthy form (I once read that the first description in a novel about a time machine was 20~30 pages long, and today we write two words for this).

Coming from that point we could try to generate higher level of intentions (like Rightsizing) or something like that and describe how this intention can be applied in various environments. I wouldn't mind if that part can be read as a book then linking to a list of pattern. (But: Information on how to scale kubernetes pods up/down is readily found on the internet and there might not be a need to duplicate this)

I do really like the idea of coming from assumptions we have about the system the reader is having. Like: "Have high CPU load -> try these patterns".
I think we need to have the reader/user in mind, so someone wants to read it. That should be the main goal.

[russelltrow]

Reviving this discussion as we have identified out first Use Case: #297