While I partially agree with the premise, I perceive the situation a bit differently. By not adequately prioritizing performance at the early technology-selecti

While I partially agree with the premise, I perceive the situation a bit differently. By not adequately prioritizing performance at the early technology-selection phase of a development project, teams often find themselves forced to prematurely adopt highly-complex deployment systems and other approaches to scale their low-performance system. In my experience, a well-functioning new team will include performance in their selection process. Doing so allows a project to defer optimizations such as higher-complexity deployment (e.g., cluster orchestration, highly sophisticated caching, and so on) for much longer than those who build on low-performance platforms and frameworks. Choosing a low-performance platform and framework sets an artificially low performance ceiling. Developers dealing with a low performance ceiling will either instinctively (through received or learned patterns) or reactively (through user complaints, issue reports, troubleshooting, and tuning) deal with performance challenges they should not need to deal with so early in a product's lifespan. Ironically, some would say that including performance in your technology selection criteria is "premature optimization," but I argue the opposite: considering performance a feature early allows you to defer costly optimizations (such as the matter at hand, Kubernetes deployment), perhaps even indefinitely.