6 ms·

You can (and people have) post this to Twitter as a joke with no additional punchline required. So, you've avoided Vendor lock-in. But at what cost? "Cloud na

You can (and people have) post this to Twitter as a joke with no additional punchline required. So, you've avoided Vendor lock-in. But at what cost? "Cloud native" is a buzzword without a meaning. Any modern service, library, or framework understands that it's most likely going to be executed in a Cloud virtualized environment. After that, the differences are negligible. The real power of the cloud isn't that it's "someone else's computers", it's the rich diverse ecosystem of different services that INTERPLAY with one another in "<provider>-native" ways. Whether it's AWS, or Azure, or Google. Pick one, and invest your platform into it. The CNCF landscape may offer you the ability to migrate between a provider easier, but whatever discounts you might realize on raw virtual instance cost per hour will be MINISCULE compared to the A) additional overhead of building cross-cloud, and B) the opportunity cost you will leave on the table of not being able to utilize specialized services from these providers that solve immediately problems you'll need to instead reimplement yourself. Lastly, and now we're getting into personal feelings territory instead of raw facts of "total cost of ownership", the whole CNCF leaves a rotten taste in my mouth by pretending to be an impartial agenda-free organization (a la Apache) when in reality it's origins and real mission are Google's attempted play at competing in the cloud wars from 3rd place. There is no debate about this. At the core of everything in CNCF is Kubernetes. And while you can run Kubernetes on any server in the cloud or otherwise, managing it and maintaining Kubernetes infrastructure is a full time job that anyone who tries wants to immediately delegate to a provider. And here comes along Google saying "Well actually, we have a Manged Kubernetes service in GCP, and wouldn't you know it, it's the best one? I mean you know Kubernetes came froM Google originally right, so it makes sense that we would build the best one." And everyone nods and goes along with it. What percentage of CNCF platforms are running on GCP? 90%? Higher? And once you embrace one of those Managed Kubernetes services, you're just as locked in if you had built on AWS Lambda or Azure Functions, only you've spent way more time and money for ZERO benefit to your actual underlying business.

marcc 6y ago
There's a lot more to Kubernetes than avoiding lock in. Pick your favorite managed provider (GKE?) and stick with it. Use all of the GCP native tooling also so that Google can manage your network ingress and load balancers, TLS certs, etc. You are 100% right that there's still lock in. But Kubernetes does more than avoiding lock in. Kubernetes creates a common interface so that if you chose GCP and I choose AWS and someone else likes DigitalOcean, we can all benefit from using the same tools across the stack. Very few tools on the linked landscape graphic are specific to a single provider. If you choose Kubernetes solely to avoid vendor lock in, then you should reconsider. But if you choose it so that you can easily use any of the tools on this landscape, regardless of where you are hosting your cluster, that's a little different and has a lot more value.
- just-juan-post 6y ago
  I don't see it as Kubernetes being the common interface but containers. So long as an organization uses a container-first philosophy or container-centric workflows for development they can deploy to pretty much anywhere. Kubernetes gets the buzz but containers are the real key to flexibility.
  - ecnahc515 6y ago
    There's way more to this than just the containers (the apps) themselves though. Orchestration is a very big piece of the puzzle, integrating into that layer is traditionally very cloud specific. Without a common orchestration layer you end up re-inventing the wheel a lot. Containers being a common interface is good, but having the orchestration have a common interface (k8s) is also important.
    - radiator 6y ago
      Why would you end up reinventing the wheel though if the orchestrarion layer were not common? No, you would be using the one from your cloud provider. I think that was the point of your greatgrandparent comment.
mstipetic 6y ago
I do not understand these arguments that always come up. Everything Kubernetes gives you out of the box you'd have to reimplement yourself for a production-grade system. From dealing with service discovery, networking, persistence and volume management to enforcing processes. Maybe you have spend some time learning those things, but it's much less in from a total cost of ownership perspective than maintaining your own custom ansible/puppet/chef/terraform god-knows-what scripts
- deanCommie 6y ago
  I'm not comparing Kubernetes vs rolling the same functionality yourself. I'm comparing it vs onboarding to the stack of Load Balancers/virtual networks/container registration/service discovery/etc offered by the major cloud providers natively on their platform, which are going to be much more well defined for solving real problems rather than K8s generic platform.
- wbl 6y ago
  Kubernetes doesn't provide networking. You have to use Cilium or a flat layer 2 or fun BGP tricks to get the packets to go where it wants them to. It doesn't provide storage: you have to run Ceph or Gluster or vanilla NFS and hook it up.
  - harpratap 6y ago
    Kubernetes is just an orchestrator. It's not a platform
boulos 6y ago
Disclosure: I work on Google Cloud. Different people have different challenges. For companies being built from scratch today, you get to pick your technologies and providers as you see fit. In that case, I’ve always been sad when I see folks doing least-common denominator and excusing it via “multi cloud” or “no lock in”. I remind them that “you don’t need to pick GCP, but your biggest challenge will be not going out of business. Focus on that. If you end up with a lock-in problem and you’re successful, that’s a good problem to have”. However, there are many folks who end up in either a multi-cloud or at least hybrid cloud setup. Any existing enterprise with sufficient infrastructure is going to start their migration to cloud as a hybrid affair, because they aren’t just going to burn their equipment to the ground. Even companies “born in the cloud” eventually get larger and often acquire other companies. If the acquired company was on Azure but you’re an AWS shop, you are suddenly multicloud. If the acquired company is a serious enough fraction of your infrastructure, or it’s locked in economically via contracts, you have the same model as on-prem plus cloud. As with hybrid, some companies push themselves to get out of this state as quickly as possible. Others accept it as “we’ll always have bits and pieces everywhere”. It really depends on the company and their business values. Finally, heavily regulated industries often have dual-sourcing or “must be able to get off within 12 months” restrictions as an example. Those folks are kind of in the “must always be either multi loud or at least hybrid”, and really appreciate a consistent “universe”. tl;dr: you can impugn Craig’s motivation for creating the CNCF, but there are people and businesses that derive value from consistency and a theoretical ability to switch.
- rectang 6y ago
  > If you end up with a lock-in problem and you’re successful, that’s a good problem to have Damned if you do, damned if you don't. If you don't go out of business in the early stages, you become powerless against the cloud provider you are now locked into upping their rent-extraction and draining you until you go out of business. "Your margin is my opportunity." — Jeff Bezos
  - boulos 6y ago
    It’s certainly a double edged sword, but as you grow it also makes the “reward” for moving higher. “We can save $100k/yr if we do this large rewrite” is much less attractive than “We can save $10M/yr. Please give us a team of X people to do so”. I also don’t think your rent-extraction hypothesis holds. Despite some obvious call outs (like App Engine realizing it should have been charging for time you were blocking on I/O, not just cpu cycles retired, in 2011 when it went from Preview to GA), prices are generally stable or decreasing. Mostly, this is a function of hardware trends and competition: the cost per thread or per byte goes down over time. So you aren’t likely to be drained out of business by decisions the providers make. It’s totally possible that your cost structure never worked out, but that isn’t “upping their rent-extraction”.
k__ 6y ago
"Cloud Native" with tools like K8s is just sooo much more work. I mean, even with services like EKS and Fargate. I was a bit disappointed, when I looked into serverless technology. It was sold to me as the savior, but it still requires much stuff I have to do myself. But Kubernetes? That's a whole nother level! I had to try K8s first to really appreciate what serverless technology gave me.

marcc 6y ago

There's a lot more to Kubernetes than avoiding lock in. Pick your favorite managed provider (GKE?) and stick with it. Use all of the GCP native tooling also so that Google can manage your network ingress and load balancers, TLS certs, etc. You are 100% right that there's still lock in. But Kubernetes does more than avoiding lock in. Kubernetes creates a common interface so that if you chose GCP and I choose AWS and someone else likes DigitalOcean, we can all benefit from using the same tools across the stack. Very few tools on the linked landscape graphic are specific to a single provider. If you choose Kubernetes solely to avoid vendor lock in, then you should reconsider. But if you choose it so that you can easily use any of the tools on this landscape, regardless of where you are hosting your cluster, that's a little different and has a lot more value.

just-juan-post 6y ago
I don't see it as Kubernetes being the common interface but containers. So long as an organization uses a container-first philosophy or container-centric workflows for development they can deploy to pretty much anywhere. Kubernetes gets the buzz but containers are the real key to flexibility.
- ecnahc515 6y ago
  There's way more to this than just the containers (the apps) themselves though. Orchestration is a very big piece of the puzzle, integrating into that layer is traditionally very cloud specific. Without a common orchestration layer you end up re-inventing the wheel a lot. Containers being a common interface is good, but having the orchestration have a common interface (k8s) is also important.
  - radiator 6y ago
    Why would you end up reinventing the wheel though if the orchestrarion layer were not common? No, you would be using the one from your cloud provider. I think that was the point of your greatgrandparent comment.

mstipetic 6y ago

I do not understand these arguments that always come up. Everything Kubernetes gives you out of the box you'd have to reimplement yourself for a production-grade system. From dealing with service discovery, networking, persistence and volume management to enforcing processes. Maybe you have spend some time learning those things, but it's much less in from a total cost of ownership perspective than maintaining your own custom ansible/puppet/chef/terraform god-knows-what scripts

deanCommie 6y ago
I'm not comparing Kubernetes vs rolling the same functionality yourself. I'm comparing it vs onboarding to the stack of Load Balancers/virtual networks/container registration/service discovery/etc offered by the major cloud providers natively on their platform, which are going to be much more well defined for solving real problems rather than K8s generic platform.
wbl 6y ago
Kubernetes doesn't provide networking. You have to use Cilium or a flat layer 2 or fun BGP tricks to get the packets to go where it wants them to. It doesn't provide storage: you have to run Ceph or Gluster or vanilla NFS and hook it up.
- harpratap 6y ago
  Kubernetes is just an orchestrator. It's not a platform

boulos 6y ago

Disclosure: I work on Google Cloud. Different people have different challenges. For companies being built from scratch today, you get to pick your technologies and providers as you see fit. In that case, I’ve always been sad when I see folks doing least-common denominator and excusing it via “multi cloud” or “no lock in”. I remind them that “you don’t need to pick GCP, but your biggest challenge will be not going out of business. Focus on that. If you end up with a lock-in problem and you’re successful, that’s a good problem to have”. However, there are many folks who end up in either a multi-cloud or at least hybrid cloud setup. Any existing enterprise with sufficient infrastructure is going to start their migration to cloud as a hybrid affair, because they aren’t just going to burn their equipment to the ground. Even companies “born in the cloud” eventually get larger and often acquire other companies. If the acquired company was on Azure but you’re an AWS shop, you are suddenly multicloud. If the acquired company is a serious enough fraction of your infrastructure, or it’s locked in economically via contracts, you have the same model as on-prem plus cloud. As with hybrid, some companies push themselves to get out of this state as quickly as possible. Others accept it as “we’ll always have bits and pieces everywhere”. It really depends on the company and their business values. Finally, heavily regulated industries often have dual-sourcing or “must be able to get off within 12 months” restrictions as an example. Those folks are kind of in the “must always be either multi loud or at least hybrid”, and really appreciate a consistent “universe”. tl;dr: you can impugn Craig’s motivation for creating the CNCF, but there are people and businesses that derive value from consistency and a theoretical ability to switch.

rectang 6y ago
> If you end up with a lock-in problem and you’re successful, that’s a good problem to have Damned if you do, damned if you don't. If you don't go out of business in the early stages, you become powerless against the cloud provider you are now locked into upping their rent-extraction and draining you until you go out of business. "Your margin is my opportunity." — Jeff Bezos
- boulos 6y ago
  It’s certainly a double edged sword, but as you grow it also makes the “reward” for moving higher. “We can save $100k/yr if we do this large rewrite” is much less attractive than “We can save $10M/yr. Please give us a team of X people to do so”. I also don’t think your rent-extraction hypothesis holds. Despite some obvious call outs (like App Engine realizing it should have been charging for time you were blocking on I/O, not just cpu cycles retired, in 2011 when it went from Preview to GA), prices are generally stable or decreasing. Mostly, this is a function of hardware trends and competition: the cost per thread or per byte goes down over time. So you aren’t likely to be drained out of business by decisions the providers make. It’s totally possible that your cost structure never worked out, but that isn’t “upping their rent-extraction”.

k__ 6y ago

"Cloud Native" with tools like K8s is just sooo much more work. I mean, even with services like EKS and Fargate. I was a bit disappointed, when I looked into serverless technology. It was sold to me as the savior, but it still requires much stuff I have to do myself. But Kubernetes? That's a whole nother level! I had to try K8s first to really appreciate what serverless technology gave me.