I'm a single-person ops team for my startup. Granted, I MAY be an exceptional learner and not realize it, but I mostly consider myself an under-achieving stoner.
I chose Kubernetes as our platform a few years ago and it's been absolutely wonderful and only getting better. Every once in a while I do a thought experiment with my co-workers to ensure Kubernetes is still the product for us. It is. We all love it and it makes my job easier. And it's really not that complicated.
Let's go ahead and list a few things Kubernetes Provides at the cost of writing a few YAML files and provisioning some docker containers in our CI/CD stack:
- Service discovery and health checks
- Zero downtime upgrades with rollouts and rollbacks
- Horizontal auto-scaling ( VM AND container )
- Configuration management and secret storage
- Immutable infrastructure
- Automatic SSL provisioning and routing via kube-lego and GCE ingress controller
- Log aggregation and monitoring via Heapster
- Cloud-provider agnostic configurations
- A consistent and approachable API to implement required features onto.
- ( With Google GKE ) Automatic security updates with a set maintenance window.
- Easy deployments with Kubernetes Keel
There are more benefits but these are the ones that come off of the top of my head.
ALSO, it's an opinionated framework that makes doing things "The Right Way" easy and intuitive to do.
In my TINY organization's reckoning, K8 actually makes our lives EASIER rather than more complicated and is considered one of the best decisions we ever made. It gets out of our way and lets us work on the fun stuff.
> In the case of applications that simply don’t have the scale problem, they usually don’t need the added complexity of a self-healing, horizontally scalable system.
If you build on a swamp your castle is going to sink into the swamp. Don't obsess over scale, but plan to scale, even if it's just "We can throw more servers at it."
Self-healing? The author is correct: Probably not necessary.
But scaling goes both ways: Our start-up is counting pennies and saving money wherever we can. Having an auto-scaling pod and node cluster makes so much sense. Our cluster automatically scales up and down based on load, saving us thousands of dollars a month.
> The problem I see with Kubernetes is that the cognitive load in the early parts of a project are simply too high. The number of things you need to create and worry about are a barrier to starting a project and iterating on it quickly. In the early days of a project, feature velocity and iteration speed are the most important factors. I view the Heroku model as the ideal development model. You have a managed hosted Postgres database and you just git push to get new code deployed and out the door. There’s very little to think about. It may not scale to infinity and it may get expensive, but you can worry about those things once you’ve actually got a hit on your hands.
I disagree with the assertion that starting out is difficult ( Or, that it is more difficult than other solutions ), and heroku is EXPENSIVE. With GKE, you are paying for the VMs and little more and get a BUCKET-LOAD more features.
What is this nebulous "complicated part" of setting up kubernetes? You literally hit a button and it creates your cluster.
You can have an application ready to go with three objects: a service, an ingress, and a deployment. I find Heroku to be of a similar complexity with less flexibility.
I get EXCELLENT monitoring and log aggregation by running `helm install datadog` and providing my key. I get a good-enough rabbitmq cluster by calling `helm install rabbitmq`. I get automatically provisioned SSL by calling `helm install kube-lego.`
So I suppose my response would be: No, I don't think it will. I think the complexity is over stated.
This is because you don't manage K8s and don't deal with this complexity. Google does.
Now, imagine a case where suddenly one pod can't ping another, but packets flow okay in reverse direction. The cost suddenly goes up from "writing a few YAML files" to "debugging CNI".
> What is this nebulous "complicated part" of setting up kubernetes? You literally hit a button and it creates your cluster.
That is, if you want to depend on other companies to provide your infrastructure. Which is perfectly reasonable business decision, but the opposite (self-managed bare-metal colocated servers) is also perfectly reasonable.
Obviously if you are spending thousands of dollars per month in infra then you are the target of K8s.
The point of TFA is that most products fail before having to scale to that point.
I'm a single-person ops team for my startup. Granted, I MAY be an exceptional learner and not realize it, but I mostly consider myself an under-achieving stoner.
I chose Kubernetes as our platform a few years ago and it's been absolutely wonderful and only getting better. Every once in a while I do a thought experiment with my co-workers to ensure Kubernetes is still the product for us. It is. We all love it and it makes my job easier. And it's really not that complicated.
Let's go ahead and list a few things Kubernetes Provides at the cost of writing a few YAML files and provisioning some docker containers in our CI/CD stack:
- Service discovery and health checks
- Zero downtime upgrades with rollouts and rollbacks
- Horizontal auto-scaling ( VM AND container )
- Configuration management and secret storage
- Immutable infrastructure
- Automatic SSL provisioning and routing via kube-lego and GCE ingress controller
- Log aggregation and monitoring via Heapster
- Cloud-provider agnostic configurations
- A consistent and approachable API to implement required features onto.
- ( With Google GKE ) Automatic security updates with a set maintenance window.
- Easy deployments with Kubernetes Keel
There are more benefits but these are the ones that come off of the top of my head.
ALSO, it's an opinionated framework that makes doing things "The Right Way" easy and intuitive to do.
In my TINY organization's reckoning, K8 actually makes our lives EASIER rather than more complicated and is considered one of the best decisions we ever made. It gets out of our way and lets us work on the fun stuff.
> In the case of applications that simply don’t have the scale problem, they usually don’t need the added complexity of a self-healing, horizontally scalable system.
If you build on a swamp your castle is going to sink into the swamp. Don't obsess over scale, but plan to scale, even if it's just "We can throw more servers at it."
Self-healing? The author is correct: Probably not necessary.
But scaling goes both ways: Our start-up is counting pennies and saving money wherever we can. Having an auto-scaling pod and node cluster makes so much sense. Our cluster automatically scales up and down based on load, saving us thousands of dollars a month.
> The problem I see with Kubernetes is that the cognitive load in the early parts of a project are simply too high. The number of things you need to create and worry about are a barrier to starting a project and iterating on it quickly. In the early days of a project, feature velocity and iteration speed are the most important factors. I view the Heroku model as the ideal development model. You have a managed hosted Postgres database and you just git push to get new code deployed and out the door. There’s very little to think about. It may not scale to infinity and it may get expensive, but you can worry about those things once you’ve actually got a hit on your hands.
I disagree with the assertion that starting out is difficult ( Or, that it is more difficult than other solutions ), and heroku is EXPENSIVE. With GKE, you are paying for the VMs and little more and get a BUCKET-LOAD more features.
What is this nebulous "complicated part" of setting up kubernetes? You literally hit a button and it creates your cluster.
You can have an application ready to go with three objects: a service, an ingress, and a deployment. I find Heroku to be of a similar complexity with less flexibility.
I get EXCELLENT monitoring and log aggregation by running `helm install datadog` and providing my key. I get a good-enough rabbitmq cluster by calling `helm install rabbitmq`. I get automatically provisioned SSL by calling `helm install kube-lego.`
So I suppose my response would be: No, I don't think it will. I think the complexity is over stated.