The full-time job of keeping up with Kubernetes
Every time a new framework or tool comes out and everybody jumps on it. I always wonder if somebody will realize that you are trading one set of problems and work for another.<p>As engineers we really need to stop supporting these sort of effort and take the time to help each other become better engineers that write and maintain our own code. We need to promote learning and mastering the underlying concepts that things like kubernetes tries to hide and shield engineers from.<p>In most cases tools like kubernetes are so vast and huge so they can be the solution looking for many problems.<p>It is also curious how once kubernetes became big how many small shops needed &quot;Google&quot; level orchestration to manage a hand full of systems. And how hard people ripped their software stack apart into many many micro services just to increase the container count.<p>I think if most engineers took a step back and said &quot;I don&#x27;t know&quot; and took some time to truly understand the requirements of the project they are working on they would find a truly elegant and maintainable solution that did not require tweaking your problem to fit a given solution.<p>Every tool and library &#x2F; dependency you add to your solution is only adding more code and complications that you will not be a expert in and one day will find your self at the whim of the provider.<p>Far to often do we include tens of thousands of lines of code of somebody else&#x27;s work all for a handful of lines of code that if somebody would have had the confidence and support from other engineers around to try and truly understand the problem domain could have implemented and owned the solution.<p>The general trend I see as I get older is that we are valuing the first to a solution rather than a more correct solution. Only to be stuck with a solution that requires  constant care and work around.<p>So I plead to all engineers, devlopers, programmers or whatever you call your self. Please stop and take a moment and think hard about how you would solve any given problem without the use of external code first. Then compare your solution to the off the shelf &quot;solution looking for a problem&quot;. You might surprise your self.<p>I will also like to point out that if when solving a problem your solution looks like a shopping list of third party tools libraries and services; you might not fully understand the problem domain.<p>-- sorry for the rant --