Hi everyone, my name is Alaks Sevugan (Senior SCVMM Program Manager) and today I’d like to go over the concept of Services in SCVMM 2012. A Service is the deployed instance of a collection of Virtual machines with applications, OS roles and features that work together for providing a Service to the end customers (e.g. any web based application with a database back end, with different parts of the application are installed in multiple machines). Service definition in VMM 2012 includes machine definition as well as the applications. VMM can deploy MSDeploy packages that contain IIS web site definitions, Server App-V packages that contain Virtualized Applications and SQL Server DAC packages that contain database definitions.
So, how do we define what will be included in a Service?
Service Template is your answer. Service Templates contain the definitions for machines, its connectivity, application definitions etc and is the starting point for a VM or a service. Service templates differ from VM templates, in one important aspect – they are source of truth for the deployed services. Today in VMM, creating a VM from a VM template is a fire-and-forget operation, once the VM is created it has no relation whatsoever with the VM template it was created from. Whereas the Services are always be linked to the Service Templates that they were created from. This way you have a central location holding the intent or the truth and less chance of different instances drifting from the desired configuration. This is also required for updating the deployed instances and for supporting scale out of services. If you need to update a deployed instance of the Service, you need to first create a new version of the service template, associate it with an already running instance and then just update the instance to match the new version of the template.
Why use Services?
1. Services help you to model and manage multi-tier applications across a group of machines as a single unit.
2. Services help you to handle peak load for your application, by enabling automatic or manual scale out.
3. Services give you the ability to compose OS images and applications dynamically at deployment time. This allows you to manage fewer OS images and this can lead to significant savings.
Service Lifecycle Management
Here is the typical Service Management Lifecycle in VMM 2012.
We will look at more details about each step in the Service management lifecycle in subsequent blog posts.
Until then ciao!
Alaks Sevugan | Senior Program Manager
The App-V Team blog: http://blogs.technet.com/appv/ The WSUS Support Team blog: http://blogs.technet.com/sus/ The SCMDM Support Team blog: http://blogs.technet.com/mdm/ The ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/ The SCOM 2007 Support Team blog: http://blogs.technet.com/operationsmgr/ The SCVMM Team blog: http://blogs.technet.com/scvmm/ The MED-V Team blog: http://blogs.technet.com/medv/ The DPM Team blog: http://blogs.technet.com/dpm/ The OOB Support Team blog: http://blogs.technet.com/oob/ The Opalis Team blog: http://blogs.technet.com/opalis The Service Manager Team blog: http: http://blogs.technet.com/b/servicemanager The AVIcode Team blog: http: http://blogs.technet.com/b/avicode The System Center Essentials Team blog: http: http://blogs.technet.com/b/systemcenteressentials The Server App-V Team blog: http: http://blogs.technet.com/b/serverappv
Very much like windows azure. But yes this is the right place to do it:. How can manage the drift and do compliance will be interesting
What kind of compliance are you looking at? thanks!