Why a private cloud is an exercise in futility

Every corporation and enterprise want a private cloud these days. The arguments vary from company to company, usually revolving around security, cost, independence and strangely enough — reliability. I could argue that given the track record of most enterprise IT departments it seems dubious they can improve even one of these parameters compared to a public cloud, but I won’t. It turns out there’s no point refuting those arguments, because, and I cannot emphasize this enough:

You are going to end up using a public cloud, even if it’s more expensive and less secure, less reliable and less independent

[Read More]

The Ironies of Reliability

Reliability promotes failures. Failures promote reliability When a system is reliable long enough, production pressure causes the operators to drive the system harder; Over time operators become less careful as the trauma of the last failure wears off. More workload is applied, new features introduced, etc, until the system trails again into the danger zone (e.g. high load once thought to be dangerous), sailing through smoothly this time, thus boosting the confidence of operators in the robustness of their system. [Read More]

Bash is a thought pattern

A new scientific truth does not triumph by convincing its opponents and making them see the light, but rather because its opponents eventually die, and a new generation grows up that is familiar with it. Max Planck, Scientific Autobiography

As I became more involved in workshops and training, I observed many people coming from old-school sysadmin backgrounds struggle with the moderns tools and methodologies that the SRE and DevOps movements are promoting. I often wonder why it so hard for some of them to learn the “new ways”. I’ve heard many people comment (often disrespectfully) that these difficulties are due to lack of “technical skills” - frequently citing poor programming abilities. While I agree this may be a real problem for some people, this explanation is far from being sufficient.

[Read More]

The most important principle of managing a software organization

During my years of consulting, I’ve run into many managers (in enterprises and startup companies alike) who just didn’t get this whole “technical debt” thing. You’ve run into those managers too, I’m sure - the kind of manager who issues pressing deadlines, marks bug reports for left-over time (which never comes), relies on VMotion or fancy SAN for high availability, refuses upgrades because of “risks” and urges you to “stop wasting your time listening to tech talks and go write features”. I’ve even heard managers tell engineers “don’t waste your time learning this framework, just write your system with it” (!!!)

I’ve often wondered - why is it so hard for them to get something that is so painfully obvious to the majority of software engineers?

[Read More]

How many startup engineers does it take to change a lightbulb?

2 - a technical co-founder and a business co-founder. Since they don’t have enough money for proper lightbulb they use an old socket and lightbulb they found in the garage and since they don’t fit the technical co-founder builds a makeshift adapter from duct tape and aluminium foil. This actually works as long as you don’t tilt it too much. During seed negotiations the co-founders break up and the technical co-founder leaves. [Read More]