Skip to content
On this page

Zypr is a Simulator & Optimizer

Introduction

Zypr is a Simulator-as-a-Service that enables enterprises to quickly and more precisely identify and execute optimal mix, consumption and utilization of their data center hardware, software, space, and power resources that reduces total spend 10-20% below expected future costs.

Infrastructure planners, engineers and analysts can directly execute simulations by interacting with the Zypr API using Swagger UI, cURL, or other client software. Zypr can also be integrated programmatically with third-party SAM, ITAM, TBM, or IaaS applications or cloud-based services.

How Zypr Reduces Costs

  1. Minimizes both discernible and unwitting resource over-provisioning.
  2. Increases monetization of gains in hardware efficiency and performance (HEP).
  3. Enables planners to accomplish highly complex analysis in minutes instead of weeks or months (e.g., M&A, divestitures, resource price and configuration changes, etc.).
  4. Enables a more agile and precise IT supply-chain cadence necessary to sustain higher hardware utilization rates.

Business Need

Most enterprises have a wide range of applications to plan, manage and monitor their technology services. But none can actually describe, simulate, and optimize the complex, inter-dependent behaviors of hardware, software, space and power resources as a time-series of future inventory transactions and ongoing resource utilization.

To compensate, technology teams typically employ their preferred model (e.g., TCO analysis) to prospectively determine hardware lifespan, where:

  • Accounting comes away with terms for hardware depreciation schedules and budgets,
  • Operations gains constant rates for hardware turnover for capacity planning, and
  • downstream planners then derive software, power and space consumption from enumerated attributes of the hardware capacity plan.

Although this provides the appearance of forward visibility, it is too imprecise to cost-effectively realize sustainably higher asset utilization rates. Worse, it only identifies a small subset of feasible solutions.

A different type of mathematical model is required that accounts for the entire solution space, which is minimally capable of:

  • hardware use terms and turnover rates that are not automatically treated as initial values (i.e., independent input values to a model), but as dependent output variables with respect to the service environment of their intended use,
  • a solution space that is bound by expectations of minimum and maximum hardware utilization rates, yet can be dynamically shifted to identify sustainably higher utilization, and
  • accept discrete events that trigger state transitions to describe resource behavior.

Unfortunately, if a technology team attempted to apply this model with their present tools, it would likely consume months of effort with a low probability of a coherent, actionable result.

Zypr solves this catch-22 by abstracting away the mathematical complexities of such a model, and technology teams gain the forward-looking visibility they need to execute supply-chain strategies to predictably evolve infrastructure resources over time at the lowest total cost.

How Zypr Works

Zypr uses a custom-built, differential dynamical system to model the evolution of a pool's resources as a sequence of discrete events for a desired period time. Discrete events represent state transitions to a pool's resource composition or solution space boundaries. Transitions may be triggered by array of discrete variables (e.g., changes to prices, software license terms, configuration, hardware performance improvement, etc.), or a continuous variable reaching a limiting condition. State transitions provide the means to more accurately describe real-world behaviors and how they impact inventory levels and resource consumption.

For example, a resource pool whose service demand grows at a continuous rate will eventually reach an upper hardware utilization limit. Reaching that limit triggers a state transition event — add more capacity — with a lower utilization limit restricting how much should be added. The duration of this repeating cycle impacts supply-chain effectiveness and total costs.

Alternatively, different types of discrete events may trigger a demand-based state transition. A business merger or divestiture may shift the absolute level of demand at a predictable future time, but not change the continuous demand rate. A new product introduction may permanently shift future demand rates higher. Or a promotional sales event (e.g., Black Friday) may temporarily increase demand.

Zypr can simulate these types of events (referred to as Jump Events), and many more.

Hardware Lifespan

Regardless of the frequency or complexity of state transitions, Zypr is uniquely able to simulate the evolution of pool resources — and provides two methods for how hardware lifespan is determined and therefore how pool resource composition and costs evolve over time.

  • Server turnover based on a predetermined, fixed lifespan (e.g., refresh servers every five years). Lifespan is therefore treated as an initial value to a simulation.
  • Server turnover is variable and dynamically determined using Zypr’s specialized optimization engine. Lifespans are an output of a simulation.

Identifying which lifespan policy is appropriate can be determined from a pool's cost structure. But to make a pool's cost structure more analytically useful, it needs to be rearranged into a ratio.

Specifically, software, power, and space resource costs (whose consumption rate is dependent upon HEP) are summed and annualized relative to the annualized cost of hardware. This cost ratio is referred to as a pool's Kratio. When the Kratio is combined as a coefficient to the rate of improvement in HEP (e.g., a "better" server), it indicates its economic value — the amount of cost avoidance or displacement that improved HEP offers with respect to the cost to acquire the "better" hardware.

Monetizing Gains in Hardware Efficiencies and Performance

Capturing these savings is referred to as monetizing HEP. The mere act of adding better hardware doesn't automatically monetize the performance or efficiency gains in hardware. It needs to be expressly orchestrated. An optimally feasible solution needs to be identified, communicated to the right stakeholders, and acted upon far enough in advance to do so.

Zypr provides the means to do so.

Lifespan Optimization

Replacing existing hardware with "better" hardware serves two fundamental purposes:

  1. Maintain technological currency, and
  2. Monetizing gains from "better" hardware.

Optimally monetizing gains in HEP produces optimal lifespans for most resource pools. Mathematically, Zypr's optimization engine is solving the differential equation that the Kratio represents in order to identify the optimal period of time a particular unit of hardware should be utilized in a particular resource pool. The solution is a hardware unit's economic-life for that particular resource pool, which doesn't necessary mean it should be retired from service. It can be assigned to another pool that has a different cost structure, as the example below will illustrate.

Let's examine a concrete example of why hardware lifespan would be dynamically determined with respect to a pool's cost structure.

Assume Pool A has a Kratio of 4.0, Pool B's is 2.0, and a new server’s performance improvement, p, is 20% relative to existing pool inventory. The new server’s value to Pool A and B can be be expressed by the terms 4p and 2p, respectively. Pool A's potential cost savings is 80% (4 x 20%) of a server's cost, with a payback of 1.25 years, whereas Pool B's is 40%, with a payback of 2.5 years. For Pool A to actually monetize this higher value, its refresh rate would need to be relatively faster than Pool B. (Note: These payback times are not optimal; they are breakeven. Zypr solves for optimal.)

Alternatively, if Pool A’s Kratio was a much lower 0.8, then p would need to be 156% for the same 1.25 payback time. Low Kratios invite other determinants to hardware lifespan. For example, major cloud providers typically have very low Kratios, own their software stacks, and charge for its use. Their lifespan policies are better informed by revenue management strategies, similar to how commercial airlines manage seat inventory.

With Kratios that typically range from 2-10, enterprises have very different infrastructure economics than public clouds, and realize higher benefits from hardware lifespan policies that are more agile and dynamically determined.

Although conceptually easy to appreciate, implementing a more agile lifespan policy requires employing a better inventory model that more accurately describes the behavior of infrastructure resources. Zypr enables that by abstracting away the mathematical complexities so enterprises can deliver a more competitive cost structure for their digital services.

To learn more about inventory policies and how Zypr's optimization engine works, you can read more here.

How To Use

Simulations are executed using Zypr's API service, which manages all interactions with the simulator. A JSON-based model is used to define a pool's initial resource composition, service demand, future events, rules, and constraints that govern how resource composition evolves for a desired, future time period. Nine jump event types are available to define state transitions that describe behaviors. The JSON model is added to a simulation request and validated. If okay, the request is submitted to the simulation engine as an on-demand job, which is executed in its own isolated container.

Zypr usually takes 1-10 minutes to find an optimal solution as it considers a very large solution space — the many feasible combinations and sequences of server additions and removals from a pool and the corresponding software, power and space resource quantities. At completion, a collection of resource forecasts is returned.

Progress updates of a running simulation and final simulation results can be retrieved using Zypr's API. Alternatively, the final simulation results can be emailed to the user who requested the simulation.

Use Cases

Operating data center infrastructure requires entering into longer-term commitments for non-hardware resources - irrespective of whether that is considered capital or operating expense. Yet, these resources all depend upon a "point-of-view" about future hardware inventory and their characteristics. Zypr brings a much higher degree of precision when constructing those future estimates, and the necessary clarity when determining how much is required for:

  • physical space
  • power handling and distribution equipment
  • power availability
  • software licenses

In addition to determining appropriate inventory policies, Zypr also supports:

  • quantifying the impact of network and storage upgrades on existing server pools
  • evaluating proposed new technologies, architectures, configurations, or infrastructure services
  • comparing on-premise, hybrid, or cloud hosting options
  • resizing for mergers & acquisitions and divestitures

Ravello Analytics, LLC