| My theory is that single-platform clouds actually make more sense than trying to be everything for everyone. While the latter can scale to $billions, the former might actually have higher margins because it delivers more value. An example might be something like a Kubernetes-only cloud driven entirely by Git-ops. Not TFVC, or CVS, or Docker Swarm, or some hybrid of a proprietary cloud and K8s. Literally just a Git repo that materialises Helm charts onto fully managed K8s clusters. That's it. If you try to do anything similar in, say, Azure, you'll discover that: Their DevOps pipelines are managed by a completely separate product group and doesn't natively integrate into the platform. You now have K8s labels and Azure tags. You now have K8s logging and Azure logging. You now have K8s namespaces and Azure resource groups. You now have K8s IAM and Azure IAM. You now have K8s storage and Azure disks. Just that kind of duplication of concepts alone can take this one system's complexity to a level where it's impossible for a pure software development team to use without having a dedicated DevOps person! Azure App Service or AWS Elastic Beanstalk are similarly overly complex, having to bend over backwards to support scenarios like "private network integration". Yeah, that's what developers want to do, carve up subnets and faff around with routing rules! /s For example, if you deploy a pre-compiled web app to App Service, it'll... compile it again. For compatibility with a framework you aren't using! You need a poorly documented environment variable flag to work around this. There's like a dozen more like this and clocking up so fast. Developers just want a platform they can push code to and have it run with high availability and disaster recovery provided as-if turning on a tap. |