Once there was only bare metal, and system administrators would set up and configure servers with everything needed. Gradually, the era of virtualization began, allowing development teams ample room to manage their own environments independently. Meanwhile, system administrators had to become virtualization experts, and developers had to understand the limitations of resources: CPU, RAM, network…
After several years of virtualization dominance, container technology emerged victorious on various fronts: portability across operating systems, speed of deployment, isolation, scalability, and more. By then, developers were accustomed to limited resources, and the transition from virtual machines to containers was not as painful as in the early days. It’s worth noting that thanks to Docker, container usage was greatly simplified, but almost all Docker engines run on virtual machines.
And what about system administrators? In addition to being specialized in virtualization, they also had to tackle the installation and configuration of Docker. Implementing all the best practices related to the security and segregation of containers to prevent data leaks and application compromises. Don’t forget, reminding developers that resources are not infinite. 😆
Finally, roles like DevOps, Site Reliability Engineer, Cloud Engineer, Platform Engineer, SysOps Admin, Hybrid Cloud Reliability Engineer, etc., emerge. The times are ripe, and the appearance of Kubernetes in the market becomes a reality. Managing a large number of services across various containers is a titanic task, especially when factors such as scalability, security, networking, monitoring, and incident response time come into play. The major cloud providers offer services to facilitate the configuration of K8S because the setup is burdensome in terms of management, maintenance, and observability. System administrators haven’t disappeared, but rather transformed into all those roles I mentioned earlier.
In addition to what has been discussed so far, let’s not forget all the activity related to CI/CD. A K8S cluster requires a minimum level of automation for deployment on the chosen cloud provider. Different roles and permission levels are needed to interact securely with the service, along with networking, user management, node scaling, auto-scaling policies, system log management, container (pod) management, and application management. So, it’s not just about knowing K8S, but also understanding the service that installs it, the organization of the cloud provider, a tool for managing infrastructure as code (IaC) and one for managing CI/CD (GitHub, GitLab, Bitbucket, Jenkins, etc.).
After all these advancements, I have the impression that things have become more complicated instead of simpler because, while we’ve engineered everything else excessively to make the work smoother on one hand, on the other hand, we’ve over-engineered everything else.
A complex world
