Microsoft forecasts a hybrid-cloud future

IT departments can't ignore the cloud. If they fail to deliver systems that are fast and easy to set up, business teams will just sidestep them and sign up for a cloud service — whatever the consequences for security or compliance.

To address that issue, the IT team may decide it needs a way to offer a private cloud aimed at the business, and to manage the public cloud services that departments are using. IT teams using Microsoft Azure, System Center and Virtual Machine Manager (VMM) 2012 will be able to offer public and private clouds to users through a new tool called System Center App Controller, which Microsoft previewed earlier this year as Concero, and announced at its Worldwide Partner Conference in July.

Microsoft says the tool is designed to allow a business team to build its own system on a private cloud, scale it out to Azure if it needs more resources, and take it back inhouse without worrying about incompatibilities — and IT can manage all these processes in the same way.

The concept of being able to move a system off premises and back again because you have the same platform resembles the approach that OpenStack is working on, but with familiar Microsoft tools. ZDNet UK asked System Center technical product manager Kenon Owens to explain what App Controller offers and what you need to make it work.

Q: So the idea is to build a private cloud that you offer to the business — as a service or as a platform?
A: Microsoft's approach to the private cloud is to take all the disparate pieces of hardware, gather them into logical units and create delegated clouds. These clouds can be assigned to, for example, different business units.

Microsoft's approach to the private cloud is to take all the disparate pieces of hardware, gather them into logical units and create delegated clouds.

We are viewing this approach not at a server but at a service level. So that's multiple tiers of multiple servers that combine together. Being able to deploy, configure, start, stop at a service level makes the cloud service much easier to manage and means I can delegate it to the business units that are running the applications.

It's all about keeping the control you need over the infrastructure, but giving the self-service user the freedom to do what he needs to do as quickly as possible.

So how does App Controller feel like a cloud to business users?
It allows self-service users to manage, monitor, deploy and operate services they've assigned. They can start them, stop, and scale them. It's a service running on a box that's connected to different connections. It communicates with them and it aggregates users' identity to make sure they're authorised to see these services.

How does it actually work?
The service catalogue is built through Service Manager where you can build these standardised packaged offerings. Service Manager 2012 has workflow engines built in that integrate with Orchestrator, so when I finish clicking 'submit' on, say, the Platinum option, a service ticket is created.

Orchestrator is monitoring that queue and when it sees that incident, it pulls it out and says, "Let me check if this person has authority, so I can just do it automatically or pass it to a human to have them approve it. If it's authorised, can I...

...expand the resources? Are resources available that I can expand it to?". The services you deploy via App Controller, when you deploy a line-of-business app, that service information, those templates are pulled out from VMM.

Does that process have to be built on a Hyper-V infrastructure?
No. Customers can have diverse infrastructure and different hypervisors. With VMM 2012, we've taken a look at the tasks that you have to do. All hypervisors have the ability to create a VM [virtual machine], deploy a VM, stop a VM, migrate it. Those are easy because it's just a one-to-one mapping.

We've been able to bring that abstraction one level higher, where we can figure out what's the custom thing you have to do in Hyper-V to do that same task, what's the task in Citrix XenServer or VMware. VMware has distributed virtual switches that are totally different from physical switches. We can handle those switches because we have created a logical abstraction.

Do we have to dumb things down to be able to support other hypervisors? No.

But there are some things we can do with Hyper-V, such as bare-metal deployment, which we can't do with VMware or XenServer. I can talk directly to a bare-metal server that doesn't have an OS on it, reboot it, throw a VHD file with Hyper-V already enabled, boot it up and it will have Hyper-V, it will install the VMM agent and it will become a member of that VMM server. Then we can add it to a cluster. With the storage mapping, we can even mask in LUNs [logical unit number objects] so we can have that shared storage for Live Migration. That's stuff we can only do with Hyper-V.

Do we have to dumb things down to be able to support other hypervisors? No.

Management of the underlying infrastructure is mostly focused on Hyper-V. Like host updates, where I have a cluster of servers and we want to do updates, I can update the Windows Server because we have WSUS [Windows Server Update Services] as the back-end engine for that. I'm going to do that for Hyper-V. I'm not going to do that for XenServer or VMware because they don't run on Windows.

Things I do with services, I can deploy those services to any of those hypervisors and I get the same benefits. I can deploy a virtual machine with Server App-V templates installed on it to a VMware server. Things like dynamic optimisation, that works across all the different hypervisors as well. I'm not going migrate a VM from Hyper-V or VMware but I'm going to move VMs around within the Hyper-V cluster and rebalance the load — and I can also do that with VMware and Citrix XenServer.

Beyond simplifying deployment, is there a level of automation?
When you deploy a service, if you have Operations Manager installed, we'll be able to connect and build a distributed application inside Operations Manager. That app will know what's part of that one service. Then, using tools such as AVIcodec, you'll be able to monitor interactions between different pieces of that service and pass that information back.

Can you automate the operational side as well?
That's where you would use Opalis. Let's say Operations Manager is monitoring a server and it's running three web servers and you have the web servers set up so they can scale. Operations Manager may say, "This app is performing slowly or my latency is high, I think we need to scale that out" and then it can use Orchestrator to initiate the scale-out task and Orchestrator will talk to VMM with the command parameters to scale out the stack.

A lot of things we're doing in VMM are built to handle those circumstances where a machine doesn't come up, so you can still use resources in that cloud. One of the things we focus on is building resiliency and redundancy in the underlying infrastructure to make sure you're not overcommitting resources.