Since I published the Horizon 7 Network Ports diagram with the latest release of Horizon 7, I’ve been frequently asked about the connection flow between the Horizon Client and the virtual desktop. VMware Horizon supports RDP, PCoIP and now Blast Extreme. I’ll start with PCoIP and then we’ll look at Blast Extreme. I’d also like to reference this excellent article by Mark Benson, Load Balancing with VMware Access Point.

The connection flow of the Horizon Client is mostly the same with Horizon 7, Horizon Air or Horizon DaaS. There may be differences in external load-balancing, Security Server or Access Point, and external URL configuration, but for this post I’ll focus on the Horizon Client itself and the aforementioned protocols.

A colleague asked me a very good question which I’d also like to address. How does Access Point know which VM to connect to?

Access Point doesn’t need to know which ESXi host is running the VM. When the entitled desktops are returned to the client(see 1b below) it also receives the external URL of the Access Point appliance, this is where the Horizon Client > Access Point connection is established on HTTPS (TCP 443). This could be a VIP on the load-balancer, or an external facing IP for each of the Access Point appliances, depending on the configuration (see Method 3 of Mark’s article).

When the user launches the chosen desktop pool, Access Point will communicate on HTTPS (TCP 443) to receive the desktop IP from the Connection server. The role of the PCoIP Gateway on the Access Point appliance is to then forward the PCoIP connection to the IP address of the Horizon Agent.

Note: In the past, Security Server used JMS, IPsec and AJP13, but Access Point doesn’t use these protocols (JMS is still used on the Connection Servers). If you refer to my Horizon 7 Network Ports diagram, you’ll see I’ve put these in a dotted line to show this.

For some time now I’ve been trying to free up some time to get stuck into the Photon Platform and gain a better understanding of Cloud Native Applications. Container technology (i.e. Docker) is starting to gain traction in production environments and it’s a popular topic amongst the developer community.

I am particularly interested in End User Computing solutions for developers, and multi-tenant platforms for Cloud Native Applications. As an architect at VMware, I have a lot in common with Sam. While I am comfortable in various scripting languages, technology like Docker is fairly new to me so the purpose of this post is to approach learning this topic from the perspective of a VMware architect.

Let’s break the ice and introduce our 8-bit friends!

On the left we have Jess, our developer with a cool Docker beanie hat. She wants to develop applications and package them using Docker on her laptop. The application containers she creates are shipped to her client for testing, and once her application is ready for production it gets deployed to the cloud. She doesn’t really care about cloud infrastructure… she just loves coding!

On the right we have Sam, our VMware infrastructure guy in a cool VMware Photon t-shirt. He wants to give developers in his organization, like Jess, the agility they need to develop awesome applications. He doesn’t know much about coding applications but he loves VMware infrastructure.

There is a lot of excitement already for VMworld 2016 as it will kick-off in Las Vegas this year. There are going to be some cool announcements, swag, vendors and importantly great content during the keynotes and breakout sessions!

In part 1 of this blog series, I discussed the Horizon 7 architecture and a typical single-tenant deployment using Pods and Blocks. In this post I will discuss the Horizon DaaS platform architecture and how this offers massive scale for multiple tenants in a service provider environment.

Horizon DaaS Architecture

The fundamental difference with the Horizon DaaS platform is multi-tenancy architecture. There are no Connection or Security servers, but there are some commonalities. I mentioned Access Point previously, this was originally developed for Horizon Air, and is now a key component for both Horizon 7 and DaaS for remote access.

In this two part blog series, I introduce the architecture behind Horizon DaaS and the recently announced Horizon 7. From a service provider point of view, the Horizon® family of products offers massive scale from both single-tenant deployments and multi-tenanted service offerings.

Many of you are very familiar with the term Virtual Desktop Infrastructure (VDI), but I don’t think the term does any justice to the evolution of the virtual desktop. VDI can have very different meanings depending on who you are talking to. Back in 2007 when VMware acquired Propero, which soon became VDM (then View and Horizon), VDI was very much about brokering virtual machines running a desktop OS to end-users using a remote display protocol. Almost a decade later, VMware Horizon is vastly different and it has matured into an enterprise desktop and application delivery platform for any device. Really… Horizon 7 is the ultimate supercar of VDI compared to what it was a decade ago.

I’ve read articles that compare VDI to DaaS but they all seem to skip this evolution of VDI and compare it to the traditional desktop broker of the past. DaaS on the other hand provides the platform of choice for service providers offering Desktops as a Service. DaaS was acquired in October 2013 (formerly Desktone). In fact I remember the day of the announcement because I was working on a large VMware Horizon deployment for a service provider at the time.