Kubernetes adds a vast amount of complexity, and in my rationale is because it centers scaling on the wrong unit (the Operating System).
Docker introduced a great level of abstraction and reproducibility over platforms. However, Docker (or OS-based containers) are the most atomic unit of computation on Kubernetes. Which causes centering scaling on the Instance, instead of the Application or even the functions.
This leads to a lot of unintended side-effects. Of which complexity is the most evident since now you need to handle scaling, monitoring and compliance over the VM layer rather than on the functions or the app.
I believe a VM centered on the app (WebAssembly VMs) or functions (serverless approach) is the right computation unit to allow proper scalability and a simpler and more powerful system on the long term.
>I believe a VM centered on the app (WebAssembly VMs) or functions (serverless approach) is the right computation unit to allow proper scalability and a simpler and more powerful system on the long term.
Docker's co-founder agrees:
"If WASM+WASI existed in 2008, we wouldn't have needed to created Docker. That's how important it is. Webassembly on the server is the future of computing."
https://twitter.com/solomonstre/status/1111004913222324225
So we circle back to app servers like Java EE WAR/EAR stuff.
With the exception that Wasm apps are based on a open standard, almost any language can target it, are more lightweight, and they can also run on the browser :)
I’m not sure I agree with the lightweight point. WebAssembly is missing features needed by many high-level languages. As a result, they have to resort to less than ideal tricks. For example, C# on WebAssembly runs using an interpreter even though normally it is JIT compiled.
> WebAssembly is missing features needed by many high-level languages
Agreed, although at some point in a not very far feature most of those missing features will resolved. So in my mind is just a matter of time.
The Wasm Community group is doing an awesome work on that :)
Ikr? Enter weblogic/websphere java ee (bleh)
To me, this essentially defines "the cloud" which exist because they've convinced CTOs that scaling is an infrastructure concern.
The scaling of their primary business (amazon.com, google.com) is at least partially an infrastructure problem - so they had to solve this anyways. Why not try to sell it too?
But it's very rare that you can scale a system by only scaling infrastructure. Ironically, probably the only way this will work is if you scale vertically - which means you don't need K8 and want to avoid the cloud like the plague.
There are all types of application-specific consistency issues that need to be treated as first class parts of the system for horizontal scaling to work.
> Which causes centering scaling on the Instance, instead of the Application or even the functions.
That should be why Red Hat took an early investment in Kubernetes. Operating systems did matter for them. Applications did not.
> I believe a VM centered on the app (WebAssembly VMs) or functions (serverless approach) is the right computation unit
I agree with that. The thing I worry about is a k8s variant like Krustlet, running Wasm instead of container, might introduce the same complexity into the Wasm world. We need a more app-centric scaling solution.