The most noticeable change in NSX-T 2.4 is the updated user interfaces. Specifically the option to perform the same configuration trough two very different UIs. In this post, I will provide some information that I hope will help in dealing with this UI split-brain.
Overview
The familiar UI available in version 2.3 has been moved to the Advanced Networking & Security Tab. We will refer to this section of the UI as the Advanced UI. The new way of configuring things is instead presented in other tabs: Networking, Security, Inventory, and Tools. We will refer to these sections as the Simplified UI.
If you know already about the NSX-T Policy and Management Plane APIs (if you do not, you can read a quick summary here), you can immediately draw a parallel between the two APIs and the two UIs. When we leverage the Simplified UI, NSX is actually interacting with the Policy API, when we use the Advanced UI instead, NSX is interacting with the Management Plane API. There are some exceptions, but this is true 99% of the time.
The first consequence of this architecture is that every time we create an object, such as a segment, in the Simplified UI, a corresponding object, such as a logical switch, is going to appear in the Advanced UI. The corresponding object in the Advanced UI is going to be read-only as it was created by the policy engine. The opposite is not true. If we create a logical switch in the Advanced UI, no segment will appear in the Simplified UI.
So which UI should we use?
We should use the Simplified UI any time it is possible. The new simplified UI does not cover all the NSX feature sets yet. Some advanced configurations such as distributed firewall timers and other knobs are only available in the Advanced UI. At the same time, new features such as VPNs and Guest Introspection are only available through the Simplified UI. The Simplified UI provides improved configuration workflows, and it is where new features are going to be available. We can expect advanced knobs to gradually find their way to the simplified UI in future versions.
As in the case of Policy API vs Management Plane API, having your configuration split into two different places is not great. Embracing the Simplified UI sooner rather than later is the best approach.
Are there any exceptions?
Cloud management platforms such as vRA and Openstack may still be leveraging the management plane API as part of their integration with NSX-T. This means that any dynamically created NSX object configured by those platforms will show up in the Advanced UI until the integration plug-ins are updated. The same consideration applies to Kubernets deployments integrated with NSX-T.
What happens in the case of an upgrade?
If you upgrade an NSX-T environment from version 2.3 to version 2.4, all the existing configuration will be ported to the Advanced UI. At the moment, there is no automated way to migrate those configurations to the Simplified UI.
Final Thoughts
Having two UI to perform the same configuration can be confusing. Especially when one of the options is to keep doing what we are used to via the Advanced UI, it might be tempting to postpone the adoption of the Simplified UI. The Simplified UI should be embraced as soon as possible instead. It provides better configuration workflows, access to the newest product features, and tight coupling with the declarative API. In case of an upgrade, though, the benefits of the Simplified UI should be weighted against the management overhead of having part of the configuration still in the Advanced UI. Having the configuration of the same feature (i.e., Distributed Firewall) split across the two UI will be particularly challenging. Depending on your scenario, it might make more sense to keep using the Advanced UI for some feature with the hope that VMware will provide an easy way to migrate those configurations to the Simplified UI soon.
Luca's Blog 
very interesting article
LikeLike