3 ms·

Amazon publishing a blog that blatantly argues for vendor lock-in? Who would have guessed? One of the big benefits of Kubernetes is the cloud-agnostic API for

Amazon publishing a blog that blatantly argues for vendor lock-in? Who would have guessed? One of the big benefits of Kubernetes is the cloud-agnostic API for running pretty much any application. CustomResources can help blur that boundary and make it easier to use some managed services, but actually arguing in favor of that approach for everything is a pure advertising tactic. It's no secret that managed services are several times more expensive than equivalent EC2 time. Sometimes it's worth it. But to throw Kubernetes into the mix just to run some controllers that deploy those services will pointlessly add to your monthly bill. Running any Kubernetes cluster is not cheap, even if it's just a bunch of controllers.

mreferre 4y ago
[ Disclaimer: Author of the blog here ] I knew this blog was very polarizing so this is a fair comment. I have called out advantages and disadvantages in the first scenario ("The pros of this approach is that the customer is decoupling heavily from the infrastructure underneath thus enabling better portability of their entire platform. The cons of doing this is that the customer is signing up for a high amount of work.") and, in retrospect, I should have called them out explicitly for the last scenario (I have just assumed readers could infer they would be the opposite). I did mention towards the end that "customers [that can benefit from the third model ] are coming from an Amazon ECS background, they are all in into Amazon ECS and AWS" but I take to heart the suggestion that I should have been more explicit. Thanks.
joshribakoff 4y ago
> It’s arguably an extreme option and one that doesn’t even exist today How is it blatantly arguing for this thing when it literally calls it extreme and something that doesn’t exist? I think a more fair criticism would be the fact they don’t call out vendor lock-in as a tradeoff > to throw Kubernetes into the mix just to run some controllers that deploy those services will pointlessly add to your monthly bill. I think you have a valid point it may be dubious but the article does outline purported reasons it could make sense for some people. I dont think there is a “right way” and a “wrong way” here, rather there is the way “you would do it” and “the way they’re proposing as an option”
- mac-chaffee 4y ago
  The author admits it's extreme, but is clearly trying to normalize it: > Someone defines Kubernetes as “a well-designed and extensible API with programmable reconciliation logic, that happens to come with a container orchestrator built in.” I like that definition.
cmeacham98 4y ago
Disclaimer: I work for AWS but had nothing to do with this blog post (I'm seeing it for the first time with everyone else here). I think this is an unfair summary of the post. Of course, using Kubernetes to orchestrate other AWS services is going to be a go-to example on the _AWS_ blog, but there is plenty of vendor-agnostic software doing similar things: DNS Records[1], Databases[2], even using Kubernetes CRDs to deploy Kubernetes[3]. The idea of using Kubernetes as an API to orchestrate external resources doesn't inherently lock you into any single vendor. 1: https://github.com/kubernetes-sigs/external-dns https://github.com/kubernetes-sigs/external-dns 2: https://github.com/kubedb/operator https://github.com/kubedb/operator 3: https://cluster-api.sigs.k8s.io/ https://cluster-api.sigs.k8s.io/
vbezhenar 4y ago
I'm running self-managed kubernetes cluster. Overhead is as follows (/month): 1 x load balancer: $20 3 x master servers: 4GB RAM, 2 CPU, 15 GB SSD: 3 * $20 = $60 also on every worker server around 15% of RAM is dedicated to kubernetes pods (kubelet). So slightly higher price for RAM and CPU. So basically overhead is like $100/month. Or $50/month with one master server which is not very reliable but acceptable for small workloads. If your project runs on $5/month VPS, Kubernetes is pure overhead. If you're paying $500/month, Kubernetes is something to consider.
- rektide 4y ago
  I also ran a single instance k3s node on my personal $8/mo 3gb vps, and it took up around 400MB. Ran some workloads, a postgres operator. Ingreds via traefik on the node. I think my overhead was like $1.20/mo. Did I have fancy HA? No. But it was an easy way to manage workloads & learn skills. Works fine.
- bryanlarsen 4y ago
  You're paying 4x as much for your self-managed cluster as I am for a vendor managed cluster. I have a single-node digital ocean cluster without a load balancer.
- steveBK123 4y ago
  Maybe I'm ignorant, but why would you pay $1200/year for the compute/storage/ram equivalent of a 5 year old iPhone?
dopylitty 4y ago
As I was reading this I thought it was calling for using the K8s API as an abstraction over all types of backend compute vendors. That would actually avoid vendor lock-in. Set up one control plane somewhere and use it to manage your AWS, Azure, GCP, on-prem VMWare etc. That would mean you need the K8s API for your control plane but not necessarily that you have to run a K8s cluster or clusters as long as the API layer is the same. Maybe the control plane is a managed service too and you just interact with it. I'm a bit skeptical of these single pane of glass type solutions since the abstractions always end up being somewhat leaky. The abstraction turtle stack is so high at this point you have to know 11 different technologies just to start a process on a Linux box. But I get the operational appeal of having a central control plane rather than a million control planes all with their own AuthN/AuthZ, logging, custom YAML DSL, APIs, security configurations, integration points etc.
- Chmouel 4y ago
  I think that's the actual goal of kcp: https://github.com/kcp-dev/kcp https://github.com/kcp-dev/kcp
- gladiatr72 4y ago
  There's an old apache project: libcloud (python) that tried to generalize various cloud service apis. It was.. not good.

mreferre 4y ago

[ Disclaimer: Author of the blog here ] I knew this blog was very polarizing so this is a fair comment. I have called out advantages and disadvantages in the first scenario ("The pros of this approach is that the customer is decoupling heavily from the infrastructure underneath thus enabling better portability of their entire platform. The cons of doing this is that the customer is signing up for a high amount of work.") and, in retrospect, I should have called them out explicitly for the last scenario (I have just assumed readers could infer they would be the opposite). I did mention towards the end that "customers [that can benefit from the third model ] are coming from an Amazon ECS background, they are all in into Amazon ECS and AWS" but I take to heart the suggestion that I should have been more explicit. Thanks.

joshribakoff 4y ago

> It’s arguably an extreme option and one that doesn’t even exist today How is it blatantly arguing for this thing when it literally calls it extreme and something that doesn’t exist? I think a more fair criticism would be the fact they don’t call out vendor lock-in as a tradeoff > to throw Kubernetes into the mix just to run some controllers that deploy those services will pointlessly add to your monthly bill. I think you have a valid point it may be dubious but the article does outline purported reasons it could make sense for some people. I dont think there is a “right way” and a “wrong way” here, rather there is the way “you would do it” and “the way they’re proposing as an option”

mac-chaffee 4y ago
The author admits it's extreme, but is clearly trying to normalize it: > Someone defines Kubernetes as “a well-designed and extensible API with programmable reconciliation logic, that happens to come with a container orchestrator built in.” I like that definition.

cmeacham98 4y ago

Disclaimer: I work for AWS but had nothing to do with this blog post (I'm seeing it for the first time with everyone else here). I think this is an unfair summary of the post. Of course, using Kubernetes to orchestrate other AWS services is going to be a go-to example on the _AWS_ blog, but there is plenty of vendor-agnostic software doing similar things: DNS Records[1], Databases[2], even using Kubernetes CRDs to deploy Kubernetes[3]. The idea of using Kubernetes as an API to orchestrate external resources doesn't inherently lock you into any single vendor. 1: https://github.com/kubernetes-sigs/external-dns https://github.com/kubernetes-sigs/external-dns 2: https://github.com/kubedb/operator https://github.com/kubedb/operator 3: https://cluster-api.sigs.k8s.io/ https://cluster-api.sigs.k8s.io/

vbezhenar 4y ago

I'm running self-managed kubernetes cluster. Overhead is as follows (/month): 1 x load balancer: $20 3 x master servers: 4GB RAM, 2 CPU, 15 GB SSD: 3 * $20 = $60 also on every worker server around 15% of RAM is dedicated to kubernetes pods (kubelet). So slightly higher price for RAM and CPU. So basically overhead is like $100/month. Or $50/month with one master server which is not very reliable but acceptable for small workloads. If your project runs on $5/month VPS, Kubernetes is pure overhead. If you're paying $500/month, Kubernetes is something to consider.

rektide 4y ago
I also ran a single instance k3s node on my personal $8/mo 3gb vps, and it took up around 400MB. Ran some workloads, a postgres operator. Ingreds via traefik on the node. I think my overhead was like $1.20/mo. Did I have fancy HA? No. But it was an easy way to manage workloads & learn skills. Works fine.
bryanlarsen 4y ago
You're paying 4x as much for your self-managed cluster as I am for a vendor managed cluster. I have a single-node digital ocean cluster without a load balancer.
steveBK123 4y ago
Maybe I'm ignorant, but why would you pay $1200/year for the compute/storage/ram equivalent of a 5 year old iPhone?

dopylitty 4y ago

As I was reading this I thought it was calling for using the K8s API as an abstraction over all types of backend compute vendors. That would actually avoid vendor lock-in. Set up one control plane somewhere and use it to manage your AWS, Azure, GCP, on-prem VMWare etc. That would mean you need the K8s API for your control plane but not necessarily that you have to run a K8s cluster or clusters as long as the API layer is the same. Maybe the control plane is a managed service too and you just interact with it. I'm a bit skeptical of these single pane of glass type solutions since the abstractions always end up being somewhat leaky. The abstraction turtle stack is so high at this point you have to know 11 different technologies just to start a process on a Linux box. But I get the operational appeal of having a central control plane rather than a million control planes all with their own AuthN/AuthZ, logging, custom YAML DSL, APIs, security configurations, integration points etc.

Chmouel 4y ago
I think that's the actual goal of kcp: https://github.com/kcp-dev/kcp https://github.com/kcp-dev/kcp
gladiatr72 4y ago
There's an old apache project: libcloud (python) that tried to generalize various cloud service apis. It was.. not good.