HN user

djmetzle

74 karma
Posts0
Comments22
View on HN
No posts found.
Use one big server 4 years ago

Generally, the burstier your workload is, the more cloudy your architecture should be.

Well, crap dude, that's the web!

Meh. Is this a hot debate still?

No mention of Ruby or smalltalk in this post, which i think of as "true" OO languages, down to the runtime. The ruby object model has its merits! Sandi Metz's POODR is a fantastic intro into OO _and_ a compositional approach to design.

FP vs OO is always a false dichotomy for sure. Actors and messaging appear in FP languages. Inheritance surely has nothing to do with OO. Inheritance means nothing for data, and it's almost a bug to extend Record types.

In short, this post seems to rage against inheritance and blind use of design patterns, not the spirit of OO. But the post also qualifies that "that is what an OO advocate would say".

Consider Typescript. The same program can be written with `class`es, or as a module of "loose" types and functions. Really, lets pick a mix that best represents the problem we're solving? I think OO can be a _useful complement_ to FP and other paradigms.

I think modern "Docker"'s security properties are underrated†

100% agree.

The docker/CRI-de-jour (by default) strips off many "dangerous" system capabilities. By default a pid on linux gets something like over one hundred system capabilities, and most container runtimes strip that down to around 50. Those number are not exact.

Stripping down the system level capabilities of your workload is assuredly a security improvement over running that workload "bare metal" on the system.

Ref: https://www.redhat.com/en/blog/secure-your-containers-one-we...

Embrace the Grind 5 years ago

Truth! Deep work and focus is difficult, expensive with continuous meetings and notifications. So the OP is extra right! Cutting through the noise looks like magic now.

I hear all of your complaints and empathize with them. Containerized workflows are in fact more complex, and it does hurt a little.

But consider this. You can mount the entire host fs, say under `/var/host` or the likes, and you're tied back to Code on the machine. You can use the host network stack with `--net=host`. And you can even skip user and process space segmentation. And so what would that get you?

Containers are just threads with good default isolation. By default, the system capabilities are greatly reduced in a container (PTRACE for example, though sometimes that one hurts a little too). Systemd does the exact same things with it's units, careful segmenting out it's units into process groups with constrained capabilities.

The point being that containers are just processes with good default isolation. That's a win for versioning and security, at the cost of complexity.

I thought this article, while a little dry, was very illuminating. It sounds Hyperfeed is running at the very least "Medium Data" (we all thing our Data is Big!). And i think it is fascinating to hear of a case where Prometheus is plainly a bad fit for it's intend purpose. It sounds like cardinality explosion around their ML models was a really bad fit for Prometheus. Its great to hear about deployments "in-situ", and people appreciating where it works well, and where it doesn't.

I think the general idea is good, in that teams should be vertically integrated. But it misses the mark. If you don't appreciate that there is specialty in developing beautiful, responsive, cross-browser modern web-apps, you're not paying attention to the very quickly evolving state of web development.

There is an emerging trend towards "full stack frontend", where we have someone who can design UX, and also wire together backing services like flux, webpack, and APIs.

As a DevOps guy, you can definitely spend a serious effort to pipelining your fronted testing, deployment, and monitoring. Setting up development environments, Sentry, optimizing webpack builds, securing CDN distributions, incorporating Analytics, etc.. these are "Frontend DevOps" kinds of tasks. Hence, vertical integration is important. The frontend can be developed as an independent service in of itself.

On the server-side, there is still a UX. We have API design, documentation, and discoverablility as the "UX" of a "backend", now more appropriately described as a "backing API", but a complete service in itself.

So i think this article is ignoring the emergence of JAM-stack and Edge compute. I think it forgoes the robustness, and ability to quickly deliver business value that these new platform paradigms can enable.

I agree.

With C, you are in control of everything your program does. That means you're also _responsible_ for everything your program does. C requires a very different mindset than dynamic languages.

I have a proposition: You know how Tor works? Onion routing? Send traffic encrypted multiple times through a list of nodes before exiting at an edge?

What if everyone sent their traffic back and forth to eachother. One hop, encrypted, and then forwarded. Just like Tor, but a single hop. Not anonymized, just peer-to-peer distributed.

If everyone did that (build it into browsers) the internet would function _full-mesh_. I mean, that's how IP works, right? Full mesh, peer-to-peer?

Hey ISPs! Good luck filtering on the entire internet.