There are many ways to define scale. There is scale related to business, there is scale related to IT, and there is scale related to business functions. Actually, when you get right down to it, there are a number of ways to define scale. It depends entirely on your point of view. Given this, there needs to be one way to define scale for the business and the code, infrastructure, and components that back the business. How do you define scale?

Scale can be seen as three distinct things:

  • Distance: The distance between parts of the business are so vast that data cannot move as fast as the business requires.
  • Velocity and Volume: The rate and quantity of data ingest far exceed easy-to-handle amounts.
  • Device Count: The device count involved exceeds easy-to-handle quantities.

In many ways, scale is about data and devices—data and devices used by the business during normal operations by those inside the organization or those outside (i.e., customers). Devices are the endpoints, intermediaries, and data repositories that make up your business. Data is the data sent between all the devices.
Each of these distinct views of scale requires rethinking how applications and even the business are built. They also require a true understanding of the data involved and the business goals, as well as a combined view on how to achieve those goals. However, the goals may differ based on company, culture, and the inherent knowledge of the decision makers. The good decision makers are those who look past the business goals to come up with ideas on how to achieve those goals. This is particularly helpful with scale.
Let us look at examples of all three of these views of scale.

One example of scale of distance is the use of data downloaded from satellites. The satellites are far away and not always overhead, so the timing for such data downloads has to be spot-on. Depending on the quantity of data to be retrieved, you may have to wait several passes. Once the data is available, it is often batch processed by handing it off to the next service in the data’s journey. Another example is data that needs to traverse the world as quickly as possible. We see this with global-scale storage devices. How data is replicated depends on the volume of that data and the distances it needs to travel.

An example of volume and velocity is a small- to medium-size enterprise that processes 44 billion queries a day with an extremely low latency. Its velocity and volume of data changes how it processes its data. In fact, since its data needs to be processed with extreme low latency, it ends up using microservices quite a bit.

An example of device count issues happened with the Pokémon Go phenomenon. The company handled this by staging out parts of the game after one region had already started. The scale of devices involved was and still is significant, which implies the back-end requirements are also significant.

In your own organization, you may see forms or goals of scale. Rapidly scaling up also has its own issues. A business that is not driven by its data or does not understand its data may never be able to scale up without failure. Your business scale can also impact your customers, and it may be affected by legislation and other requirements.
Join us as we tread the path of strategies around scale for business and technology. To achieve scale, some level of automation is required. More importantly, discussions end up taking place about the data and how it is processed. When you tie scale to low latency, you end up with very interesting business processes, constraints, and discussions.
Where are you in your discussion about scale? Have you started it by having a cloud-first discussion? A container-first discussion? Do you have a strategy that takes into account the data and the business regardless of technology used?