Good primer for DevSecOps threat modeling

Jim Gumbley, writing in Martin Fowler's valuable web site, gives us a simple, and very-approachable primer for how to do threat modeling in DevSecOps. I had previously not seen the thrilling NotPetya story before and really enjoyed that real-life cyber thriller.

If you are a software developer or DevOps professional and your perception of DevSecOps and information security is simply "minimal compliance with draconian InfoSec policies," you are in for a frustrating experience and you will develop inferior software services.

Arbitrary dates destroy software and service value

Here is an article by "Gandalf Hudlow" from IISM on the failure of date-driven schedules. I have a slightly different perspective that accommodates date-driven schedules but enables the creation of business value.

Some mature software and service industries run on "train schedules" of relatively frequent releases, where the business and customer never know what they will get in each release but they know they will get something at the scheduled release times.  For example, as a user of Google Keep, I did not know when Google would ship integration with Assistant to be able to say, "OK Google, remove milk from my Safeway list." But it was obvious to me that eventually such a  feature would arrive.  Similarly Microsoft sends out monthly patches on the first Tuesday of every month but you never know which updates will blow away all your settings or brick your device.

Many software or services are intended to meet some business goal or innovate in some way that consumers will immediately love, disrupting an entrenched consumer norm.  In these cases, schedule-driven software development always fails to deliver value to customers and results in much more waste than enabling normal software gestation and postpartum iteration until the business objective is achieved.  Across all industries, 70% of software projects fail to produce their intended business result because the specific business purpose of the software becomes schedule-driven.  In these cases I agree with the author.

Exhalation Stories by Ted Chiang

This fantastic collection of short stories finally rose up in my queue. 5/5 Stars.  Very good.

Tinkerers by David Brinn

For a short time in 1982 - 1983 I lived near David Brin in La Jolla (near San Diego) and despite his fame and fortune as a great writer and speaker we have stayed in touch.  David helps me whenever I ask, most recently with my High School curriculum development for applied terrestrial terraforming. (I hope to blog more on that topic in the future).  David wrote a very short, somewhat political graphic novel called Tinkerers that has become available online for free. It's an interesting perspective on Yankee Ingenuity and US culture. 4/5 Stars.

in case you need even more overwhelming medical data about exercise

Benefits continue to burst out into new categories of how we measure health. 

Automatically delete your stale feature flags

If you use feature flags extensively, it is likely you have a large number of stale feature flags clogging up your code base.  Those back room boys over at Uber have released a useful dead-code deletion tool they call "Piranha" that lints your code for dead feature flags and refactors the code to eliminate the flags.  Slick.

Learn Linux

At a recent Large Installation Systems Administration (LISA) conference I used to attend in the 20th century, one of the speakers gave an introduction to some useful Linux and Bash concepts with examples.  If you are an absolute beginner you will get a lot out of it.

Among the many annoying and self-destructive features of my personality is my tendency to assume everyone knows as much or more than I do about some topic we are discussing, or, more frequently, that everyone remembers everything from all of their college courses.  I noticed at work recently, that my use of pipelines and xargs in a command line freaked everyone out and my suggestions about better bash wrapper script programming was way above the heads of my audience.  

Based on peer feedback about one of my mentees, I strongly suggest that the mentee learn Linux and Bash, to become facile at command line typing, as the skills will be useful through more than one career.  The mentee diligently took courses and was promoted.  I was thrilled when my mentee privately relayed that one secret of success was proficiency at Bash and Linux.

A new volume of ThoughtWorks' "Tech Radar" series

There is something for everyone in the new "Tech Radar" series.  ThoughtWorks calls it "an opinionated guide to technology frontiers," it has some good information on tools and process.  It's easily worth a skim through the table of contents.

Windows Package Manager -- Linux assimilation continues

If you are as confused as I am by the PowerShell commands to manage Windows applications and their dependencies, this preview of "winget" the forthcoming Windows package manager will be a welcome addition to Windows.  I have already replaced my terminal with Windows' new, awesome terminal program in which I run bash on Ubuntu.

Microsoft continues its predatory  "embrace and extend" Linux assimilation, creating promising, tantalizing but not-quite-good-enough proprietary alternatives to basic Linux features and capabilities.

NoOps, DevSecOps, Cloud Functions, Serverless

I just stumbled across Tom McLaughlin's 3-part series on serverless.: (part-1, part-2, part-3). Tom was bitten by the NoOps Serverless bug because of its promise to relieve the pain of managing people and process associated with the mundane and painful 24x7 operation of web services.  For Tom, there is no need to consider alternatives.

Yesterday, I had an hour-long debate with a very-intelligent mentor and friend about the economics and total cost of ownership for NoOps.  There are many devils in the details of each business and each situation.  For small and non-tech businesses right now, the public cloud providers charge too much for each API call of their libraries in most serverless settings.  If your business requires predictable, high-availability services with neither distractions nor overhead of consultants or employees who "operate" or develop your operations (DevOps) then the TCO model of maintenance favors serverless.  If I were a consultant, I would develop a complex TCO spreadsheet model and questionnaire to enable companies to make the right choice now and revisit their choices as public cloud costs change.  But if you are a scrappy small business where everyone wheres "many hats" (works in many different roles), it is less expensive in the short term to burn all the labor hours and do the DevSecOps yourself.  If there is clear opportunity cost associated with burn-out and the labor of this work, the economics will still swing the other way and you should go NoOps and Serverless all the way down.