IMO
0

The Phoenix Virtual Application…

Traditionally, applications based on physical and/or virtual machines have a lifecycle that can be measured in months to years. Today, a Software Defined Data Center virtual application and its network security constructs can easily be defined in a Blueprint for consumption as needed, but longevity of these applications worse case can still be considerable.

The Phoenix Virtual Application describes an application that has a lifecycle measured from minutes to a few weeks at most, then reclaimed (deleted) and redeployed over and over again…

The Batch Process Phoenix Virtual Application

Media and entertainment industries benefit from multimedia processes when an input is processed to create a desired output. An example of this is Transcoding converting multimedia files from one format to another, or rendering to perform render processing of an image or movie sequence.

Using Transcoding as an example, the physical or virtual application that supports the transcoding batch process is somewhat unimportant, its the input and output of the batch process that is important. Certainly, there is VM, application, network, and security configuration, but once the input has been processed and output produced, the application is really no longer required and can be reclaimed (a nice way of saying deleted).

In the past, a batch process physical or virtual application would not be deleted, if only because there was considerable work force effort to set up storage, virtual or physical machines, network, and firewall policies, and it would be an expensive waste to throw this work effort away.

SDDC with network virtualization provides a simple way to define batch process phoenix virtual applications to be used then deleted. VM, network, and security policy is define right-once-first-time for ongoing reuse.

The use of batch process phoenix virtual applications is just as applicable to a retail bank as it is to a multimedia company. Stepping back and reviewing why physical and virtual machines even exist within your data center provides the opportunity to see what VM’s can be converted and used in batch process phoenix virtual application blueprints.

Recompose Phoenix Virtual Applications

Taking a note from the virtual desktop playbook, I have seen examples of customers recomposing their applications as an alternative to ongoing patching.

As an example, a multi tier application made up of web, app, and database tiers can easily be blueprinted so that as an alternative to ongoing patching and associated gold image version creep, PowerShell, Puppet, and/or Chef scripting is used in-conjunction to the definition of a application blueprint so that much of application can be recomposed (deleted and redefined) against current gold images.

DNS?

I was asked “What about DNS and such?” – In many cases, multiple applications deployed can be given DNS entries at runtime and orchestration can publish this information as appropriate. In the case of a batch process that produces an output, the application itself does not need to be publicly known, only when the batch task is complete and the location of the output. With orchestration and automation, anything is possible!

Certainly, database clusters need to be handled with care, but today, I would suggest a majority of the non database VM’s are disposable and easily recreated.

In summary, the four very desirable benefits of phoenix virtual applications are –

  1. Security, network, compute, and storage policy is embedded with the application blueprint.
  2. The decision where to run the application can be made at runtime… In your private cloud or in a public cloud service.
  3. Business Continuity/Disaster Recovery is implied. If the application is defined in a blueprint, it can be recreated anywhere.
  4. Applications VM’s and/or Physical Machines are not idle waiting for processing consuming data center resources.
Related Posts
What Micro Segmentation Is Not…
Science Experiments / Technology Evaluations