I also started (non-trivially) contributing to OSS with OpenStack, and later switched to contributing to Kubernetes. I whole-heartedly agree with the points made here; these same observations really shaped how I chose to contribute to Kubernetes.
Trying to get all the AWS early adopters to abandon their investment and move to something else seemed like it was a huge barrier to adoption, so I started off contributing to the AWS support for kubernetes and making sure that kubernetes worked well there. But the pains of installing OpenStack from upstream were fresh in my mind, so I also contributed to make sure that kube-up worked well and then (as we outgrew that architecture) started the kOps project. My goal is that you should always be able to run OSS kubernetes from upstream, even if you just treat that as an insurance policy that gives you the confidence to use a managed service.
I think the miracle of kubernetes is that I was just one of a large number of people here, each of us bringing our past experiences to make kubernetes better in some way. And the community continues to grow with people each addressing their own painpoints, which does create a lot of churn/progress (depending on your perspective!) I'd say that the people that organized the community were the unsung heroes here, and I suspect they learned a lot from OpenStack as well.
It turned out to be somewhat tricky, because it increased the size of the Node object, and colocating node heartbeats onto the same object meant that a bigger object was changing relatively often. But that was addressed by moving heartbeats to a different object: https://github.com/kubernetes/enhancements/issues/589
Maybe it could be read that way, but I think it's a good indication of the problem that a strict reading doesn't include that. The article advocates that you should be using Heroku or Vercel or Netlify or Fly as not doing so is an antipattern, but it then says that instead of k8s "Most organisations should consider some of the higher-level building blocks available via cloud providers", which seems contradictory.
I quite liked the actual message of the article (which I take as "be mindful of your technology choices") - but I think that it is really devalued by the less coherent but more click-baity arguments (e.g. "javascript is the only rational language choice")
Edit: Actually, re-reading the article yet again, I think I can see your reading (though I wish you had written the article, as your writing is much clearer). As I understand it, the article says you should use a PaaS-style solution until you outgrow it, when you should move to something from the cloud providers. For me, that would be CloudRun -> GKE-Autopilot -> GKE (skipping CloudRun if you don't want to learn two systems), but there may be some google-bias there!
The problem with this sort of argument is that it sets up a straw-man, without describing what you should do instead. Kubernetes could be better - of course - but what better approach is the author recommending to use instead? It would be better if we could use one language on frontend and backend - of course - but what is this one language that works everywhere? It would be better - of course - if there was a SaaS that could do everything for us, is cheap and is open source - but what is that SaaS?
It's very easy to say something could be improved, but much harder to propose something to replace it that doesn't have its own shortcomings.
It's a pity because this article actually makes a good point, that we should think about what the actual user/business goal is before making technical decisions, and be careful lest we spend all our time on technology. I've heard this idea described as "innovation tokens". It's disappointing that the article chose to wrap this idea in clickbait, but I guess we wouldn't be talking about it otherwise!
Disclaimer: I have no end of personal biases in favor of kubernetes!
The only nuclear plant under construction in the US is at Plant Vogtle, in Georgia. Regulators set up a system (CWIP) whereby the companies building the plant earn a 10% return on their costs, until the plants come online. I think it's not surprising therefore that costs keep increasing and the delays keep coming. I don't think we can infer that nuclear power plants cannot be built at reasonable cost, rather that we need to consider "regulatory capture" as a significant construction risk.
Thanks for the input on kops. There's a lot of functionality in kops - e.g. we can manage CNI providers, etcd etc. In some places this manifests as more code, but my gut is that if you add up all the code you're relying on it turns out to be a wash. And you can definitely use kops from CI, driving it from yaml files that are checked in to git - that seems to be a great configuration particularly for people managing large numbers of clusters.
The long-term strategy is to get most of the kops functionality upstreamed into standalone community projects - and we're making progress with etcdadm, addon-operators, cluster-api etc. Then it will be easy to write your own tooling if you don't like some of the kops decisions, but still benefit from the community investment in e.g. etcd management etc. kops itself becomes a thinner shim around those shared common pieces. A lot of the decisions that are now generally agreed (e.g. dynamically attaching etcd volumes) weren't as well accepted when we started off, so it was harder to get them going as community efforts!
We do have support for "phases" in kops which should allow you to use a provided VPC, but to be honest it's still not as easy as the rest of kops is. We also have a few PRs in-flight that to allow you to specify an alternative to an IGW e.g. a VPN, but it's hard to reach consensus (but I guess we should based on your input!). The big trade-off here is that once you start allowing arbitrary configuration, you lose the ability to validate things, and so for some fraction of people there are going to be mistakes. That works great for small community projects, it is really great if your business model is paid support, but for a large community project it really can be problematic. I don't think we've got the balance totally correct in kops, but that's the trade-off we wrestle with.
Yes, the reality is probably somewhere in between. We've heard that users like the idea that kops releases are more ready, where the .0 releases of k8s might have more issues particularly with ecosystem components. So we do lag a little behind - ideally one release.
1.12 has been a particularly tricky release getting everyone from etcd2 -> etcd3, but we've finally turned the corner on that one, so that should now let us catch up a bit.
Finally, we've also heard that users want more of a choice, so we're going to start doing e.g. 1.13-alpha and 1.14 alphas much sooner. We'll still wait to do kops 1.14.0 until everything is ready, but for users that want to run k8s 1.14 sooner, they will have an option that isn't building from source. And hopefully this also gets more people using pre-release versions of kops (in non-production environments) and also helps stabilize the releases more rapidly.
Yes, we're waiting till 1.11.6 lands - some important fixes for clouds in there. We've debated releasing at the same time as Kubernetes, but the feedback we've got is that users prefer that a kops release is ready to run, but we also need to do a better job of releasing alphas & betas earlier.
Obviously the current delay is not great - I'd much prefer for us to be on 1.12 (which actually has fixed the main issue already). I'm hoping we can catch up once we're (finally) done with the etcd3 migration.
I can assure you that's not the case! Also, while people like to repeat this meme, Google Cloud does have a formal deprecation policy (https://cloud.google.com/terms/), whose intent is to give you some assurances.
(I work at Google, on GKE, though I am not a lawyer and thus don't work on the deprecation policy)
My working assumption is that 18006 should have closed out 18005. But now it sounds like there's a different issue, which we're working to get to the bottom of.
Hi - I work at Google on GKE - sorry about the problems you're experiencing. There's a lot of people inside Google looking into this right now!
It looks like the UI issue was actually fixed, and that we just didn't update the status dashboard correctly. But we're double checking that and looking into some of the additional things you all have reported here.
The article suggests that the difference is the water recirculation - that the "waste" water is cleaned rather than being removed. Is that how your farm's raceway worked?
Which company is that from, and did you include the surcharges? I'm on Georgia Power on the R-22 residential tariff, and I pay about twice as much as the "headline rate", once I've added them all in: http://www.psc.state.ga.us/calc/electric/GPcalc.asp
Ah - sorry, probably should have disclaimered that! I did write the original kops code, but now there's a pretty active set of contributors working on kops (and contributions are always welcome and appreciated!)
kops 1.9 is very close to ready now, but this is a longer lag than normal. We've historically released kops 1.x when we consider that k8s 1.x is stable, including all the networking providers and ecosystem components. That's typically about a month after release.
User feedback has been that that we want to keep that, but that we should also offer an alpha/beta of 1.10 much sooner, so that users that want to try out 1.10 today can do so (and so we get feedback earlier). So watch for kops 1.10 alpha very soon, and 1.11 alpha much earlier in the 1.11 cycle.
Trying to get all the AWS early adopters to abandon their investment and move to something else seemed like it was a huge barrier to adoption, so I started off contributing to the AWS support for kubernetes and making sure that kubernetes worked well there. But the pains of installing OpenStack from upstream were fresh in my mind, so I also contributed to make sure that kube-up worked well and then (as we outgrew that architecture) started the kOps project. My goal is that you should always be able to run OSS kubernetes from upstream, even if you just treat that as an insurance policy that gives you the confidence to use a managed service.
I think the miracle of kubernetes is that I was just one of a large number of people here, each of us bringing our past experiences to make kubernetes better in some way. And the community continues to grow with people each addressing their own painpoints, which does create a lot of churn/progress (depending on your perspective!) I'd say that the people that organized the community were the unsung heroes here, and I suspect they learned a lot from OpenStack as well.