4 ms·

You are assuming a lot here. Kubernetes is not nearly as popular and used as much to justify that we only need that interface. CloudFormation is replaced with T

You are assuming a lot here. Kubernetes is not nearly as popular and used as much to justify that we only need that interface. CloudFormation is replaced with Terraform, Ansible and Pulumi much more than it is replaced with Kubernetes.

hardwaresofton 6y ago
I am assuming a lot, very possibly super early but I do want to point out that it's terraform/pulumi, and separately ansible (unless you're talking about ansible for provisioning/cloud modules[0] which no one ever seems to know about). But what I'm trying to get at is that the kubernetes interface basically is the terraform/pulumi interface, just with a different configuration language (and less built-in templating macros, which is a GOOD thing, see CloudFormation), but better, because it's continuous. You write a configuration (no matter how dynamic you make things, there's one version that's sent out to AWS/GCP/whatever) with terraform/pulumi, and terraform/pulumi make it true once. You write a relatively similar configuration with k8s and it is made to be true once, but also continuously. As far as popularity goes, kubernetes is insanely popular -- kubernetes was adopted by just about every cloud provider with a speed I've never seen before. Terraform/Pulumi basically took on the work of adapting to cloud provider APIs, not the other way around. [0]: https://docs.ansible.com/ansible/latest/modules/list_of_cloud_modules.html https://docs.ansible.com/ansible/latest/modules/list_of_clou...
- jacques_chester 6y ago
  > You write a relatively similar configuration with k8s and it is made to be true once, but also continuously. This is true if and only if there is a controller written to achieve reconciliation. Defining a CRD doesn't do anything, it's just a reservation of a path and, maybe, a schema attached. A controller can be written that listens but does nothing. It can be written to do something, but not listen. The API Server does not care. There is no magic logic engine or pathfinder or query planner. Someone has to write a controller. All that bare Kubernetes gives you for CRDs is the equivalent of MongoDB.
  - hardwaresofton 6y ago
    You're right technically, but who writes a controller that does nothing? Also, just the existence of the CRD can be enough to signal state to other controllers, so there are some knock-on benefits to just having it there in storage. Regardless of corner cases, this is a step change difference between tools like terraform/pulumi that reach out and call APIs and finish executing compared to k8s which supports reconciliation. A tool with reconciliation is strictly more capable than one without (for better or for worse).

hardwaresofton 6y ago

I am assuming a lot, very possibly super early but I do want to point out that it's terraform/pulumi, and separately ansible (unless you're talking about ansible for provisioning/cloud modules[0] which no one ever seems to know about). But what I'm trying to get at is that the kubernetes interface basically is the terraform/pulumi interface, just with a different configuration language (and less built-in templating macros, which is a GOOD thing, see CloudFormation), but better, because it's continuous. You write a configuration (no matter how dynamic you make things, there's one version that's sent out to AWS/GCP/whatever) with terraform/pulumi, and terraform/pulumi make it true once. You write a relatively similar configuration with k8s and it is made to be true once, but also continuously. As far as popularity goes, kubernetes is insanely popular -- kubernetes was adopted by just about every cloud provider with a speed I've never seen before. Terraform/Pulumi basically took on the work of adapting to cloud provider APIs, not the other way around. [0]: https://docs.ansible.com/ansible/latest/modules/list_of_cloud_modules.html https://docs.ansible.com/ansible/latest/modules/list_of_clou...

jacques_chester 6y ago
> You write a relatively similar configuration with k8s and it is made to be true once, but also continuously. This is true if and only if there is a controller written to achieve reconciliation. Defining a CRD doesn't do anything, it's just a reservation of a path and, maybe, a schema attached. A controller can be written that listens but does nothing. It can be written to do something, but not listen. The API Server does not care. There is no magic logic engine or pathfinder or query planner. Someone has to write a controller. All that bare Kubernetes gives you for CRDs is the equivalent of MongoDB.
- hardwaresofton 6y ago
  You're right technically, but who writes a controller that does nothing? Also, just the existence of the CRD can be enough to signal state to other controllers, so there are some knock-on benefits to just having it there in storage. Regardless of corner cases, this is a step change difference between tools like terraform/pulumi that reach out and call APIs and finish executing compared to k8s which supports reconciliation. A tool with reconciliation is strictly more capable than one without (for better or for worse).