9 ms·

This is nice. But the real problem is Kubernetes. What do I mean by that? I mean the setup, care and feeding of K8s. It's nice to have a tool that you can qui

This is nice. But the real problem is Kubernetes. What do I mean by that? I mean the setup, care and feeding of K8s. It's nice to have a tool that you can quickly push stuff to K8s. There are other tools out there that do that too. The thing is this, the majority of people who use K8s, don't need to use K8s. Those people could easily get by with something like Dokku or even just start containers by hand to deploy. Acorn is just perpetuation the cycle of recommending the over-engineering of K8s for small workloads and small companies that really and truly don't need it. I'll say it again people. Spin up a few giant servers and call it a day. Save thousands of dollars in hosting costs and tens of thousands if not hundreds of thousands of dollars in engineer hiring costs. Bonus side effect? 10x performance than a passel of wimpy VPS's. P.S. I'm coming from using K8s in both Google Cloud and on Bare Metal.

V99 4y ago
(Acorn cofounder) We largely agree ourselves (so much we wrote Rancher 1.x with its own simpler runtime, before k8s took over the world). But that's the obvious runtime the market is interested in right now. So what we are focusing on is let the infrastructure/ops team do their k8s thing, but insulate the devs/people that just want to run apps from it. If real demand for it appears, with that abstraction we could write an alternate backend that talks to say Nomad or a-fancy-shell-script-that-runs-docker-cli instead of k8s. And then your app's Acornfile could now run on a totally different runtime, with no (or maybe minimal) changes.
sergey4brin 4y ago
vbezhenar 4y ago
I’m migrating from few giant servers to k8s. So far I like it.
ianbutler 4y ago
You're missing the point of Kubernetes. Kubernetes is so organizations can have a standard way to deploy infrastructure that makes talent and knowledge portable between organizations. Everyone building their infrastructure from a kluge of their own scripts is not the way forward for the industry imo. You're fair to argue then we should have a less complicated tool that's being standardized on but Kubernetes is where the industry is congregating now and that less complicated tool, that satisfies the most use cases and a high level of standardization, has yet to emerge, there have been multiple that have tried but never gained traction or outright proved to actually be more complex to manage once you go beyond small businesses. Personally as a maturing profession we should stop reinventing the wheel for much of our tooling, adopt common tooling across as much of the industry as we can and then draft and produce standards engineers can work by so we stop having so much slop across the industry.
- deleted 4y ago
  [deleted]
- MuffinFlavored 4y ago
  I haven’t met two organizations that do Kubernetes the same way lol
  - pan69 4y ago
    I haven't met two organisations that use Linux in the same way either but what it gives you is a common terminology, understanding and way of thinking.
  - lolinder 4y ago
    But you have met two organizations that do kubernetes. Kubernetes may be overly flexible, but having everyone on k8s is a heck of a lot more standardized than having everyone writing their own bash files.
- datalopers 4y ago
  Kubernetes creates more technical debt and bullshit jobs than anything I've witnessed in the past two decades.
  - geocar 4y ago
    This sounds like you worked for people who wanted to put kubernetes on their CV instead of using it to solve an actual problem.
    - tluyben2 4y ago
      So, most ‘experts’ then? I try to know as little about k8s and aws as I can but because of ‘people who embellished their resume’ (I am trying to be nice here), I had to because most that had it on their resume did ‘something’ with it but not anything usable. Now I can do it myself (but hate it very much) and ask questions during interviews 99% of so called ‘k8s experts’ (…) cannot answer. And I see this now happening more and more in security as well; people ran a vuns detection script once and put security expert on their resume.
mikepurvis 4y ago
I can't speak to production deployment of long lived containers, but absolutely for short-lived CI worker nodes and the like? Being able to point your Jenkins or GitLab CI config at a microk8s (or whatever) installation is a huge step forward from configuring non isolated workers or dealing with docker in that role.
0xedd 4y ago
How do you implement healthcheck? Does the loadbalancer know how the healthceck is implemented? How do you determine it's time to scale? How do you implement always-on-process? service unit, initd, cron? How do you export the logs? How do you inject configs? /etc/environment, profile.d, systemd config, /etc/bestestapp/config? What about secrets? Service discovery? Is unbound/bind9? And on and on and on and on. These items are best done in a standard way. That's a major selling point in k8s. You define and implement these in a consistent way that also integrates seamlessly with other tools. Doubly so on cloud. Less reinventing the wheel means less money. The more teams, the faster this becomes exponentially expensive. Take this into consideration before your next interview.
- nurettin 4y ago
  Set up large baremetal so that you don't have to scale for a long time and by the time you do, you have had your first million users and you can afford spending for inanely complex infra and don't care about aws billing anymore. Set up user services with systemctl, access your logs through journalctl, change your configs with rsync. And op was arguing against the cloud so giving cloud examples is beside the point. No need for all the sass.
  - jb_gericke 4y ago
    And when your one big server fails and your first million customers start looking for more stable alternatives?
    - nurettin 4y ago
      Then you have a few hours of downtime. Happens to the best of us.
    - v3ss0n 4y ago
      One big server ( 6 Physical Core Xeon with 64GB of Ram , 1TB Nvme SSD) only cost 80$ a month . Can start with 2-3 big servers across 3 different DC. Equlivant specs would cost easily 300$ a month on AWS/GCP/Azure .
deleted 4y ago
[deleted]
glintik 4y ago
"But the real problem is Kubernetes." Yeah, that's true. Setting up full k8s with scaling, logging, prometheus, etc. for Wordpress(real example from Acorn) - that's definitely a sign you are doing it wrong. 90% of internet websites don't need k8s at all, docker compose covers all needs at very efficient manner.
- vbezhenar 4y ago
  Any website need k8s. Reliability, scalability, observability is needed by everyone. K8s might be too hard to use right now. Too expensive for simple websites. That’s a problem we should solve.
  - glintik 4y ago
    Yes, that’s too expensive, so not for any website. And you can’t solve this.
    - vbezhenar 4y ago
      Why do you think you can’t solve this?
      - glintik 4y ago
        Not me. I’m sane enough. You can’t sell Mercedes with price of Kia.
        vbezhenar 4y ago
        I don't see any particular difference between selling apache/php/mysql hosting and selling k8s namespace with managed monitoring/logging/gitops/etc. It's not a mercedes, it's the same shared CPU/RAM/Storage, just with different software. May be k8s is not ready yet to host completely different applications on the same cluster, but it just means that there's still work to be done for better isolation.

V99 4y ago

(Acorn cofounder) We largely agree ourselves (so much we wrote Rancher 1.x with its own simpler runtime, before k8s took over the world). But that's the obvious runtime the market is interested in right now. So what we are focusing on is let the infrastructure/ops team do their k8s thing, but insulate the devs/people that just want to run apps from it. If real demand for it appears, with that abstraction we could write an alternate backend that talks to say Nomad or a-fancy-shell-script-that-runs-docker-cli instead of k8s. And then your app's Acornfile could now run on a totally different runtime, with no (or maybe minimal) changes.

sergey4brin 4y ago

vbezhenar 4y ago

I’m migrating from few giant servers to k8s. So far I like it.

ianbutler 4y ago

You're missing the point of Kubernetes. Kubernetes is so organizations can have a standard way to deploy infrastructure that makes talent and knowledge portable between organizations. Everyone building their infrastructure from a kluge of their own scripts is not the way forward for the industry imo. You're fair to argue then we should have a less complicated tool that's being standardized on but Kubernetes is where the industry is congregating now and that less complicated tool, that satisfies the most use cases and a high level of standardization, has yet to emerge, there have been multiple that have tried but never gained traction or outright proved to actually be more complex to manage once you go beyond small businesses. Personally as a maturing profession we should stop reinventing the wheel for much of our tooling, adopt common tooling across as much of the industry as we can and then draft and produce standards engineers can work by so we stop having so much slop across the industry.

deleted 4y ago
[deleted]
MuffinFlavored 4y ago
I haven’t met two organizations that do Kubernetes the same way lol
- pan69 4y ago
  I haven't met two organisations that use Linux in the same way either but what it gives you is a common terminology, understanding and way of thinking.
- lolinder 4y ago
  But you have met two organizations that do kubernetes. Kubernetes may be overly flexible, but having everyone on k8s is a heck of a lot more standardized than having everyone writing their own bash files.
datalopers 4y ago
Kubernetes creates more technical debt and bullshit jobs than anything I've witnessed in the past two decades.
- geocar 4y ago
  This sounds like you worked for people who wanted to put kubernetes on their CV instead of using it to solve an actual problem.
  - tluyben2 4y ago
    So, most ‘experts’ then? I try to know as little about k8s and aws as I can but because of ‘people who embellished their resume’ (I am trying to be nice here), I had to because most that had it on their resume did ‘something’ with it but not anything usable. Now I can do it myself (but hate it very much) and ask questions during interviews 99% of so called ‘k8s experts’ (…) cannot answer. And I see this now happening more and more in security as well; people ran a vuns detection script once and put security expert on their resume.

mikepurvis 4y ago

I can't speak to production deployment of long lived containers, but absolutely for short-lived CI worker nodes and the like? Being able to point your Jenkins or GitLab CI config at a microk8s (or whatever) installation is a huge step forward from configuring non isolated workers or dealing with docker in that role.

0xedd 4y ago

How do you implement healthcheck? Does the loadbalancer know how the healthceck is implemented? How do you determine it's time to scale? How do you implement always-on-process? service unit, initd, cron? How do you export the logs? How do you inject configs? /etc/environment, profile.d, systemd config, /etc/bestestapp/config? What about secrets? Service discovery? Is unbound/bind9? And on and on and on and on. These items are best done in a standard way. That's a major selling point in k8s. You define and implement these in a consistent way that also integrates seamlessly with other tools. Doubly so on cloud. Less reinventing the wheel means less money. The more teams, the faster this becomes exponentially expensive. Take this into consideration before your next interview.

nurettin 4y ago
Set up large baremetal so that you don't have to scale for a long time and by the time you do, you have had your first million users and you can afford spending for inanely complex infra and don't care about aws billing anymore. Set up user services with systemctl, access your logs through journalctl, change your configs with rsync. And op was arguing against the cloud so giving cloud examples is beside the point. No need for all the sass.
- jb_gericke 4y ago
  And when your one big server fails and your first million customers start looking for more stable alternatives?
  - nurettin 4y ago
    Then you have a few hours of downtime. Happens to the best of us.
  - v3ss0n 4y ago
    One big server ( 6 Physical Core Xeon with 64GB of Ram , 1TB Nvme SSD) only cost 80$ a month . Can start with 2-3 big servers across 3 different DC. Equlivant specs would cost easily 300$ a month on AWS/GCP/Azure .

deleted 4y ago

[deleted]

glintik 4y ago

"But the real problem is Kubernetes." Yeah, that's true. Setting up full k8s with scaling, logging, prometheus, etc. for Wordpress(real example from Acorn) - that's definitely a sign you are doing it wrong. 90% of internet websites don't need k8s at all, docker compose covers all needs at very efficient manner.

vbezhenar 4y ago
Any website need k8s. Reliability, scalability, observability is needed by everyone. K8s might be too hard to use right now. Too expensive for simple websites. That’s a problem we should solve.
- glintik 4y ago
  Yes, that’s too expensive, so not for any website. And you can’t solve this.
  - vbezhenar 4y ago
    Why do you think you can’t solve this?
    - glintik 4y ago
      Not me. I’m sane enough. You can’t sell Mercedes with price of Kia.
      - vbezhenar 4y ago
        I don't see any particular difference between selling apache/php/mysql hosting and selling k8s namespace with managed monitoring/logging/gitops/etc. It's not a mercedes, it's the same shared CPU/RAM/Storage, just with different software. May be k8s is not ready yet to host completely different applications on the same cluster, but it just means that there's still work to be done for better isolation.