4 ms·

Where would you draw the dividing line between where you think it does make sense to use something like Kubernetes and where it doesn't?

wayoutthere 7y ago
There isn’t a dividing line per se; every operating model is going to have different breakpoints. In general though, I would consider Kubernetes an “enterprise technology”. If you’re a startup you’re going to be better off paying AWS/Heroku for one of their more managed services than hiring someone to build / manage a Kubernetes cluster.
- falcolas 7y ago
  A note on this - AWS (or any other host's) managed k8s will not reduce the need to understand what's going on under the hood. It's still k8s, you're just not running the daemons to make it work (which is, arguably, the easy part).
bryanlarsen 7y ago
You've signed an > 99.9% availability SLA with a customer and a service like Elastic Beanstalk or Heroku isn't sufficient for your needs.
- falcolas 7y ago
  Technically, the cloud in general probably isn't for you, since none of them guarantee more than 3x9's on any of their services.
  - bryanlarsen 7y ago
    Yup, meant to say >= 99.9%. Of course most businesses operate more like what Cloudflare makes explicit with it's "100%" SLA. Architect for 3 nines and then just pay the penalty when the 3 nines architecture doesn't hit 4 nines.
cies 7y ago
If you need your workload to span over an (possibly growing) number of server hardwares, you may want to use k8s. There are other options that are good contenders in case of such a workload.
xemdetia 7y ago
I'm starting to feel that the whether or not you need Kubernetes is closer to old conversations related to whether or not you need a dedicated DBA. Can your organization survive and recover with hourly/nightly backup restores to recover from an incident? Is your replication so complex that you really need a guy to ensure that's never getting into a bad state? Worse case scenario can most people working on the project restore the database to a valid state if something does go wrong? I feel like these questions have similar representatives in whether or not Kubernetes is right for an organization. Kubernetes also makes more sense if you look at it as a common way for an organization to run applications among disparate teams with a shared operations infrastructure. It provides a standardized model for things to work the same enough to work the same. If you are only delivering one kind/whole organization thing and it all looks and quacks like a duck maybe you should just deliver a duck instead of putting a duck hat on Kubernetes and asking it to quack. I don't think there is anything wrong with designing an application that would transition easily into Kubernetes but I feel like many of the proposals/PoC I have seen in the last few years are either fresh systems that get consumed by Kubernetes complexity or are poor replacements to systems that already exist and only seem to serve as resume padders for the team architecting the replacement which gets a viking funeral as soon as they leave. Often the latter case is because the underlying architecture and goal of the system is pre-Kubernetes and doesn't fit the model well of having mostly stateless/replaceable pieces.
moduspol 7y ago
Kind of implicit in the other responses here are use cases that call for a full cluster and all the complexity that goes along with it. But running a single node cluster is totally valid. I use one at home to run arbitrary containers (a DNS-over-TLS proxy, VPN server, radius server, network AP / switch manager, etc.). I don't use load balancers and just use host-based persistent storage, which removes the vast majority of the complexity. I've seen a lot of people get wrapped up in the complexity of wanting to be able to have a persist storage-backed process go down on one node and come back up on another, and that's not unreasonable, but that's a lot of stuff to figure out early on. If I weren't using this as a single node k8s instance, I might use it to manage VMs, which might be easier to understand but much heavier and more work to maintain. With what I have now, I've got a folder of YAMLs that defines everything to run on my node, and I'm able to easily put all their persistent data in the same top-level dir for easy backup. I think the perception of k8s might change over time once people realize that it provides a lot of value even if you completely rule out the tougher stuff to do on bare metal (like load balancers and shared persistent volumes).

wayoutthere 7y ago

There isn’t a dividing line per se; every operating model is going to have different breakpoints. In general though, I would consider Kubernetes an “enterprise technology”. If you’re a startup you’re going to be better off paying AWS/Heroku for one of their more managed services than hiring someone to build / manage a Kubernetes cluster.

falcolas 7y ago
A note on this - AWS (or any other host's) managed k8s will not reduce the need to understand what's going on under the hood. It's still k8s, you're just not running the daemons to make it work (which is, arguably, the easy part).

bryanlarsen 7y ago

You've signed an > 99.9% availability SLA with a customer and a service like Elastic Beanstalk or Heroku isn't sufficient for your needs.

falcolas 7y ago
Technically, the cloud in general probably isn't for you, since none of them guarantee more than 3x9's on any of their services.
- bryanlarsen 7y ago
  Yup, meant to say >= 99.9%. Of course most businesses operate more like what Cloudflare makes explicit with it's "100%" SLA. Architect for 3 nines and then just pay the penalty when the 3 nines architecture doesn't hit 4 nines.

cies 7y ago

If you need your workload to span over an (possibly growing) number of server hardwares, you may want to use k8s. There are other options that are good contenders in case of such a workload.

xemdetia 7y ago

I'm starting to feel that the whether or not you need Kubernetes is closer to old conversations related to whether or not you need a dedicated DBA. Can your organization survive and recover with hourly/nightly backup restores to recover from an incident? Is your replication so complex that you really need a guy to ensure that's never getting into a bad state? Worse case scenario can most people working on the project restore the database to a valid state if something does go wrong? I feel like these questions have similar representatives in whether or not Kubernetes is right for an organization. Kubernetes also makes more sense if you look at it as a common way for an organization to run applications among disparate teams with a shared operations infrastructure. It provides a standardized model for things to work the same enough to work the same. If you are only delivering one kind/whole organization thing and it all looks and quacks like a duck maybe you should just deliver a duck instead of putting a duck hat on Kubernetes and asking it to quack. I don't think there is anything wrong with designing an application that would transition easily into Kubernetes but I feel like many of the proposals/PoC I have seen in the last few years are either fresh systems that get consumed by Kubernetes complexity or are poor replacements to systems that already exist and only seem to serve as resume padders for the team architecting the replacement which gets a viking funeral as soon as they leave. Often the latter case is because the underlying architecture and goal of the system is pre-Kubernetes and doesn't fit the model well of having mostly stateless/replaceable pieces.

moduspol 7y ago

Kind of implicit in the other responses here are use cases that call for a full cluster and all the complexity that goes along with it. But running a single node cluster is totally valid. I use one at home to run arbitrary containers (a DNS-over-TLS proxy, VPN server, radius server, network AP / switch manager, etc.). I don't use load balancers and just use host-based persistent storage, which removes the vast majority of the complexity. I've seen a lot of people get wrapped up in the complexity of wanting to be able to have a persist storage-backed process go down on one node and come back up on another, and that's not unreasonable, but that's a lot of stuff to figure out early on. If I weren't using this as a single node k8s instance, I might use it to manage VMs, which might be easier to understand but much heavier and more work to maintain. With what I have now, I've got a folder of YAMLs that defines everything to run on my node, and I'm able to easily put all their persistent data in the same top-level dir for easy backup. I think the perception of k8s might change over time once people realize that it provides a lot of value even if you completely rule out the tougher stuff to do on bare metal (like load balancers and shared persistent volumes).