3 ms·

All fair points. I think the thrust of what I was saying is simply: resist the pressures to provide huge scale before there is reasonable evidence that the prod

All fair points. I think the thrust of what I was saying is simply: resist the pressures to provide huge scale before there is reasonable evidence that the product has some traction. Some huge percentage of companies will have to do a major pivot before they get that traction, so the balance should be heavily on simplicity, speed and agility, and if that's at the expense of scale, so be it. Obviously, performance does matter, and so does good architecture, but staying in business matter most :-)

bhauer 9y ago
> resist the pressures to provide huge scale You and I completely agree on this: huge scale is a irrational target out of the gate for most projects. The potential for huge scale preoccupies many an architect whose aspirations exceed their budget, to say nothing of their market reality. A premature preoccupation with huge scale tends to yield over-engineered systems that are needlessly complex and work against all of the goals you cite: simplicity and the ability to react quickly to changing business needs. It seems my addition here is reduced to this: All else being equal—if your team is equally comfortable with two technology options—selecting the platform with a higher performance ceiling will further defer the architectural complexity typically associated with scale. Architectural complexity (e.g., multiple languages, lots of orchestrated or inter-dependent processes, many abstraction layers, complex deployments) tends to be the friction force against the simplicity, speed, and agility we both seek.