3 ms·
If multi-cloud is actually something an org cares about, which I'll concede ought to be exceedingly rare for an early stage startup, there ways you can design y
by spmurrayzzz 4y ago
If multi-cloud is actually something an org cares about, which I'll concede ought to be exceedingly rare for an early stage startup, there ways you can design your infrastructure to mitigate that problem.
There is some up front work of course, but there's a ton of cloud provider-agnostic library tooling out there these days that you can use to build something like autoscaling (pulumi, terraform, et al.). You might not end up with full feature parity of what k8s offers, but you'd get 90% of the way there.
- runlevel1 4y agoUsing Pulumi and Terraform don't really make your setup cloud-agnostic. The config becomes cloud-specific very quickly due to the differences between the providers. Kubernetes, in and of itself, only makes a few core things somewhat cloud agnostic (compute, LBs, and volumes). You can use those primitives to run cloud-agnostic alternatives to managed services within your cluster, but for most startups that's going to be a premature optimization.
- spmurrayzzz 4y agoDefinitely agree that the multi-cloud thing is a premature optimization for sure. But k8s isn't cloud agnostic either, at least not if you hold it to the same standard that you're holding pulumi/terraform. Many of the lower level native abstractions, like CNI plugins, aren't 100% interchangeable and don't always just work depending on your use case. There's a reason AWS had to build its own VPC CNI plugin to get EKS fully functional across all of its networking services (particularly any service involving peering like DirectConnect etc).