5 ms·

My guess is that > 90% of people using Kubernetes will never need to scale elastically. My company uses it, cost a ton of developer time. It gives us high avail

by collyw 6y ago

My guess is that > 90% of people using Kubernetes will never need to scale elastically. My company uses it, cost a ton of developer time. It gives us high availability which is nice, but we have no need for the scaling in the foreseeable future, and that was what was used to sell Kubernetes to our founders.

Guthur 6y ago
Yes, though the GP made no reference to Kubes at all and was talking more generally about AWS. AWS has an absolute tonne of great and not so great services but you can easily use the basic stuff to get quite simple and cost effective solutions. You can YOLO it on the console and not even worry about cloudformation if you want, and if you have no customers it will likely be free tier to boot.
nilkn 6y ago
I see this sentiment a lot online, but k8s for us has been quite simple to learn and use and, like you acknowledged here, solved a lot of availability issues out of the box for us that we previously had to deal with in more manual ways. Better yet, it’s a standardized platform that we can use company-wide and that every engineer understands, including potential hires — that’s very valuable. I feel it has become a common trope to claim k8s is complicated and overkill but we are quite glad we made the move to using it.
- weeboid 6y ago
  Have you ever considered the workforce aspect of technologies? Like, you'll still need devops, and if you aren't at least dabbling in containers and elasticity, you're going to get the luddites.
matthewmacleod 6y ago
Kubernetes was not mentioned by the comment I replied to, which was about AWS. Even then, your founders might have made a bad business decision – which isn't unusual, and companies can often make bad business decisions, such as prioritising investment in scalability when it's not a required feature. They can equally make good business decisions – such as rolling out a relatively standard technology like Kubernetes to gain the workflow and availability features, even though scalability is not required. I agree that it is important to remember that sometimes "old-fashioned" approaches can be totally suitable for some use-cases, and they can be too often written off. But equally let's try not to assume that everyone who rolls out a particular modern technology stack is a gullible fool.

by collyw 6y ago

Guthur 6y ago

Yes, though the GP made no reference to Kubes at all and was talking more generally about AWS. AWS has an absolute tonne of great and not so great services but you can easily use the basic stuff to get quite simple and cost effective solutions. You can YOLO it on the console and not even worry about cloudformation if you want, and if you have no customers it will likely be free tier to boot.

nilkn 6y ago

I see this sentiment a lot online, but k8s for us has been quite simple to learn and use and, like you acknowledged here, solved a lot of availability issues out of the box for us that we previously had to deal with in more manual ways. Better yet, it’s a standardized platform that we can use company-wide and that every engineer understands, including potential hires — that’s very valuable. I feel it has become a common trope to claim k8s is complicated and overkill but we are quite glad we made the move to using it.

weeboid 6y ago
Have you ever considered the workforce aspect of technologies? Like, you'll still need devops, and if you aren't at least dabbling in containers and elasticity, you're going to get the luddites.

matthewmacleod 6y ago

Kubernetes was not mentioned by the comment I replied to, which was about AWS. Even then, your founders might have made a bad business decision – which isn't unusual, and companies can often make bad business decisions, such as prioritising investment in scalability when it's not a required feature. They can equally make good business decisions – such as rolling out a relatively standard technology like Kubernetes to gain the workflow and availability features, even though scalability is not required. I agree that it is important to remember that sometimes "old-fashioned" approaches can be totally suitable for some use-cases, and they can be too often written off. But equally let's try not to assume that everyone who rolls out a particular modern technology stack is a gullible fool.