From: https://blog.jetbrains.com/kotlin/2023/07/update-on-the-name...
As a former maintainer of the saltstack config management software (and still occasional contributor): https://github.com/saltstack/salt/commits?author=SEJeff
I find that kubernetes is a better fit for a lot of the applications which previously had dedicated hardware that ran at 0.00% utilization all day. It is also a much better user experience for developers as it was previously along the lines of:
1. User contacts linux team and asks for a server to run say a webapp but it needs redis
2. Linux team sees the ticket and realizes there is no hardware to run dedicated app, so they ask the Datacenter team to get a server.
3. There are no unused servers in the warehouse, so the Datacenter team gets purchasing to send a PO to the server vendor, and in a week we have a new server.
4. The Datacenter team racks the server, and goes back and forth with the Linux team until the network config is correct from a physical standpoint.
5. The Linux team builds out the box and configures the services the user requests, with config management and some fancy tunables for that user.
6. The user gets the server only to find a few things are misconfigured they don't have access to change and go back to step 5.
7. The app works, but the user has to ask the Linux team to update internal DNS for their new service (adding a CNAME generally).
The process now involves:
1. User creates container images of their apps and pushes to our internal registry.
2. User looks at the copious example application templates and makes their app run in kubernetes.
4. Their app runs, but if they have questions, the Linux team will help them with specific requirements. They get automatic dns via coredns, which runs in every kubernetes cluster and creates dns for each service that runs.
5. They spend more time prototyping new software than they do worrying about deployment.
Major features added in release: