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.

"Dev complete" is neither developed, nor complete.

Charity Majors published a great rant about slow testing and common CI/CD pipeline antipatterns.  The core of her analysis and prescriptive remedies struck a chord with me because in my day job, developers will claim they are "dev complete" for work that customers won't experience for weeks because of slow, centralized, large-scale CI/CD pipelines and bureaucratic, inefficient processes.  Yes, 15 minutes instead of three weeks is an attainable goal.

Wayward Galaxy by Jason Anspach & J. Chaney

Not good, 2/5 Stars.  Inconsistent, terrible plot holes, lousy science.  Good close combat.

Permafrost by Alastair Reynolds

Good story with compelling characters, great, consistent magic system and intriguing mystery.  4/5 Stars.