4 ms·
The complexity of the systems (mostly!) reflects the reality of the needs. Thousands of services working in orchestration in an environment that is, by definiti
by eof 5y ago
The complexity of the systems (mostly!) reflects the reality of the needs. Thousands of services working in orchestration in an environment that is, by definition, hostile; is non trivial.
Little parts of a system being over engineered may be the fault of an engineers ego somewhere, but the massive complexity of distributed systems isn’t some ego trip or frivolous fiddling with shiny new tech.
It’s just big and hard for mere mortals. It’s hard to say when k8s actually decreases complexity, but I think most will get there before ~100 software engineers do.
- p_l 5y agoMy current record is one week with 1 infrastructure person trying to run small containerized application on Azure. This is specific to Azure (I could get it running on GCP no problem, AWS would be a bit more complex), but it reflects, IMO, how k8s is simplifying operations because I could do it easily with k8s on all of those platforms (and that includes setting and managing the cluster). I lost track on how many hours (more like man-months, mythical or not) k8s has saved so far in my work, whether it was in team of 2 or team of 15 supporting multiple other teams.
- leetrout 5y agoThe portability and the widespread adoption is a force multiplier but I have yet to be on a (healthy) team where everyone levels everyone up as the k8s complexity grows for even "simple" things (where you end up adding custom controllers or similar). One engineer will add it based on a Google help article or stackoverflow post, HOPEFULLY the engineer reviewing the PRs tries to understand it and only later when it breaks does everyone find out it exists and only Sally knew all the potential issues, etc etc. On a highly functioning team with strong communication skills and no major egos it should go a lot smoother where everyone is leveling up on the knowledge at the same time.