9 ms·

This is the first time I’m seeing that. It’s so beautiful. It’s elegant. I can understand it. Why can’t the world move in that direction, instead of the insane

by cblum 7y ago

This is the first time I’m seeing that. It’s so beautiful. It’s elegant. I can understand it. Why can’t the world move in that direction, instead of the insane Kubernetes hype that’s prevalent these days?

bitlax 7y ago
Libraries, helper functions, support, etc.
agumonkey 7y ago
Plausible. There's nix and guix, and maybe others. There's intetest and worth but it may take time.
ar_lan 7y ago
Curious - what don't you like about Kubernetes?
- movedx 7y ago
  Repeating my reply to this question asked by someone else above. I genuinely want to engage people on this question. --- My problem with Kubernetes is people adopt it without understanding it. They adopt it because everyone else is without ever asking, "Why?" I've installed and managed a simple K8s cluster before now and it was a nightmare (this was only a year ago.) It wasn't until we moved the management of the cluster to a managed service that it became worth it. It was at THAT point it was worth containerising the application(s) (another complexity to overcome) and letting K8s handle the deployment and scaling. I'm worried that as an engineering culture we're not pushing back enough and saying, "Yeah K8s is cool but look: do you really need it? It's very likely you don't". For me to automatically recommend K8s to my clients I'd need to see a (near) zero friction deployment options that's fully feature compliant and truely fully managed. It's at that point I would be happy to say, "Sure! Let's go with K8s and just write YAML files to deploy our containers!" (And then there's the whole debate as to whether or not you even need a container around your monolith... probably not. Then the next debate about people starting out with microservices when we all know that's not a good idea.)
  - ar_lan 7y ago
    I work with Kubernetes quite a bit, so I'm reasonably knowledgable on the pro's and con's. I definitely think there is a misunderstanding about what Kubernetes solves. I think Kubernetes is very good at helping structure very large applications where a split of micro-services makes sense. Most start-ups don't need it - it's likely overkill, and unless you go with a vendor you're likely to set it up incorrectly. But it is an advantage in much larger, spread out teams if the culture surrounding all the teams makes sense. If sub-teams can handle their applications really well, which many companies have achieved, then it does provide significant benefits over monoliths. I think the problem you're noticing is that everyone wants to jump onto Kubernetes without realizing why it's even there - the same with micro-services. I shudder when I hear that from my friends with no more than 10 people on their development team, but I think it makes a lot more sense when I see teams of >200 complaining that their huge monolith is what causes the most friction.
    - movedx 7y ago
      Absolutely spot on. This is my experience too and this is also howI feel about it. It's an excellent piece of kit, but like most tools it has to be not only used correctly but also in the right context.
YawningAngel 7y ago
What do you think is wrong with kubernetes, out of interest?
- lhuser123 7y ago
  I think is referring to abstractions in general. Levels and levels of abstractions. Not always a bad idea but sometimes it ends up complicating things too much and burning new comers brains.
  - ikeyany 7y ago
    The levels of abstraction seem to be a hazing ritual that seems to be a point of pride sometimes. I also imagine it's good job security for those who spent years on these tools.
    - jacobush 7y ago
      Aw man. When I started in this industry we made new employees build their work PC from parts.
  - cblum 7y ago
    Yep, exactly this. Whenever I try to grasp it, I feel like things are being abstracted beyond comprehension. It doesn’t feel right. That, and the fact that it seems like you need to adopt about 100 completely heterogeneous tools to successfully manage a Kubernetes cluster.
    - mroche 7y ago
      I went from using Singularity to bundle scientific tools for HPC cluster useage at my university straight into admining OpenShift at my current employer and I have to say it was not a smooth transition. Felt like a complete idiot for a good amount of time. But after spending a few months with it I’ve really gotten to see the power and use for the k8s infrastructure and its value as a tool/platform. And honestly, I’m digging it. It’s really cool stuff and once you get developers writing production services and applications that would otherwise have been virtualized on dedicated systems on it, they love it to for their speed of delivery and development. But we’re also managing hundreds of projects with multiple applications/services with high availability, so OCP/Kube makes sense for us.
ioror93jf 7y ago
Because Google, AWS, & MS need everyone to focus on their needs, guh. If any of them could drive the Nix project from within their own walls we would be going that route.
whateveracct 7y ago
Network effects and money mostly (hype as you say). NixOps is a great tool..when it works. When it doesn't, it's not inherent. It's just that it is clearly not heavily invested in by any entity with a bunch of money.
parhamn 7y ago
I mean thats not doing much... You can docker run anything in a line. A few lines of terraform or any other deployment tool can run a binary on EC2 (and roll forward, and have state management, and so on). The complexity comes when you want to do something more interesting.
- movedx 7y ago
  > The complexity comes when you want to do something more interesting. And for 500,000,000 people.
gravypod 7y ago
Kube is one layer that you use to get to a completely platform independent version of this. Look at kubecfg for an example of this being applied. When Cuelang, the next step after jsonnet, is finished and integrated with kubecfg it will be basically this with: 1. Run anything anywhere (no platform lockin) 2. The ability to talk about your arch using a shared dialect 3. Tooling that integrated with the API server for everything storage and DB (things like Rook), networking and security (CNIs), observability (Service Mesh), and many more abstractions. Kube is the low level dialect. The tooling around it makes it work like you want.
- ryan_lane 7y ago
  Run anything anywhere, as long as you don't any feature of the platform, except for compute. You're still tied in to the platform, or you're likely not doing too much.
  - gravypod 7y ago
    You can build controllers and CRDs to completely integrate any platform features you need all while maintaining a workflow with kubecfg and using kube to manage state recovery, roll out, and networking.
    - movedx 7y ago
      My problem with Kubernetes is people adopt it without understanding it. They adopt it because everyone else is without ever asking, "Why?" I've installed and managed a simple K8s cluster before now and it was a nightmare (this was only a year ago.) It wasn't until we moved the management of the cluster to a managed service that it became worth it. It was at THAT point it was worth containerising the application(s) (another complexity to overcome) and letting K8s handle the deployment and scaling. I'm worried that as an engineering culture we're not pushing back enough and saying, "Yeah K8s is cool but look: do you really need it? It's very likely you don't". For me to automatically recommend K8s to my clients I'd need to see a (near) zero friction deployment options that's fully feature compliant and truely fully managed. It's at that point I would be happy to say, "Sure! Let's go with K8s and just write YAML files to deploy our containers!" (And then there's the whole debate as to whether or not you even need a container around your monolith... probably not. Then the next debate about people starting out with microservices when we all know that's not a good idea.)
anonytrary 7y ago
I don't think declarative architecture and kubernetes are mutually exclusive. Seems like you could write a declarative file (terraform, cloudformation, etc.) that deploys a dockerized app to a kubernetes cluster in AWS.
- arianvanp 7y ago
  Thing is; nixos has been architected for being declarative from the start. Whilst Kubernetes is a stateful REST API. Sure you can emulate a declarative view on top of a mutable thing (Think React and virtualdom), but having a declarative core makes declarative deployments easier to manage and more elegant. E.g. in Kubernetes automatically deleting a resource is still hard; It's hard to figure out when something is not "used" anymore. In nix, you simply run `nix garbage-collect` and all the things that are not referenced by your declaration are automatically deleted.
Thaxll 7y ago
Because this is a toy demo that doesn't do anything, in the real world you need much more that than just to do something simple. Also it looks "beautiful" to your eye, from a programming perspecting it looks really un-readable if you don't use FP. https://github.com/Gabriel439/simple-twitter/blob/master/Main.hs#L174 https://github.com/Gabriel439/simple-twitter/blob/master/Mai...
- adrusi 7y ago
  from a programming perspecting it looks really un-readable if you don't use FP. I don't mean this as a slight, and I myself am slacking in the same regard, but it's depressing to me that this attitude is so prevalent among professionals. There might be some good engineering reasons that tools like Docker and Kubernetes have much more traction than Nix, but "it's unfamiliar if you don't use FP" is a terrible one. It doesn't require that much investment to become familiar, and there seems to be many fantastic advantages to functional approaches. Why does our industry tolerate this laziness?
  - ajdlinux 7y ago
    I haven't touched FP languages in years, but my first year undergraduate intro programming course was taught in Haskell... FP principles aren't so difficult that the average programmer can't learn them to at least a basic level.
    - rimliu 7y ago
      And pretty much any widely used language already provides functional features.
  - chongli 7y ago
    but "it's unfamiliar if you don't use FP" is a terrible one I get the sense that there is a large contingent of programmers who feel disdain for mathematics and FP gets caught in the crossfire. It’s unfair toward both mathematics and functional programming. I would love it if North American culture could adopt a better attitude toward mathematics in general. I think far too many people decide they’re bad at mathematics at some point in high school and never look back. This attitude is far less prevalent in many Asian cultures, where the emphasis is put on hard work instead of talent.

by cblum 7y ago

bitlax 7y ago

Libraries, helper functions, support, etc.

agumonkey 7y ago

Plausible. There's nix and guix, and maybe others. There's intetest and worth but it may take time.

ar_lan 7y ago

Curious - what don't you like about Kubernetes?

movedx 7y ago
Repeating my reply to this question asked by someone else above. I genuinely want to engage people on this question. --- My problem with Kubernetes is people adopt it without understanding it. They adopt it because everyone else is without ever asking, "Why?" I've installed and managed a simple K8s cluster before now and it was a nightmare (this was only a year ago.) It wasn't until we moved the management of the cluster to a managed service that it became worth it. It was at THAT point it was worth containerising the application(s) (another complexity to overcome) and letting K8s handle the deployment and scaling. I'm worried that as an engineering culture we're not pushing back enough and saying, "Yeah K8s is cool but look: do you really need it? It's very likely you don't". For me to automatically recommend K8s to my clients I'd need to see a (near) zero friction deployment options that's fully feature compliant and truely fully managed. It's at that point I would be happy to say, "Sure! Let's go with K8s and just write YAML files to deploy our containers!" (And then there's the whole debate as to whether or not you even need a container around your monolith... probably not. Then the next debate about people starting out with microservices when we all know that's not a good idea.)
- ar_lan 7y ago
  I work with Kubernetes quite a bit, so I'm reasonably knowledgable on the pro's and con's. I definitely think there is a misunderstanding about what Kubernetes solves. I think Kubernetes is very good at helping structure very large applications where a split of micro-services makes sense. Most start-ups don't need it - it's likely overkill, and unless you go with a vendor you're likely to set it up incorrectly. But it is an advantage in much larger, spread out teams if the culture surrounding all the teams makes sense. If sub-teams can handle their applications really well, which many companies have achieved, then it does provide significant benefits over monoliths. I think the problem you're noticing is that everyone wants to jump onto Kubernetes without realizing why it's even there - the same with micro-services. I shudder when I hear that from my friends with no more than 10 people on their development team, but I think it makes a lot more sense when I see teams of >200 complaining that their huge monolith is what causes the most friction.
  - movedx 7y ago
    Absolutely spot on. This is my experience too and this is also howI feel about it. It's an excellent piece of kit, but like most tools it has to be not only used correctly but also in the right context.

YawningAngel 7y ago

What do you think is wrong with kubernetes, out of interest?

lhuser123 7y ago
I think is referring to abstractions in general. Levels and levels of abstractions. Not always a bad idea but sometimes it ends up complicating things too much and burning new comers brains.
- ikeyany 7y ago
  The levels of abstraction seem to be a hazing ritual that seems to be a point of pride sometimes. I also imagine it's good job security for those who spent years on these tools.
  - jacobush 7y ago
    Aw man. When I started in this industry we made new employees build their work PC from parts.
- cblum 7y ago
  Yep, exactly this. Whenever I try to grasp it, I feel like things are being abstracted beyond comprehension. It doesn’t feel right. That, and the fact that it seems like you need to adopt about 100 completely heterogeneous tools to successfully manage a Kubernetes cluster.
  - mroche 7y ago
    I went from using Singularity to bundle scientific tools for HPC cluster useage at my university straight into admining OpenShift at my current employer and I have to say it was not a smooth transition. Felt like a complete idiot for a good amount of time. But after spending a few months with it I’ve really gotten to see the power and use for the k8s infrastructure and its value as a tool/platform. And honestly, I’m digging it. It’s really cool stuff and once you get developers writing production services and applications that would otherwise have been virtualized on dedicated systems on it, they love it to for their speed of delivery and development. But we’re also managing hundreds of projects with multiple applications/services with high availability, so OCP/Kube makes sense for us.

ioror93jf 7y ago

Because Google, AWS, & MS need everyone to focus on their needs, guh. If any of them could drive the Nix project from within their own walls we would be going that route.

whateveracct 7y ago

Network effects and money mostly (hype as you say). NixOps is a great tool..when it works. When it doesn't, it's not inherent. It's just that it is clearly not heavily invested in by any entity with a bunch of money.

parhamn 7y ago

I mean thats not doing much... You can docker run anything in a line. A few lines of terraform or any other deployment tool can run a binary on EC2 (and roll forward, and have state management, and so on). The complexity comes when you want to do something more interesting.

movedx 7y ago
> The complexity comes when you want to do something more interesting. And for 500,000,000 people.

gravypod 7y ago

Kube is one layer that you use to get to a completely platform independent version of this. Look at kubecfg for an example of this being applied. When Cuelang, the next step after jsonnet, is finished and integrated with kubecfg it will be basically this with: 1. Run anything anywhere (no platform lockin) 2. The ability to talk about your arch using a shared dialect 3. Tooling that integrated with the API server for everything storage and DB (things like Rook), networking and security (CNIs), observability (Service Mesh), and many more abstractions. Kube is the low level dialect. The tooling around it makes it work like you want.

ryan_lane 7y ago
Run anything anywhere, as long as you don't any feature of the platform, except for compute. You're still tied in to the platform, or you're likely not doing too much.
- gravypod 7y ago
  You can build controllers and CRDs to completely integrate any platform features you need all while maintaining a workflow with kubecfg and using kube to manage state recovery, roll out, and networking.
  - movedx 7y ago
    My problem with Kubernetes is people adopt it without understanding it. They adopt it because everyone else is without ever asking, "Why?" I've installed and managed a simple K8s cluster before now and it was a nightmare (this was only a year ago.) It wasn't until we moved the management of the cluster to a managed service that it became worth it. It was at THAT point it was worth containerising the application(s) (another complexity to overcome) and letting K8s handle the deployment and scaling. I'm worried that as an engineering culture we're not pushing back enough and saying, "Yeah K8s is cool but look: do you really need it? It's very likely you don't". For me to automatically recommend K8s to my clients I'd need to see a (near) zero friction deployment options that's fully feature compliant and truely fully managed. It's at that point I would be happy to say, "Sure! Let's go with K8s and just write YAML files to deploy our containers!" (And then there's the whole debate as to whether or not you even need a container around your monolith... probably not. Then the next debate about people starting out with microservices when we all know that's not a good idea.)

anonytrary 7y ago

I don't think declarative architecture and kubernetes are mutually exclusive. Seems like you could write a declarative file (terraform, cloudformation, etc.) that deploys a dockerized app to a kubernetes cluster in AWS.

arianvanp 7y ago
Thing is; nixos has been architected for being declarative from the start. Whilst Kubernetes is a stateful REST API. Sure you can emulate a declarative view on top of a mutable thing (Think React and virtualdom), but having a declarative core makes declarative deployments easier to manage and more elegant. E.g. in Kubernetes automatically deleting a resource is still hard; It's hard to figure out when something is not "used" anymore. In nix, you simply run `nix garbage-collect` and all the things that are not referenced by your declaration are automatically deleted.

Thaxll 7y ago

Because this is a toy demo that doesn't do anything, in the real world you need much more that than just to do something simple. Also it looks "beautiful" to your eye, from a programming perspecting it looks really un-readable if you don't use FP. https://github.com/Gabriel439/simple-twitter/blob/master/Main.hs#L174 https://github.com/Gabriel439/simple-twitter/blob/master/Mai...

adrusi 7y ago
from a programming perspecting it looks really un-readable if you don't use FP. I don't mean this as a slight, and I myself am slacking in the same regard, but it's depressing to me that this attitude is so prevalent among professionals. There might be some good engineering reasons that tools like Docker and Kubernetes have much more traction than Nix, but "it's unfamiliar if you don't use FP" is a terrible one. It doesn't require that much investment to become familiar, and there seems to be many fantastic advantages to functional approaches. Why does our industry tolerate this laziness?
- ajdlinux 7y ago
  I haven't touched FP languages in years, but my first year undergraduate intro programming course was taught in Haskell... FP principles aren't so difficult that the average programmer can't learn them to at least a basic level.
  - rimliu 7y ago
    And pretty much any widely used language already provides functional features.
- chongli 7y ago
  but "it's unfamiliar if you don't use FP" is a terrible one I get the sense that there is a large contingent of programmers who feel disdain for mathematics and FP gets caught in the crossfire. It’s unfair toward both mathematics and functional programming. I would love it if North American culture could adopt a better attitude toward mathematics in general. I think far too many people decide they’re bad at mathematics at some point in high school and never look back. This attitude is far less prevalent in many Asian cultures, where the emphasis is put on hard work instead of talent.