

This can be a big problem when you have to troubleshoot such a system during a production incident and k8s adds a lot of abstraction to the mix which doesn't make it easier.Ĭoming back to COBOL, k8s is on its way to becoming something similar. So obviously, there is some knowledge gap of the underlying architecture.
KEEP IT SIMPLE AND STUPID HOW TO
I have seen engineers who knew about containers and how to configure resource restrictions for a Docker container managed via k8s but have never heard the terms Linux control groups and Linux namespaces. Maybe the younger generation knows all of this already after graduation, but then they are missing other critical parts of the system for sure. The younger generation of IT professionals
KEEP IT SIMPLE AND STUPID SOFTWARE
They all need to be re-educated on what cloud-native means, and they also need to understand the key concepts of k8s for writing optimal software for it. The latter not only applies to the engineers managing the k8s cluster - it also applies to the software engineers, who now have to develop 'cloud native' applications and, therefore, have to change how they developed software how they used to. But all of this also comes with costs: You need experts operating the k8s cluster (or you need to pay extra for a managed cluster in the cloud), increased complexity of the system (k8s comes with a steep learning curve). Of course, there are many benefits of using k8s (auto-scaling, reproducible deployments, dynamic resource allocation and resource sharing, saving of hardware costs, good commercial for potential employees as it is the current hot sauce of infrastructure). Now have a look at Kubernetes (k8s), the current trendy infrastructure thing to use nowadays.

KEEP IT SIMPLE AND STUPID CODE
There's too much COBOL code out there that can't be replaced from today to tomorrow. Why is this? It's just too scary to write everything from scratch. No one is learning COBOL in college or university anymore, but many legacy systems still require COBOL experts. Have a look at COBOL, a prevalent programming language of the past. Unfortunately, many project owners scare away from it as they only want to get their project done and then move on. The latter would require much more resources in the short run, but in the long run, it should pay off. Often, it's so much easier to buy speedier hardware than rewrite a whole system from scratch from the bottom-up. Also, newer and faster hardware is required to make it run smoothly. So more experts are needed to support it. This not just makes the system much more complex, difficult to maintain and challenging to troubleshoot, but also slow. One layer or framework is built on top of another layer, and in the end, nobody has got a clue what's going on. In the early days, so I was told, engineers understood every part of the system, but nowadays, we see more of the "lasagna" stack. Unfortunately, most systems tend to become complex and challenging to maintain in today's world. The fancier the system is, the more can break. _|_|/ \|_|_.*._|_|_Ī robust computer system must be kept simple and stupid (KISS). Keep it simple and stupid Keep it simple and stupid
