3 ms·

I am biased because in my work, I have indeed seen many projects that are struggling or outright failing because of performance problems. The underlying sentim

by bhauer 9y ago

I am biased because in my work, I have indeed seen many projects that are struggling or outright failing because of performance problems. The underlying sentiment of this article may be (mis)interpreted by some as "don't worry about performance." I feel that is not the right guidance, at least in many cases. That said, there is an important premise presented by the article. If I can reframe it slightly: don't over-complicate your system architecture, especially not needlessly. If, by selecting some fancy and trendy new technology, you will complicate your architecture or development process for unknown or modest performance gains, it's probably wise to postpone such adoption until the need is more palpable. My advise, again showing my bias, is quite simple: just select foundation technologies that are mature and high-performance. Using high-performance foundation software gives your application a high performance ceiling, which in turn provides breathing room to build your application in a more "brute-force" fashion. With this approach, you can defer performance tuning and optimization for some time, and perhaps indefinitely. I have seen plenty of small and small-medium businesses operate well with very modest technology platforms. But importantly, they are modest in architecture (few servers, few processes, low system complexity, simple deployments) because they used high-performance platforms (e.g., JVM, Go, so on). On the flip-side, I've seen many small businesses struggling and prematurely adopting complex system architecture because their software platform (e.g., Ruby, PHP) presents a bottleneck early in the business' life, which creates a challenging scale event before the company has even found their market sweet spot. When I've written about this in the past, I've pointed out that many people call this situation a "good problem to have," which is of course valid in important ways. But it's also crude and demeaning to your development team. You're basically saying, "Fantastic, our business is scaling. Yes, our servers are on fire and my developers are panicking, but that's great!" It's better, in my opinion, to have used a high-performance foundation and (potentially) avoid that unnecessary pain. All else being equal (e.g., importantly, your development team is comfortable with a JVM language, for example), I recommend keeping your application simple by using platforms that give you a high ceiling to grow.

mkarliner 9y ago
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.

by bhauer 9y ago

mkarliner 9y ago

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.