Makura no Soshi

On cloud computing and vendors …

• Multi-Cloud Is a Trap – Brave New Geek
  It comes up in a lot of conversations with clients. We want to be cloud-agnostic. We need to avoid vendor lock-in. We want to be able to shift workloads seamlessly between cloud providers. Let me say it again: multi-cloud is a trap.
• The Private Cloud Has Failed Us – Chuck’s Blog
  Perhaps there is no deeper disappointment in life than when a cherished concept fails to produce the desired results. Such is the case with the industry’s notion of private clouds. I’m throwing in the towel, walking away – and cursing under my breath. It’s a failed concept.
• Google Cloud Platform – The Good, Bad, and Ugly (It’s Mostly Good) – Deps
  For companies that don’t want to spend a lot of time learning and dealing with the complexities of AWS, I recommend looking at Google Cloud.
• How do you explain the unreasonable effectiveness of cloud security? – High Scalability
  With the enormous attack surface of cloud providers like AWS, Azure, and GCP, why aren’t there more security problems? […] Dr. Byron Cook gave an enthusiastic talk on Formal Reasoning about the Security of Amazon Web Service.
• CloudWatch Is of the Devil, but I Must Use It | Linux Journal
  When you take a hard look at CloudWatch’s complete failure across all 14 Leadership Principles, you wonder how this product ever made it out the door in its current state.
• Jerry Hargrove | Cloud Diagrams & Notes
  Various diagrams of AWS services.
• Re:Invent 2018 Re:Watch Helper
  On the youtube channel, it can be hard to search by description or session level. Try these pages to help you navigate.

On computer and programming history …

• What is Code?
  Software has been around since the 1940s. Which means that people have been faking their way through meetings about software, and the code that builds it, for generations.
• Learning BASIC Like It’s 1983
  In 1983, though, home computers were unsophisticated enough that a diligent person could learn how a particular computer worked through and through. That person is today probably less mystified than I am by all the abstractions that modern operating systems pile on top of the hardware.
• How Lisp Became God’s Own Programming Language
  Lisp transcends the utilitarian criteria used to judge other languages, because the median programmer has never used Lisp to build anything practical and probably never will, yet the reverence for Lisp runs so deep that Lisp is often ascribed mystical properties.
• Should you learn C to “learn how the computer works”?
  I’ve often seen people suggest that you should learn C in order to learn how computers work. Is this a good idea? Is this accurate?
• C Portability Lessons from Weird Machines
  In this article we’ll go on a journey from 4-bit microcontrollers to room-sized mainframes and learn how porting C to each of them helped people separate the essence of the language from the environment of its birth.
• The Coming Software Apocalypse
  A small group of programmers wants to change how we code—before catastrophe strikes.

On teams and their problems …

• The First Question to Ask When Building Teams – Is This Really a Team?, byStefan Lindbohm and Viktor Cessan
  You might assume that if you put together a bunch of people and give them a goal, they’re a team. But that’s not how it works.
• SRE: The Biggest Lie Since Kanban | the agile admin
  So doing SRE can – and in many shops does – mean doing nothing new. You just call your existing ops team SRE and figure you’re done.
• Kobayashi Maru Management – Rands in Repose
  A Kobayashi is a system failure because the usual means of getting important work done in a group of humans failed spectacularly.
• Your app is an onion: Why software projects spiral out of control
  You start with the best of intentions. You hire a developer to build out your startup idea. But almost every week, it feels like the project needs tweaking. Features start creeping in, and the scope slowly expands. It’s as if the project has a life of its own, and is trying to destroy your life.
• Why Are Enterprises So Slow? – zwischenzugs
  In this article I want to explain a few things about enterprises and their software, based on my experiences, and also describe what things need to be in place to make change come about.
• lenazun/working-remotely
  Working remotely sounds great. We think we’ll save ourselves the commute and we’ll be able to flexibly weave in and out of work and home life. In reality, work takes a different shape when there is no office, and we’re all in different environments trying to connect to other humans. […] These are some of the things we’ve learned while working remotely

I recently updated my small mailserver and finally configured DKIM. But another change was easier and still had more impact: installing postwhite. This little tool takes a list of mail domains, then uses their SPF records to derive a list of their outgoing mail servers, then writes this list into a postscreen whitelist configuration. The current default setting contains 43 domains and generates a whitelist with nearly 2000 lines (each containing an IP or subnet). Everything is nicely scripted and can run as a nightly cronjob.

This setup eliminates my biggest problem with greylisting, which is Office356. Their combination of long email resubmit intervals and using multiple cluster servers for delivery attemps always lead to long delays before I received email from Microsoft or any company using Office356. (BTW, I really like greylisting but this is its biggest design problem: it works for single SMTP servers and enforces certain behaviour, but does not and can not consider clusters.)

More about microservices and Docker …

• Serverless Microservice Patterns for AWS – Jeremy Daly
  Since I work with serverless microservices all the time, I figured I’d compile a list of design patterns and how to implement them in AWS. I came up with 19 of them, though I’m sure there are plenty more.
• 10 Tips for failing badly at Microservices, by David Schmitz
  If you mind my tips, then surely you will fail at Microservices and your boss will never again try to move away from your beloved vintage monolith.
• The Death of Microservice Madness in 2018
  Microservice madness goes something like this:
  Netflix are great at devops.
  Netfix do microservices.
  Therefore: If I do microservices, I am great at devops.
• Services, monoliths, modularity
  My not-useful takeaway from these reckons is that what you need is modularity, not microservices.
• Microservices Are Something You Grow Into, Not Begin With — Nick Janetakis
  Let’s talk about when it might be a good or bad idea to start using microservices. SPOILER ALERT: it’s not the same for every project.
• Revisiting Using Docker, by Gregory Szorc
  When you look at all the options for running containers in 2018, I think it is obvious that Docker – usable though it may be – is not ideal for a significant number of container use cases.
• Docker is the dangerous gamble which we will regret | Lawrence Krubner, Smash Company
  Summary: don’t use Docker, or any other container technology. Use Terraform and Packer instead.

Some computing history …

• The complete history of the IBM PC, part one: The deal of the century | Ars Technica
  One could claim that the IBM PC was not really IBM’s first PC at all.
• The Observation Deck » The sudden death and eternal life of Solaris
  Judging merely by its tombstone, the life of Solaris can be viewed as tragic: born out of wedlock between Sun and AT&T and dying at the hands of a remorseless corporate sociopath a quarter century later.
• Where Vim Came From
  And yet Vim is also a mystery. […] Despite its ubiquity and importance, there doesn’t seem to be any kind of committee or organization that makes decisions about Vim.
• Linux Load Averages: Solving the Mystery
  Load averages are an industry-critical metric – my company spends millions auto-scaling cloud instances based on them and other metrics – but on Linux there’s some mystery around them.
• Living on the Plateau
  Most of us work in an environment of virtual infinities. There may be some contraints out there somewhere, but most of us know we will never bump into them. That’s what happens when you ride Moore’s trains through twenty-eight doublings.
• Wie erkläre ich es meinem Kind: Internet in der DDR / Blog / Privat – Lutz Donnerhacke
  Ich hatte heute ein längeres Gespräch mit einer Journalistin, die fragen zur DDR-Top-level-domain “.dd” hatte. Das Gespräch war lang. Allerdings stellte sich schnell heraus, dass sie zu jung ist, um sich die Realität von vor 30 Jahren vorstellen zu können.

For some reason I wanted to improve performance of a small data driven Python program and tried to parallelize it. These are a few learnings to keep around for next time.

I nearly started with the very basics, defining my own threads as well as task and result queues. But then I found the very useful concurrent.futures module which provides a high-level interface to distribute tasks to both threads and processes.

I still made the mistake to start with threads. Everything worked nicely and the tool ran along with four worker threads — but every thread received 25% of CPU time and the overall runtime did not improve. I realized I had forgotten about Python’s Global Interpreter Lock (GIL).
The GIL basically prevents performance improvement using multithreading (at least of CPU-bound tasks, it is still useful for I/O). More information about the GIL:

• David Beazley: Understanding the Python GIL
  
• Nick Coghlan: Efficiently Exploiting Multiple Cores with Python
  

So I had to switch to multiprocessing instead. The switch itself is really easy because it is nearly completely hidden inside concurrent.futures, I only had to replace the initialization of the ThreadPoolExecutor() with a ProcessPoolExecutor().

But with multiple processes I can no longer share variable values. Everything, including the called function itself, has to be pickled and send to the subprocess.
This required some refactoring, as I had to move the function to the module top-level (as local functions cannot be pickled) and then tried to find a good minimal set of parameters and return values in order to reduce the data transfer between the processes.

I saved my code examples for different concurrent.futures invocations as a gist for later reference: mschuett/concurrent.py

Along the way I also tried the asyncio module for “Asynchronous I/O, event loop, coroutines and tasks”. That one is also quite interesting, but as the name suggests it is focussed on I/O and coroutines in a single thread; functions you need for a network server. For my use case it is not useful, because asyncio does not help to utilize a second CPU core.

• Colin Percival: Some thoughts on Spectre and Meltdown
  While I have not been involved with handling these issues directly, I think it’s time for me to step up and provide both a wider context and a more broadly understandable explanation.
• How Meltdown and Spectre Were Independently Discovered By Four Research Teams At Once | WIRED
  “As far as I can tell it’s a crazy coincidence,” says Paul Kocher, a well-known security researcher and one of the two people who independently reported the distinct but related Spectre attack to chipmakers. “The two threads have no commonality,” he adds. “There’s no reason someone couldn’t have found this years ago instead of today.”
• Myths Programmers Believe about CPU Caches – Software the Hard way
  Such misconceptions are mostly harmless (and maybe even helpful), but can also lead to bad design decisions. For instance, developers can start to believe that they are insulated from the above concurrency bugs, when working with single-core-systems.
• Why Raspberry Pi isn’t vulnerable to Spectre or Meltdown
  Happily, the Raspberry Pi isn’t susceptible to these vulnerabilities, because of the particular ARM cores that we use. To help us understand why, here’s a little primer on some concepts in modern processor design.
• Jens Neuhalfen: Meltdown and spectre explained — for normal people
  This is for “normal people”. With these slides I fill the hole between we are going to die! and white noise. You, the reader, will understand what went wrong, how it went wrong, and why this is bad. I will try to minimise the computer specialists words to an absolute minimum. Promised! (Recording from FrOSCon2018)
• Jon Masters: The spectre of hardware bugs
  Great Keynote and detailed slides with more information. (Recording from FrOSCon2018)