6 ms·

IaaS is not "the cloud". it was in 2008 when all we had was EC2 and RDS. Today Kubernetes is the antithesis of the cloud - Instead of consuming resources on

IaaS is not "the cloud". it was in 2008 when all we had was EC2 and RDS. Today Kubernetes is the antithesis of the cloud - Instead of consuming resources on demand you're launching VMs that need to run 24/7 and have specific roles and names like "master-1". Might as well rent bare-metal servers. It will cost you less.

deadmutex 6y ago
Doesn't kubernetes also have autoscaling capabilities? https://kubernetes.io/blog/2016/07/autoscaling-in-kubernetes/ https://kubernetes.io/blog/2016/07/autoscaling-in-kubernetes...
- cortesoft 6y ago
  That is autoscaling within the cluster.... not the cluster itself. Although, managed kubernetes clusters let you auto-scale the cluster itself, so i think the GP is wrong.
  - frompdx 6y ago
    Check out Cluster AutoScaler: https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler https://github.com/kubernetes/autoscaler/tree/master/cluster... This tool allows you to autoscale the cluster itself with various cloud providers. There is a list of cloud providers it supports at the end of the readme.
  - cortesoft 6y ago
    I misread the link... it is genuine cluster scaling
DenisM 6y ago
> Might as well rent bare-metal servers In light of this statement, what do you make of the fact that billions of dollars are spent on EC2? And of the people who spend that money?
- nihil75 6y ago
  Outdated. We were further ahead in the abstraction ladder with PaaS, and honestly most apps could run perfectly fine in Beanstalk/App Engine/Cloud Foundry/Heroku. But then the devs demand Jenkins, Artifactory and MongoDB, and instead of using cloud-provider alternatives you're back to defining VPCs and autoscaling groups.
  - shiftpgdn 6y ago
    Thats a whole lot of dangerous vendor lock in you've just listed there.
    - Multicomp 6y ago
      Exactly why we use ec2. If AWS goes belly-up then we use terraform to make the equivalent on whatever new cloud provider pops up and keep going about our day. No vendor lock-in
enos_feedler 6y ago
Does cloud really mean "resources on demand"?
- ableal 6y ago
  Jonathan Schwartz, last CEO of Sun Microsystems, in March 2006: "Frankly, it’s been tough to convince the largest enterprises that a public grid represents an attractive future. Just as I’m sure George Westinghouse was confounded by the Chief Electricity Officers of the time that resisted buying power from a grid, rather than building their own internal utilities." https://jonathanischwartz.wordpress.com/2006/03/20/the-network-is-the-computer/ https://jonathanischwartz.wordpress.com/2006/03/20/the-netwo...
specialp 6y ago
If that is your definition of "cloud" then most stuff running on AWS and other "cloud" providers isn't. I agree that Kubernetes and even containers aren't the end all. I think they are a stepping stone to true on demand where you have the abstraction of just sandboxed processes compiled to WASM or something run wherever. But as of where we are now, it is a good abstraction to get there. It provides a lot of stuff like service discovery, auto-scaling and redundancy. Yes you do need to have instances to run K8s, but that is as of date the only abstraction that we have on all cloud providers, local virtualization, and bare metal. So yes it isn't true on demand "cloud" but in order to work like that you need to fit into your service provider's framework and accept limitations on container size, runtime, deal with warm up times occasionally.
- nihil75 6y ago
  We had (have) discovery, auto-scaling and redundancy in PaaS. Most apps could run just fine in Cloud Foundry/App Engine/Beanstalk/Heroku. But the devs insist on MongoDB & Jenkins instead of using the cloud-provider solution and now you're back to defining VPCs, scaling policies, storage and whatnot.
  - Aeolun 6y ago
    Cloud foundry has been my best experience with enterprise cloud so far. The issue was mainly with the admins not provisioning enough capacity, but for us devs it was fucking magical.
    - harpratap 6y ago
      Knative does exactly that. You can use your buildpacks and everything in Tekton and configure your application via Knative Services. No need to bother about anything else.
frompdx 6y ago
> Might as well rent bare-metal servers. It will cost you less. Long term, but up front costs are what make cloud services appealing. FWIW, it's possible to minimize your idle VM costs to an extent. For example, you could use one or more autoscale groups for your cluster and keep them scaled to one vm each. Then use tools like cluster auto scaler to resize on demand as your workload grows. You are correct that idle vm costs can't be completely avoided. At least not as far as I am aware.
- chx 6y ago
  > > Might as well rent bare-metal servers. It will cost you less. > Long term, but up front costs are what make cloud services appealing. There are no up front costs. GP said rent dedicated, not buy your own metal. If there's anything in cloud it's the many pre-written services (queue, database etc) but GP is right: if you go k8s you aren't going to use many/at all so why not just go and rent cheap servers that get deployed in two minutes instead of renting expesive virtual servers which get deployed in a few seconds?
jjjensen90 6y ago
You are completely wrong. It is trivial to have your k8s control plane and your workload cluster in something like an ASG, and basically know nothing about the nodes in either group. I'm not even using GKS or EKS, just ASGs on AWS. My servers and applications are cattle, not pets. I knew literally nothing about k8s in September and now I have multiple clusters humming along, treating the worker cluster nodes as a generic pool of compute, autoscaling the cluster as well as the pods inside it. Upgrading is a breeze, I have great observability, I can deploy experiments and new applications with a single CI step or click, in fact I have nodes that are killed and get replaced for cost savings by SpotInst in the middle of the business day and I don't even need to know about it. My load balancers and even DNS are all provisioned for me and I can use the same Helm charts to create an identical staging and production environment. Kubernetes IS the spirit of the Cloud and 12 factor apps. It's not that scary, and with tools like Rancher and k3s you can make it even simpler.
- pnako 6y ago
  I don't have a horse in this nonsense but I find it hilarious that even users of Kubeanraenet have some trouble defining what it even is.
  - jjjensen90 6y ago
    No trouble, it is a system that can do many things and has many optional pieces. It is fundamentally a cloud native orchestration system.
- jen20 6y ago
  > Kubernetes IS the spirit of the Cloud and 12 factor apps. I would argue that Kubernetes has _nothing whatsoever_ to do with the spirit of the Cloud, and that in fact "serverless" embodies the spirit of pay-as-you-use consumption models.

deadmutex 6y ago

Doesn't kubernetes also have autoscaling capabilities? https://kubernetes.io/blog/2016/07/autoscaling-in-kubernetes/ https://kubernetes.io/blog/2016/07/autoscaling-in-kubernetes...

cortesoft 6y ago
That is autoscaling within the cluster.... not the cluster itself. Although, managed kubernetes clusters let you auto-scale the cluster itself, so i think the GP is wrong.
- frompdx 6y ago
  Check out Cluster AutoScaler: https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler https://github.com/kubernetes/autoscaler/tree/master/cluster... This tool allows you to autoscale the cluster itself with various cloud providers. There is a list of cloud providers it supports at the end of the readme.
- cortesoft 6y ago
  I misread the link... it is genuine cluster scaling

DenisM 6y ago

> Might as well rent bare-metal servers In light of this statement, what do you make of the fact that billions of dollars are spent on EC2? And of the people who spend that money?

nihil75 6y ago
Outdated. We were further ahead in the abstraction ladder with PaaS, and honestly most apps could run perfectly fine in Beanstalk/App Engine/Cloud Foundry/Heroku. But then the devs demand Jenkins, Artifactory and MongoDB, and instead of using cloud-provider alternatives you're back to defining VPCs and autoscaling groups.
- shiftpgdn 6y ago
  Thats a whole lot of dangerous vendor lock in you've just listed there.
  - Multicomp 6y ago
    Exactly why we use ec2. If AWS goes belly-up then we use terraform to make the equivalent on whatever new cloud provider pops up and keep going about our day. No vendor lock-in

enos_feedler 6y ago

Does cloud really mean "resources on demand"?

ableal 6y ago
Jonathan Schwartz, last CEO of Sun Microsystems, in March 2006: "Frankly, it’s been tough to convince the largest enterprises that a public grid represents an attractive future. Just as I’m sure George Westinghouse was confounded by the Chief Electricity Officers of the time that resisted buying power from a grid, rather than building their own internal utilities." https://jonathanischwartz.wordpress.com/2006/03/20/the-network-is-the-computer/ https://jonathanischwartz.wordpress.com/2006/03/20/the-netwo...

specialp 6y ago

If that is your definition of "cloud" then most stuff running on AWS and other "cloud" providers isn't. I agree that Kubernetes and even containers aren't the end all. I think they are a stepping stone to true on demand where you have the abstraction of just sandboxed processes compiled to WASM or something run wherever. But as of where we are now, it is a good abstraction to get there. It provides a lot of stuff like service discovery, auto-scaling and redundancy. Yes you do need to have instances to run K8s, but that is as of date the only abstraction that we have on all cloud providers, local virtualization, and bare metal. So yes it isn't true on demand "cloud" but in order to work like that you need to fit into your service provider's framework and accept limitations on container size, runtime, deal with warm up times occasionally.

nihil75 6y ago
We had (have) discovery, auto-scaling and redundancy in PaaS. Most apps could run just fine in Cloud Foundry/App Engine/Beanstalk/Heroku. But the devs insist on MongoDB & Jenkins instead of using the cloud-provider solution and now you're back to defining VPCs, scaling policies, storage and whatnot.
- Aeolun 6y ago
  Cloud foundry has been my best experience with enterprise cloud so far. The issue was mainly with the admins not provisioning enough capacity, but for us devs it was fucking magical.
  - harpratap 6y ago
    Knative does exactly that. You can use your buildpacks and everything in Tekton and configure your application via Knative Services. No need to bother about anything else.

frompdx 6y ago

> Might as well rent bare-metal servers. It will cost you less. Long term, but up front costs are what make cloud services appealing. FWIW, it's possible to minimize your idle VM costs to an extent. For example, you could use one or more autoscale groups for your cluster and keep them scaled to one vm each. Then use tools like cluster auto scaler to resize on demand as your workload grows. You are correct that idle vm costs can't be completely avoided. At least not as far as I am aware.

chx 6y ago
> > Might as well rent bare-metal servers. It will cost you less. > Long term, but up front costs are what make cloud services appealing. There are no up front costs. GP said rent dedicated, not buy your own metal. If there's anything in cloud it's the many pre-written services (queue, database etc) but GP is right: if you go k8s you aren't going to use many/at all so why not just go and rent cheap servers that get deployed in two minutes instead of renting expesive virtual servers which get deployed in a few seconds?

jjjensen90 6y ago

You are completely wrong. It is trivial to have your k8s control plane and your workload cluster in something like an ASG, and basically know nothing about the nodes in either group. I'm not even using GKS or EKS, just ASGs on AWS. My servers and applications are cattle, not pets. I knew literally nothing about k8s in September and now I have multiple clusters humming along, treating the worker cluster nodes as a generic pool of compute, autoscaling the cluster as well as the pods inside it. Upgrading is a breeze, I have great observability, I can deploy experiments and new applications with a single CI step or click, in fact I have nodes that are killed and get replaced for cost savings by SpotInst in the middle of the business day and I don't even need to know about it. My load balancers and even DNS are all provisioned for me and I can use the same Helm charts to create an identical staging and production environment. Kubernetes IS the spirit of the Cloud and 12 factor apps. It's not that scary, and with tools like Rancher and k3s you can make it even simpler.

pnako 6y ago
I don't have a horse in this nonsense but I find it hilarious that even users of Kubeanraenet have some trouble defining what it even is.
- jjjensen90 6y ago
  No trouble, it is a system that can do many things and has many optional pieces. It is fundamentally a cloud native orchestration system.
jen20 6y ago
> Kubernetes IS the spirit of the Cloud and 12 factor apps. I would argue that Kubernetes has _nothing whatsoever_ to do with the spirit of the Cloud, and that in fact "serverless" embodies the spirit of pay-as-you-use consumption models.