Scale Out Architecture

As organizations grapple with the growing need to manage large and quickly expanding data sets and applications, it is no surprise that cloud-based, scale out architectures have taken hold as the preferred approach to data storage.

For both public and private clouds, scale out architectures afford organizations what was once a luxury: cost-effective, incremental scalability as they need it. While many IT leaders maintain some traditional data centers, the scale out approach is generally agreed to improve flexibility, efficiency, and cost savings.

Here’s a quick overview on the key difference in scale out architecture, and why it’s so important for any services layered onto that architecture to conform to the paradigm.

The Basics: Scale Up vs Scale Out

In its simplest form, scale out architectures allow an organization to grow by adding more systems or nodes, rather than adding more computing power to its existing machines. This lets you grow your environment incrementally according to your needs. Instead of building an environment all at once that can support planned or potential growth, a scale out environment can expand and contract as the business need demands.

By contrast, scale up architectures require you to add more “horsepower” to existing systems or nodes by adding RAM or disk space inside the same hardware component. This usually means you purchase hardware in advance in order to meet your current and future computing requirements, so you’re paying for expected future needs even if you’re not utilizing the hardware.

The Value of Scale Out Architecture

Need-Based Resource Consumption

Scale out architecture allows an organization to grow and flex the size and configuration of its environment as the need demands. You can now scale your environment incrementally instead of in batches, and remove or repurpose underutilized resources. The efficiency gains are clear.

Cost Efficiency

Scale out systems allow for the usage of commodity hardware, since you’re going for quantity over quality. That, coupled with the need-based consumption model, gives organizations more control over their storage costs and naturally reduces waste, when actively managed.

Because spinning up new resources has become so easy, it also necessitates both thoughtful planning and monitoring. Consumption based models are now a “must have” as clouds grow in size and the need for automation vs manual configuration becomes non-negotiable… but organizations must have oversight into system utilization KPIs to maintain the efficiency and proficiency of the environment.

Monitoring and metering supports capacity planning and cost oversight, and is critical to ensuring that your environment is meeting your data management needs in the most cost effective way possible — especially as your environment continues to scale.


An added benefit of the scale out approach is its built-in redundancy. Because you’re utilizing multiple machines when you might have only used one or two previously, the system is significantly less likely to fail just because a single device fails. You’ve distributed the workloads to multiple machines and, consequently, the risk.

(Nearly) Infinite Scalability

In traditional datacenters, a need for additional resources means a call for labor-intensive, time-consuming and thus costly manual configurations of your environment. The beauty of scale out environments (like OpenStack clouds) lies in how easy it is to spin up or replace compute, storage, and/or networking projects — or components thereof.

Scale out architecture is theoretically unlimited in its size, since you can always add more systems or nodes. Scale up systems are, inversely, very much limited by the capabilities of your existing resources.

OpenStack’s Scale Out Architecture

When we think of cloud-based scale out architectures such as OpenStack, it is based on modular applications that support decoupled services. This decoupling is the key to OpenStack’s agility; it allows components of the architecture to be added (and also removed) as needed.

This is “scale out architecture” at its finest, especially as these environments are built on software-defined everything. For example, software-defined networking (SDN) has evolved to become a critical piece of scale out capabilities; it allows an organization to make automated adjustments to its network that don’t necessitate manual intervention.

Scaling the environment to meet capacity demands can happen automatically, with resources deployed and load balanced across the architecture. OpenStack vendors offer countless plug-ins and components to help manage this scale out and load balancing capability with ease.

Why Your Services Need to Scale Out Too

As the OpenStack world continues to evolve — and as more organizations across the globe work to meet increased application and data management demands — the ability to flex an entire environment to a changing scale becomes a “must have.”

Scale out architectures offer agility and flexibility unmatched by traditional datacenters. This is why we continue to see more and more organizations moving to cloud-based OpenStack environments, and why your organization should consider this architecture as the right foundation for managing your data.

Layering legacy systems on top of these scale out systems is sometimes unavoidable, but nearly always adds administrative headaches and requires ongoing upkeep. Consider data protection services (because, hey, that’s our specialty): most legacy solutions rely on agents to take backup snapshots and use caching devices to store data. When you add new resources, someone on your team needs to manually add those agents and devices to the new node. Multiply this by the number of users you have, the number of nodes in your system, and how often a node changes or breaks, and you’re left with a configuration nightmare.

A cloud-native approach is the opposite of this legacy approach: it’s made for the cloud, and natively integrates so that it scales out as your system scales out. TrilioVault, for example, uses native APIs to take snapshots, so there’s no need to install agents on each node you spin up. It scales as your system scales, forever. Isn’t that the whole point of a scalable cloud?

To learn more about Trilio’s cloud-native approach, read this post from our CTO, Murali Balcha, or contact us.