Make patterns more abstract and not so fine grained - General Strategy?

[markus-gsf-seidl]

Currently we are on the track to produce very, very fine granular patterns that are sometimes trivial:

• Right-sizing
  • https://patterns.greensoftware.foundation/catalog/cloud/match-utilization-requirements-of-vm
  • https://patterns.greensoftware.foundation/catalog/cloud/match-utilization-requirements-with-pre-configured-server/ (which, ironically, has the exact same word-for-word description of the pattern above!)
  • https://patterns.greensoftware.foundation/catalog/cloud/scale-down-kubernetes-workloads/
  • https://patterns.greensoftware.foundation/catalog/cloud/scale-kubernetes-workloads-based-on-events/
• CPU Utilization (which is in the same territory as right-sizing)
  • https://patterns.greensoftware.foundation/catalog/cloud/optimize-avg-cpu-utilization/
  • https://patterns.greensoftware.foundation/catalog/cloud/optimize-peak-cpu-utilization/ (exact same description)
  • https://patterns.greensoftware.foundation/catalog/cloud/scale-kubernetes-workloads-based-on-events/ (scale on CPU metrics)
  • https://patterns.greensoftware.foundation/catalog/cloud/scale-down-kubernetes-workloads/ (scale when CPU idle, maybe different aspect)

Wouldn't it make more sense to categorize these on a higher level and then break them down? Or cluster them in more general patterns (like Right-sizing). If we continue like this we have a list of very fine granular patterns like:

• Optimize CPU Utilization in VM
• Optimize CPU Utilization in K8S
• Optimize CPU Utilization in AWS
• Optimize CPU Utilization in Azure
• ...

There are more patterns that are overlapping.

[jawache]

Thanks @markus-ntt-seidl this is great insight.

I think we have a statement that patterns should be decomposed to the point where the SCI impact statement doesn't change any more on further decomposition. E.g. if you have a pattern that is both Energy and Embodied, if it can be split up into two patterns one on Energy and one on Embodied then break it down.

We came up with that approach because someone submitted a patter that was very very high level, "make software carbon aware".

But I can see from your first two examples that we have gone the other extreme as well, two patterns that are worded almost exactly the same seems redundant.

One thought that's popped into my head reviewing your examples above is that there might be a mixture of a pattern and an implementation of a pattern.

E,g, https://patterns.greensoftware.foundation/catalog/cloud/scale-down-kubernetes-workloads/ sounds like a pattern, whereas https://patterns.greensoftware.foundation/catalog/cloud/scale-kubernetes-workloads-based-on-events/ sounds like an implementation of a pattern.

But then again you could also argue that https://patterns.greensoftware.foundation/catalog/cloud/scale-down-kubernetes-workloads/ is an implementation of "scale workloads".

So at what point do we say something is a pattern vs an implementation?

[greenhsu123]

from @navveenb "Maybe we can have patents as per SCI Energy, Hardware and Carbon Awareness. For example, we would have one patent for sizing and optimization - web, server etc.. and have tags applicable for web, cloud etc"