it shares a lot of interesting information but is wrong from the start. First of all it does not consider the business and cost side of development and that's a common problem for programmers. Being IBM I was not expecting that.
docker and kubernetes are apples and oranges. While k8s might be a good choice for container orchestration you should not make this comparison.... docker swarm is a simple transition to scale without the upfront complexity of k8s. ALSO there is a development cost with k8s that you may or may not recover.... what happens if you spend that extra cash on a k8s installation and the volume never arrives? Lastly you've simply waved your hands at the DB and API servers... you cannot just throw any number of java database adapters at the problem and expect great performance. There are limits to the other components.... you have to scale that too. IBM certainly know it's stuff but this is a bad article.One other thing... While k8s does "work" with docker it really wants to manage containerd. And while docker does, sort of, operate in this environment there are still other challenges.
One glaring hole that most designers do not discuss is exactly what should be in a container. A container can be as simple as a single executable and some supporting files to a complete operating system and your application. For example "helloworld" is built on top of the docker Scratch container which is an empty container. The application is executed in the docker sandbox and then exits. If the application needs or is built with an OS like Alpine then all the daemons and drivers need to be loaded. That can and will take cycles from the host. It's not like the guests will be idle while waiting for work. At that point it's not much different from a VMware installation.