One of the great advances provided by virtualization is that a server ceases to become aÂ monolithicÂ combination of hardware and software that is brittle and difficult to manage. Instead a server is encapsulated into a virtual machine which can then be managed independently of its underlying hardware. Since every server is now a file and since files are much easier to manage than hardware/software servers, just putting servers into images was a huge step forward. But as is always the case in this industry where an innovation simply produces a new problem to solve,Â anointingÂ the image as the unit of management for a server created some problems.
Issues with Image (Virtual Machine) Based Management
The principle issue with managing servers as images results from the fact that once a server is an image, it is extremely easy to create copies and variations of it, and therefore to end up with a proliferation of images. While many organizations suffered from physical server sprawl – having bought a server for every single instance of every single task that anyone wanted to do, images created virtual server sprawl. Virtual server sprawl occurred because now creating a new server was simply a matter of copy an existing image file and then starting it up.
As the number of images proliferated beyond the previous number of physical servers that got virtualized, image management collided with another reality in the world. That reality is that organizations want to and need to get more software into production more quickly and to update that software more frequently. So you can think of this as the collision of image based management with Agile Development and DevOps. It simply is too hard to keep all of those rapidly proliferating images up to date.
vFabric Application Director
vFabric Application Director is a brand new product that VMware has just made available, that seeks to significantly simplify the process of deploying applications and updating those applications. vFabric Application Director works by allowing you to declare your application and its components and make a blueprint of that application. vFabric Application Director then integrates with the vCloud API’s (more on the implications this in a moment) to deploy your application into a private or public cloud.
An important aspect of vFabric AppDirector is that it is not about building up a single image. It is about assembling an entire multi-tier application into a container that even contains the scaling rules for each of the tiers. This container is actually a vApp, but all of the complexities of dealing with a vApp are completely handled by vFabric AppDirector and shielded from the user. In this respect AppDirector is actually complementary with tools like Puppet, Chef and ScaleXtreme which are focused more on being able to build and rebuild the image with reusable scripts.
Â Integration with vFabric APM
Once of the nice things about having a blueprint for your application is that once you have that blueprint you pretty much have the information that a monitoring tool would need in order to know how to monitor that application. To this end VMware has cleverly integrated AppDirector with vFabric AppInsight (the two are bundled together an an offering called vFabric APM).
So now as a part of building the template for your application you can also specify how it will be monitored in production (by VMware’s APM tools, of course).
Implications and Issues with vFabric AppDirector
The most significant thing about AppDirector and the previously delivered AppInsight is that they along with the CloudFoundry efforts show the VMware is very serious about building applications, platforms for applications, deploying applications, and managing the performance of applications in production. If you build your application in Spring, deploy it on vFabric Web Server, deploy it with AppDirector, and manage its performance with AppInsight you will have one throat to choke for that application all of the way from the writing of the first line of code to the first issue with response time. What this means is that VMware is not just interested running everyone else’s applications on their platforms, they are also interested in you building applications to their environment to run on their platform.
Strategically this rounds out the threat that VMware poses to both Microsoft and Red Hat. Both the Microsoft and Red Hat operating systems have prospered by being platforms for applications as much as they have been systems to manage data center hardware. Obviously vSphere is the data center management OS. The vFabric product line is all about applications.
There are, at least right now some limitations:
- AppDirector uses the vCloud API’s. The vCloud API’s are implemented in vCloud Director. So if you do not have vCD in production (or something else that implements the vCloud API’s), you cannot use AppDirector to blueprint and deploy your applications. The statement of direction on this front is for AppDirector to become cloud independent over time, as is also the case with the rest of vFabric product line.
- Right now AppDirector supports mainly Linux operating systems, middleware, and databases. Support for the entire Windows stack is still forthcoming.
- While the ability to initially define your application is quite robust and strong the ability to updated your application on a sub-component basis with strong versioning and rollback still needs some work.
You can read more about AppDirector at VMware Rethink IT Blog.
With vFabric Application Director, vFabric AppInsight and the rest of the vFabric product line we are seeing VMware’s application level strategy come to life. It is clear that VMware is making an enormous and strategic investment on this front, probably second only in priority to the continued investment in vSphere’s domination of data centerÂ virtualization. The combination of vFabric and vSphere also brings into clear focus the fullness of the VMware software stack, and the degree to which VMware seriously threatens established OS vendors like Microsoft and Red Hat.