I think people are overly concerned with 'performance'. So long as the approaches meet real world thresholds for specific things, particularly the speed of cer

I think people are overly concerned with 'performance'. So long as the approaches meet real world thresholds for specific things, particularly the speed of certain time-sensitive requests - then the technology is 'viable'. (And let's also assume 'reliability' as a key component of 'viability') Once the tech is 'viable' - it's really a whole host of other concerns that we want to look at. #1 I think would be the ability of the tech to support dynamic and changing needs of product development. Something that is easy, fewer moving parts, smaller API, requires less interference and support from Devops - this is worth a lot. Strategically - it may be the most valuable thing for most growing companies. 'Complexity' in all it's various forms represent a kind of constant barrier, a force that the company is going to have to fight against to make customers happy. This is the thing we want to minimize. Obviously, issues such as switching costs and the 'proprietary trap' are an issue, and of course 'total cost of operations' i.e. the cost of the services are important basis of comparison, but even the later is an issue later on for the company, once it reachers maturity. (i.e. A 'Dropbox' type company should definitely start in the cloud, and not until they have the kind of scale that warrants unit-cost scrutiny would they consider building their own ifra) In the big picture of 'total cost of ownership' - it's the ability of the system to meet the needs of product development, now 'how fast or cheap' it is, that's really the point. Something that is 2x the cost, and 10% 'less performant' - but is very easy to use, requires minimal devops focus, and can enable feature iteration and easy scale - this is what most growing companies need. Unless performance or cost are key attributes and differentiators of the product or service - then 'take the easy path'.