4 ms·

You aren't supposed to use a tool made for Google level complexity unless you work with such complexity in the first place.

by oxff 4y ago

k8sToGo 4y ago
I don't think that is true. Kubernetes brings a lot of advantages to people who have to manage infrastructure (like me). It gives me a single interface that I can apply across multiple teams. They all only need to provide me with a docker image and that's mostly it. Also what is the alternative? Self-written unmaintainable bash-scripts? That's what they had before. Every team had their own way of deployment, creating packages,.... It was quite the nightmare. To be fair, we use EKS, so a lot of the annoying work is done by AWS.
- treis 4y ago
  >Also what is the alternative? Docker compose. Or if we're getting wild pick a technology, use it across the company, and rely on language tools to establish the APIs between modules. Then deploy the application however the language provides.
  - itintheory 4y ago
    >Docker compose. Swarm is a closer alternative, although it's future is unclear. Another alternative is Nomad.
- nomorecodehere8 4y ago
  The first thing with bash scripts is you need to use a type system. Enforce json as your configuration language. Then have error handling as part of a default shell function library that emits json. All you are doing then is passing bad returns to a function that can emit json and reviewing json configurations for shell script variable definitions. Don't do in shell scripts what you can do in terraform. Don't use ansible/salt/puppet for what can be done in shell scripts. Shell scripts and makefiles go to CI/CD agencies (Jenkins). Ansible, terraform, etc...go to services that specialize in these.
guywhocodes 4y ago
Where do I go for my 3-5 node cluster which I want to schedule containers to, run dynamic workloads etc? How do I build a container based DAG in a small cluster today without k8s? Solutions that are not k8s tend to be single programming language/sdk based or not easier to set up. I get the feeling the alternatives are dying off unnaturally fast.
- drbojingle 4y ago
  What exactly are you making that requires the use of multiple languages?
  - discreteevent 4y ago
    It would seem that the requirement for multiple languages often has nothing to do with making something or the customer requirements. It's often a developer requirement. Developers want to work in their favorite language. In the 90s you just wrote in whatever the company or ecosystem had mandated. Now that developers are in high demand they can specify what they want to use. It started with books like "Beyond java" (and java was beyond C++) and disparaging articles by the likes of Paul Graham. They made some good points but if you have ever worked on a single system with multiple languages and are honest about it you would have to say that it wastes an enormous amount of time and generates unnecessary complexity. When a developer has to make a microservice just to write part of the system in another language you have wonder if they have the ability to evaluate technical trade-offs. Just pick one language and get on with it.
    - drbojingle 4y ago
      Kinda what I expect as well. I could understand it if a company was bringing in whole teams to scale up development of a large project quickly. Even then support would could be a nightmare. Doing it just because sounds painful.
  - guywhocodes 4y ago
    My problem needing multiple machines is less weird than needing more than python for my dag?
tazjin 4y ago
As a Xoogler I'd say that Kubernetes is harder to use than Google's internal equivalents. It may not be harder to run, but that doesn't matter inside of Google unless you're on the teams responsible for the base layers. My point is, Kubernetes isn't really "made for Google level complexity" - Google only uses it for a handful of cloud products, internal research stuff and not much else.
- fn1 4y ago
  Why did Google then release the complex Kubernetes to the world than their simpler internal tools?
  - zikduruqe 4y ago
    It's a ninja smoke bomb to distract the tech world into thinking we are cool like Google.
  - eadmund 4y ago
    I've long wondered if K8s is really a dastardly scheme to hold back the industry …
  - amannm 4y ago
    To loosen up AWS-entrenched customers and their much more varied use-cases, probably.
  - tazjin 4y ago
    It's basically impossible to release this kind of internal tooling due to the way Google works. You'd have to rewrite it, or open-source essentially the entire foundation, and Google probably doesn't want to do either.

You aren't supposed to use a tool made for Google level complexity unless you work with such complexity in the first place.

by oxff 4y ago

You aren't supposed to use a tool made for Google level complexity unless you work with such complexity in the first place.

k8sToGo 4y ago

I don't think that is true. Kubernetes brings a lot of advantages to people who have to manage infrastructure (like me). It gives me a single interface that I can apply across multiple teams. They all only need to provide me with a docker image and that's mostly it. Also what is the alternative? Self-written unmaintainable bash-scripts? That's what they had before. Every team had their own way of deployment, creating packages,.... It was quite the nightmare. To be fair, we use EKS, so a lot of the annoying work is done by AWS.

treis 4y ago
>Also what is the alternative? Docker compose. Or if we're getting wild pick a technology, use it across the company, and rely on language tools to establish the APIs between modules. Then deploy the application however the language provides.
- itintheory 4y ago
  >Docker compose. Swarm is a closer alternative, although it's future is unclear. Another alternative is Nomad.
nomorecodehere8 4y ago
The first thing with bash scripts is you need to use a type system. Enforce json as your configuration language. Then have error handling as part of a default shell function library that emits json. All you are doing then is passing bad returns to a function that can emit json and reviewing json configurations for shell script variable definitions. Don't do in shell scripts what you can do in terraform. Don't use ansible/salt/puppet for what can be done in shell scripts. Shell scripts and makefiles go to CI/CD agencies (Jenkins). Ansible, terraform, etc...go to services that specialize in these.

guywhocodes 4y ago

Where do I go for my 3-5 node cluster which I want to schedule containers to, run dynamic workloads etc? How do I build a container based DAG in a small cluster today without k8s? Solutions that are not k8s tend to be single programming language/sdk based or not easier to set up. I get the feeling the alternatives are dying off unnaturally fast.

drbojingle 4y ago
What exactly are you making that requires the use of multiple languages?
- discreteevent 4y ago
  It would seem that the requirement for multiple languages often has nothing to do with making something or the customer requirements. It's often a developer requirement. Developers want to work in their favorite language. In the 90s you just wrote in whatever the company or ecosystem had mandated. Now that developers are in high demand they can specify what they want to use. It started with books like "Beyond java" (and java was beyond C++) and disparaging articles by the likes of Paul Graham. They made some good points but if you have ever worked on a single system with multiple languages and are honest about it you would have to say that it wastes an enormous amount of time and generates unnecessary complexity. When a developer has to make a microservice just to write part of the system in another language you have wonder if they have the ability to evaluate technical trade-offs. Just pick one language and get on with it.
  - drbojingle 4y ago
    Kinda what I expect as well. I could understand it if a company was bringing in whole teams to scale up development of a large project quickly. Even then support would could be a nightmare. Doing it just because sounds painful.
- guywhocodes 4y ago
  My problem needing multiple machines is less weird than needing more than python for my dag?

tazjin 4y ago

As a Xoogler I'd say that Kubernetes is harder to use than Google's internal equivalents. It may not be harder to run, but that doesn't matter inside of Google unless you're on the teams responsible for the base layers. My point is, Kubernetes isn't really "made for Google level complexity" - Google only uses it for a handful of cloud products, internal research stuff and not much else.

fn1 4y ago
Why did Google then release the complex Kubernetes to the world than their simpler internal tools?
- zikduruqe 4y ago
  It's a ninja smoke bomb to distract the tech world into thinking we are cool like Google.
- eadmund 4y ago
  I've long wondered if K8s is really a dastardly scheme to hold back the industry …
- amannm 4y ago
  To loosen up AWS-entrenched customers and their much more varied use-cases, probably.
- tazjin 4y ago
  It's basically impossible to release this kind of internal tooling due to the way Google works. You'd have to rewrite it, or open-source essentially the entire foundation, and Google probably doesn't want to do either.