5 ms·

Becuase of kubernetes. The platform of platforms. Kubernetes is the andriod to amazon iphone (in analogy). It is the only way to get out of cloud vendor lock i

Becuase of kubernetes. The platform of platforms. Kubernetes is the andriod to amazon iphone (in analogy). It is the only way to get out of cloud vendor lock in. IBM is mainly a consultancy business, so they basically back integrated with the cloud os - kubernetes, or more specifically in this case - open shift. The only issue here is that are around 23 or more certified kubernetes distors, so this might have been an expansive price to pay.

mike_hearn 7y ago
Kubernetes has nothing to do with cloud vendor lockin. I don't know where you're getting this from. Any hosting provider can spin you up some managed Linux nodes on a bunch of distros and they can be admined by the same tools and same people. That's why all the big clouds spend so much effort creating new services with custom APIs that aren't just "run a process in a chroot jail with fiddly bits". Big Data, AI and so on. That container will still need to store data somewhere, get traffic from somewhere else, etc, and they want to sell you services to do that. If anything I am skeptical about Kubernetes' future. Not in the short term, k8s/docker are the MongoDB of the late 2010s and the same sorts of people are jumping on the bandwagon. But look at the discussion about the AMD EPYCs in Google Cloud. Big machines are now getting so big that a bog standard OS running a bunch of processes is going to provide more than enough power for even very large websites. One machine now provides more power than a whole rack used to, and horizontal scaling technologies are expensive. A research paper from 2013 showed that just scaling up beat the performance of scaling up for virtually all jobs analysed, which came from Microsoft, Yahoo, and Facebook. So the sorts of companies that are poster-children for this kind of cloud technology. https://www.researchgate.net/publication/261862149_Scale-up_vs_scale-out_for_Hadoop_time_to_rethink https://www.researchgate.net/publication/261862149_Scale-up_... There's not much career or intellectual capital to be gained by just running things on big boxes, but, eventually the cost effectiveness of this will become hard to ignore.
- streetcat1 7y ago
  I getting it from Jo Beda, the CTO of heptio (now VMWARE). More specifically , from his definition of cloud native. A cloud native system is a system that manage its resources via an API. The vendor locking in this case is the cloud API. I.e. if I want a resource (e.g. a VM) , I need to use the EC2 api. With kubernetes, I write to the kuberentes API which is open source, cloud vendor natural. However, and this the key to my comments - kubernetes is the platform of platforms. It is an API platform and not just an API. In the future (some would say near future), all of the cloud services will be offered as kubernetes APIs (via a set of domain specific CRD). I am currently working on the AI platform. As for the big machines comments. I absolutely agree. However, I would like to ignore the actual hardware (banning some sort of HA that would require at least 2 machines).
  - ethbro 7y ago
    > In the future (some would say near future), all of the cloud services will be offered as kubernetes APIs (via a set of domain specific CRD) If (big if) some standardized variant of kubernetes "wins." K8s was transparently Google's strategic shot at forcibly commodifying AWS. But everyone has their own agenda. Google, Microsoft, and (to a lesser extent) Amazon could survive in a world of fully commodified compute. Give their compute assets are essentially surpluses from running their other businesses (advertising, software sales, and online retail). So none of them have a strategic imperative to derail k8 evolution. But managed, specialized cloud services are lucrative to all of them (especially Amazon). So their best-case isn't a fully commodified future.
    - dodobirdlord 7y ago
      > Give their compute assets are essentially surpluses from running their other businesses (advertising, software sales, and online retail). This is mythology. It is mostly not actually true.
      - ethbro 7y ago
        Source? Do any of the major clouds publish their base, first-party load?
        dodobirdlord 7y ago
        Consider the ever-expanding region lists of cloud providers, and it becomes clear that the vast majority of cloud infrastructure was purpose-built to support their cloud offerings.
        ethbro 7y ago
        Yet at the same time, expanding their own use. I doubt very much the first deployment of Gmail looked anything like its footprint today. More regions doesn't necessarily stem solely from customer demand. I expect the vast majority does, but without numbers, that's just a guess.
- hodgesrm 7y ago
  The scale-up vs. scale-out argument is very old. I don't see Kubernetes providing a new answer either way. But it does not have to. Let's stipulate that most analytic applications can run on single servers. You still need a way to schedule work efficiently when the applications in aggregate require more than a single host. Kubernetes does that very well. That's leaving out considerations like HA. The paper is notably silent on this topic. To keep systems up across failures as well as maintenance you need replicas in different locations. There's an implication in the paper that everyone is just going to run off S3, which is assumed to be globally available. Not everyone makes that choice for a variety of reasons. So we will continue to see shared nothing designs that require placement across hosts, racks, AZs, etc. Kubernetes is efficient at deploying these.
pojzon 7y ago
To use for example EKS (Amazon Kubernetes) you still have to provide worker nodes by using EC2 API.. which more or less means your infrastructure management is in the same lock-in as you were previously while simply deploying with EC2 VMs.. Kubernetes doesnt solve the vendor lock in issue completely. You still need workers, external dns, databases, gateways and other to operate. The strength of Kubernetes comes in development speed. And thats pretty much it. You can push something out pretty fast and scale it. Ah, this and the fact its easier to find newbs familiar with k8s (they often have no idea how to deal with bare-metal). I wouldnt say the amount of operational work vs normal cloud management is simplified. Managing kubernetes cluster is painful, Ive witnessed 3 updates of EKS where each one broke some part of the cluster: dns / autoscaling / monitoring etc. But hey it is fast. Building runtime image with immutable layers is a huge adventage in itself.
- dankohn1 7y ago
  Take a look at SIG Cluster API for Kubernetes-native ways to spin up and down new nodes. https://github.com/kubernetes-sigs/cluster-api https://github.com/kubernetes-sigs/cluster-api Also see https://github.com/kubernetes-incubator/external-dns https://github.com/kubernetes-incubator/external-dns.

mike_hearn 7y ago

Kubernetes has nothing to do with cloud vendor lockin. I don't know where you're getting this from. Any hosting provider can spin you up some managed Linux nodes on a bunch of distros and they can be admined by the same tools and same people. That's why all the big clouds spend so much effort creating new services with custom APIs that aren't just "run a process in a chroot jail with fiddly bits". Big Data, AI and so on. That container will still need to store data somewhere, get traffic from somewhere else, etc, and they want to sell you services to do that. If anything I am skeptical about Kubernetes' future. Not in the short term, k8s/docker are the MongoDB of the late 2010s and the same sorts of people are jumping on the bandwagon. But look at the discussion about the AMD EPYCs in Google Cloud. Big machines are now getting so big that a bog standard OS running a bunch of processes is going to provide more than enough power for even very large websites. One machine now provides more power than a whole rack used to, and horizontal scaling technologies are expensive. A research paper from 2013 showed that just scaling up beat the performance of scaling up for virtually all jobs analysed, which came from Microsoft, Yahoo, and Facebook. So the sorts of companies that are poster-children for this kind of cloud technology. https://www.researchgate.net/publication/261862149_Scale-up_vs_scale-out_for_Hadoop_time_to_rethink https://www.researchgate.net/publication/261862149_Scale-up_... There's not much career or intellectual capital to be gained by just running things on big boxes, but, eventually the cost effectiveness of this will become hard to ignore.

streetcat1 7y ago
I getting it from Jo Beda, the CTO of heptio (now VMWARE). More specifically , from his definition of cloud native. A cloud native system is a system that manage its resources via an API. The vendor locking in this case is the cloud API. I.e. if I want a resource (e.g. a VM) , I need to use the EC2 api. With kubernetes, I write to the kuberentes API which is open source, cloud vendor natural. However, and this the key to my comments - kubernetes is the platform of platforms. It is an API platform and not just an API. In the future (some would say near future), all of the cloud services will be offered as kubernetes APIs (via a set of domain specific CRD). I am currently working on the AI platform. As for the big machines comments. I absolutely agree. However, I would like to ignore the actual hardware (banning some sort of HA that would require at least 2 machines).
- ethbro 7y ago
  > In the future (some would say near future), all of the cloud services will be offered as kubernetes APIs (via a set of domain specific CRD) If (big if) some standardized variant of kubernetes "wins." K8s was transparently Google's strategic shot at forcibly commodifying AWS. But everyone has their own agenda. Google, Microsoft, and (to a lesser extent) Amazon could survive in a world of fully commodified compute. Give their compute assets are essentially surpluses from running their other businesses (advertising, software sales, and online retail). So none of them have a strategic imperative to derail k8 evolution. But managed, specialized cloud services are lucrative to all of them (especially Amazon). So their best-case isn't a fully commodified future.
  - dodobirdlord 7y ago
    > Give their compute assets are essentially surpluses from running their other businesses (advertising, software sales, and online retail). This is mythology. It is mostly not actually true.
    - ethbro 7y ago
      Source? Do any of the major clouds publish their base, first-party load?
      - dodobirdlord 7y ago
        Consider the ever-expanding region lists of cloud providers, and it becomes clear that the vast majority of cloud infrastructure was purpose-built to support their cloud offerings.
        ethbro 7y ago
        Yet at the same time, expanding their own use. I doubt very much the first deployment of Gmail looked anything like its footprint today. More regions doesn't necessarily stem solely from customer demand. I expect the vast majority does, but without numbers, that's just a guess.
hodgesrm 7y ago
The scale-up vs. scale-out argument is very old. I don't see Kubernetes providing a new answer either way. But it does not have to. Let's stipulate that most analytic applications can run on single servers. You still need a way to schedule work efficiently when the applications in aggregate require more than a single host. Kubernetes does that very well. That's leaving out considerations like HA. The paper is notably silent on this topic. To keep systems up across failures as well as maintenance you need replicas in different locations. There's an implication in the paper that everyone is just going to run off S3, which is assumed to be globally available. Not everyone makes that choice for a variety of reasons. So we will continue to see shared nothing designs that require placement across hosts, racks, AZs, etc. Kubernetes is efficient at deploying these.

pojzon 7y ago

To use for example EKS (Amazon Kubernetes) you still have to provide worker nodes by using EC2 API.. which more or less means your infrastructure management is in the same lock-in as you were previously while simply deploying with EC2 VMs.. Kubernetes doesnt solve the vendor lock in issue completely. You still need workers, external dns, databases, gateways and other to operate. The strength of Kubernetes comes in development speed. And thats pretty much it. You can push something out pretty fast and scale it. Ah, this and the fact its easier to find newbs familiar with k8s (they often have no idea how to deal with bare-metal). I wouldnt say the amount of operational work vs normal cloud management is simplified. Managing kubernetes cluster is painful, Ive witnessed 3 updates of EKS where each one broke some part of the cluster: dns / autoscaling / monitoring etc. But hey it is fast. Building runtime image with immutable layers is a huge adventage in itself.

dankohn1 7y ago
Take a look at SIG Cluster API for Kubernetes-native ways to spin up and down new nodes. https://github.com/kubernetes-sigs/cluster-api https://github.com/kubernetes-sigs/cluster-api Also see https://github.com/kubernetes-incubator/external-dns https://github.com/kubernetes-incubator/external-dns.