Resource Quotas

The SimSpace platform allows organizations to create cyber ranges – virtualized scale models of network environments used for training and testing. Using a cyber range (and therefore using SimSpace) requires virtual computing resources (e.g., vCPU and vRAM). To better manage the use of resources within their organization, our largest customer asked that we build a quota system, which would enable usage limits on the groups within the organization, and also allow the leaders within those groups to impose usage limits on subgroups if needed.

I worked with another designer on a cross-functional product team, consisting of:

  • 1 Product Manager
  • 2 Designers
  • 2 engineering leads (front end and back end)
  • 5-6 other software engineers

Understanding the Problem

To start, we worked with our customer to better understand the problem and their needs. In this case, the customer was already attempting to impose resource quotas in a manual fashion, so we were able to discuss their process and its shortcomings. I worked with another designer and a product manager to come up with our initial set of questions, and we had a couple of calls with the customer for discussion.

Our key takeaways were:

  • Visibility – “Resource Managers” needed visibility into the resources at their disposal and the ability to guarantee resources to the groups below them.
  • Empowerment – They wanted to empower each group and subgroup to administer their own resources.
  • Flexibility – They needed to be able to change resource quotas at any time and needed support for both percentage-based and absolute unit quotas. They were also interested in the idea of assigning a minimum and maximum amount of resources as opposed to a single value, or in the inclusion of some kind of “overflow pool.”
  • Enable large events – A key use case was around planning for large training events – if there was a large event resource usage would be severely limited to enable the event to succeed.
  • Adding new groups – When adding new groups to the system, they wanted to avoid situations in which new resources are added to the system for a new group, but the resources are immediately reserved by existing groups.

User Flow and Concept Diagrams

After working with the customer to understand the problem space, we worked as a team to break down the problem. This involved a lot of collaboration with the engineering team, as we had to work with existing “Resource Manager” code for the project. Our primary output was a user flow diagram. This user flow established the basic model for resource quotas – a given resource could be allocated or placed “on hold,” meaning nobody can use it). Resources that are allocated can be guaranteed to a specific subgroup, meaning only that group can use them. Any resources that are allocated but not guaranteed to a particular group are placed in a “community pool,” meaning that any subgroup can use them on a first-come-first-served basis. We validated this approach with our customer before proceeding with designs.

I also created some more conceptual diagrams which helped to communicate our design intent with the quota system. These were helpful in providing a shared artifact during frequently abstract conversations about potential system behavior.

Clickable Prototype

The prototype snippet below shows some of the core interactions within the flow – making resources available or placing on hold, switching between percentages and units, and the automated validation within the adjust quotas page. As the total amount of allocated resource is updated (by clicking the green and red slider at the top of the page), the guaranteed values are automatically updated. Temporary blue highlighting indicates which values have been updated.

Outcomes

Our Resource Quotas solution was delivered to the customer, and so far we received positive feedback about the flexibility the system affords. We also received requests for additional functionality that are in a planning phase at the time of writing.