The Space Merchants by Frederik Pohl

This 1952 book holds up well and the marketing dystopia of consumerism hits close to home, 4/5 stars.  Fun.

2020 Week 6 Dev-Ops Scouting Update

I have decided to post my dev-ops musings and scouting on this public Internet blog instead of internally where I work because there is nothing here that is specific or proprietary to my employer and because a few friends have asked for my thoughts.  I welcome all feedback, especially bad (criticism).

TL;DR

• Gene Kim hawks his new book The Unicorn Project on the Ship Happens podcast

• Accenture's Markos Rendell wrote a summary of  Team Topologies (slides here)

• Rick Branson explains why we should never count bugs / incidents

• Great talk on Terraform without the mess by James Nugent, one of the Terraform authors

• Control costs for no-ops (Google cloud functions, Amazon lambda) presentation

• Here is a short deck about fun and infrequently used features of YAML

• Netflix has open-sourced the riskquant python library for helping you quantify risks

• ap4k has rebranded itself as dekorate and is in use by some teams where I work

 #

I assume everyone knows that all software and services always takes on the design of the organization that ships it.  Features and menu hierarchies in user experience, and micro-services decomposition always align to the shape of the organization that produces them.  This phenomenon is known as "Conway's Law." Gene Kim, in his new book, explores other such phenomena and gives some prescriptive device for creating a high-performing engineering team.  Much of the book is fluff and common sense.  But there are numerous counter-intuitive phenomena and some good easy-to-implement practices.

 #  

On the topic of organizing a high-performing team, a pair of dev-ops authors wrote another interesting book recently on "cognitive load" and org structures that optimize for the success measures of your product.  The slides from their presentation in October 19 are very approachable.  The book summary by Markos Rendell is dry and comprehensive.  The book itself has some important concepts and should be skimmed by senior leaders in a position to design dev-ops organizations.

 

 # 

Teams will always "game the system" when their success is measured by bug counts or incidents. If the goal is fewer bugs and fewer incidents, they will go to great lengths to hide their bugs & incidents from tracking.  If the goal is "yield" (ratio of bugs we find before customers find them to the number of customer-reported bugs), then engineers will stuff the bug tracking system with trumped up tick-tack P6 bugs.  Reactive support organizations will push every 30-second bit of customer interaction through their ticketing system and demand more headcount because of the flood of tickets.
Don't count bugs or incidents. Just don't! "Counts" is the wrong single-number summary.  Instead, consider measurements from the customer's point of view (service level indicators, SLIs).  Severe, ship-stopping or money-losing bugs or incidents should be aggregated and combined with a few other measurements into Management's desired single-number summary.

“What can be counted doesn’t always count, and not everything that counts can be counted.”

           — William Bruce Cameron.

 #

Terraform has evolved rapidly; James Nugent believes we should apply the "Composition Root" software pattern to factor our Terraform modules.  In a recent talk he makes very strong and convincing arguments, especially in light of security and separation of concerns.

 #

The reason you are using serverless cloud functions is to reduce operations cost to zero (no-ops).  You were wise enough to realize that over 80% of the total cost of your software during its lifetime is maintenance and operation.  Now you are looking at customer experience and that hefty public cloud bill with an eye on reducing latency and cost-cutting.  How can you further reduce the cloud function costs?  This presentation explains where to look.  Hints: Don't use Java or a JVM language if you can avoid it.

 # 

A good craftsman understands the breadth, depth, and capabilities of the tools she uses.  Learn and use more of YAMLs interesting features by reading this fun deck.

 #

I have frequently tried to explain risk analysis and prioritization to people without much success. Netflix has open-sourced "riskquant" (get it?)  a python library for risk people to do risk analysis. It's not just financial services institutions that need risk analysis.  Software and service failure risks have hefty economic impact as well.

 #

 



Dekorate generates your kubernetes (k8s) configurations for you when you include a dependency in your Java classpath; you can customize your k8s config by setting an annotation or application property in your code.

Galaxy's Edge: Legionnaire by Anspach Cole

I am enjoying the series, character building, and close combat, great mindless airplane reading, 4/5 stars.

Starship Congress 2019: Bend Metal by the Planetary Society

Great reporting and interviews in an extended podcast by the Planetary Society on the 2019 Starship Congress, 3/5 stars.

A Peace to End All Peace: Fall of Ottoman empire and making of modern middle east by David Fromkin

Extremely informative, well-written, very depressing.   The "great powers" are much more evil and incompetent than anyone could imagine.  4/5 stars.

Walking to Aldebaran by Adrian Tchaikovsky

Interesting horror / sci-fi cross-over story, well-written.  4/5 stars.

Our Mathematical Universe by Max Tegmark

Max Shapiro (Tegmark) writes better for a popular science audience than Roger Penrose.  But having just read Cycles of Time, I am wondering how Tegmark's very odd theory at the end accounts for the second law of Thermodynamics.  The end of Tegmark's book is slightly off-topic & very depressing but the entire book is very well-written, worthwhile, and approachable by a lay audience (like me) 4/5 Stars.

Breakaway by Joel Shepherd

I am starting to like this series as much as the Spiral Wars series. Loved the politics, 5/5 stars.

What's Next with Containers?

Chris Hickman speculates about the future of containers in his blog this week with a nominal and partial tour of virtualization directions.  He touches on my favorite concept of unikernels in containers.  I have a different point of view from Chris' but I think his ideas are more mainstream.

Why Unikernels? (The application is the container!)

I am very passionate about elegance and simplicity in Software Design and in software service security, I believe there is no attack surface like no attack surface.  That is, If you remove everything from your container that can be attacked, you are more likely to be secure than if you bring all of the attack surfaces of a full-blown kernel and operating system.  And even if you are compromised, other microservices should be protecting themselves from you (authentication, parameter checking). Further, there is almost nothing in your unikernel the attacker can use to attack the rest of your microservices ecosystem.

Obviously it is more difficult to debug complex microservices to discover why they are failing in production if there are no helper tools and capabilities in the container.  But an instrumented services mesh can enable "playback" payloads and traffic for a non-production version of your microservice to diagnose your problem.  And, removing complex components can prevent these useless resource wasting elements from interfering with your service; so bugs frequently become shallower (all of the bugs are yours).

However, coders are lazy and will prefer to have convenient shell access to their containers running in production so that they can debug under live traffic circumstances.  And, most developers prefer to bolt on convenient tools, libraries, deep stacks, and monolithic resource hogging pieces to their run-time environment because they perceive it is faster and easier to copy/paste a few annotations or changes into a larger software monolith. Therefore I am pessimistic we shall see a rise in Unikernels outside of environments where security is important and leadership understands the value of simplicity.

Heart of Vengeance by Glynn Stuart and Terry Mixon

Rebel with too many causes, interesting universe with "The Expanse" like solar system factions competing and fighting. 3/5 Stars.