4 ms·
A lot of the problem with using Kubernetes is it appears to be the only option for running microservices in a cloud environment. People choose it because they t
by peterwwillis 7y ago
A lot of the problem with using Kubernetes is it appears to be the only option for running microservices in a cloud environment. People choose it because they think there's no other option (and they're somewhat right). But there's Nomad, DC/OS, Docker Swarm (for a little bit anyway), ECS, GKE, etc. That's still not a ton of options, but there are options.
That's just microservice orchestration. That's a small part of the totality of things needed to implement a full-out SDLC. You can't just build Kubernetes and think you're done; your code will need to integrate into a lot more stuff, and you'll end up writing 10 layers of glue because that's just how many use cases you have to support.
And it's weird that all that glue doesn't use standards. I mean, we have TCP/IP & RPC & REST, we have pipes & filehandles, we have the OCI specs. That gets us to a point where (at most) half of the stack of an architecture is portable and interoperable with any system following those standards. But then there's every other component of the architecture that connects all the pieces together, meaning you're writing glue that will only work for one implementation. Change your implementation, and you have to change your glue, and probably more stuff.
I think a lot of that non-reusable glue could be erased if it all followed standards, such that the configuration and operation of each part followed a standard interface, set of data types, etc. Tools and libraries could just "talk container orchestrator" or "talk load balancer" or "talk object storage" or "talk secrets management", and virtually any component could be integrated into any other, by virtue of either a system-wide or application-specific configuration.
You could argue we have something like that now with a "kubectl file" or similar, but that's not only still platform-specific, but other tools don't speak it, so K8s has to do everything, because it's the only thing that speaks its language (config file/backend data store/IAM/secrets/roles/etc).
Rather than resign ourselves to those limitations, we could bundle everything in an implementation-agnostic standard way with standard interfaces. The exact same configuration (as code) could be used to run the same complete architecture on a dozen different platforms, because every component would speak the same language and handle all the other components in the same ways. The backend services could all translate the standard based on how they were configured, such that generic instructions are then translated into implementation-specific actions. You could really write your architecture once and run it anywhere, without the caveat of "anywhere on this platform only".
I feel like we're not talking about doing that because we keep getting caught up in "Fuck, Kubernetes is pretty hard" conversations. Yeah, it's hard; building and operating an 18-wheeler is hard. But what about the roads? What about the gas stations? What about the containers we put on the trucks? All that stuff is standard, and so we don't have to worry about what implementation of gas station or road we use. I feel like we still don't have those things in the cloud, and it's just weird.