Advanced Simplicity Is All About User Interface

Recently I wrote about advanced simplicity. This is the idea that a great software product hides complexity from its users behind a simple interface. As an illustration, I’d like to discuss a piece of software that exposes lots of complexity, then examine how it would be easier to use if the user interface were different. As my example, I am going to use VMware’s Host Profiles feature. I’m picking on Host Profiles because my experience is that the feature is awesomely useful but incredibly painful to operate. In fact, I have found it so painful that I seldom use Host Profiles in the way that it is intended.

The objective with Host Profiles is to have a consistent configuration across every ESXi server in a cluster, or across multiple clusters. The need for this consistency was a regular theme in my teaching of VMware training courses over the years. A consistent and reliable platform for applications is still a regular part of my writing and philosophy. So why am I complaining about Host Profiles here? Mostly because it exposes far too much complexity to end users. Host Profiles usually start with a perfectly built ESXi server. From that host, a configuration profile is extracted. This profile is then applied to multiple ESXi servers—usually entire DRS/HA clusters. Any ESXi server settings that are not the same as the profile are flagged as requiring changing. Host Profiles can then remediate and make the settings match the profile. Naturally, Host Profiles allows for unique settings on each host; things like IP addresses and host names should be unique. These unique settings are stored in an answer file, which is attached to the Host Profile. Sounds great so far. What is my problem?

I have several problems, but let’s stick to the ones with Host Profiles. My first issue is that it is impossible to go all in with Host Profiles. I cannot disallow manual changes to individual hosts. I can only regularly check for compliance with the profile and then remediate non-compliance. It is always possible to make a single settings change on a single ESXi server, most often to troubleshoot a problem. Once a change is made, we are left with the question of whether to roll it back to the standard or roll the change out to the whole cluster. The user interface to configure ESXi servers does not change when I implement Host Profiles. There isn’t even a warning that I am making a change that will render a specific ESXi server non-compliant. I would like Host Profiles to be a fence at the top of the cliff, preventing me from making a non-compliant change. Instead, it is the ambulance that is called to the bottom of the cliff that is asked to fix a configuration drift problem after it has occurred.

The next problem that I have is that the user interface to view and modify the Host Profile bears no resemblance to the one to configure an ESXi host. The settings do not even have the same names or the same layout. So, in order to make changes to the host profile, I must learn a whole new interface. I would love to have a user interface for managing a Host Profile that looks the same as the user interface for configuring an ESXi server. In the end, the whole point of Host Profiles is to configure ESXi servers. Why does it not look like I’m configuring an ESXi server?

What would I like to see? I would like to see Host Profiles as a cluster setting. When I turn on HA on the cluster, every host is automatically configured. Why is Host Profiles not the same? I would like the user interface in the cluster’s Host Profiles to look like I am configuring an ESXi server. To have the Host Profile set a specific advanced setting, I’d like to go to a screen that looks like the advanced setting screen on an ESXi server. To create a VMkernel port in the Host Profile, I’d like to use the Add Networking wizard. Of course, the Add Networking wizard would need to let me say that each host’s IP address should come from an answer file. That answer file should be a property of the cluster, and the Host Profile editing screens should be a tab on the cluster, too.

I would also like to see the Host Profile as the primary way of configuring hosts in a cluster. In fact, I’d like the configuration screens on individual ESXi servers to be disabled when they are in a cluster with Host Profiles. This way, you know that every ESXi server is compliant with the profile: no configuration drift and no snowflake ESXi servers.

With these two changes in place, it would be a simple matter to create a cluster of hosts with the same configuration. Before a single host is added to the cluster, I could configure the Host Profile just as though I were configuring a single ESXi server. Host Profiles could easily become a policy engine for the configuration of ESXi servers in a cluster. All the complexity of configuring a consistent ESXi cluster could be hidden. One of the characteristics of advanced simplicity is having a really good user interface design.

Posted in SDDC & Hybrid Cloud