Cobra Outlaw by Timothy Zahn

The story trundles along with more parallel plots, intrigues, and too many people from the same family, 3.5 Stars.

Four Words: Reliability, reliability, reliability, reliability

Observability and learning are emerging as the big themes in site reliability engineering (SRE) at the moment.  The tools vendor FireHydrant (Robert Ross) synthesises and summarises the concepts into where we should put our emphasis in 2021.

How did things go right?

I somehow missed Ryan Kitchens' awesome talk at SRE-Con. Ryan's talks are always spectacular and controversial. But this one is especially fun.  He goes deep into how we communicate and has lots of references for further reading.  The biggest take-away is that we should concentrate more on learning and less on process. I especially love his concept of a 2-D timeline that describes many parallel factors in what went right and what went wrong.  Don't miss this one!

Extreme Ownership by Jocko Willink & Leif Babin

It is a little hard to get past the testosterone haze and combat metaphors but the concepts are  applicable to leadership in very many contexts, including business & work.  3/5 Stars. Interestingly a few indirect messages emerge from their battle examples:  

1 - The authors disrespect the Iraqi military elements allied to the USA

2 - The authors have great respect for the "Muj" (Mujahidenn مجاهدين‎) against whom they fought, despite hating the Muj's barbarity, brutality.

konveyor & peloris

Over the weekend I was referred to the konveyor.io Kubernetes evangelism society and movement, and discovered those folks develop a very interesting tool called peloris.

Peloris is part of Redhat's approach to "metrics driven transformation."

and is a drop-in set of grafana dashboards for Redhat's openshift clusters.  It appears the concepts from the book Accelerate book concepts are gaining enormous momentum across the software industry.

I wish our teams could use true open source tools at my day job.

Ready Player 2 by Ernest Cline

It's a fun sequel with great 1980's and 1990's pop culture video games and movie references, geeky D&D players, and more of the same drama as the first book.  The big idea, awe, wonder of advanced tech and AI are far fetched (quite bad) but the story is very entertaining, 4/5 Stars.

web page load performance measurements with Lighthouse

I stumbled across this blog entry about improving web page performance in which the authors write about the "Lighthouse" calculator.  Apparently web developers all run the calculator in the Chrome developer tools or node.js on their workstations.  But you can also use the pagespeed insights portal to run the tool on public Internet pages from several regions.  I, of course, ran the tool on some of my company's public pages and we do quite well, scoring in the 70's and 80's in most categories.

ARM for server workloads?

The folks over at Percona discover some interesting results using Amazon's new ARM processor offerings.  Intel, of course, has another generation of processors that will blow the doors off of all competitors; but in the meantime, if you run PostgreSQL on AWS, consider moving to their ARM instances.

Civil, respectful, political discourse

I normally try very hard not to get distracted by national politics.  This video is an exception worth sharing.  One one side of our national politics we have people who fear a "great purge," where our big-tech companies and winning political party are "using their power to repress, silence, ruin and criminalize tens of millions of private citizens for the crime of opposing them politically."  And on the other side of the debate we have leaders vigorously enforcing the rule of law to prosecute those who aid and abet criminal activities.  Professor Swire explains how and why we should reconcile and ends his interview with these quotes from Abraham Lincoln:

A government of the people, by the people, for [all] the people should not perish from the earth.

With malice toward none; with charity for all; with firmness in the right, as God gives us to see the right, let us strive on to finish the work we are in; to bind up the nation's wounds; to care for him who shall have borne the battle, and for his widow, and his orphan—to do all which may achieve and cherish a just, and a lasting peace, among ourselves, and with all nations.

No Rules Rules by Erin Meyer and Reed Hastings

Although this book is not applicable to my "day job" because I do not work at a company that is in any way like Netflix, it was still fun and entertaining.  Yes, people at Netflix live in fear of getting fired. Yes, your colleagues at work tell you all the time about your mistakes.  Yes, you are very stressed out about big decisions.  But the authors defend this high-pressure, high-stress daily work life as a good way to run a business. 4/5 Stars.  THe book is worth your time to skim through it.

Alert Fatigue webinar on Jan 14

This interesting webinar is about how to reduce alert fatigue.  11am Europe time.

sketch notebooks to learn Google Cloud Platform (GCP)

Priyanka Vergadia has collected a bunch of docs about how to use GCP offerings that are in the fun "sketch notebook" format. 

FOSDEM 2021 is virtual on Feb 6 & 7

Here are the FOSDEM21 tracks for Feb 6 & 7.  Find the free open source software you love and visit the virtual session to chat with other like-minded coders.

cloud providers as a framework

(total cost of ownership (TCO) is dominated by maintenance; public cloud providers maintain their components and are less expensive in total cost)

Amazon IBM, Google, and other cloud providers have evolved their offerings to the point that they must now be considered application development frameworks, especially with cloud functions and no-ops.  The folks at Galvanize walk us through the evolution of cloud providers using AWS as an example and the inevitability of serverless and no-ops, forcing us to conclude that our cloud providers must now be considered software development frameworks.

automated upgrades?

Remember when Python-3 was released?  Guido von Rossum shipped the release with an automated upgrade tool called 2to3 that would translate your Python-2 code into Python-3 syntax automatically.  Similarly, Rob Pike released the v1.0 version of Go with a command called fix that would translate your v0.9x versions to v1.0 syntax.

James Abley is proposing that all package maintainers should ship completely-automated upgrade tools for each release of their packages.  Minor-release number changes (non-breaking changes) are already straightforward and many tools exist to help change manifests, build & YAML files.  But major releases require transformers that actually change your code.  It is a cool concept and appears feasible at first glance.  Everyone needs them.  The total available market is huge.

The Time Wanderers by Boris & Arkady Strugatsky

This tightly-woven, well-written has fantastic literary descriptive writing.  But the reader must concentrate to keep all of the nuances, clues, and innuendos aligned.  It is hard and slow going for me. 3/5 Stars.

The Human by Neal Asher

Interesting conclusion to a thrilling space opera.  The evolution of the magic system is unappealing, unscientific, and inconsistent but the story line was fun and entertaining, 3/5 Stars.

strong types in APIs?

Sometimes we want to write fast, hacky code in languages with weak typing (perl, python, javascript), or lazily put data into "string" in Java.  Other times we want strong typing, better observability, and easier maintenance.  The folks at buf are trying to make protocol buffers as easy to use as json.  They make some strong arguments for stronger types in our APIs.

great introduction to message queue concepts

Sudhir Johnson has written a great summary of message queue systems and considerations.  It's worth skimming if you have not considered dead letter DDOS attacks or poison pill messages.

cost transparency for developers

Lawrence Jones describes a somewhat esoteric and counter-intuitive example of speed and cost savings teams can gain by applying compression in their own software components instead of relying on underlying libraries and components to apply compression where appropriate (e.g. Avro). However the deeper insight is for large organizations where developers are frequently divorced from the true cost of running and operating their software.  In my "day job" we run co-located data centers and on-premise systems, and large scale "IT" manual operations. "Ticket" and manual task mentality and culture dominate operation of the software services developed.  Large IT operations teams control cost by limiting capacity, which in turn is manually managed, allocated, and provisioned by humans via tickets and manual tasks.  The unintended consequence of separating capacity all the way down to the node and sometimes even hardware-level without auto-scaling is enormous over-provisioning -- most of the capacity is under-utilized because there is no auto-scale down of VMs, memory, or storage.  A more-sinister consequence is that the over-constrained teams start to "think small" and limit the capabilities of their software design because of the assumption that capacity is so tiny and constrained.

The remedy, of course, is to show developers and their product teams the real cost of the network and computing resources their software consumes when it runs.  No matter how much waste and bloat the manual operations infrastructure teams add to the cost, clever software designers will be able to design software within these constraints to keep their services profitable.  Clever developers can use APIs available in "ticket" systems to write software that programs humans in natural language and enables auto-scaling within a pool of quota, albeit with extremely long latency.