3 ms·

In some respects K8s is a bit of a step backwards from Heroku or AppEngine. It's complicated and requires you master its learning curves to deliver benefits.

In some respects K8s is a bit of a step backwards from Heroku or AppEngine. It's complicated and requires you master its learning curves to deliver benefits. This looks like a lot of cloud products which are becoming more complicated to sell to bigger companies where they have the ops teams dedicated learning these products. You get an 'easy' to setup demo with a lot of copy-paste or bash|sh but you'll need a PhD for running your own apps in production. And each product is a different learning curve and they don't always play nice. The next paradigm is composability and simplification. I should be able to define an application, its configuration, what it needs to talk to, and level of desired spend for which availability/performance SLO and it should mostly just work. Security should just work and each perimeter is automatically configured - without managing separate configuration for admin APIs, end user auth, peer auth, k8 network policies, firewall policies, etc. I shouldn't have to care about runtime - GKE vs Cloud Run vs Lambda or optimizing Node shapes or whatever new product launched yesterday. If I push a production change there should be a consistent way of simulating, canarying, and slowing rolling that change out across all products. Ideally, it should basically be a marketplace of commodity network/compute/storage and the providers are dynamically bidding for my business. If you can run my application as fast or as reliable with less spend, you get the business - if not the app magically moves the provider that can.

odonnellryan 5y ago
My problem with kubernetes is for a lot of stuff you don't know what is happening really. I recently installed cert manager and the config file alone for that resource was 5k lines generated by helm. That is just crazy. I want to know generally how that part of the app is configured (it is a user facing cert) and it isn't that complicated in the real world when you set things up with nginx. I feel like I probably should trust the people working on these products more than I trust me securing a Linux box, but... I dunno if I'm there yet.
rektide 5y ago
> In some respects K8s is a bit of a step backwards from Heroku or AppEngine. It's complicated and requires you master its learning curves to deliver benefits. what, exactly, do you think kubernetes is? what is the central design philosohy of it? how does it work? can you name anything about kubernetes that makes it better or different than Heroku or AppEngine? nothing you've said gives me confidenc you can identify the most basic strengths or competencies here, that you can identify how kubernetes is different from the more prosaic & narrow platforms which came before it &nehat that meams. kis is a different take than just an app delivery platform, but i dont see that recognizance here. to me, you are propoing we should all switch from planes to bicycles because bicycles are simpler & all folks need. this reductionism is a misservice to real debate over what & where we should go. endless consumerization of computing, treating all computing workloads as services for petty end-users, who need dumb simple integrated ways to continue shipping legacy software platforms, bundled into fancier containers, is a dead end shithole future. by themselves, simplicity & composability buy us nothing but low-ended-ness. they reduce our ability to think & integrate & fins better cloud patterns to make software with. thankfully i see little potential threat out there from this proposal that we make ourselves more naive. tbis beleif that we can just somehow snap our fingers & simplify & the complexity goes away doesnt seem to ne enough. what i do have faith in are better management tools & practices taht emerge atop & integrating with existing full-blooded clous platforma like kunernetes. folks like ArgoCD or Flux provide a pretty reasonable seveloper experience somewhere reasonably between Herokus bramch-based deployment model & the modern open source cloud platform. last, but definitely not least: what specifically does your comment have to do with this link that was shared? i dont see any direct connection to the link. it seems like you just wanted to dump a generic opinion on us, to neg kubernetes broadly. how if at all have you engaged the material in thia video in your negging? edit: very quickly to -2. im not playing kind but i think silicon deserved heavily to be challenged. if you disagree, i think words are appropriate.
- YPPH 5y ago
  I'm not dang, but I would suggest you review the news guidelines, both in respect of the content of the comment and commenting on the votes on your comment. You should take the comment at its highest and assume the person understands K8s, rather than introducing doubt about the person's competency to speak on the subject by, in effect, cross-examining them. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
p_l 5y ago
Kubernetes explicitly targets the layer below a PaaS (there used to be a nice sliding demo at Google Cloud Next 2017 in SF, with a moving slider between cloud functions and I think either full VM or bare metal). Also, it's drastically simpler than the software it heavily pushed out, and provides a lot of composability and simplification in fact compared to what was there before - but due to needs of flexibility and not being a magical genie (or Sufficiently Advanced Orchestrator) it leaves certain things on the table. What you describe is closer to goals of TOSCA and similar, which are supposed to be parsed by service providers implemented for example on top of Kubernetes or OpenStack or <insert your imagined platform here>. It turns out it's non-trivial, though kubernetes pushing simple standard API interaction led to interesting development in that area.
halayli 5y ago
If Heroku/AppEngine is all you need then keep using them. But comparing apples and oranges and claiming that one is a step backwards is nonsensical. One is a service and one is a software that you can take with you to any cloud provider, and the problems they solve are different in nature with slight overlap.
mohanmcgeek 5y ago
If I were using a managed k8s offering + a gitops ci/cd tool like flux, what would I be missing?

odonnellryan 5y ago

My problem with kubernetes is for a lot of stuff you don't know what is happening really. I recently installed cert manager and the config file alone for that resource was 5k lines generated by helm. That is just crazy. I want to know generally how that part of the app is configured (it is a user facing cert) and it isn't that complicated in the real world when you set things up with nginx. I feel like I probably should trust the people working on these products more than I trust me securing a Linux box, but... I dunno if I'm there yet.

rektide 5y ago

> In some respects K8s is a bit of a step backwards from Heroku or AppEngine. It's complicated and requires you master its learning curves to deliver benefits. what, exactly, do you think kubernetes is? what is the central design philosohy of it? how does it work? can you name anything about kubernetes that makes it better or different than Heroku or AppEngine? nothing you've said gives me confidenc you can identify the most basic strengths or competencies here, that you can identify how kubernetes is different from the more prosaic & narrow platforms which came before it &nehat that meams. kis is a different take than just an app delivery platform, but i dont see that recognizance here. to me, you are propoing we should all switch from planes to bicycles because bicycles are simpler & all folks need. this reductionism is a misservice to real debate over what & where we should go. endless consumerization of computing, treating all computing workloads as services for petty end-users, who need dumb simple integrated ways to continue shipping legacy software platforms, bundled into fancier containers, is a dead end shithole future. by themselves, simplicity & composability buy us nothing but low-ended-ness. they reduce our ability to think & integrate & fins better cloud patterns to make software with. thankfully i see little potential threat out there from this proposal that we make ourselves more naive. tbis beleif that we can just somehow snap our fingers & simplify & the complexity goes away doesnt seem to ne enough. what i do have faith in are better management tools & practices taht emerge atop & integrating with existing full-blooded clous platforma like kunernetes. folks like ArgoCD or Flux provide a pretty reasonable seveloper experience somewhere reasonably between Herokus bramch-based deployment model & the modern open source cloud platform. last, but definitely not least: what specifically does your comment have to do with this link that was shared? i dont see any direct connection to the link. it seems like you just wanted to dump a generic opinion on us, to neg kubernetes broadly. how if at all have you engaged the material in thia video in your negging? edit: very quickly to -2. im not playing kind but i think silicon deserved heavily to be challenged. if you disagree, i think words are appropriate.

YPPH 5y ago
I'm not dang, but I would suggest you review the news guidelines, both in respect of the content of the comment and commenting on the votes on your comment. You should take the comment at its highest and assume the person understands K8s, rather than introducing doubt about the person's competency to speak on the subject by, in effect, cross-examining them. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

p_l 5y ago

Kubernetes explicitly targets the layer below a PaaS (there used to be a nice sliding demo at Google Cloud Next 2017 in SF, with a moving slider between cloud functions and I think either full VM or bare metal). Also, it's drastically simpler than the software it heavily pushed out, and provides a lot of composability and simplification in fact compared to what was there before - but due to needs of flexibility and not being a magical genie (or Sufficiently Advanced Orchestrator) it leaves certain things on the table. What you describe is closer to goals of TOSCA and similar, which are supposed to be parsed by service providers implemented for example on top of Kubernetes or OpenStack or <insert your imagined platform here>. It turns out it's non-trivial, though kubernetes pushing simple standard API interaction led to interesting development in that area.

halayli 5y ago

If Heroku/AppEngine is all you need then keep using them. But comparing apples and oranges and claiming that one is a step backwards is nonsensical. One is a service and one is a software that you can take with you to any cloud provider, and the problems they solve are different in nature with slight overlap.

mohanmcgeek 5y ago

If I were using a managed k8s offering + a gitops ci/cd tool like flux, what would I be missing?