via ME! 😊
The gif this week is the first of many I’ve made with a focus on teaching engineering concepts.
It is part of an article I wrote for The New Stack explaining different patterns for Kubernetes cluster upgrades.
The full article be available later this month.
With a little bit of shared knowledge you know exactly what is happening in that gif with almost no words.
I’ll still be sharing gifs I find funny or intriguing in the newsletter, but creating and sharing my own gifs was a desire from day 0.
Usually, I share information I find valuable to learn, but this week I have three articles I disagree with.
I didn’t reach out to the authors.
I didn’t tweet or comment about how terrible these articles are.
I share them with you to hopefully help you know that even if you disagree with something you can do so in silence.
I know I’m “publicly disagreeing” here in the newsletter but this audience is very small — less than 100 — and it’s perfectly fine to talk about how you disagree in private.
Maybe you’ll learn something new from the people you tell.
Maybe you’ll end up agreeing.
The important thing is to always have an open mind and try to learn.
Not try to be right.
The thought that companies would be able to run reliable Kubernetes in their data center, provide self-service provisioning, accurate billing, and secure multi-tenancy while meeting public SLAs is not a reality of any on-prem environment I’ve worked.
The author mentions that anything can be provisioned as a service behind an API.
This assumes the admins of those resources have a level of development ability and all of a sudden have clear backlogs to dedicate time to building and documenting APIs and libraries for internal and external customers.
I can’t imagine this renaissance happening.
At least not the way the author describes it.
Datacenter Renaissance: part one | Fluid Thinking
With the rise of Kubernetes, enterprise investments in legacy datacenters can become significant economic leverage, by converting legacy IT ops into private clouds. While many enterprises have considered divesting their datacenter infrastructure, and moving primarily or purely into public cloud environments, they may be missing a significant economic opportunity. Kubernetes, along with other automation, provides a unique opportunity to transform cost centers into value-producers, creating efficiencies and accelerating innovation.
This article was misleading and left out some key bits of information in an effort to make Google — and specifically GKE — look bad.
The thing X.Org is saving $3000 a month on is they don’t have to pay egress charges for CI builds.
Why did they have high egress charges?
Because Packet gives them free CI resources — read the linked PDF in the article for more info.
Benjamin Tissoires, a Red Hat/IBM employee and GCP competitor, mentions creating their own K3s on Equinix was “painful” compared to GKE.
If X.Org didn’t have free resources with Packet I’m sure the monthly costs and benefits of hosting their own Kubernetes, Gitlab, and object storage would be very different.
Given the examples in this next article I completely understand why the author doesn’t like environment variables for configuration.
I have different examples from my own experience and absolutely love environment variables for configuration for command line tooling — I mostly dislike them for web application configuration.
The entrenched nature of environment variables in Linux and Unix for basic functionality like
USER make me know fighting environment variables is a losing battle unless, maybe, you’re using Windows locally and on your servers.
Nibble Stew: Never use environment variables for configuration
Suppose you need to create a function for adding two numbers together in plain C. How would you write it? What sort of an API would it have?…