3 ms·

> I'm hoping that this is the start of a trend away from the overly complex, overly engineered, big ball of mud that is Kubernetes towards simpler and easier de

> I'm hoping that this is the start of a trend away from the overly complex, overly engineered, big ball of mud that is Kubernetes towards simpler and easier deployment/hosting/container runtimes that are easier for smaller and large teams alike to manage. But is it easier to manage? Is it simpler? So they went from kubernetes to - Control Pane running in - Container running on - Firecracker with Kuma running on - Nomad with CoreOS running on - Some servers No idea what half of those words are, how they all are ocnfigured, interact with each other, and fail in spectacular ways.

gravypod 5y ago
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).
- 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.

gravypod 5y ago

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).
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.