Chapter 1: Understanding Nutanix and data centers

In the begining of my internship, I enaged in frequent back and forth with key stakeholders of the project to understand the context, their perspectives, and build rapport.

Have you ever wondered what kind of data centers does the military use? What about large businesses, hospitals, banks? In a statistic published by Cloudzero, over 80% of all organizations use a mix of private and public cloud. This ensures business resiliency, efficiency and cost effectiveness. This mix, called a hybrid multi cloud setup, lets businesses access the best of both worlds.

Nutanix's primary offering is the Prism operating system, designed to operate on private data centers making them as seamless as public data centers (a.k.a. "the cloud"). Picture it like renting a laptop with a pre-installed OS (Cloud storage) vs Building your own PC and renting an OS of your choice (Private storage).

Objects Storage & Federations
In data centers large amounts of unorganized data like videos and images - in magnitude of petabytes, are stored in so called data lakes. These data lakes implement the Objects Storage System, that works similar to a valet service. You give and receive data from the object's manager, without having to worry about where it gets stored iside the lake. This storage is further scaled as follows.

✪ Objects store
Large amounts of physically-connected storage forms an objects store.

✪ Data centers
Each object store in a data center has a unique URL.

✪ Federated URLs
A federated URL is a single access point for all of its member object stores.

Buckets
Finally, an Object store can be divided into logical sections for Access control, ease of use, etc. In a real life scenario an application would ping multiple buckets located in different object stores to store and access different data.

Because federated URLs exist, the application uses only one URL to access all member buckets.

The problem? Federated URLs as a feature only supported private data centers.

Chapter 2: Understanding the users

Now the goal was making federations a true hybrid multi cloud feature. Reading through the PRD gave me an idea of the scope and future plans for the feature. I conducted another round of stakeholder analysis which helped me identify user archetypes and their associated roles -

PC admin
IT admins with access to the admin section of Prism OS. Sets up Object Stores and manage physical infrastructure. Creates users, their permissions, access and roles.

Sub admin
Managers that ensure smooth communication between PC admin and End user. Creates buckets in Objects Stores as per end user requirements.

End user
Engineers working on applications. Wants to access relevant buckets, Pings the federation with get/put requests.

How do they co-ordinate?
Suppose the end user is working on an application that needs to access a particular bucket in an Object Store. However the Object Store is not a member of the Federation that the app runs on. Now the sub admin requests the PC admin to add it to the Federation. After which the sub admin creates a bucket and shares it to the end user.

Chapter 3: Ideas and the breakthrough

To integrate URLs of external storage providers into the Federated URLs, we needed to decide the 'Object Store' equivalent for external storage. Each cloud provider has a different approach to Objects storage infrastructure.

Understanding the black box
Let's simplify things with the help of a metaphor. You have files both on your laptop, and on google drive. If you wanted to create a central access point for your relevant files on your laptop, would you add,

1. Just the folders you want, individually
2. A single parent folder that contains all relevant sub folders inside
3. The entire google drive account along with its permissions

Add role-based access control on top of this for three different users and you have the problem at hand.

Deciding the approach
I came up with six different approaches to the solution, which I narrowed down to three via discussions with my mentor. Using the well developed design library, I was able to quickly design major flows for these three approaches, to present to the stakeholders.

Adding external storage locations hit the right balance & achieved consensus amongst stakeholders.

Chapter 4: The final showdown

With the approach set, I covered all aspects of the setup using the CRUD framework - Create ✦ Read ✦ Update ✦ Delete. Let us look at one of the major flows, as discussed earlier, of adding a bucket to a federation.

Prism OS's Federation admin page
The page shows a summary of the federation, a table of member Object Stores, and an empty table to add external endpoints (storage locations).

The PC admin now clicks on add a new External Endpoint

Add external endpoint
Next a form appears to enter the details of the external endpoint, as provided by the Sub admin. The illustration dynamically updates with the form.

After hitting save, the new endpoint appears on the federation page. With this, The PC admin role is over.

Sub admin Federation view
Next, the Sub admin will log onto their view of the Federation, to create a new bucket.

The Sub admin now selects the option to add an external bucket.

Add external bucket
A new form appears, this time for the details of the bucket.

A new bucket appears in the list of buckets. This bucket needs to be shared with the End user.

The Sub admin selects the bucket and clicks share. In the new page, they enter the details of the End user to share to. With this, the Sub admin role is over.

End user Federation view
Finally, the End user is able to log on to their version of federation and access the bucket shared to them!

With this, ends the first and the most important flow in the entire feature.

Error States
Along with the flows, I also identified and designed the major error states, and collaborated with the content team to write the error messages.

Accessibility
Further, I performed an accessibility audit on the designs, which included identifying screen reader order, and alt text for buttons.

Handoff
After over nine weeks of work, I was finally able to handoff the high fidelity designs, where I highlighted every change made for future reference and ease of understanding.

Chapter 5: Feedback and learnings

Towards the end of the internship, Nutanix organized an exhibition of all our intern projects. There, I got the opportunity to explain and exhibit my project to company wide attendees, including people in the Objects team. Not only was the day exciting and bustling with energy, I also got valuable insights on the project and vision of Objects storage.

Feedback

" Shivam was quick to understand the domain quite well even though he had limited time. He had multiple iterations with the product team and brainstormed on multiple solutions for federation to cloud from admin and end users perspective. "

" He worked on one of the features which fits very well into our hybrid multicloud strategy and was able to deliver a good experience which well was balanced with technical limitations we have. "

Learnings

• Designers are users advocates in between Developers who might want to ship the easiest solution and PM who might want the most marketable features.

• User is not always the customer sometimes the person buying the product might be a Chief Officer of the company and the person using it an understaffed IT admin.

• Get frequent feedback on rough ideas instead of polished outputs, people are less likely to criticize well polished outputs.

• Don't forget to have fun, " you are a 20 year old in Bangalore with disposable income, you will never have this again " - a fun guy :P

Thank You!

........

Confidentiality and Liability Notice:
This case study is shared under the terms of a Non-Disclosure Agreement (NDA) and is intended solely for the recipient's review. By accessing this content, you agree to the following: Confidentiality: The information contained in this case study is confidential and proprietary. It is not to be shared, reproduced, or disseminated in any form without explicit written consent from the original disclosing party. Liability: Any further distribution, sharing, or public disclosure of the contents of this case study is solely the responsibility of the individual accessing it. The author of this case study, or any affiliated parties, shall not be held liable for any unauthorized dissemination or use of this information.