Raise your virtual hand if you’ve been discussing a problem in software and asked the question “Does it Scale?”
You are probably raising your virtual hand right now, because we as software developers LOVE to ask that question. Interestingly, when we ask that question, it tends to mean a lot of things. In general, it can be translated into two main, and very distinct, questions:
- Can the solution be easily changed to allow for more user traffic over time?
- Can the solution be easily changed to allow features to be added and updated over time?
The first question generally deals with things like adding hardware to servers or adding additional servers to accommodate load. The second question deals with what architectural patterns are used, how many unit tests are written, what development methodologies are used and how the solution is supported, among many other things.
A couple of years ago, I was in a three day training with Ayende about RavenDB. At the time I had just become a tech lead and was taking point on my first project, which was using RavenDB.
During a discussion of sharding, I mentioned that we might be interested in this feature. Ayende asked me to name the number of requests per minute that we expected to have, and the number of requests that we never expected to reach, even if massively successful – a practical upper limit per say. I wasn’t able to give a good answer to this.
I think this reflects a general trend of developers when interacting with the question “Does it scale?” Truthfully, I think we don’t know what the heck we’re talking about when we ask that question!
I would like to propose some alternative questions to “Does it Scale?” that I think enhance the way we think about our technologies.
- What are my target usage goals and will this solution either allow me to reach them with a single server, or allow me to add additional servers to my cluster to reach my target usage goals?
- Does my programmatic solution allow me to add additional servers to my cluster without issue?
- Is my deployment story a maintainable one over time?
- Is my code following SOLID design principals so the code base will be able to grow over time?
- Are my tests adequate to allow for refactoring in the future?
- Will simply adding additional hardware adequately provide for my growth needs?
- Does the technology I’m considering using have a good DevOps story? Is it easy to deploy, configure, and keep in good health?
All better things to think about than “Does it Scale?”.