The 5 Dimensions of Scale in Technology

Why do I choose certain tools in technology over others? I can arrive at a decision point with a vendor rather quickly, usually faster than most. My north star for these decisions is all about scale.

The third definition of ‘scale’ in a google search:

?

As definition says, “The full range” is something to understand. In technology, often when people mention scale, they usually mean “does it get bigger?”. That doesn’t do the word justice—not in technology and not in the true definition. When someone says, “cloud scale”, often too them mean, “you can burst beyond and serve more!”. Even in circles where folks talk about bursting to the cloud, they still connote we’re moving in one direction—to make things bigger.

I’m here to tell you that we’re missing half of the equation. Scale happens in all directions. In, out, up, and down. Out and up seem to be the most talked about. Whereas in and down are the buzz kill dimensions of scale. Often ignored, glanced over, assumed to be off-the-shelf, in, and down are associated as bottom line efficiencies, not top line opportunity.

Here is a little visual I created to describe scale in all directions with an example of cloud versus on prem.

An appreciation of scale in, scale down must be a part of any cloud estimation and FinOps practice. Scale in and scale down, for this purpose, we’ll call it scale-negative is a competitive advantage. Especially when you introduce the fifth dimension of scale—TIME. If you can scale in all directions quickly, you're doing it right. Cloud providers won't lead with this practice either, because it's not really in their best interest to remind you that you've left the bath tub running while you left town for two weeks. It's the open secret of cloud revenues. So much idle waste is generated in compute in data centers around the world because people aren't solving for scaling negative.

But if you can crack the nut of how to scale negative, you're ready for cloud native approaches.

Notice that On-prem doesn’t necessarily scale any way but up and out. This is true, but I’m not advocating for cloud only. ?Once a baseline of usage is established that is needed to be “always on”, this application would best be placed where you can get the lowest cost over the long term.

I work in consulting, there’s ebb and flow to our work and the all mighty billable hour reigns supreme. We scale in all directions with our people and our toolsets.

While I’m obviously a fan of cloud for the reasons mentioned above, I apply this principle to software tool choices as well.

Right now, I’m leading initiatives to build our Data & Analytics Posture for delivery in consulting and advisory services. I get to chat with many software vendors about how their tool might help our delivery. I feel bad for ending certain sales calls early if the vendor answers ‘no’ to any of these questions:

• Can I just pay for what I use?
• Can I start small and scale up as needed?

If your software requires named users billed annually, I can’t play ball. Many vendors have this model, and it just doesn’t scale well. It scales well on the vendor’s net retention metrics and revenue, but does it always equate to value? Sure, I’ll support prototyping on these platforms, but that’s it. If you want something in production and you want it to scale, you’ll be limited. I’m procuring tools and platforms for people to build and commercialize for profit. If you seek to commercialize something you’ve built, and the thing you’ve build has in its supply chain a myriad of named user licensed dependencies—you’ll always be beholden to proper planning, forecasting, and procurement of those named user licenses. They also don’t scale in well-- unless someone gets hit by a bus. Let’s look at another visual. Notice how vertical doesn’t really apply here.

? ?

When combining those two visuals you’ll be able to guess that my preference is for cloud, and if I must pay a license, for it to be usage based (think databricks, Synapse, Big Query). Conversely if the deployment is on premise and named user—it’s the worst of all worlds, I’m not having fun, and much time will be spent trying to plan for how scale is achieved, how usage is coupled with value, and who gets access to what.

In closing, never estimate your cloud costs with lift and shift mentality-- factor in all dimensions of scale (in, out, up, down, time). If you're going for a large platform-level play, keep your supply chain simple. Don't complicate it with an over reliance on technology or infrastructure that doesn't tightly couple value supplied to value deployed.