Cloud-Native: Echoes of the Java World

Introduction

There’s a new ecosystem growing in its own little universe, deliberately ignorant of the operating system on which it relies.

It reminds me of the Java space: using the software means wrangling gargantuan XML files to operate a system which poorly reimplements some existing feature of an OS. It’s the so-called “cloud-native” ecosystem.

Nobody really uses Kubernetes for day-to-day work, and it shows. Where UNIX concepts like files and pipes exist from OS internals up to interaction by actual people, cloud-native tooling feels like it’s meant for bureaucrats in well-paid jobs. There’s real culture shock coming from a - let’s say - “traditional UNIX background” where computing doesn’t require filling out YAML forms.

My Struggle

To monitor my home network and a couple of others I manage, I use VictoriaMetrics, a fork of Prometheus suitable for more resource-constrained environments. There’s a command called vmalert which manages sending alerts. You can’t run vmalert without flags:

% vmalert
2023-10-09723:16:34.0432 fatal victoriaMetrics/app/vmalert/main.go:151 failed to init: failed to init datasource: datasource.url empty

So I need some flags. Which ones?

% vmalert -h | wc -w
   3300

500 words in to the over 3,000 word dump, I gave up. I guessed the smallest command:

% vmalert -datasource.url http://127.0.0.1:8428

Some questions going through my head:

• Why can’t it assume that vmetrics is listening on the loopback address on the default port?
• How does it know that I’m using TCP? Do I specify that too?
• What if, as in the provided example. I used localhost instead of the IPv4 address 127.0.0.1?
• Which DNS resolver will it use? Is there a flag dnsresolver.address?
• There is even the option -datasource.disableKeepAlive. Why doesn’t other software let me specify this?

The answer is that the operating system upon which vmalert runs implements established conventions for all this - transparently. But in the cloud-native world, like in the Java world, there’s a tendency towards that verbose, industrial, “sophisticated” way of running software. When you finally specify all those flags, neatly namespaced with . to make it feel all so very organised, you feel like you’ve achieved something. Sunk-cost fallacy kicks in: look at all those flags that I’ve tuned just so - it must be robust and performant!

“Cloud Engineers” get paid $150K+ to fiddle with these strings and make sure it’s all escaped/delimited correctly in YAML files. It’s a fucking mess. I’m ashamed enough that I can’t really apply to these jobs. Maybe writing and running software on servers in the commercial world is not a good fit for someone like me who despises corporate jargon.

Want an asynchronous, hierarchical, recursive, key-value database? With metadata like modified times and access control built-in? Sounds pretty fancy! Files and directories. And you’d think filesystems would be hard to use. But they’re not: you open(), read(), and close() without thinking about it. In the 90s my school taught us files and folders when we were 8 years old.

“Clould-native” software co-exists with corporate jargon. They obscure and complicate in the interest of perpetuating lucrative contracts over productive environments.

Using VictoriaMetrics like this feels like a bit of a strawman argument. But that’s just the way it came out today!