Yesterday at VMworld in the Session presented by Harry Labana he talked about a unified console. He demo’ed a workflow where a desktop or application is provisioned like you order a pizza. Just simple and not having to go to many many console, just like we want it.
At the Atlantis party I had a long chat with Harry Labana about the message VMware is sending out and the road it is on. It was a good chat, so I decided to cover this in a blog.
Buying – integrating
As I wrote before I had a talk with him , it was about the message VMware was sending out about the integration of products in EUC and the integration itself. The reason to talk about this was a blog from me about Liquidware Labs Profile Unity FlexApp versus Appvolumes. In that blog I mention that VMware lacks the integration and therefore Appvolumes together with UEM is hard to use. There are work arounds but they are not called work arounds for nothing. So we talked about that message and the integration.
Before VMworld 2015 I had a hard time finding where VMware was going with EUC. It’s fun to buy cool products but when you don’t integrate them they become a burden in your selling strategy.
If you don’t integrate there will be consoles popping up that administrators don’t want. There is no one that is happy operating four consoles to e.g. provide a workspace.
It’s good to hear VMware also understands that.
A new console – a new way of delivering resources
So VMware has acknowledged that there is an issue with the many consoles they have. They are working on creating one management console and a new way of working with it.
What they are doing is creating layers so to say with lets say the console being one of the layers. The console will be fed by the next layer which is an API layer. VMware products will need to be redesigned to talk to that API layer so that the input is consistent.
From a VMware product point of view they will get commands from and talk to a new communication layer which is identical for all products. So if any 3rd party products would be added to the console that vendor would need to create an interface to talk to the API as well.
With smart workflows, and that’s the hardest part, the products are given commands to order your pizza to keep with that analogy. The products that will be handled by Astro will need to be able to handle the command they get and execute in a certain way to make the workflow work.
Most products nowadays still have their own console and the output they deliver is not always usable directly for other products just like that. So VMware needs to streamline the products and design a workflow. that’s a huge job to do.
What kind of workflow would there be?
If you think of EUC there are some simple workflows so let me give an example;
Setup a new endpoint for a user that bought a new desktop (Mirage)
Install printer drivers for the user depending on the location he is now (Airwatch+Mirage)
Deploy common used applications (Mirage)
Assign an Appstack with common used apps to the desktop (Airwatch+Appvolumes)
Configure the UEM profile for the user that it will connect to a specific printer, mailbox etc
Entitle the user to get access to company RDSH applications (Enzo/horizon Air)
Configure the Horizon View client (Airwatch)
From an administrator perspective it should be a click and perhaps a few checkboxes to pick the right Appstack. In the back it’s a combination of all products working together and that’s a lot of work.
The cool thing… VMware is building this. 🙂
Where can I get it?
Well you can’t, not yet…. it’s something they are working on. There is no roadmap or anything yet. It’s a hell of a job to change the VMware products so that they talk to an API and understand the workflow command as intended.
It’s coming, have patience… and perhaps at VMworld we will hear more about it.
I for one can’t wait, hopefully I explained it correct so you all understand the idea behind it. If not ping me.