We use it in our company to manage multiple UCS traffics and servers.

I use the solution for data center upgrades.

My company's customers use the Cisco UCS Director to support the servers from Cisco UCS and for configuration purposes.

In most of the projects I've worked on, the use cases are tied mostly to orchestrating the on-prem infrastructure, and specifically to achieving a self-service for infrastructure. For example, we have the Cisco infrastructure, which is UCS, which also has other integral components like the storage network. If you want to provision workloads on this infrastructure, we also want to take care of these third-party products such as NetApp and Cisco switches and routers. So we use the UCS Director to define a blueprint or a workflow, which we then use to orchestrate each and every step that is supposed to be part of this automation.

We use this solution to generate workflows.

It is deployed in our private cloud environment.

The solution is used for configuration purposes.

I was responsible for fixing this solution in my company.

My role was designing the zones.

The typical use case is for web services. It is integrated with our database.

Our primary use for Cisco UCS is workflow enhancement.

We primarily use this solution for automation. In my team, we manage approximately one thousand UCS blades. As such, scalability is very important. We use UCS director for simplified deployment, where we can use a single pane of glass to view everything across our thirty-five to forty data centers that we have globally.

The primary use case of this solution is the interconnection between two applications. One that resides on the data center and the other that resides in the architecture. 

It's a scale-out architecture and a hybrid setup. In case there are any workloads, it works on either public or private cloud architecture.

The main use for this solution is for orchestration.