In the past, I have spoken about evolutionary architecture and emergent design. As it turns out, I have learned my first lesson in Kubernettes programming.
I have learned not to be too technically focused early in the process. At the beginning of my work, most of the concepts were new to me and, in an attempt to start getting something coded, I decided to focus on one of the important technical problems.
This did not end up bearing any early fruit. I was constantly thinking about the bigger picture and focusing on a tiny part was not helping the bigger picture come into focus. It felt like I was diving down a rabbit hole instead of getting the design right.
So I had this use case and some ideas on how to break it up into CRDs, but there was not a flow of ideas coming out of the iterative process. The engine had stopped.
This has changed. I was reading the Programming in Kubernetes book, and there is a section on edge-triggered, level-driven logic. It seems that focusing on the interactions between the objects is again the path to revealing the right design. I should have been following my own advice of creating conceptual diagrams as they allow you to see some of the eventual code structures before actually coding.
Anyway, as it turns out. Things are always the same. Problem decomposition into objects is the first step, and the next is to define the interactions between objects. From there, it's a matter of matching your design to the problem.
So now the design begins to emerge:
Some of the questions that are helping to reveal the overall design.
1. How does changing a parent affect the children and visa-versa?
2. User vs System generated events?
3. What is the initial state in the cluster?
4. How do you scale at each level in the system?
This is the problem you need to solve after defining the CRDs. Keeping objects at their correct state via the "Control Loop"
https://learning.oreilly.com/library/view/Programming+Kubernetes/9781492047094/ch01.html#edge-vs-level
No comments:
Post a Comment