3 ms·

Clever code is bad code. Always aim for simple, obvious code. Do you need kubernetes? Nope. 90% chance you don't. You're right, they probably are having issues

Clever code is bad code. Always aim for simple, obvious code. Do you need kubernetes? Nope. 90% chance you don't. You're right, they probably are having issues with some lasagna architecture right now.

tombert 7y ago
I don't disagree with the thesis of your comment but I feel like people often use this reasoning to simply avoid doing any kind of architecting. Yes, something with Postgres and PHP is probably ok for a lot of usecases, but a) Robin Hood is a pretty big target, and might exceed the simple limits of that, and b) there are plenty of cases where Kubernetes (or any other big orchestration framework like Mesos or Nomad or Docker Swarm) will simplify the codebase. I'll agree that engineers are sometimes a bit too eager to just jump on the new HN tech a bit too early, but it's not like that tech isn't useful, and it's not like it doesn't serve some kind of purpose.
- marcus_holmes 7y ago
  I agree on the need for architecting, except that there's a tendency to do that waaaay prematurely. You don't know where the best place to fragment your monolith is until you've got to the point where there monolith is struggling to keep up, because then you know where the slow bits are and how to scale them. And there's no need to split the whole thing. You can just split off the slow bits. Starting with Kubernetes from the get-go seems insane to me.
  - tombert 7y ago
    I don't run a big successful website, but I do run a Kubernetes cluster at home in my basement. Why? Because the computers I run everything on are six Nvidia Jetson Nanos; I'm a fan of running these because I like having access to a good GPU, and I can leave them running 24/7 without having to feel too guilty about power usage. Just one Nvidia Jetson Nano wouldn't be enough to handle all my server needs (movie streaming, video transcoding, random odds and ends of projects I have), and using a framework like Docker Swarm or Kubernetes makes this relatively easy. Is having the ability to linearly scale my home server overkill? Maybe, but at the same time it certainly felt necessary for the job, and carries the nice advantage that I don't have to rearchitect everything later while trying to shoehorn in the "old" way of doing stuff for compatibility sake. > You don't know where the best place to fragment your monolith is until you've got to the point where there monolith is struggling to keep up, because then you know where the slow bits are and how to scale them. Sure, it's not a silver bullet, and I certainly wouldn't claim it as such. That said, there are reasonable places to expect bottlenecks that can benefit from an architecture; things hitting a spinning disk or making an external HTTP call tend to be slow, so it is often better to model them asynchronously and buffer through a message queue; even if you don't have concrete numbers on your side it's not an unreasonable assumption to make.
ftlio 7y ago
I don't want to know how complicated someone has made their life if K8s can't simplify it.
takeda 7y ago
They recently had a blog about moving to kubernetes https://robinhood.engineering/building-an-application-deployment-platform-on-kubernetes-f6af367d1e05 https://robinhood.engineering/building-an-application-deploy...
siscia 7y ago
Yeahhh I am all down for simplify the stack as much as possible, but up to your necessity. Eventually you will reach a point where you will need clever and fast code.

tombert 7y ago

I don't disagree with the thesis of your comment but I feel like people often use this reasoning to simply avoid doing any kind of architecting. Yes, something with Postgres and PHP is probably ok for a lot of usecases, but a) Robin Hood is a pretty big target, and might exceed the simple limits of that, and b) there are plenty of cases where Kubernetes (or any other big orchestration framework like Mesos or Nomad or Docker Swarm) will simplify the codebase. I'll agree that engineers are sometimes a bit too eager to just jump on the new HN tech a bit too early, but it's not like that tech isn't useful, and it's not like it doesn't serve some kind of purpose.

marcus_holmes 7y ago
I agree on the need for architecting, except that there's a tendency to do that waaaay prematurely. You don't know where the best place to fragment your monolith is until you've got to the point where there monolith is struggling to keep up, because then you know where the slow bits are and how to scale them. And there's no need to split the whole thing. You can just split off the slow bits. Starting with Kubernetes from the get-go seems insane to me.
- tombert 7y ago
  I don't run a big successful website, but I do run a Kubernetes cluster at home in my basement. Why? Because the computers I run everything on are six Nvidia Jetson Nanos; I'm a fan of running these because I like having access to a good GPU, and I can leave them running 24/7 without having to feel too guilty about power usage. Just one Nvidia Jetson Nano wouldn't be enough to handle all my server needs (movie streaming, video transcoding, random odds and ends of projects I have), and using a framework like Docker Swarm or Kubernetes makes this relatively easy. Is having the ability to linearly scale my home server overkill? Maybe, but at the same time it certainly felt necessary for the job, and carries the nice advantage that I don't have to rearchitect everything later while trying to shoehorn in the "old" way of doing stuff for compatibility sake. > You don't know where the best place to fragment your monolith is until you've got to the point where there monolith is struggling to keep up, because then you know where the slow bits are and how to scale them. Sure, it's not a silver bullet, and I certainly wouldn't claim it as such. That said, there are reasonable places to expect bottlenecks that can benefit from an architecture; things hitting a spinning disk or making an external HTTP call tend to be slow, so it is often better to model them asynchronously and buffer through a message queue; even if you don't have concrete numbers on your side it's not an unreasonable assumption to make.

ftlio 7y ago

I don't want to know how complicated someone has made their life if K8s can't simplify it.

takeda 7y ago

They recently had a blog about moving to kubernetes https://robinhood.engineering/building-an-application-deployment-platform-on-kubernetes-f6af367d1e05 https://robinhood.engineering/building-an-application-deploy...

siscia 7y ago

Yeahhh I am all down for simplify the stack as much as possible, but up to your necessity. Eventually you will reach a point where you will need clever and fast code.