partners that leverage the Service Provider Framework (SPF). This provided a single
portal for users to provision, view, and control their services across clouds.
Unfortunately, App Controller has been removed in System Center 2016, leaving an
apparent gap, as SCVMM has no native portal. However, all is not as it seems.
Although App Controller exposed the clouds defined in SCVMM to the end user and
allowed self-service within the quotas defined as part of the cloud capacity and the
tenant quotas, there was no concept of a provisioning workflow nor approval of
requests. SCVMM and App Controller also lacked detailed reporting on resource usage
and the ability to charge business units based on resource consumption. To achieve
this requirement, you would (and still could) leverage the Orchestrator and Service
Manager components, as I explain later in this chapter.
This was the challenge: two separate portals. App Controller provided a nice control
portal to stop, start, and view services provisioned in clouds. To enable a workflow-
based provisioning process, however, the Service Manager self-service portal would be
leveraged, utilizing runbooks defined in Orchestrator to publish request offerings to
the end user. The solution in System Center 2012 R2 for a single portal, and the only
real control solution for System Center 2016, is to leverage Windows Azure Pack with
System Center 2016, which exposes clouds defined in SCVMM but can also publish
request and service offerings defined in Service Manager through the third-party
GridPro solution, enabling workflow-based provisioning and then full control of the
created resources. Another option is not to use SCVMM for the clouds and instead use
Microsoft Azure Stack, but that is covered later in this chapter.