Warning - this is a large amount of text highlighting general strategy for my time at this conference. What I deem as valuable may not work for others with separate strategies. See the TLDR of each day if interested in the general overview.
KubeCon has wrapped up and with it I can definitively say that it was the most productive and impactful event in all of my previous KubeCon attendances. I went into this event with a strategy - which included observations and exploration as well as targeted tasks.
It’s no secret - and likely I am a broken record at this point - that homelabbing is not only a hobby of mine, but also a great activity for learning.
The experiments I have ran from my own hardware have informed me in ways where I could participate in discussions and architectural decisions in ways that provided value to myself and others. It is still an activity that I work to establish as a habit in some way/shape/form throughout my schedule.
In a week of the news around xz utils backdoor vulnerabilitity, it provides a reminder that there are systems that we need to remain vigilant in monitoring.
I’m a believer that one of our most vulnerable assets is our developer environments. We conduct tons of experimentation and use them to drive upgrades to downstream systems.
How are we keeping track of what is installed and the versions etc? seems like a solved problem - but I can guarantee that even big enterprise still remains vulnerable - more so in the age of containers.
If there is one value that I believe has contributed to the most meaningful time spent - in work and out - it’s the guiding principle that How you do anything is how you do everything. I don’t know where I originally heard it - but it immediately resonated as a truth with me.
Break it down
Hear me out - from the task that are very important and require intense focus - to the menial, routine tasks that require your attention in order to get them done - how you approach doing them is often consistent over time. Meaning that your system for approaching and solving any problem at hand is a byproduct of your systems. As James Clear puts it, “You do not rise to the level of your goals. You fall to the level of your systems”.
As a follow on from my previous post from OSCAL, I wanted to take a step back and discuss the role of Open Source GRC Engineering. If we look at traditional Governance, Risk, and Compliance (GRC) tooling - because I do imagine there are GRC platforms today that are not Open Source but are innovating - we’ve seen interfaces that primarily operates on consuming data and visualizing it. Not a bad business model by any means, but where it can fundamentally fail is defined paths for data to flow.