3 ms·

To be fair many of these words would be needed for running a bare metal kube cluster. - Some servers: you need servers to run a bare metal cluster. - CoreOS:

To be fair many of these words would be needed for running a bare metal kube cluster. - Some servers: you need servers to run a bare metal cluster. - CoreOS: This is just a minimal OS that's designed to be PXE booted. Think of it as a docker container for a bare metal machine. - Kuma: Multi-cluster mesh network. This makes it easier to write services that talk to `foobar:8080` and have it automatically fail over to other pods in other regions. I wouldn't use kuma, there's a few other options, but this is very helpful. Good service meshs will allow you to do Canary deployments. If you are multi-cluster than this sort of reliability is probably important to you. But, an important part of this is that you don't need these if you're ok with running on another cloud's infrastructure.

dmitriid 5y ago
> But, an important part of this is that you don't need these if you're ok with running on another cloud's infrastructure. Same with kubernetes ;)
- gravypod 5y ago
  Kube gives you portability. You can move away if you need to. Very difficult to do that with AWS Fargate.
  - dmitriid 5y ago
    > Kube gives you portability. You can move away if you need to. It doesn't, you can't. Because you don't buy in to some nebulous clouds. You buy in to services and capabilities. This tweet sums it up the best: https://twitter.com/coryodaniel/status/1412645383876927492 https://twitter.com/coryodaniel/status/1412645383876927492
    - gravypod 5y ago
      In my experience I haven't bought into anything like that. The most I've done is paid for a hosted DB which is a complexity I could offload to many different companies. I haven't used any services that have lock in, I've been able to ship services efficiently and meet deadlines, and have an abstracted compute layer. I've also multiple times spun up demo environments with docker-compose on a bare metal machine to demo clients without networking. Kube abstracts the compute and load balancing capabilities to a bare level. Everything else can be implemented within kube for at-cost prices.
      - dmitriid 5y ago
        > Kube abstracts the compute and load balancing capabilities to a bare level. > Everything else can be implemented within kube for at-cost prices. Until you need something more than a bare service with nothing in it: anything from messaging to databases to storage. Companies don't usually run a bare-bones service in a kubernetes cluster. It needs to connect somewhere and do stuff. For example, we use BigQuery on GCP. Any idea how it "can be implemented within kube for at-cost prices"?
        gravypod 5y ago
        Don't use services that lock you in. Instead use a layer that abstracts that. In the past I think I have heard of people using Presto for similar operations and that can be self hosted. I would never build a company on top of tech I can only get from one place. Regardless of the layer in the stack. If it's abstracted behind an agreed upon industry standard protocol (MySQL, pg, mongo connections or S3/NFS storage, etc)? Sure. If it's special sauce? No way. My $Job-1 is migrating the stack I setup from Azure to GCP and it's been fairly painless from what I heard (only taking a few weeks to make an account, test, then move everything over).
        dmitriid 5y ago
        > Don't use services that lock you in. Why, if they bring value? > Instead use a layer that abstracts that. How can I "abstract" BigQuery? > If it's abstracted behind an agreed upon industry standard protocol (MySQL, pg, mongo connections or S3/NFS storage, etc)? This still doesn't answer the question of "can be implemented within kube for at-cost prices." BigQuery is amazing at processing enormous amounts of data at fraction of time and cost it would take, say, MySQL to process the same data. How can I "abstract it away" and "implement it at cost with kube". Even if it's purely standard stuff like PubSubs, or Apache Beam, there are value-added options that are hard to get from other providers (or implement yourself): anything from monitoring to management to scaling to... I'm not to crazy about vendor lock-ins myself, but "abstract everything away and you can easily move over if needed" is largely a myth.
fosk 5y ago
May I ask why you wouldn't use Kuma?
- gravypod 5y ago
  Kuma is probably fine but I haven't used it so I'd probably use other tools I had used in the past. For example: cilium & stuff by weave.

dmitriid 5y ago

> But, an important part of this is that you don't need these if you're ok with running on another cloud's infrastructure. Same with kubernetes ;)

gravypod 5y ago
Kube gives you portability. You can move away if you need to. Very difficult to do that with AWS Fargate.
- dmitriid 5y ago
  > Kube gives you portability. You can move away if you need to. It doesn't, you can't. Because you don't buy in to some nebulous clouds. You buy in to services and capabilities. This tweet sums it up the best: https://twitter.com/coryodaniel/status/1412645383876927492 https://twitter.com/coryodaniel/status/1412645383876927492
  - gravypod 5y ago
    In my experience I haven't bought into anything like that. The most I've done is paid for a hosted DB which is a complexity I could offload to many different companies. I haven't used any services that have lock in, I've been able to ship services efficiently and meet deadlines, and have an abstracted compute layer. I've also multiple times spun up demo environments with docker-compose on a bare metal machine to demo clients without networking. Kube abstracts the compute and load balancing capabilities to a bare level. Everything else can be implemented within kube for at-cost prices.
    - dmitriid 5y ago
      > Kube abstracts the compute and load balancing capabilities to a bare level. > Everything else can be implemented within kube for at-cost prices. Until you need something more than a bare service with nothing in it: anything from messaging to databases to storage. Companies don't usually run a bare-bones service in a kubernetes cluster. It needs to connect somewhere and do stuff. For example, we use BigQuery on GCP. Any idea how it "can be implemented within kube for at-cost prices"?
      - gravypod 5y ago
        Don't use services that lock you in. Instead use a layer that abstracts that. In the past I think I have heard of people using Presto for similar operations and that can be self hosted. I would never build a company on top of tech I can only get from one place. Regardless of the layer in the stack. If it's abstracted behind an agreed upon industry standard protocol (MySQL, pg, mongo connections or S3/NFS storage, etc)? Sure. If it's special sauce? No way. My $Job-1 is migrating the stack I setup from Azure to GCP and it's been fairly painless from what I heard (only taking a few weeks to make an account, test, then move everything over).
        dmitriid 5y ago
        > Don't use services that lock you in. Why, if they bring value? > Instead use a layer that abstracts that. How can I "abstract" BigQuery? > If it's abstracted behind an agreed upon industry standard protocol (MySQL, pg, mongo connections or S3/NFS storage, etc)? This still doesn't answer the question of "can be implemented within kube for at-cost prices." BigQuery is amazing at processing enormous amounts of data at fraction of time and cost it would take, say, MySQL to process the same data. How can I "abstract it away" and "implement it at cost with kube". Even if it's purely standard stuff like PubSubs, or Apache Beam, there are value-added options that are hard to get from other providers (or implement yourself): anything from monitoring to management to scaling to... I'm not to crazy about vendor lock-ins myself, but "abstract everything away and you can easily move over if needed" is largely a myth.

fosk 5y ago

May I ask why you wouldn't use Kuma?

gravypod 5y ago
Kuma is probably fine but I haven't used it so I'd probably use other tools I had used in the past. For example: cilium & stuff by weave.