‍

As part of a full-stack design of Network Interfaces, a critical resource that connects data to servers, I led the UX Architecture and UI Design from concept to General Availability. This project achieved over 10,000 active resources within the first three months of its production release on IBM Cloud.

‍

Introduction

Duration: 10 Months | Beta: 1Q24 | GA: 2Q24 | Role: Product Design Lead

A Network Interface is what allows your phone, laptop, TV, or any other internet connected device to communicate with the outside world. It’s a hardware component that enables your WiFi, Ethernet, or cellular connections, linking your devices to each other and the public internet. Apply this same concept to a server (a big and powerful computer) in a data center (lots of big and powerful computers working together).

Network Interface Cards (often referred to as NICs) have traditionally been a set of Ethernet Ports that are physically bound to a server’s motherboard, or as an add-on card that’s inserted into the expansion slots of a server’s motherboard. Without a NIC, server hardware is just that, pieces of silicon and metal consuming power. It’s like your phone on Airplane Mode. It’s the NIC and subsequent network that make them useful to us by enabling the server to communicate with other servers and devices in the data center and beyond, allowing data to flow in and out seamlessly.

Now that we know what comes out of a NIC, we can discuss what goes into it. NICs require two inputs, a Security Group (SG) and an Internet Protocol (IP). Security Groups are a set of rules that control the incoming and outgoing traffic to a network interfaces, it’s like a filter for each data packet. It adds a layer of security that the user setting up the SG can control. They can block or allow traffic from certain websites, servers, IPs, and more. An IP is a unique identifier assigned to each device on a network, ensuring data is sent to the correct destination.

‍

Identifying the problem

The Network Administrators and Engineers who create and configure Network Interfaces, alongside a Virtual or Bare Metal server, will find themselves limited to one single IP. This leads to three major pain points for our customers:

‍

Lack of Scalability - Modern Cloud environments rely on multiple IPs to manage traffic. Some of this traffic is coming from connected databases, other servers, and end users. In the example above, there are 8 IPs and 1 SG in a VPC Subnet (in reality, customers have thousands of IPs and Security Groups in their VPC Subnets). Being limited to one IP per Network Interface forces users to create 8 individual Network Interfaces to connect to just one server.

Server Dependency - In this environment where users connect 8 IPs and 1 SG to 3 Servers (1 primary, 1 secondary, and 1 tertiary), Network Admins must spend considerable time configuring 24 individual interfaces, managing security settings, and ensuring proper connectivity for each. Each Network Interface is bound to a specific server. This dependency means that if the primary Server goes down, the entire configuration associated with its Network Interfaces is lost. This issue is detrimental in scenarios involving Backup and Load Balancing. If the primary server fails, the secondary and tertiary servers would need to take over. The complex reconfiguration required to transfer all Network Interfaces and IPs to these backup Servers can lead to significant downtime and potential data loss.

Operational Complexity - With each Network Interface being Server dependent, dynamically reallocating IPs and traffic based on Server load becomes cumbersome. In this example, for every 1 IP added, 3 new Network Interfaces must be added, or for every 1 server added, 8 new Network Interfaces must be created.

These pain points fundamentally reduce the user experience of managing SGs, IPs, and Network Interfaces in an already complex Cloud environment.With the help of our in-house Software Architects, we redesigned how Network Interfaces work from the ground up, and created a fresh UI to streamline the setup and management of this IBM Cloud service suite.

‍

Crafting the solution

Simplify, simplify, simplify. To address all the legacy pain points, we introduced several key features in our new approach to creating, attaching, and managing network interfaces:

Secondary IP Support - Imagine having a phone that can handle multiple phone numbers at once. Our new network interfaces can support over 200 IP connections, with a distinction between Primary and Floating IPs. This means Network Administrators can run multiple services with differing sources on a single instance without introducing further failover difficulties. It’s like having a phone that can switch seamlessly between different numbers if one line goes down.

Portability - Think of network interfaces like SIM cards that can be easily moved between phones. VNIs can be attached and detached from instances without losing their previous network integrations. This flexibility allows Network Administrators to configure and move network interfaces independently of specific devices, providing the robust enterprise flexibility our customers expect.

Consolidation - This makes Network Interfaces similar to having all of your phone numbers and contacts in one place, easily transferable between different devices. We consolidated all IPs and Security Groups into one resource that can move between different target resources.

‍

Reviewing competitors

We reviewed AWS Elastic Network Interfaces and Azure’s network interfaces to validate the need for this service and its features. These reviews confirmed that such capabilities are industry standards for cloud providers. They also validated our expected user flows, as our competitors offer ways to create standalone network interfaces without an attached resource. We were surprised to discover AWS and Azure customers have the ability to attach or assign a VNI to a Server that is already up and running, which we had not considered necessary before this review.

‍

Defining the journey

VNIs can be configured across all Network, Compute, and Storage pillars of Infrastructure. Customers have the option to set them up as standalone resources during initial network planning then allocate them to a needed resource later in their journey, or create them alongside Servers or File Shares.

To ensure each option is accounted for, I collaborated with our internal Engineers to create a comprehensive user journey across all four entry points. We translated these discussions into a set of low-fidelity user flows where Virtual Network Interfaces are present. We decided not to deprecate the existing (now legacy) Network Interfaces despite introducing a new capabilities. Our challenge was to encourage customers to adopt this new, improved offering while still supporting the old method, as some customers indicated they did not want to migrate to VNIs immediately.

‍

Medium fidelity wireframes

There are also specific rules that determine the compatibility of VNIs with other resources, involving settings like Protocol State Filtering and Infrastructure NAT. For instance, when customers create a VNI for Bare Metal Servers, Protocol State Filtering and Auto Release must be disabled. Conversely, the opposite settings are required for customers creating an unattached VNI for Virtual Servers. This presented a unique challenge, which we addressed through our in-context VNI creation process. More details on this are discussed below.

I collaborated with our User Experience Research lead, Uyhun Ung, to conduct an unmoderated usability study of these mid-fidelity wireframes with five participants via UserZoom. Participants ranged from Senior Managers of Data Centers and IT Operations to Network Engineers with 3 to 10 years of experience in both Compute and Network Infrastructure.

‍

I. Unattached VNI

Users can configure, purchase, and manage a standalone, unattached VNI. This method allows for maximum control and customization with the intent of attaching the VNI to a server or mount target later. After purchasing, customers can view all specifications and service integrations. Participants went through the VSI setup with minimal issues and rated the task 100/100 in ease of use and confidence in creating the prescribed VNI configuration.

‍

II. VNIs for Virtual and Bare metal servers

Creating a VNI from scratch involves many steps, and only certain settings make an unattached VNI compatible with servers or other resources. We offer a default, auto-compatible VNI when selecting servers. If further customization is needed, we designed an in-context experience to provide control over settings as if creating an unattached VNI from scratch. Guardrails were included to prevent incompatibilities and additional pain points. All five participants used the default variables without needing changes.

‍

III. VNIs for File shares

File Share Mount Targets are created by customers who are not subject matter experts in Compute or Network, Servers, and VPC. To mitigate any confusion they may experience, we designed a very limited in-context experience with one setting alternative to the default. This ensures simplicity and ease of use for creating and managing VNIs strictly for Storage purposes.

‍

Beta feedback

We collected beta feedback from Customer Success Managers of our early entry Beta customers and our internal Quality Assurance team. Although over 50 findings were identified, we prioritized the following:

Secondary IP Notifications - Users receive up to 240 notifications when auto-generating secondary IPs. We need a way to consolidate these notifications or integrate them with the Status history page.
Lack of VNI Templates - Users requested the ability to change VNI configurations to match what is needed to attach to a VSI, including Zone, Network Configs, and Subnets. A pre-selected list of VNIs that will/won’t work could act as a template for each unattached VNI.
Primary VNI on Network Attachment Distinction - Users requested listing the VNI as Primary on its details page and moving the tooltip text to a more prominent position.

‍

Final design and impact

By introducing contextually auto-populated fields, pre-generated IPs, and auto-compatible settings, we reduced the number of clicks needed to create a VNI in the context of another service from 17 to 0. General Availability was achieved in March, with 10,000 active resources within the first three months, an average standalone provisioning time of 2 minutes 42 seconds, and in-context provisioning of 0 clicks for Virtual and Bare Metal Servers. You can view the live experience on IBM Cloud, or review the supplemental documentation here.

‍

Team feedback

“Eli is a great team player and an asset to the Network Infrastructure team. His detail-oriented approach, proactive collaboration with other teams, and strive to provide the best possible User Experience is greatly appreciated. Virtual Network Interfaces [VNI] has been a tremendous amount of work and collaboration across teams. He has done it with so much attention to detail, through many reviews and fine refinements. VNI has been a major, top-level resource requiring extensive thinking and deliberation on its design.
He was always ready for organization wide presentations and improved the final designs as many times as needed until it was nearly perfect for our customers.”
Amudha Ramachandran — Project Manager, IBM Cloud Network Services