I posited that this was the benefit in knowing Kubernetes all along, and possibly the ace up GCP's sleeve -- soon no cloud provider will have to offer their own interface, they'll all just offer the one invented by Kubernetes.
"Specifically, in the coming months we plan to focus on:
Amazon Relational Database Service (RDS), track via the RDS label.
Amazon ElastiCache offers fully managed Redis and Memcached, track via the Elasticache label."
In 5 years maybe this will be comparable to Cloudformation, but AWS will likely launch services faster than this adds them.
There is also the AWS CDK (https://aws.amazon.com/cdk/) which is essentially lets you use your favorite language like Typescript or Python to generate CloudFormation, with an experience similar to Terraform. We've been experimenting with instead of TF, hoping it's here to stay.
Took the comment right out of my keyboard (?) -- these days whenever I talk about devops with people, I bring up pulumi. HCL and and almost all config-languages-but-really-DSLs are a death sentence.
I am very unlikely to pick terraform for any personal projects ever again, imagine being able to literally drop down to AWS SDK or CDK in the middle of a script and then go back to Pulumi land? AFAIK this is basically not possible with terraform (and terraform charges for API access via terraform cloud? or it's like a premium feature?)
I'm really liking CDK so far - it feels like Typescript which I'm using it with fits is really well. Things like being able to pass variables around (like which branch to deploy!) is really nice - makes some things that would be really horrible in plain CloudFormation really easy. I do worry a bit about TypeScript (or really any 'complete' programming language) for defining infrastructure though, I could easily see loads of ways to make it really hard and complex to follow. I wonder if an eslint plugin could help keep things on the right path.
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.
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.
> 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.
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).
Well except that EKS uses CloudFormation on the backend during cluster provisioning process. So even if you use Terraform to provision an AWS EKS cluster it will ultimately result in rendering Cloudformation templates at AWS. The eksctl tool works the same way i.e it builds CloudFormation templates.
If CloudFormation is an AWS-internal tool, it might as well not exist to those of us outside AWS. I couldn't care less what AWS uses to provision the machines I order with a different interface -- it's their birthday/funeral.
At the risk of audience running out of pop corn, Cloudformation if the only thing you really need for Infra as a Code in AWS. Nothing else. ECS Cluster, ECS Service, TaskDefinition, ALB - it's all that's needed to orchestrate containers.
I posited that this was the benefit in knowing Kubernetes all along, and possibly the ace up GCP's sleeve -- soon no cloud provider will have to offer their own interface, they'll all just offer the one invented by Kubernetes.