Today, I came across a true gem: Akin's Laws of Spacecraft Design. Originally written for the aerospace engineering domain. I find many parts of it relevant for software engineers as well. Below, I share my thoughts on the Laws that resonate most with my experience as a software designer and tech blogger.
As it often happens, I discovered it through Matt Rickard's newsletter.
What DALL-E thinks the image for this blog post should look like.
This is a long overdue post on iximiuz Labs' internal kitchen. It'll cover why I decided to build my own learning-by-doing platform for DevOps, SRE, and Platform engineers, how I designed it, what technology stack chose, and how various components of the platform were implemented. It'll also touch on some of the trade-offs that I had to make along the way and highlight the most interesting parts of the platform's architecture. In the end, I'll, of course, share my thoughts on what's next on the roadmap. Sounds interesting? Then brace for a long read!
"How to start programming in Go and for Kubernetes?" - the question I often get from fellow DevOps people. This is a tricky one. And I don't have a universal answer to it. However, I do have some thoughts to share.
But first, let me tell you my own story.
In my case, it was rather an evolutionary step - I'd been developing software for almost 10 years by the time I started coding for Kubernetes. I'd also been (sporadically) using Go for some of my server-side projects since probably 2015. And around 2019, I started my transition to, first, SRE and, then, Platform Engineering. So, when I decided to get my hands dirty with Kubernetes controllers, it was just a matter of joining the right team and picking up the Kubernetes domain. Luckily, I had a good candidate on my radar, and that required just an internal transition from one team to another.
However, based on my observations, for many contemporary DevOps engineers, the direction of the desired transformation is often inverse. From Ops to Dev (preferably, for Ops).
Since your background and experience may vary, instead of giving a concrete piece of advice here, I'll try to explain how I'd approach the problem given different levels of proficiency with the technologies.
A short one today. Just wanted you to meet my new favorite Go library to work with Kubernetes -
k8s.io/cli-runtime. It's probably the most underappreciated package in the whole
k8s.io/* family based on its value to the number of stars ratio.
Here is what the README file says about it:
Set of helpers for creating kubectl commands, as well as kubectl plugins. This library is a shared dependency for clients to work with Kubernetes API infrastructure which allows to maintain kubectl compatible behavior.
If the above description didn't sound too impressive, let me try to decipher it for you - with the
cli-runtime library, you can write CLI tools that behave like and are as potent as the mighty kubectl!
Here is what you actually can achieve with just a few lines of code using the
- Register the well-know flags like
--kubeconfig|--context|--namespace|--server|--token|...and pass their values to one or more
- Look up cluster objects by their resources, kinds, and names with the full-blown support of familiar shortcuts like
- Read and kustomize YAML/JSON Kubernetes manifests into the corresponding Go structs.
- Pretty-print Kubernetes objects as YAML, JSON (with JSONPath support), and even human-readable tables!
Interested? Then have a look at the usage examples below 😉