Category Archives: devops

It’s been a little over six months since Kubernetes for Developers hit the streets. It has been interesting to see the uptake, and where the holes have been from what I first envisioned. The metrics I receive on book sales are unfortunately wan – nothing so effective as a daily metric for either sales orContinue reading “Lessons from Kubernetes for Developers”

Intermittent issues, or bugs with intermittent reproducibility, are some of the most frustrating issues to track down. In past experience, these kinds of bugs are often multi-thread race conditions or a failed assumption about something that’s happening asynchronously that you thought was synchronous (or just expected to happen quicker). Tracking these down is immensely timeContinue reading “Stochastic testing and developer tools”

It is conventional wisdom (has been for years) that you don’t want to ship your tests with your code. When I was doing quite a lot of build engineering, there was always the step in creating whatever packaging that separated the test code from the production code. Maybe that was excluding packing some java classes intoContinue reading “Ship tests with the code”

A bit over a year ago, I wrote out Six rules for setting up continuous integration, which received a fair bit of attention. One of the items I called out was the speed of tests, suggesting to keep it to around 15-20 minutes to encourage and promote developer velocity. A few weeks ago, the team at SemaphoreCI usedContinue reading “Using 3 Tiers of Continuous Integration”

Last week, the CoreOS team posted a benchmark review of etcd 3.0 on their blog. Gyo-Ho Lee was the author, and clearly the primary committer to the effort – and he did an amazing job. First and foremost is that the benchmark is entirely open, clear, and reproducible. All the code for this effort isContinue reading “Benchmarking etcd 3.0 – an excellent example of how to benchmark a service”

Some background before I get into what I see Kubernetes community doing. When I say “Full loop performance automation”, I am talking about scaling up and down services and resources in response to application metrics – often response time, but many different dimensions of metrics are interesting for useful solutions. It is a sort of holy grail for modern applications; it’sContinue reading “Kubernetes closing on full loop performance automation”

I made a conscious choice to use the phrase “should we…” when asking a question about technical implications rather than “can we…”. The difference is subtle and very significant. There is a lot of self-pride in being able to solve the problem in the engineering community. Using probably too hasty a generalization, culturally its a bundle of people who loveContinue reading “Can we versus should we”