For the longest time I’ve thought that we were doing container images “wrong”1.
Container images always felt so unnecessarily BIG.
Yes, there are lots and lots of ways to make images smaller, but still fundamentally they are shipping a root filesystem around. “Works on my machine!” Let’s ship the machine then.
Multi-stage builds came around and solved one class of bloat problem. At least we don’t need to embed lots of intermediate layers.
High Performance Computing (HPC) has always been interesting to me, ever since the first time I read a Beowulf cluster joke on slashdot.
High performance interconnects, huge storage, hundreds of nodes all working as one, the Top 500 list, what is not to love?
I’ve only dabbled with the HPC world a little bit in my career, so this blog post is NOT written from the perspective of an HPC veteran.
This blog post falls into the “I hope it is useful to someone” category.
I recently had the pleasure of figuring out how to restore a Cru RTX800-TR RAID array that was suspected to be inoperable.
This thing is a beast, and worth saving.
This was a personal favor for a friend, not related to work.
This is a technical write-up of what I did.
Specs Product: RTX800-TR Interface: Thunderbolt up to 10 Gbps bi-directional Drive Types Supported: 3.
Stealing a poker metaphor, there is an important lesson that senior engineers exercise when working in tech: Knowing when to Hold ’em, Fold ’em, or when to walk (or run!) away.
> You've got to know when to hold 'em, > know when to fold 'em, > Know when to walk away, > know when to run. > You never count your money > when you're sittin' at the table. > There'll be time enough for countin' > when the dealin's done.
I don’t normally write blog posts that regurgitate information from normal documentation, but this particular subject irks me.
If you are running an internal Kubernetes (k8s) platform, you owe it to yourself to make sure there is nothing external to your platform determining your reliability.
You could ask yourself: How many internet dependencies do you have to start a pod? Should be zero, right???
If you use stock k8s, you might be surprised to know that each of your k8s nodes is actually reaching out to registry.
Five years ago I wrote a blog post against Kubernetes sidecars. I wrote that in response to the early days of sidecar containers becoming in vogue, and in response to Airbnb’s talk demonstrating the 7 containers they need for service discovery.
At Yelp, we held off on running sidecars at all, and stuck to the single-container model on k8s for a long time, relying on host daemons for almost everything extra.
In part 1 I talked about why I don’t like sidecars generally. In this part 2, I want to look at why we don’t use good ole libraries instead.
I Wish Libraries Were Easier to Make and More In Vogue Perhaps remind yourself: Why do we have sidecars in the first place again?
There are usually a couple of answers:
Separation of concerns: keep the app small and externalize functionality to the sidecar Independent deployment lifecycle: upgrade sidecars independently of your main app Independent resource/request limits: Clamp your sidecar to a given amount of RAM/CPU Let’s look at each of these reasons more closely.
I recently bought some motorized blinds from SmartWings. I’m working towards my dream home setup, with really good thermal qualities and a sane amount of automation.
In this case, I want every window to have a really good motorized blind, and I never want to have to think about when to open and close them. Those blinds should have the type of honeycomb thing so that they keep the heat in during the winter, and can stop incoming heat in the summer.
There are a couple of infographics out there for “Latency Numbers Every Programmer Should Know”: 1, 2, 3.
These are great, but I wondered: how up to date are they?
Sure, they are meant to be general ballpark numbers, but there can be a huge difference between my five year old overheating laptop and a cutting edge server.
What are the latency numbers for my computer in front of me?
In this blog post, I’m going to look at some init systems, but not very thoroughly:
nitro tini dumb-init pid1 supervisord runit s6 daemontools systemd What Makes it a “Container” Init System? A tool can be considered “container” (PID1) ready if it can do two things:
Handle signals as PID1: In Linux, any PID1 process won’t automatically get signal handlers it hasn’t registered for. If you don’t do this, your process will not respond to signals as expected, and you will have long and non-graceful shutdown time.