5 ms·

And I might cynically offer it was "invented" to solve the problem of ex-googlers not having any useful immediately transferable skills as the Google internal t

And I might cynically offer it was "invented" to solve the problem of ex-googlers not having any useful immediately transferable skills as the Google internal tech stack had nothing in common with industry.

jvolkman 4y ago
But the internal tech stack doesn't have much in common with Kubernetes, either.
jrockway 4y ago
That's not really been my experience. The number of people who knew how to deploy software at Google was much smaller than the number of people writing software there. I was certainly the only person on my team who ever dealt with the nitty gritty of running stuff in production. That seems about like the industry standard; I'd say the average software engineer in industry, inside or outside Google, considers their work done when their code is merged. At my first job outside of Google we used something called Convox, which was very similar to running things in production at Google. You triggered a package build from your workstation (!) and then adjusted production to pick that up. Very similar to mpm packages and GCL files. (The difference is that Google had some machinery to say "while the build might have been triggered from a workstation, all this code has actually been checked in and reviewed". Convox did not have that part, so yeah, you could just edit some files and push them to production without checking them in, which wasn't great. But when you are a 4 person development team, not the end of the world by any means.)
lacker 4y ago
In 2005 Google search got into a sticky spot, where they were completely unable to deploy new versions of the search engine from the master branch of the code for a while, because there were performance regressions that nobody could find. Deployment and related things like "deploy a copy of the production configuration to these spare 2000 machines" were manual slogs. I was the noob on the team doing such important yet unfulfilling tasks as "backport this Python performance testing script to Python 1.x because our only working test environment doesn't have the same version of Python as production does". This was before borg aka kubernetes, and let me tell you, a whole bunch of stuff was dysfunctional and broken. All this is not to say that Kubernetes is the right solution to your problem, or to almost anyone's problem. It was just an improvement to Google's infrastructure, for the sort of problems that Google had. For some people it makes sense... for you it might not.
- dlp211 4y ago
  Borg is not K8S, K8S is not borg. Borg is far more advanced in its scaling abilities.

jvolkman 4y ago

But the internal tech stack doesn't have much in common with Kubernetes, either.

jrockway 4y ago

That's not really been my experience. The number of people who knew how to deploy software at Google was much smaller than the number of people writing software there. I was certainly the only person on my team who ever dealt with the nitty gritty of running stuff in production. That seems about like the industry standard; I'd say the average software engineer in industry, inside or outside Google, considers their work done when their code is merged. At my first job outside of Google we used something called Convox, which was very similar to running things in production at Google. You triggered a package build from your workstation (!) and then adjusted production to pick that up. Very similar to mpm packages and GCL files. (The difference is that Google had some machinery to say "while the build might have been triggered from a workstation, all this code has actually been checked in and reviewed". Convox did not have that part, so yeah, you could just edit some files and push them to production without checking them in, which wasn't great. But when you are a 4 person development team, not the end of the world by any means.)

lacker 4y ago

In 2005 Google search got into a sticky spot, where they were completely unable to deploy new versions of the search engine from the master branch of the code for a while, because there were performance regressions that nobody could find. Deployment and related things like "deploy a copy of the production configuration to these spare 2000 machines" were manual slogs. I was the noob on the team doing such important yet unfulfilling tasks as "backport this Python performance testing script to Python 1.x because our only working test environment doesn't have the same version of Python as production does". This was before borg aka kubernetes, and let me tell you, a whole bunch of stuff was dysfunctional and broken. All this is not to say that Kubernetes is the right solution to your problem, or to almost anyone's problem. It was just an improvement to Google's infrastructure, for the sort of problems that Google had. For some people it makes sense... for you it might not.

dlp211 4y ago
Borg is not K8S, K8S is not borg. Borg is far more advanced in its scaling abilities.