3 ms·

They're rebuilding the Death Star of complexity

13 points by mpweiher 4y ago

rektide 4y ago
If you're maintaining an app and a db, yeah, there may not be a ton of advantage. Your bespoke artisinal admin-ing directly by the teams writing the code is probably fine. And hopefully it will be somewhat understandable in 3 years when there's no one left from that era & folks have to go repair/extend/improve their inheritance. If you are an org with multiple services & apps, with multiple teams, a container is a very compelling encapsulation, of a lot of aggregated build/deploy/manage complexity, with very little overhead, and some decently good isolation benefits. Likewise if you just have a dozen boxes and are ok hand managing what resources are allocated to what systems, you might not need any orchestration. You can just do whatever. But again, over time, you may come to want something that can handle a wider range of apps & services well. You may benefit from the autonomic behavior, rather than having to be as on call & juggling allocations yourself. As your teams grow, having RBAC may be smart or necessary. Having logical namespaces can be useful. Being able to plug in various container storage capabilities, for remote storage, might be a boon for some. There's a suite of potential nice to haves, that you might keep being able to replicate if you tried. The view that it's all easy & all this stuff is unnecessary is alluring. It is a little extra comedic to see the viewpoint being raised from the house of Rails though. Rails was the original batteries included/omakase "the rails way" well built out path (and that still ended up pretty sprawling, especially widening out as the un-JS-ness diminished). Kubernetes is & isnt as everything baked in- on the one hand, there's a sea of storage & networking plugins, and oodles of operators one can add to extend their cloud. But on the positive hand, there is one consistent way to manage & run everything, via api-server & letting control-loops kick in, there is a standard set of primitives, that manage standard, modular, interoperable containers. It's a way, and it's common, and while one can get fancy it mostly works fine out of the box with k3s for example & isnt ostentatious about it. It's a reasonable way to tackle complexity that is real & exists, for legitemate reasons, and having The Kubernetes Way is a huge leap over what we had before, which was next to mo consistency between shops for how to do anything, a mix & match of various small parts that were never designed to work together at all.
nh23423fefe 4y ago
I dunno, whining about bloated specifications vs simple solutions seems pointless. In the real world, I hack on some internal "framework" which is based on the same bloated specs but has no spec and pretends to be slim. I'd rather just use the spec and get the tooling support. Literally we have an internal ASP, internal Groovy, internal make, internal httpclient, etc. These things are all undocumented, bit-rotting over time, and essentially useless without intervention from some random team in slack which doesn't know how it works because of reorg n-1. So I just copy paste some template repo and hack on it until it works for my case. Complexity isn't some parasite that hucksters are selling. Everyone everywhere is piling complexity on. You only get to pick your poison. Software which solves real problems isn't simple. If your problem is solved by a unix tool, then it wasn't a hard problem.
TigerTeamX 4y ago
In 2022 and start of 2023 we have moved all of our servers away from Docker Compose to just running bare metals. Yes a bit more setup in the start, but it makes it easier to maintain the servers. It really feels like all of these good ideas of the unix philosphy are getting rebuilt ontop of this new stack. Like they're rediscovering all of it again.
karmakaze 4y ago
Seems funny talking about complexity from a Rails perspective. The most interactive codebase I've ever encountered was in Ruby/Rails with no static type information, gems that magically work, and application-specific DSLs that can only make sense if you were there like a punchline to an 'in' joke. I don't even think it was unusual--just happened to be at a company that lasted long enough for the amount of cruft and action-at-a-distance to accumulate and not long enough to grow out of it and write more scalably.

13 points by mpweiher 4y ago

If you're maintaining an app and a db, yeah, there may not be a ton of advantage. Your bespoke artisinal admin-ing directly by the teams writing the code is probably fine. And hopefully it will be somewhat understandable in 3 years when there's no one left from that era & folks have to go repair/extend/improve their inheritance. If you are an org with multiple services & apps, with multiple teams, a container is a very compelling encapsulation, of a lot of aggregated build/deploy/manage complexity, with very little overhead, and some decently good isolation benefits. Likewise if you just have a dozen boxes and are ok hand managing what resources are allocated to what systems, you might not need any orchestration. You can just do whatever. But again, over time, you may come to want something that can handle a wider range of apps & services well. You may benefit from the autonomic behavior, rather than having to be as on call & juggling allocations yourself. As your teams grow, having RBAC may be smart or necessary. Having logical namespaces can be useful. Being able to plug in various container storage capabilities, for remote storage, might be a boon for some. There's a suite of potential nice to haves, that you might keep being able to replicate if you tried. The view that it's all easy & all this stuff is unnecessary is alluring. It is a little extra comedic to see the viewpoint being raised from the house of Rails though. Rails was the original batteries included/omakase "the rails way" well built out path (and that still ended up pretty sprawling, especially widening out as the un-JS-ness diminished). Kubernetes is & isnt as everything baked in- on the one hand, there's a sea of storage & networking plugins, and oodles of operators one can add to extend their cloud. But on the positive hand, there is one consistent way to manage & run everything, via api-server & letting control-loops kick in, there is a standard set of primitives, that manage standard, modular, interoperable containers. It's a way, and it's common, and while one can get fancy it mostly works fine out of the box with k3s for example & isnt ostentatious about it. It's a reasonable way to tackle complexity that is real & exists, for legitemate reasons, and having The Kubernetes Way is a huge leap over what we had before, which was next to mo consistency between shops for how to do anything, a mix & match of various small parts that were never designed to work together at all.

nh23423fefe 4y ago

I dunno, whining about bloated specifications vs simple solutions seems pointless. In the real world, I hack on some internal "framework" which is based on the same bloated specs but has no spec and pretends to be slim. I'd rather just use the spec and get the tooling support. Literally we have an internal ASP, internal Groovy, internal make, internal httpclient, etc. These things are all undocumented, bit-rotting over time, and essentially useless without intervention from some random team in slack which doesn't know how it works because of reorg n-1. So I just copy paste some template repo and hack on it until it works for my case. Complexity isn't some parasite that hucksters are selling. Everyone everywhere is piling complexity on. You only get to pick your poison. Software which solves real problems isn't simple. If your problem is solved by a unix tool, then it wasn't a hard problem.

TigerTeamX 4y ago

In 2022 and start of 2023 we have moved all of our servers away from Docker Compose to just running bare metals. Yes a bit more setup in the start, but it makes it easier to maintain the servers. It really feels like all of these good ideas of the unix philosphy are getting rebuilt ontop of this new stack. Like they're rediscovering all of it again.

karmakaze 4y ago

Seems funny talking about complexity from a Rails perspective. The most interactive codebase I've ever encountered was in Ruby/Rails with no static type information, gems that magically work, and application-specific DSLs that can only make sense if you were there like a punchline to an 'in' joke. I don't even think it was unusual--just happened to be at a company that lasted long enough for the amount of cruft and action-at-a-distance to accumulate and not long enough to grow out of it and write more scalably.