this post was submitted on 10 Oct 2023
38 points (77.1% liked)
Programming
17319 readers
150 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
This has always felt untrue to me. The command line has always been simple parts. However we cannot argue that this applies to all Unix-like systems: The monolithic Linux kernel, Kerberos, httpd, SAMBA, X windowing, heck even OpenSSL. There's many examples of tooling built on top of Unix systems that don't follow that philosophy.
Depends on what you mean. "Everything is a file"? Sure, that metaphor can be put to rest. "Low coupling, high cohesion"? That's even more valid now for cloud architectures. You cannot scale a monolith efficiently these days.
Kubernetes is more complex than a single Unix system. It is less complex than manually configuring multiple systems to give the same benefits of Kubernetes in terms of automatic reconciliation, failure recovery, and declarative configuration. This is because those three are first class citizens in Kubernetes, whereas they're just afterthoughts in traditional systems. This also makes Kubernetes much more maintainable and secure. Every workload is containerized, every workload has predeclared conditions under which it should run. If it drifts out of those parameters Kubernetes automatically corrects that (when it comes to reconciliation) and/or blocks the undesirable behaviour (security). And Kubernetes keeps an audit trail for its actions, something that again in Unix land is an optional feature.
If you work with the Kubernetes model then you spend 10% more time setting things up and 90% less time maintaining things.
It also has negligible adoption compared to HTTP. And unless it provides an order of magnitude advantage over HTTP, then it's going to be unlikely that developers will use it. Consider git vs mercurial. Is the latter better than git? Almost certainly. Is it 10x better? No, and that's why it finds it hard to gain traction against git.
Even an online filesystem does not guarantee high availability. If I want highly available data I still need to have replication, leader election, load balancing, failure detection, traffic routing, and geographic distribution. You don't do those in the filesystem layer, you do them in the application layer.
Nice ad hominem. I guess it's rules for thee, but not for me.
So what's the problem? Didn't you just say that the Unix way of doing things is outdated? Let the CSI plugin handle the filesystem side if things, and let Kubernetes focus on the workload scheduling and reconciliation.
Dismissal based on flawed anecdote is preconception.
No. I'm not married to the "cloud" way of doing things. But if someone comes to me and says "Hey boblin, we want to implement something on system foo, can you help us?" and I am not used to doing things the foo way I will say "I'm not familiar with it but let's talk about your requirements, and why you chose foo" instead of "foo is for bureaucrats, I don't want to use it". I'd rather hire an open-mined junior than a gray-bearded Unix wizard that dismisses anything unfamilar. And I will also be the first person to reject use cases for Kubernetes when they do not make sense.
There are scenarios where cloud compute just does not make sense, like HPC. If the author had led with something like that, then they would have made a better argument. But instead they went for
,
, and
It's hard to not take that as bad faith.
I can see why you would come to think that if all you've been exposed to is Linux and its orbiting ecosystem. I agree with you that modern Unix has failed to live up to its ideals. Even its creators began to see its limitations in the late 80s and began to develop a whole new system from scratch.
That was never true in the first place. Very few things under Unix are actually represented as files (though credit to Linux for pursuing this idea in kernel-space more than most). But Plan 9 shows us this metaphor is worth expanding and exploring in how it can accomplish being a reliable, performant distributed operating system with a fraction of the code required by other systems.
My point is Kubernetes is a hack (a useful hack!) to synchronize multiple separate, different systems in certain ways. It cannot provide anything close to something like a single system image and it can't bridge the discrete model of computation that Unix assumes.
All these features require a lot of code and complexity to maintain (latest info I can find is almost 2 million as of 2018). Ideally, Kubernetes is capable of what you said, in the same way that ideally programs can't violate Unix filesystem DAC or other user permissions but in practice every line of code is another opportunity for something to go wrong...
Just because something has more security features doesn't mean it's actually secure. Or that it's maintainable without a company with thousands of engineers and tons of money maintaining for you. Keeping you in a dependent relationship.
So? I don't expect many of these ideas will be adopted in the mainstream under the monopoly-capitalist market system. It's way more profitable to keep selling support to manage sprawling and complex systems that require armies of software engineers to upkeep. I think if state investment or public research in general becomes relevant again maybe these ideas will be investigated and adopted for their technical merit.
"Highly available" is carrying a lot of weight there lol. If we can move some of these qualities into a filesystem layer (which is a userspace application on some systems) and get these benefits for free for all data, why shouldn't we? The filesystem layer and application layer are not 2 fundamentally separate unrelated parts of a whole.
Lol, stop being condescending and I won't respond in kind.
I think the reason the Unix way of doing things is outdated is cuz it didn't go far enough!
What? lol
It's not a flawed anecdote or a preconception. They had their own personal experience with a cloud tool and didn't like it.
You can't
someone into liking something.
I'm not a gray-bearded Unix wizard and I'm not dismissing these tools because they're unfamiliar. I have technical criticism of them and their approach. I think the OP feels the same way.
The assumption among certain computer touchers is that you can't use Kubernetes or "cloud" tools and not come away loving them. So if someone doesn't like them they must not really understand them!
They probably could've said it nicer. It's still no excuse to dismiss criticism because you didn't like the tone.
I think Kubernetes has its uses, for now. But it's still a fundamentally limited and harmful (because of its monopolistic maintainers/creators) way to do a kind of distributed computing. I don't think anyone is coming for you to take your Kubernetes though...
Kubernetes is not intended to provide anything like a single system image. It's a workload orchestration system, not an operating system. Given a compatible interface (a runtime) Kubernetes can in theory distribute workloads to any OS.
I'm not going to argue that Kubernetes is not complex. But as I stated previously Kubernetes as a bespoke ecosystem is less complex than configuring the same features with decoupled systems. The requirements for an orchestrator and the challenges (technical, security, human, etc) to manage said orchestrator are higher. All else being equal, Kubernetes has implemented this in a very lean way, delegating networking, storage, and runtime to pluggable providers on the left, and delegating non-basic workload aspects to operators on the right. It's this extensibility that makes it both popular with operators and makes it appear daunting to a layperson. And going back to security, is has provably shown to have a reduced attack surface when managed by a competent operator.
So you're... what, dismissing HTTP because it has been adopted by capitalist market systems? Are you going to dismiss the Fediverse for using HTTP? What about widely adopted protocols? DNS, BGP, IPv4/6, etc?
How about we bring this part of the discussion back to the roots? You said that HTTP and REST as communication protocols seemed strange to you because Unix has other primitives. I pointed out that those primitives do not address many modern client-server communication requirements. You did not refute that, but you said, and I paraphrase "9P did it better". I refrain from commenting on that because there's no comparative implementation of complex Internet-based systems in 9P. I did state though that even if 9P is superior, as you claim, it did not win out in the end. There's plenty of precedents for this: Betamax-VHS, git-mercurial, etc.
(My emphasis) It's not free though. There's an overhead for doing this, and you end up doing things in-filesystem that have no business being there.
*Ahem*:
That is not an experience, it's a provably wrong statement.
That's a very weird assumption, and it's the first time I've heard it. Can you provide a source? Because in my experience the opposite is the case - there's no community more critical of Kubernetes' flaws than their developers/users themselves.
I dismissed the criticism because it makes an appeal to pathos, not to logos. Like I said, there's plenty of valid technical criticisms of Kubernetes, and even an argument on the basis of ethics (like you're making) is more engaging.
No my Kubernetes. I use it because it's academically interesting, and because it does the tasks it is meant to do better than most alternatives. But if CNCF were to implode today and Kubernetes became no longer practical to use then I would just pivot to another system.
I'm not going to argue whether it's a harmful way of doing distributed computing based on their maintainers/pedrigee. That's a longer philosophical discussion than I suspect neither you or I have time for.