OP's piece is heat not much light except maybe replacing HTTP with gRPC (if true). Should have added second path and made it configurable. Storing Kubernetes stuff in ETC is the raison d'etre for multi PAXOS systems: it stores stuff. Also ETCD seems to be an innocent by-stander: the real whine seems to be about K8s.
Etcd, or, why modern software makes me sad
351–360 of 648 posts
Re: Etcd, or, why modern software makes me sad
#352> In 2015, an unrelated tool called Kubernetes was released by Google (but, really, by Xooglers). I would go so far as to say that Kubernetes (or, as the "cool kids" say, k8s) is the worst thing to happen to system administration since systemd. This, I think, is the key to understanding this whole rant. It is entirely of a piece with the anti-systemd crowd, and I think understanding what was really going on there hel…
You hit the nail right on the head here. I too am sick of people telling me to accept ubiquitous containerisation (snapd), locking down of filesystems (macOS), overly complex init systems (systemd (1)), lack of server access (manage it via ansible/k8s, not ssh). Usually the arguments given are "it's necessary 'for security'", "this is where everything is going", "you have to trust the vendor". This is not the spirit…
> As such I found it sad when even Arch fell to the systemd camp. And it's one of the few things it really enforces, it supports 6 different network initialisation methods for example, where all other distributions just pick one and go with it.
Arch has only supported one init system at all times. We could still have stuck with the sysvinit with hacks to look like openrc, but nobody liked that. The initscripts where a mess to maintain and systemd enabled us to not having to care about these details.
If we stuck with the old system, what would the argument be today? "Arch only supports sysvinit! That is not the UNIX philosophy!"? You don't see any complaints on distributions that only support one init which is either runit, s6 or openrc. But when it's systemd somehow people get sad?
Re: Etcd, or, why modern software makes me sad
#353Earlier quoted context omitted.
The misconception is the idea that anyone can easily implement a compliant HTTP 1.1 server, or even client. The protocol may appear simple on paper but parsing it correctly and securely is quite tricky. IMO, one of the benefits of HTTP 2 and 3 is they force people to use libraries and remove the illusion that interacting with HTTP bytes on the wire is a reasonable thing to do.
> IMO, one of the benefits of HTTP 2 and 3 is they force people to use libraries What a strange comment. "The benefit of this protocol is that it's so complex that nobody understands it, so they have to use an existing implementation."
Bram Cohen made a similar observation[0] years ago.
Bram's Law - The easier a piece of software is to write, the worse it's implemented in practice.
I'm not sure whether I agree with him but it's not obviously wrong.
[0] https://web.archive.org/web/20170629144859/http://www.advoga...
Re: Etcd, or, why modern software makes me sad
#354[deleted]
Re: Etcd, or, why modern software makes me sad
#355Earlier quoted context omitted.
What's wrong with the YAML? It's easy to read and write, concise, and generally has sane defaults meaning you don't have to be overly verbose.
In the Kubernetes and Ansible/Salt world it's frequently templatized, and then you need to worry about indentation that you place or your template engine places. Every day I pray that Helm will incorporate support for jsonnet so I never need to touch YAML again.
I agree with, and have felt the same pain as you here. But this isn't YAML's fault, IMO, it is that the templaters, like Helm, aren't safe, and don't escape their outputs.
If have a string, and I use that in the middle of a YAML template, I expect a string — I don't expect "300" to become (integer) 300; give me a function for that conversion.
Any HTML templating system that behaved this way would be frowned upon due to the potential for XSS. There's little risk of XSS here, but it's still annoying to get the wrong results.
Re: Etcd, or, why modern software makes me sad
#356> HTTP/2 a.k.a. SPDY is a comically bloated Layer 4/5/7 mega-combo protocol designed to replace HTTP. It takes something simple and (most importantly!) comprehensible and debuggable for junior programmers and replaces it with an insanely over-complicated system that requires tens of thousands of lines of code to implement the most minimal version of, but which slightly reduces page load time and server costs once you…
The misconception is the idea that anyone can easily implement a compliant HTTP 1.1 server, or even client. The protocol may appear simple on paper but parsing it correctly and securely is quite tricky. IMO, one of the benefits of HTTP 2 and 3 is they force people to use libraries and remove the illusion that interacting with HTTP bytes on the wire is a reasonable thing to do.
The value of being able to build an HTTP 1.1 server is not in putting a hand-crafted server on the internet and serving traffic. It's in the experience of building the server and later applying that detailed byte-by-byte knowledge in real work. It's also in teaching young engineers that yes, they can learn something by digging into the layers that surround their own code. Part of the dysfunction of "enterprise" programming is the programmed helplessness of people who are surrounded on all sides by complex, opaque technology that turns curiosity into a liability. We are replacing a "whoa, I can see how it works!" experience with a "fuck, I guess have to leave this part to those bigcorp engineers" experience.
(I'm not agreeing with the author, just pointing out why he might care about the ability for an individual to implement the protocols the web is built on.)
Re: Etcd, or, why modern software makes me sad
#357Earlier quoted context omitted.
describe the steps to release the simplest ever code in javascript to production: write a js file, host it, done. The same thing in TS adds at least one step (not to mention the rest of the tooling you will want) So while a prefer it over JS, there's no arguing that it is more complex as now you require a build step for a language that only exist because people wanted a language without a build step.
Almost nobody does Javascript without a build step these days, unfortunately. I miss those simpler days.
You might like deno (https://deno.land) then!
It’s native typescript.
Re: Etcd, or, why modern software makes me sad
#358"Kubernetes is the worst thing to happen to system administration since systemd." I'll take that quote into my fortune file.
What are some of the arguments against `systemd`? I've used it in several production systems and don't really have an opinion on it.
Branding perhaps. If 50 tools had been released, called "newInit", "newDns", "newNTP" etc, with each tool succeeding or failing (upstart) on it's own merits, that would be one thing.
There is a perception that systemd has taken over the entire system as a cancer - replacing things that have worked for decades just because it's cool.
One annoyance I get is this: I've just taken an Ubuntu 1604 server running apache and b0rked the config file.
$ sudo systemctl restart apache2.service
Job for apache2.service failed because the control process exited with error code. See "systemctl status apache2.service" and "journalctl -xe" for details.
$
$ sudo service apache2 reload
* Reloading web server apache2
* The apache2 configtest failed. Not doing anything.
Output of config test was:
AH00526: Syntax error on line 1 of /etc/apache2/sites-enabled/sd.conf:
Invalid command 'blah', perhaps misspelled or defined by a module not included in the server configuration
Action 'configtest' failed.
The Apache error log may have more information.
You run the first and it outputs the last few lines of log. Why not output that when I call restart in the first place?
Another one is taking over DNS from resolv.conf. Muscle memory from years of "cat /etc/resolv.conf" (with a tab somewhere in the middle) has been replaced with the ungainly "systemd-resolve --status".
Now all of this is great if you're running servers as cattle - if you have thousands of machines doing web-scale stuff you don't want to see what's happening on a single machine, your layers of automation abstract it all away, your system can cope with machines going down, you probably don't even have an ssh account.
If you are looking after individual machines though, systemd came in and turned everything upside down to presumably make things easier for cattle owners.
Re: Etcd, or, why modern software makes me sad
#359Earlier quoted context omitted.
React I have been thinking about, having worked with it a lot and also recently done a React / TS / GraphQL (GraphQL may have been the poorest choice I made; time will tell) project. I think React itself is awesome and I've always enjoyed it. While I'm not an expert, it's conceptual foundations and core abstractions felt right, and I do think it makes lots of frontend tasks simpler, especially for non-small projects.…
I have that rant daily at this point. Dev A: I need an API to CRUD Me: But we've been doing CRUD for 30 years without an API this is a small project Dev A: But I don't know how, its not best practice, my team lead agrees, here is a medium article, get with the times, etc. Me: Ok so you don't know how to do your job. Dev B: Here, put the React SPA in a Docker container and run it on some cloud its easy... Me: But all…
Dude! You need to run more servers. 250 should do it. I realize its just a simple page with a pair of boxes for name registration, but that's irrelevant! All the cool kids agree. You need infrastructure. It needs to be done as complex as possible! Complexity-as-a-Service won't just happen, you have to want to make it happen. You don't want to be uncool, do you?
Looks at a specification on the desk Yep. We'll keep the first and last page. Everything else is gibberish. Next!
Edit: Looks like a few people disagree. Perhaps they might like to explain why I saved a bunch of companies around 100k in AWS fees just by pruning their server requirements? No? And yes, one of the projects was a simple set of web forms that required 7 servers to run. We pruned it down to 3 and that was just for redundancy and load. That's just one example.
If you disagree state your why.
Re: Etcd, or, why modern software makes me sad
#360Earlier quoted context omitted.
The apprehensiveness of sysadmins May have been justified in the world 5 years ago but today it sounds somewhat out of place. Note that critically evaluating new technologies is still an important skill and many infrastructure people I work with are extremely cautious about adopting new tech without spiking/getting to know it. But the sysadmins with the penchant for saying no is probably one of the reasons the devops…
Revisit this comment of yours in a decade.
A decade is a long time in software engineering. Kubernetes would be obsolete by then. What do I need to revisit?