4 ms·

In that case use a managed cluster and it’s less work.

speedgoose 6y ago
It has about the same issues but because it's managed and because you are a small company, nobody cares about your issues and you can do nothing about it.
zimbatm 6y ago
You still have to do upgrades every 3 months, sometimes with breaking changes. Because the underlying infrastructure gets replaced, it means spinning up a new cluster, deploying the application on it to make sure that everything is working. Then switch the traffic to it. If the cluster hold any state this can be quite a bit of work to replicate all of the data.
- q3k 6y ago
  Kubernetes clusters can be upgraded in place, though? GKE definitely allows you to do that.
  - zimbatm 6y ago
    It works most of the time. I have also seen multiple in-place upgrades ending up in weird places. Or some resource having changed API and we had to rush to upgrade the code. What will you do if that happens? It's a bit like upgrading Postgres. It's a good idea to at least make a backup before changing the underlying storage.
  - dharmab 6y ago
    Yes, if you’re careful and do your research. Once you start extending Kubernetes you can back yourself into corners. We’ve also found breaking bugs in Kubernetes that prevented in-place upgrades in some cases (which we reported upstream and were patched).
capableweb 6y ago
zimbatm mentioned "early startups", I take that to assume you've just started the company and you're working on getting the product market fit right. There is absolutely no need for any clusters for that, unless you're anticipating Google-level traffic on launch day. Most companies today are better off NOT running distributed anything, as everything will get harder to do, from logging to deployments. People start with clusters when they really should start with centralized services and only go distributed when they need to.
- zimbatm 6y ago
  Indeed. A single machine is often more than enough for early startups. It's easy for developers to understand and debug. What's important is to put the tooling in place to make the deployment reproducible. Deploy using Terraform and Docker to the single VM. Avoid modifying things manually. That's what provides the agility to then scale the infrastructure into bigger shapes as needed. That's why we developed https://github.com/numtide/terraform-provider-linuxbox https://github.com/numtide/terraform-provider-linuxbox , to make that use-case even easier.
deleted 6y ago
[deleted]

It has about the same issues but because it's managed and because you are a small company, nobody cares about your issues and you can do nothing about it.

zimbatm 6y ago

You still have to do upgrades every 3 months, sometimes with breaking changes. Because the underlying infrastructure gets replaced, it means spinning up a new cluster, deploying the application on it to make sure that everything is working. Then switch the traffic to it. If the cluster hold any state this can be quite a bit of work to replicate all of the data.

q3k 6y ago
Kubernetes clusters can be upgraded in place, though? GKE definitely allows you to do that.
- zimbatm 6y ago
  It works most of the time. I have also seen multiple in-place upgrades ending up in weird places. Or some resource having changed API and we had to rush to upgrade the code. What will you do if that happens? It's a bit like upgrading Postgres. It's a good idea to at least make a backup before changing the underlying storage.
- dharmab 6y ago
  Yes, if you’re careful and do your research. Once you start extending Kubernetes you can back yourself into corners. We’ve also found breaking bugs in Kubernetes that prevented in-place upgrades in some cases (which we reported upstream and were patched).

capableweb 6y ago

zimbatm mentioned "early startups", I take that to assume you've just started the company and you're working on getting the product market fit right. There is absolutely no need for any clusters for that, unless you're anticipating Google-level traffic on launch day. Most companies today are better off NOT running distributed anything, as everything will get harder to do, from logging to deployments. People start with clusters when they really should start with centralized services and only go distributed when they need to.

zimbatm 6y ago
Indeed. A single machine is often more than enough for early startups. It's easy for developers to understand and debug. What's important is to put the tooling in place to make the deployment reproducible. Deploy using Terraform and Docker to the single VM. Avoid modifying things manually. That's what provides the agility to then scale the infrastructure into bigger shapes as needed. That's why we developed https://github.com/numtide/terraform-provider-linuxbox https://github.com/numtide/terraform-provider-linuxbox , to make that use-case even easier.

deleted 6y ago

[deleted]