kind, gentle introduction to services mesh concepts

Here is a fantastic and simple introduction to services mesh concepts with a comparison and review of service mesh software currently available.  TIMTOWTDI.

OAUTH v2.1 will mitigate some security holes

Teri Rachel explains why and how we should all follow Amazon's better practice of forbidding Implicit Grants in OAUTH and require proof key for code exchange (PKCE). The Internet is becoming less and less safe.  We all must spend more time and effort defending ourselves.

fear of true continuous deployment is very expensive

Almost two months ago, I read this interesting post by Charity Majors about the cost of our slow CI/CD pipelines.  I was meaning to summarize and write about that article here but got distracted.  Gareth  Rushgrove pointed me at this fantastic google sheet calculator that actually quantifies the dollar value.  Plug in your own assumptions and you get a first-order approximation.  In my particular case, the opportunity cost of delaying pain relief to my suffering customers is much higher.

extending software package data exchange into a bill of materials

In my, ahem, somewhat motley career in software development I recall the "Total Quality Management" (TQM) movement in the last millenium that evolved into ISO9000 and other horrors.  The recent trend in increasing successful and devastating cybercriminal attacks using software supply chains has resurrected a concept from TQM we called the bill of features (BOF) and bill of materials (BOM).  The BOF contained the customer-visible changes we were shipping to our software and the BOM was an exhaustive list of components in the software we shipped.  In our modern version control & configuration management systems, as well as their continuous integration and continuous deployment tools, we have most of the artifacts and tracking information;  we have automated away the tedium of BOF/BOM using tools and "git-ops" methods (oppa gitops style!).

In a recent medium post, Dr. Rispens suggests we use what he calls "blockchains" along with our package management and build systems to secure the bill of materials from supply chain attacks.  What he really means is that we should use a distributed ledger to store package component signatures to detect and prevent supply chain attacks.  Blockchains are overkill for this purpose.  I don't understand how this method would overcome source code submitted by bad actors that is merged into official component releases, complete with signatures, as was accomplished in the ssh1 open-ssl exploit or the recent node.js vulnerability.  BTW: some folks speculate the open-ssl exploit gave rise to boringssl.

Despite my criticisms, I think this idea does have some merit. Malicious source code submissions do provide a few forensics for the white hats to start characterizing the black hats and possibly identifying them.  The cost is low and the increase in transparency is desirable.

Hanlon's Razor and the Negativity Trap

In addition to using the books and writings of Frances Frei on Trust, most of us can improve our joy, engagement, and productivity at work by establishing habits that help us overcome our negativity and pesky cognitive biases that prevent effective collaboration.  A friend pointed me at this jesuit priest's analysis of "negativity poisoning" in relationships as well as this excellent, more-serious, deeper, and extended version of an aphorism called Hanlon's Razor: "Never ascribe to malice what is adequately explained by stupidity."  I frequently quote Hanlon's Razor but have never considered how broadly applicable it could be overcoming some of our serious cognitive biases at work and in our personal relationships.

ArgoCD simplifies multi-cluster k8s management

Among the interesting challenges infrastructure teams, site reliability engineering teams, and DevOps developers face when developing or factoring the deployments of their containerized microservices workloads is designing resilience to failure of the node cluster on which the microservice pods are running.  If the k8s masters stop working, or the entire  namespace fails (a frequent occurrence where I work), your wonderfully resilient system will become unavailable.  Global load balancing with multi-regional and multi-cluster / namespace redundancies can mitigate this problem, but adds complexity and creates new types of cascading failures such as flapping, undetected service failures, and false alarms.  Even Amazon Fargate and Google Cloud Platform autopilot are not yet immune to these problems, though AutoPIlot does have extremely high availability in my personal testing.

A simpler, and more-elegant abstraction that solves this problem is ArgoCD. I am embarrassed to admit that I first heard of ArgoCD when this silly video came out (the ArgoCD reference is about three minutes in).  Here is a very gentle, 5-minute introduction to ArgoCD concepts that can help get you started quickly. 

augmenting our bodies

In his first book, More than Human in 2010, our buddy Mez took us on some great thought experiments about the promise of brain-enhancing drugs and body-enhancing prosthetic devices such as exoskeletal limbs.  We are starting to see early prototypes of concepts beyond simple enhancements and towards additional functionality.  The third thumb project is one example.

Do YOUR Job first

Charity Majors posted some more good career advice in her blog on 2021-03-07.  It's about focus and getting YOUR job done first, before you get distracted by all the other important work that is peripheral to the mission and purpose of your own job.   Many of us are attracted to shiny, new objects and are easily distracted.  Other folks are opportunistically looking to gain credit or glory unrelated to their job.

In 2016, on their way to their fifth (and best) super bowl championship, the New England Patriots cut one of the best players and athletes on their team, Jaime Collins.  Collins is a fantastic player.  Why was he cut?  To function effectively and win as a team, each person must do her own job first. Do YOUR job.

Why are all CEOs of trillion dollar companies originally software engineers?

The International Institute of Software Management (iism.org) features a relatively long but worthwhile analysis of why there are so many successful CEOs who were developers. and guidance for leaders who started out as developers for applying their skills to wealth creation and success.

Better Code Review Practices

I recently reminded folks at work that it sometimes helps to look back at the issues we put into our code in the last 3-9 months.  We can formulate a short (3-5 item)  bullet list in a checklist.  The list is the 3-5 most-frequent types of errors we made in the recent past. The checklist reminds us during code reviews  to look for the same type of bug in  new code while we  are reviewing the new code.  Of course, the checklist must change, so there is effort in re-reviewing the last 3 months of bugs 4x per year and updating the checklist.  If all the bugs we put in are unique and there are no visible patterns, this effort is not worth doing. This idea comes from Steve McConnell's book Code Complete.  He calls the process "checklist driven code reviews" and he published a (long) list of common patterns of issues as examples.  Steve's book and approaches are quite old and modern integrated experiences and tools enable more, better refactoring, as well as some new difficulties for reviewers.

Over the weekend, I stumbled upon this interesting post from Mike Lynch with very-useful advice for how you should formulate your pull requests so that reviewers can more-easily review your code.