4 ms·

I am interested in people's opinion on the "break even point" between using Kubernetes and not using Kubernetes. Let's pretend that the only options are Kuberne

I am interested in people's opinion on the "break even point" between using Kubernetes and not using Kubernetes. Let's pretend that the only options are Kubernetes and something substantially less powerful. What is the simplest/easiest personal project where using Kubernetes might be justified? I am a junior software engineer trying to figure out how to contextualize all of these container/container management systems.

l_t 8y ago
IMO, Kubernetes is one of those things where if you have to ask, you don't need it. It's only really "justified" if you're actually using features like: - High availability services (more than one copy running at once). - Service discovery (services talking to each other in a resilient way). - Ability to automate operational tasks. - Rolling deployments of services. Very few personal projects will tick those boxes -- by the time they do, they've usually evolved into a full-on "real project". Doesn't mean you can't mess around with Kubernetes for fun and learning, of course. But from a purely practical perspective, it's overkill unless you have all of those requirements above. (If you just have one or two of those needs, there is usually a simpler tool to fulfill it with less overhead).
- fulafel 8y ago
  If you need high availability, you get into the second order effects: consider the risk from the complexity of the HA setup, your lack of experience with its failure modes, and lack of low level access to the managed kubernetes service? If you are not a seasoned SRE, there are a lot of "unknown unknowns" for you waiting around the corner.
  - l_t 8y ago
    Yeah, great point. Kubernetes done right can help with these things, but done wrong, it can cause more problems than it solves. Of course, for a personal project, hitting those "unknown unknowns" is all part of the growing process, but in a business context I would be even more hesitant to adopt K8s unless you already have an ops team that's ready to support it.
eropple 8y ago
This is a little bit negotiable, but it's where I'd start considering Kubernetes: 1. at least six independent twelve-factor-app services with their own datastores and a need for high availability across all of them and a near-complete understanding of the high-availability interactions between instances of your services 2. an inability to predict ahead of time where your system's hot spots are, necessitating rapid scaling of different parts of the application 3. a willingness to overspend on capacity to be able to respond to scaling events or deploys in seconds rather than minutes 4. an code-focused ops team (as opposed to a mouse-driven ops team) with extremely strong diagnostic skills and the bandwidth to babysit a service with a potential pain-in-the-ass ceiling around that of a Cassandra cluster Without #1, you don't have enough variation in systems to benefit; just stick a monolithic application in an autoscaling group. (Most people should do this.) Without #2, you can lean into the hot spots of your application by scaling them horizontally--bear in mind that you'll be paying for capacity you don't use with k8s in order to get that environmental reactivity, so you could just spend that on making your hot spots faster. Without #3...well, that one's pretty obvious when you look at things like EC2 instances, which are more easily partitioned, can be spun up in smaller/cheaper groupings, and their primary downside is that it takes longer than deploying a container. And without #4, you're gonna go off the cliff. Reasonable people can nibble at the edges. But to answer the thrust of your question: it's probably never reasonable to design a personal project around k8s unless the point of the project is to be done on k8s.
- tetha 8y ago
  > 4. an code-focused ops team (as opposed to a mouse-driven ops team) with extremely strong diagnostic skills and the bandwidth to babysit a service with a potential pain-in-the-ass ceiling around that of a Cassandra cluster Here it is running fine... running fine.. running fine... aaaaand there's a compaction-and-gc cycle of death and fire and lost data and tears. Thank you for this terrible memory.
  - eropple 8y ago
    I was going to say "we've all been there," but we haven't, and that's the deceptive thing about the five-minute-demo culture that a lot of "devops" has gotten into. Everything is easy when it has nothing riding on it. When it isn't is where the value of a tool comes into focus.
krishicks 8y ago
Like with anything, it should be evaluated based on what your needs are. For a simple deploy you probably don't need Kubernetes or even containers. If you are running containers, you'll need a mechanism for running them. And maybe at some point you want something to recreate them when they die or become unhealthy. Maybe you want to run multiple containers, and you want to do rolling deploys of them. Maybe you want to run them on multiple hosts and network them together. Maybe you want to be able to attach a persistent disk to some of them, or interface with some secrets management software. And maybe you want a single, well-supported API for doing all of the above. There's a lot more that can be said about Kubernetes; it offers a lot out of the box as well as an API for extending it when you need behavior it doesn't provide.

l_t 8y ago

IMO, Kubernetes is one of those things where if you have to ask, you don't need it. It's only really "justified" if you're actually using features like: - High availability services (more than one copy running at once). - Service discovery (services talking to each other in a resilient way). - Ability to automate operational tasks. - Rolling deployments of services. Very few personal projects will tick those boxes -- by the time they do, they've usually evolved into a full-on "real project". Doesn't mean you can't mess around with Kubernetes for fun and learning, of course. But from a purely practical perspective, it's overkill unless you have all of those requirements above. (If you just have one or two of those needs, there is usually a simpler tool to fulfill it with less overhead).

fulafel 8y ago
If you need high availability, you get into the second order effects: consider the risk from the complexity of the HA setup, your lack of experience with its failure modes, and lack of low level access to the managed kubernetes service? If you are not a seasoned SRE, there are a lot of "unknown unknowns" for you waiting around the corner.
- l_t 8y ago
  Yeah, great point. Kubernetes done right can help with these things, but done wrong, it can cause more problems than it solves. Of course, for a personal project, hitting those "unknown unknowns" is all part of the growing process, but in a business context I would be even more hesitant to adopt K8s unless you already have an ops team that's ready to support it.

eropple 8y ago

This is a little bit negotiable, but it's where I'd start considering Kubernetes: 1. at least six independent twelve-factor-app services with their own datastores and a need for high availability across all of them and a near-complete understanding of the high-availability interactions between instances of your services 2. an inability to predict ahead of time where your system's hot spots are, necessitating rapid scaling of different parts of the application 3. a willingness to overspend on capacity to be able to respond to scaling events or deploys in seconds rather than minutes 4. an code-focused ops team (as opposed to a mouse-driven ops team) with extremely strong diagnostic skills and the bandwidth to babysit a service with a potential pain-in-the-ass ceiling around that of a Cassandra cluster Without #1, you don't have enough variation in systems to benefit; just stick a monolithic application in an autoscaling group. (Most people should do this.) Without #2, you can lean into the hot spots of your application by scaling them horizontally--bear in mind that you'll be paying for capacity you don't use with k8s in order to get that environmental reactivity, so you could just spend that on making your hot spots faster. Without #3...well, that one's pretty obvious when you look at things like EC2 instances, which are more easily partitioned, can be spun up in smaller/cheaper groupings, and their primary downside is that it takes longer than deploying a container. And without #4, you're gonna go off the cliff. Reasonable people can nibble at the edges. But to answer the thrust of your question: it's probably never reasonable to design a personal project around k8s unless the point of the project is to be done on k8s.

tetha 8y ago
> 4. an code-focused ops team (as opposed to a mouse-driven ops team) with extremely strong diagnostic skills and the bandwidth to babysit a service with a potential pain-in-the-ass ceiling around that of a Cassandra cluster Here it is running fine... running fine.. running fine... aaaaand there's a compaction-and-gc cycle of death and fire and lost data and tears. Thank you for this terrible memory.
- eropple 8y ago
  I was going to say "we've all been there," but we haven't, and that's the deceptive thing about the five-minute-demo culture that a lot of "devops" has gotten into. Everything is easy when it has nothing riding on it. When it isn't is where the value of a tool comes into focus.

krishicks 8y ago

Like with anything, it should be evaluated based on what your needs are. For a simple deploy you probably don't need Kubernetes or even containers. If you are running containers, you'll need a mechanism for running them. And maybe at some point you want something to recreate them when they die or become unhealthy. Maybe you want to run multiple containers, and you want to do rolling deploys of them. Maybe you want to run them on multiple hosts and network them together. Maybe you want to be able to attach a persistent disk to some of them, or interface with some secrets management software. And maybe you want a single, well-supported API for doing all of the above. There's a lot more that can be said about Kubernetes; it offers a lot out of the box as well as an API for extending it when you need behavior it doesn't provide.