The DevOps of Music: Part 1 – Learning through Experience

Fender Bullet (Author's photograph)
Fender Bullet

My day to day life in DevOps engineering is rooted in experience. Occasionally I can remember the magic setting that just works, but it is far more usual that I am starting from a problem (and tool) I’ve never seen before, so I just have to mentally roll my sleeves up and pay close attention to what I am seeing. (The phrase I use most often with other engineers is “show me” and then the close follow up is “let’s try it.”)

This mindset prioritizes experiment over analysis, and it developed over time as I realized how seldom analyzing DevOps engineering problems really helped. Some critical thought is needed to rule out obviously dumb experiments, but after that there are just too many possibilities, and you really just have to try stuff.

I’ve been finding this mindset creeping into my studio work recently. I keep getting questions about vintage amplifiers, advanced plugins, rare guitars, exotic signal processors, and the answer is nearly always “let’s try it and see how it sounds.” If a $50 guitar fits the track, we’ll take it. If the $1000 plugin doesn’t, we’ll mute it.

Just like in DevOps – the problem might be horrible, but the fix might be as simple as a single setting (e.g. don’t leave Entity Framework logging in TRACE mode).

Posted in Agile, DevOps, Music Production | Tagged , | Comments Off on The DevOps of Music: Part 1 – Learning through Experience

DevOps Reading List


The seminal book. Teaches the key principles through a highly readable story. If you haven’t read this, you won’t know what’s going on when people say “X is a bit of a Brent”

The foundational work on continuous integration and continuous delivery. Both Dave Farley and Jez Humble are fantastic speakers if you ever get the chance.

Great introduction to Lean principles from a wider perspective than IT ‚Äď like the Phoenix Project, it reads as a novel.

Google’s alternative framing of DevOps. Some interesting ideas, and worth reading just so you understand how the term SRE actually involves a lot more than its descent into common usage might indicate. Free online also.

Beginners in DevOps think its all about learning a sometimes horrifying amount of new tools and skills. With experience, people think it is about culture and people.

But, darlings of whatever level, you better get *real* good at Bash. Inside out and back to front.

A relatively new entry to the field, and too early to get the ‘classic’ recommendation that the other books on my list have, but if you are in a siloed “DevOps Team” or have the specific problem of helping large organizations rethink the way their teams are working this book is well worth being aware of.

Online Resources

  • Jeff Bezos’ 2002 email telling people that all Amazon services would henceforth be implemented as externalisable services. Teams that did not do this would be fired.
  • Site collecting resources on Trunk Based Development. Pretty soon in your DevOps career, you are going to be lectured by developers about complex branching strategies looking something like GitFlow. In my experience, there is a strong correlation between the vehemence with which GitFlow is advocated, and the dogs dinner of abandoned branches, failing pipelines and poorly tagged releases that you end up with. And surely if the authors of CI/CD are asking questions, we should be open to change?
  • SS64. Fast, authoritative reference to all the main scripting tools.
  • Puppet State of DevOps Report. This content is endlessly recycled by consultancies (and me) – required reading.
  • Stack Overflow Developer Survey 2021 – note the top two non-managerial roles: site reliability engineer and DevOps specialist.

The DevOps Roadmap

There’s no shortage of things to learn in this field …

Source: DevOps Roadmap: Learn to become a DevOps Engineer or SRE

Posted in Agile, DevOps | Tagged , , , , | Comments Off on DevOps Reading List

Controlling Family Screen Time – Part 2

This article follows on from Part 1, where we discussed using Windows 10 features to control computer device access.

In this article, we look at what controls are available for the family network as a whole – this is where you need to look if your children and their guests have smartphones and tablets. We will look at the specific capabilities provided by Plusnet, a well known UK broadband provider, but the principles can be applied to other providers.

The first interesting control is on the router itself – under Home > Settings > Plusnet Access Control, we find a feature to limit Internet access for a given time window. In this case, the family member in question is blocked between 21:00 and 06:00 the next day:

Plusnet Access Control

The second interesting control is actually in the ISP’s member area – under Broadband > SafeGuard, we have a feature to block websites both by category and individually:

SafeGuard Control Panel

The block can be set on a timer (for instance if you want to loosen controls after a certain time of day), but otherwise it will apply at all time, see example message below:

Plusnet ISP FIlter

The limitation of the SafeGuard product is it doesn’t allow you any control over individual devices (filter categories may need to be different for adults in the household), and also you cannot report on what sites have been blocked. To achieve this, we need to look at a dynamic DNS service such as openDNS, and that is what we will review in the next post.

Posted in Home Computing | Tagged , , | Comments Off on Controlling Family Screen Time – Part 2

Limiting Family Screen Time in Windows 10 – Part 1

Windows 10 Logo Windows 10 has an administrative feature you can use to limit screen time for any account. This feature has the following limitations:

  • It only works on the hour. You have to say 9am-5pm, not 09:30-17:30
  • It only works on the login screen. So if the user is already logged in, it won’t stop them working until their screen locks

To use the feature, you’ll need to be running an account with administrator privileges – then take the following steps:

  1. Type ‘Windows Key + x’ and choose ‘Windows PowerShell (Admin)’ from the menu.
  2. Answer ‘Yes’ to the User Account Control popup.
  3. Type ‘cmd‘ at the prompt and then Enter key (type Enter after all of the commands below)
  4. Type ‘net user‘ at the new prompt to list all of the users on your machine
  5. Type ‘net user username1 /time:M-T,09:00-17:00;W,09:00-20:00;F-Sa,09:00-18:00‘ (for example) to limit times Monday to Saturday, with no time allowed on Sunday.
  6. Exit
  7. Exit (Blue PowerShell window should close)

The syntax for this command is documented quite widely on the Internet – see for example

Posted in Home Computing | Tagged , , , | Comments Off on Limiting Family Screen Time in Windows 10 – Part 1

VirtualBox Networking Lab

Excellent tutorial from Brian Linkletter here:

Couple of lessons learnt for me:

  • Install your networking tools such as traceroute on your base image before you clone it.
  • Make sure the lab’s internal network doesn’t clash with your home router network ūüôā

Posted in VirtualBox, Virtualisation | Tagged , | Comments Off on VirtualBox Networking Lab

London Heathrow to Frankfurt on Luthansa – Airport Hacks

A highly situational list – but it might help someone!

[1] (FRA) Boarding Pass Check Dodge

Due to the airport only having two electronic boarding pass scanners in Hall B, which often break down, long queues can build up while a single employee manually checks every boarding pass. If you don’t mind being a weasel, you can walk through the back of the shopping malls from Hall A, and arrive more or less at the beginning of the queue. And then try and look innocent and/or important while you merge into the head of the queue.

[2] (FRA) Security Line Mini-Dodge

Frequent visitors will dread the security line at Frankfurt, which can take over an hour to get through. Once you’re past the first two folds of the snake, it pays to keep your eyes open as you near and pass each red coat, as they will periodically open the barriers to let in 20 or so people to another scanner area. I’ve no idea why.

[3] (FRA) Passport Check Dodge

After you’ve finally cleared the security line, you’ll be dismayed to discover another big line to get through passport control. If you’re an EU passport holder, turn left past both the electronic gates and the big queue, and you’ll find another set of electronic gates, which usually have no traffic.

[4] (FRA) Mysterious Pre-Boarding Check Explanation

This one is not a hack, really just an explanation. You’ll sometimes see everyone queueing up at the gate before boarding is announced. This is so passports can be pre-checked, in return for a slip of paper, which makes boarding that little bit faster.

[5] (FRA) Taxi / Mobile Signal Tip

There appears to be very poor mobile signal outside Arrivals, and also it seems to take taxis ordered through services like MyTaxi a long time to arrive. Just get the esclator one floor up to Departures, where you’ll get better signal, and much more chance of a taxi who has just dropped off.

[6] (FRA) Lounge Tips

The Lufthansa lounge is OK, but you need to be a Frequent Flyer to take advantage. Don’t be tempted by the Priority Pass (Pay-As-You-Go) lounge. It has limited facilities, but the killer blow is it is landside, so you can’t stay there for very long, because of the mutliple long queues you still have to surmount before you get to your gate.

[7] (LHR) Lounge Tips

Spoilt for choice. The Lufthansa lounge in Terminal 2 is excellent, but the Priorty Pass lounge is even better, and has an excellent lunch and evening meal if you’re flying later on

[8] (LHR) Other Tips

I’m afraid the only other tip for Terminal 2 is to enjoy the efficiency, space and comfort – the trouble is usually at the other end.


Posted in Travel | Tagged , , , | Comments Off on London Heathrow to Frankfurt on Luthansa – Airport Hacks

API Banking – 10 Bank Developer Portals

In no particular order …

UK Market (Open Banking)

[1] HSBC

[2] RBS #BankOfAPIs Developer Portal

[3] Barclays

[4] Lloyds Bank Developer Portal

[5] Halifax

European Market (PSD2)

[6] Nordea Developer Portal

[7] ING Developer Portal

[8] Deutsche Bank Developer Portal

US Market

[9] Wells Fargo Developer Portal

[10] Citi Developer Hub

Posted in API | Tagged , , | Comments Off on API Banking – 10 Bank Developer Portals

REST API Design – A Beginner’s Reading List

There’s no better place to start than Steve Yegge’s post, where he dicusses the Jeff Bezos memo that kicked off the service architecture revolution at Amazon:

The RESTful cookbook is a your next stop – an easy to digest of many of the key topics:

Then you should read this classic worked example – ‘How to GET a Cup of Coffee’:

(If you read the comments section of the article, you’ll get a useful taste of the kind of design discussions that come up in the field)

The REST API Design Handbook is a good, quick read, once you’re starting to get more confidence:

It’s a little dated now, but the RESTful Web Services Cookbook is a great resource once you start needing deeper coverage on topics such as asynchronous calls and versioning:

Lastly, if you want to see a standard for REST API design published by an organisation that’s got some serious experience, check out this public document from Zalando:

It is long, but you’ll find yourself agreeing with most of it.

Posted in API, Enterprise Integration | Tagged , | Comments Off on REST API Design – A Beginner’s Reading List

Bluff Your Way in Enterprise Architecture

Being an architect is hard work. Given how small the population of people willing to do hard work is,¬†it might be a¬†little mysterious to you how many people manage to wangle ‘architect’ into their job titles*, but how few know what they are talking about.

If so, help is at hand Рuse this handy list of bluffing points to enable you or your team (or even that guy from Pret who brought the sandwiches in today) to play the role of enterprise architect while HR complete the twelve month recruitment process.

Bluff¬†1: I’m just not sure this solution will scale

Unanswerable, since any attempt to defend the solution can be simply rebutted by you declaring that wasn’t what *you* meant by scale. See below for worked example:

Victim: “So our document storage system can store upto 2 petabytes of data on a single node”

You: “I’m just not sure this solution will scale”

Victim: “Well we can easily scale out to 64 nodes without needing any additional configuration”

You: “I’m sure the trivial case is fine, but I was more concerned about real world scenarios;¬†we are looking at a zetabyte load”

Bluff¬†2: What’s your use case?

¬†Ostensibly an appeal to practicality, this is actually a¬†brilliant way to patronise¬†someone by insinuating they don’t talk to their customers and are obsessed with technology for technology’s sake. The use of Agile lingo makes it particularly hard to counter, since no-one wants to argue against Agile, right?

On very rare occasions you will meet someone who is actually half competent at Agile, in which case your fallback position is to bamboozle them with semantics, as follows:

You: “But I’m just not clear what our use case is here.”

Victim: “Well, as a customer of Big Corp, I want to log into my mobile app, so that I can check my orders”

You: “Hmmm. But are we sure that’s really a use case? To me that sounds more like an epic/spike/…/etc”

Bluff 3: What does the Technical Traffic Warden Committee say about this?

Every large organisation attracts a modest but determined band of people who love to proceduralise and standardise the joy out of anything they can get their hands on, including the very thing that got most of us into computing in the first place, which is playing with cool new stuff.

The TTWC won’t actually be named as such, but their ostensible function (preventing technical sprawl), and their actual effect ( keeping their organisation a decade behind the rest of the industry) will feel very familiar to anyone who has gotten a parking ticket.

Dobbing your victim into the TTWC will embroil them in months of red tape while they try to explain to a bunch of fifty-somethings what a graph database is. This will definitely make you enemies, so use with caution.

Bluff¬†4: Sorry, I’ve got to jump into another meeting now …

Never, ever, under any circumstances, decline a meeting. If you play this one right, you should have at least two different meetings happening in your calendar at any point in the working week. To get the full effect, you should share your calendar, so anyone who actually gets a bit of your time is fully aware how lucky they are, and how you might have to dash off at a moment’s notice (particularly if you’ve got something more interesting do, or if people start talking about deliverables). Also, if you fail to turn up to one meeting, the attendees will naturally assume you are at the other meeting. Not for the beginner, but can be devastatingly effective.

Bluff¬†5: Are we sure we’ve correctly separated the [control/management/data] plane from the¬†[management/data/control] plane here? (Delete as applicable)

This is a ninja move guaranteed to bamboozle most people in the room in any meeting, sending them into a mental tailspin of anxiety as they try to figure out what you are talking about.

In computing this gets fantastically complicated, as people do crazy stuff like insist on separate physical networks for these things, and then wonder why they can’t afford a test environment or release more than once a year. Great for you, as you can simply¬†make things more complicated if anyone looks like understanding:

You: “I’m just not sure we’ve correctly separated the management plane from the data plane here.”

Victim: “Well the admin process runs on a separate port secured by TLS”

You: “Hmmm. I don’t suppose you support a different LDAP domain for admin users, do you? That’s the Big¬†Corp standard.”

Bluff 6: I think we need to run this one past Security

Not quite as bad as throwing someone to the TTWC (see above), but this will have similar effect, as the victim attempts to navigate whether they should be talking to the security architecture team or the threat prevention team. All of these teams will be small and incredibly overworked, to the point that the only way of speaking with them will be to actually accost them as they run from the smoking remains of one emergency to the next.

Security teams are usually masters at making sure the responsibility and effort for securing systems remains with the people building or buying them, so this is a good way of giving a project a mountain of invisible work that they are pretty much obliged to do if they want to get into production.

Bluff¬†7: I think there’s quite a lot of overlap here with the XYZ initative. I think we need to set up a meeting with them before we go any further with this.

Any large organisation will have multiple projects on the go, all competing for the same limited nutrients of money and management attention. There will definitely be something else out there which resembles or overlaps in some superficially plausible way with the project you’re looking at, so why not “help” by getting them together in the same room¬†to pretend to be interested in each other? You can even rerun Game of Thrones for your private entertainment by secretly christening one project the Lannisters, and the other project the Starks.

Bluff¬†8: Why don’t we just try this out as an experiment before we commit?

The idea here is that¬†to¬†spend a few weeks/months kicking the tyres, before you commit millions, so you can walk away if it doesn’t work out.

Sounds reasonable, doesn’t it?

Despite sounding reasonable, it turns out most organisations are about as good at experimenting with projects as¬†you and I¬†would be with experimenting with crack.¬†Experiments turn into POCs, which turn into pilots, which turn into Phase 1,¬†which finally turns into¬†Security being asked to sign off for go live on a solution¬†they’ve never heard of.

So, yeah, you’re really only saying this to be the one¬†who said it, with a side order of plausible deniability if it all goes Pete Tong.

Bluff 9: The underlying, guaranteed solution to all technology problems

I’ve used this one to justify multiple board position for two decades, it absolutely cannot fail. All you need to do is – ah, shoot, I’ve got to go to a meeting with the CCB about a¬†firewall change,¬†I’ll drop it to you in an email I promise …

*¬†¬†I’m talking to you,¬†‘DevOps Architect’,¬†seriously?

Posted in Agile, Architecture, Humour | Comments Off on Bluff Your Way in Enterprise Architecture

Infrastructure as Code – Key Terms

There’s an excellent introductory series on Terraform over at Gruntwork, and apart from anything else it has a very clear introduction to what the different tools in this space do.

I recommend the blog, but here’s a quick summary of some key terms:

Provisioning Configuring
Provision the servers. Install and mange software on existing servers.
Orchestration. Configuration Management.
Terraform, CloudFormation. Chef, Puppet, Ansible.
Talk to the datacentre (e.g. vSphere, OpenStack) Talk to the server (e.g. Linux, Windows)
Posted in Automation, Virtualisation | Tagged , | Comments Off on Infrastructure as Code – Key Terms