As a former Google SRE, I'm pretty annoyed with the number of abstractions, indirections, and arbitrary features being pumped into docker.
As a former Google SRE, I'm pretty annoyed with the number of abstractions, indirections, and arbitrary features being pumped into docker. The core concept of Containers is supposed to be that you write to the unix process model, and the process model alone; Not create new systems from whole cloth in overly abstract ways. This doesn't work for a lot of legacy systems, but rather than port or write new systems to do those functions, the Docker model seems to have absorbed all the hacks without documenting any of the best practices, allowing anyone who's going about creating new systems to wander off into the weeds of subfeatures and hacks. Unfortunately, the LMCTFY project seems to be dead; They're porting features into the already bloated libcontainer, though I'm certain the borglet it is based on stays fairly pristine. LMCTFY and the google stack are a very different style of systems administration than is currently in vogue; but together they create a beautiful and pristine ecosystem with very few rough edges. Anyway: If you want to know what you should be building with Docker, figure out how you would build it with just what LMCTFY provides. Some of it is non-obvious (Service discovery is a core service that exists in many forms, but few that are analogous/replacements for what the google stack needs), but by paring down what you work with, you ultimately create much tighter, more reliable systems.
Posted by GauntletWizard on Jun 29, 2015, 6:59 AM
Tags
Related issues
- This is my biggest problem with agents, they constantly defensively code for cases that have no chance of happening and in most cases a p...
- I wish there was something like LEAN for biology.
- The issue is really the extreme difficulty of programming them, especially for anything sequential (rather than combinatorial).
- I probably could have beared with it if it was only limited to programming, but it showing up in creative fields has made me feel all sor...
- I hate that I'm in deep enough to know what you mean.
- The biggest problem with “AI” is that big corps are shoving it down our throats.
Raise real-world problems, find people facing the same issue, and discuss solutions.5,500 issues0 comments
reliability (Other)
This is my biggest problem with agents, they constantly defensively code for cases that have no chance of happening and in most cases a p...
NewI wish there was something like LEAN for biology.
NewThe issue is really the extreme difficulty of programming them, especially for anything sequential (rather than combinatorial).
I probably could have beared with it if it was only limited to programming, but it showing up in creative fields has made me feel all sor...
I hate that I'm in deep enough to know what you mean.
The biggest problem with “AI” is that big corps are shoving it down our throats.
in the middel of a coding session with 5.6 sol.
[Hero Run] 535B-A23B on 18T tokens
As a former Google SRE, I'm pretty annoyed with the number of abstractions, indirections, and arbitrary features being pumped into docker.
As a former Google SRE, I'm pretty annoyed with the number of abstractions, indirections, and arbitrary features being pumped into docker. The core concept of Containers is supposed to be that you write to the unix process model, and the process model alone; Not create new systems from whole cloth in overly abstract ways. This doesn't work for a lot of legacy systems, but rather than port or write new systems to do those functions, the Docker model seems to have absorbed all the hacks without documenting any of the best practices, allowing anyone who's going about creating new systems to wander off into the weeds of subfeatures and hacks. Unfortunately, the LMCTFY project seems to be dead; They're porting features into the already bloated libcontainer, though I'm certain the borglet it is based on stays fairly pristine. LMCTFY and the google stack are a very different style of systems administration than is currently in vogue; but together they create a beautiful and pristine ecosystem with very few rough edges. Anyway: If you want to know what you should be building with Docker, figure out how you would build it with just what LMCTFY provides. Some of it is non-obvious (Service discovery is a core service that exists in many forms, but few that are analogous/replacements for what the google stack needs), but by paring down what you work with, you ultimately create much tighter, more reliable systems.
Comments (0)
No comments yet. Start the discussion.