3-dimensions of scalability to consider when curating a tech stack.
Like in Seth McFarlane’s movie A Million Ways to Die in the West, there are a million ways to fail when building a tech company. Many of those ways, sadly, are entirely out of our control. Geo-political shifts, financial market volatility, new tech innovations, talent scarcity, and many other factors can unapologetically render a business obsolete or inoperable overnight.
For tech companies developing software, the technologies selected for developing their solution(s) present many ways to die. However, these are choices in their control. Hence, choosing a tech stack should be carefully and thoughtfully conducted. Making it an afterthought or delegating the decision to someone not qualified may one day…kill you.
The most common word heard when curating a tech stack is “scalability.” Believing that a product will scale is a top concern for leadership, engineers, and key stakeholders. This is why every no-code, low-code, developer tool, and cloud provider alike foremost advertise solutions they offer to “scale automatically,” “0 to 1,000,000 users without a hiccup,” “unlimited capacity,” “grow to ∞” and so on.
As a result, scalability has been rendered a soulless buzzword that essentially means nothing for all practical purposes.
In the buzzword context, scalability suggests that some service or platform is reliable in an environment of ever-increasing utilization. Unfortunately, while this can be relevant, it is an extremely narrow view of a much larger picture. Also — and most often — this never even becomes a concern that gets experienced for most applications built.
Here is a strategy for evaluating the scalability of technologies in/for your tech stack. Each part of which may profoundly impact the overall scalability of your product and— most importantly–business.
The Triangle
When evaluating products and services for scalability, you can consider three dimensions, as represented in the triangle above. On the Triangle of Scalability’s vertexes, you have Team, Feature, and Resource as concerns. Each of these should always be considered in “will _product/service_ allow me to scale _concern_?”
However, it’s essential to think about what scale means for your business before that.
Scale can mean having 1) a vast team, 2) an incredibly feature-rich product that’s constantly getting updated and evolving, 3) 1,000,000+ daily active users worldwide — and any combination thereof. This is important as a contextualizing of scale for your own business will help you make technology choices that solve your business’s current and future challenges.
Team
The concern of Team Scalability when curating a tech stack has to do with ensuring that technologies and services do not become productivity bottlenecks for a growing team. Here are some practical examples:
- You find some great software that lets you develop beautiful user interfaces using drag & drop. It’s also proven to support 1,000,000’s customers using your built app without a problem. However, as your company starts growing and you hire more front-end developers and designers, it becomes clear that the tool only allows one person to be productive at a time.
- You hire your first talented engineer, and they decide to develop an application using C++ that’s integral to your product. You and your customers are blown away by how performant the solution is and how well it works. However, as your company starts growing and needs to hire new engineers quickly, it becomes clear that this tool is too difficult to find experienced developers for.
In evaluating Team Scalability, the primary concern is, “will this technology limit my ability to source talent and make hired talent productive?” If the answer is yes, and your business will require a growing team, then that technology will not scale.
Feature
The concern of Feature Scalability when curating a tech stack has to do with ensuring that technologies and services do not introduce limitations or maintenance complexities for a growing product. Here are some practical examples:
- You find some fantastic software that will allow you to develop precisely the product you’ve dreamt up. Using that software, you build the first version of your product, launch it, and everyone is happy. However, as customers start providing feedback, it becomes clear that the tool is not flexible or extensible enough to accommodate initially unplanned features, tweaks, and capabilities.
- You decide to build your product using some platform that doesn’t support testing. It is so easy and inexpensive to use, though; why even bother with testing? So you work hard to get the first version of your product out the door, and — again — everyone is happy. However, as you continue to develop new features into your product, other features start breaking. It becomes clear that the platform doesn’t provide good tools for you to reliably maintain/ensure the integrity of existing functionality when building new features and capabilities.
In evaluating Feature Scalability, the primary concern is, “will this technology limit my ability to build upon and evolve my product safely?” If the answer is yes, and your business will require an ever-changing and stable product, then that technology will not scale.
Resource Scaling
The concern of Resource Scalability when curating a tech stack has to do with ensuring that technologies and services do not introduce limitations for a product experiencing ever-increasing–or varying–utilization. Here are some practical examples:
- You hire a developer who agrees to partner in building your big idea using the latest and greatest web framework. After 1-month of development, you’re amazed to see a live and working version of your product and many users signing up. However, all those concurrent users result in everything running painfully slow and frequently crashing. It becomes clear to the developer and you that this web framework doesn’t have best practices available — or is proven — for handling high-traffic applications/workloads.
- After a great conversation with their sales team, you purchase a product or service to solve for part of your tech stack. They were able to demo just how easy it is to get started developing with their solution and promise that they’ll be right there to support and grow with you as you grow. You do grow; 100,000’s customers sign up, and immediately their APIs start dropping requests and proving unreliable. It becomes clear that this company didn’t expect you to reach the usage levels you did and now has to re-engineer their product to support yours.
In evaluating Resource Scalability, the primary concern is, “will this technology break down as utilization of my product increases/varies?” If the answer is yes, and your business will require or expect ever-increasing and varying product utilization, then that technology will not scale for you.
Conclusion
Technologies don’t scale—implementations of technology scale. Ruby on Rails apps deployed to Heroku have been appropriately implemented and support 100,000+ concurrent users/workloads. Meanwhile, Django apps deployed to AWS’s EC2 have been improperly implemented and crash at 50+ concurrent users/workloads. Simply selecting a hot/popular framework, platform, or API product won’t mitigate risks associated with your own application’s scalability.
Using the lenses of Team, Feature, and Resource when evaluating the scalability of the products we’re building and the technologies we acquire to develop those products, we can better judge the impacts and limitations introduced to our businesses.
A business needs to grow its team, product offering, and enabling technologies while incurring the fewest possible bottlenecks and constraints during that growth. Identifying those bottlenecks and constraints before they are ever experienced will give your product the best chances of survival.
I hope you found this helpful. Thanks for reading!