Frequently Asked Questions

We work with whatever you already have in place.  You don’t need something new added to your management mix.  You can manage apps that are running in a VAA on a server much like you’d manage any app running on a server.  We don’t interfere at that level.  We integrate.  We don’t want to cause any extra work.

Although we can not answer for all vendors, our experience is that, in the case of a problem, most vendors request that the problem be reproduced in a clean environment, such as a sandbox.  AppZero would not be an element in this environment.  If an organization is very concerned about this issue, AppZero offers a dissolve function by which an application can be instantly deployed in a VAA which is then dissolved.

AppZero does not change licensing.  Licensing and license management remain the responsibility of AppZero’s customers.

There is no installation required and transfer time is much faster than a typical VM.  The reason transfer time is so small is that we only move the app, which is generally a small part of the full server disk footprint.

Unlike working with individual machines, a VAA is the same wherever it is copied, providing consistency.

All graphical capabilities are also available on the command line to support full automation.

AppZero supports normal command line scripting during migration to automatically make such an adjustment if needed. We have a set of examples for common items such as SQL Server.

Because the application is never installed – just copied and run – and the changes are contained in the VAA, it never needs to be uninstalled.  It can simply be moved or deleted.

A single machine can be used to run lots of different apps just by running whatever VAA is required.  Because the applications operate in the isolation of a VAA, they can be run at the same time, on the same server, without conflict.

• VAA is uncompressed into a subdirectory
• VAA can be edited -- Items can be added, changed or deleted
• VAA files are kept in a subdirectory with the same structure that is used by the application
  • Additional folders for XML template, logs, settings, etc.
• VAA registry is in a file but is visible to regedit and other tools

When you move a fully configured server app inside a single VAA file into a new environment, the very first thing we do is uncompress it.  We lay down that application into a special subdirectory that AppZero creates, and the contents of the VAA are placed in the subdirectory.

It is just a normal disk structure, so we’re not some proprietary cloud format and you can go in on the command line to see things, rename things – add/delete – just like a normal disk.  And because it’s in the VAA subdirectory, changes will become part of the VAA.  We also have other files around that hold registry entries or templates so other constructs are available as well, once the VAA has been expanded.

AppZero can capture all the parts of new and existing server applications, such as SAP, into a single file called a VAA.

If you have a monitoring system that wants to see log files, you could have those log files written to the underlying OS and everything else written to the VAA. This approach gives your management system what it needs while maintaining the complete containment of the application within a VAA – and its readiness to be moved at any time to instantly run on another server.

When running, all changes an application makes, including configuration changes, are captured within the VAA, leaving the underlying OS unchanged (unless specifically directed to do otherwise).

Yes.  If a COM component is running, we don’t try to start up a new one.  Other things we leave alone are things like IIS – because it’s tightly integrated with the OS.  Things like application pools that help you do your load balancing – to run multiple instances – we fit into your existing environment by using IIS virtual directory capability.  Other things we don’t try to do are isolate management.  You don’t need another thing to manage. 

Also, RPC and networking environments, we really don’t touch at all.  If your app can be reached by an RPC, by using machine name, that will still work when it’s running in a VAA.  It’s a matter of keeping an application isolated but allowing it to integrate with the things it needs in order to play a part in your normal operations.

File system (includes deletion), registry, background services, COM components (dll, new exe), and new processes.

AppZero adds a layer – the intercept layer -- which gives a different view of the machine to include the contents of the VAA.  From the application’s point of view, it looks as if it’s been natively installed on the hard disk.  The reality is that those files are still in the VAA.  But the application’s view is a merged view of what is in the VAA and the OS.

We separate the application from the OS, packaging it into a single VAA/file for distribution – making it easy to copy and run at the destination machine.  However, when the VAA arrives at the destination server (physical or virtual) the application will require a working OS in order to run.  However, because the app can move among differently configured OSs in different environments, it can also easily move between Amazon and Rackspace without change.

AppZero is hypervisor agnostic.

Either physical servers or virtual machines – data center or cloud, with no changes.

No, AppZero is not a deployment platform or a management framework. It is software that provides a way to capture applications in a file and move that file to run the app on another machine.

AppZero is unlike other virtualization vendors because we focus on server applications.  These applications are far more complicated than the desktop and have items such as Web servers, background services, multiple tiers and so on.

All creation and administrative functions are fully scriptable.  We support complete automation that allows you to do any do any of our operations and all functionality through a command line interface.  So you can integrate with solutions for release and configuration management using any deployment methodology you have in place.  All can talk to AppZero on the command line for automation without any manual intervention.  We didn’t invent the language – it’s the normal command line of the OS so all of your tools will work for ease of integration with your existing management tools and processes.

The Admin console allows us to start and stop a VAA.  It shows all configurations a VAA has in graphical tabs and has some convenient features.  For instance, it allows you to dynamically manage IP address with a running app.  The IP address could be the same everywhere the VAA goes or the admin console allows you to set the address dynamically when the VAA is brought to a new machine.  It helps you to deal with networking concerns when you scale up so each server would have its own IP address.  Very simple to do.  So, the Admin Console:

• Gives full control and monitoring of all VAA operations
• Displays VAA configuration and allows for changes at time of deployment
• Supports convenient features such as setting an IP address dedicated to the VAA

A template is an XML file that describes what’s being brought along in a VAA.  That allows for discovery or to recreate a VAA along the lines of what’s already been created.  So you don’t have to use the creator and go through a creation process each time.

• A template defines the content and configuration of a VAA
• Produced as part of VAA creation or from an existing VAA
• Can be reused to capture a new application instance and its unique configuration

The Creator is a snapshot-based tool … We take a look at the OS and configuration before and after installation and capture it in a VAA.  We supply filters that cut out things you may not want to take along with you – like a Windows update.  You can also create a VAA from a running application for a physical to virtual conversion.  And we support templates.

Put the data elements onto data servers, put the web app on a web tier… Things are kept separate as they are scaled up – or can be brought back to one, at will.  A lot of our customers take this approach for 3-tiered applications.  Any combination is possible and fluid. 

One set of VAAs gives you lots of flexibility in deploying on multiple topologies as opposed to say VMotion which would have to move all 4 at once to each machine.  We don’t compete with VMotion, but it helps to illustrate the difference.  Whereas VMotion moves the entire machine image, AppZero allows you to move the VAA lego blocks as needed.

AppZero offers a far more granular approach – with fewer things to manage.  With a single OS running, you can repurpose that machine simply by running a different VAA on it.  Same OS – different apps.  You may want 2 machines to be web tier during the day and do reporting at night … easy and a lot less maintenance required.

Another advantage of multiple VAAs in a stack is that you can scale up.  Should you need to have more bandwidth on a  web site, you can easily scale out the web server VAA..

There can be a lot of reuse – like SOA or Lego building blocks.  It allows for an object-oriented approach to deploying applications.  And you can separate out concerns along organizational lines.  One gold MySQL VAA could have tons of different application VAAs on top – powerful and flexible.  One group could be responsible for maintaining the MySQL VAA and another group the Apache Web Server VAA.  Each group can make the changes independently of each other. 

Instead of lining up in order with installation media, each group simply takes care of their own VAA.  When the VAAs that make up the application stack are run in context, the result is one running system – updated, current.  The fact that each group does their own VAA independently puts fences with clear accountability amongst organizations.

We set rules in what we call “namespaces” through which you decide what gets written where when the app is running.  In general, you can specify for any VAA, where things are read from and written to, customized to your needs.  Rarely, you may want to specify that things be written to or read from the underlying OS.  So, if you have a monitoring system that wants to see log files, you could have those log files written to the underlying OS and everything else written to the VAA.  Namespaces give you lots of flexibility in how VAAs are used.

Multiple VAAs can be combined to form an application stack.  For instance take an Apache Web server running Wordpress on a My SQL database.  You can create one VAA that has My SQL and one that has Apache server.  In this scenario, it would be typical to have a gold version of My SQL and a vanilla Web server.

You would also have a highly specialized version of the Wordpress infrastructure elements and app.  You could split that part into two VAAs – Wordpress web site and Wordpress data files.  When you run them “in context” they run as one.  The in context view is through all of these layers.  The context of all those layers are visible to the Wordpress app and it appears to be one running system. 

In the case of Wordpress, when it makes a database change, we can set it up that it is contained in/written to the Wordpress data VAA as opposed to the underlying My SQL VAA.  That keeps the Wordpress data separate from the generic MySQL database implementation.

You can run any executable in a VAA context.

There is a Creator – a graphical process that allows you to capture the application and its requirements in a VAA.  The VAA can be tweaked or adjusted as you need to accommodate your application.  The result is a VAA which is then compressed and can be copied to whatever server is desired. 

At run time, we have a small runtime layer called the AppZero Director.  It redirects requests an application makes for things like files and registry entries to the VAA instead of to the underlying OS.  That’s how we encapsulate an application.  It “believes” it’s running normally, making registry requests, calling for files …. But it is the AppZero Director that supplies these items to the VAA.

Any changes the app makes to a file or any configuration changes it makes, are also contained in the VAA.  The underlying OS (UOS) is never effected so the VAA can be moved to another environment if desired.  Or replicated if you’re trying to scale up.  We see that you get the full configuration of the app.

We also have an administration tool to manage VAAs, that is graphically based – that lets you start them and stop them, or reconfigure them if you like.  That’s what we use for on-going maintenance of VAAs.

Combining multiple VAAs allow generic layers to be created and then given a "personality" for a specific application.  For example, a generic database VAA can be combined with an application-specific VAA containing the app's data files and database configuration.

Apps with multiple tiers may benefit by having each tier put into a separate VAA.  This approach allows each tier to be deployed separately on different machines, or combined together on one.  It provides great flexibility because each tier can also be scaled individually by copying the VAA for it to another machine.

No.  AppZero allows multiple VAAs to work together. Applications can be broken up “Lego-style” into separate components and maintained separately by different groups/people.

Normally, when you install an application – for example, SQL Server – it makes changes to registry settings and introduces new services.  What we do at AppZero is watch all of that and take those items – registry items, configuration items, and program files – and capture them in a VAA.  Once this is accomplished, that VAA including the application, program and data files, and configuration items can be separated away from the OS into a single file, ready to be copied and run, rather than installed.

The application runs as usual, unaware that it is executing within the context of its VAA.  Any changes it makes are written to the VAA, leaving the underlying OS unchanged.

At the highest level, AppZero encapsulates an application into what we call a virtual application appliance (VAA) so that the application can be copied and run instantly, without installation.  Unlike a VA/VM, AppZero encapsulates an application without an OS – anticipating a running OS will be available on the target machine, be it physical or virtual).  AppZero encapsulates, provisions, and isolates an application so that it can instantly run with zero installation, zero conflicts with other applications, and zero lock-in anywhere -- Applications may be moved among machines easily, including those in a cloud, providing OS-free instant provisioning.

1. Package:  Create virtual application appliance (VAA) with the AppZero Creator
2. Deploy: VAAs are copied to physical or virtual machines  -- applications run without installation. Zero-install. A VAA is compressed for minimal transfer time.
3. Run: AppZero Director creates small runtime environment to isolate VAA from operating system.  The application writes changes to the VAA.  Underlying OS is unchanged.
4. Administer: AppZero Admin manages VAAs

• When you move an application as an AppZero VAA, its image size will be 10-100 times smaller than as a machine image.  This difference in size makes network move times significantly faster using AppZero.
• AppZero’s lighter application virtualization and isolation allows for a much higher density
  • Offers cost savings on hardware, software, and OS licenses
• Target OS can be certified, hardened, etc.
• Application state, configuration can be layered dramatically increasing reuse
• Gold OS and gold App images can be dynamically composed
  • Reduces number of OS and Apps to manage, patch, certify, etc
  • Viruses can be dumped, cleansed via dynamic gold composition

The machine image approach: When an entire image is moved, all of the infrastructure elements come with it, including: security systems, backup, monitoring, management and so on.  This all inclusive aspect may not be appropriate for a new environment.  It's not just device drivers that need to be changed. Differing configuration surrounding a machine will also cause migration problems.  For example, if multiple network segments are in use, or if new storage configurations are required, adjustments must all be made for each instance at the OS level.  With AppZero, these aspects can be set up as required in a standard way and the virtualized mount points and networking can simply be set to use the existing configuration.

Both approaches have the following in common:

• Broad platform support – including Windows, Linux and UNIX
• System portability – Note:  the machine image approach moves an entire system’s personality and AppZero moves the application. Both move to dissimilar hardware
• Physical and virtual migration (P2P, P2V, V2P and V2V)
• The application state can be captured for ease of cloning or movement
• Support for both DAS and SAN booting

Scaling is easily done by simply copying the VAA to another server, as opposed to reconfiguring the OS again in a VM.  Unlike P2V or moving VMs, we do not require the OS to be reconfigured.

Even very complex services, including DB servers, all end up as a single VAA file with no dependency on the OS.  Because it is a single file with no dependency on the OS, the VAA is so easy to move around – copy and run.

Unlike a virtual machine approach in which an application is installed on a VM, AppZero VAAs sit above the OS level and are unconcerned about different things like:

• Different hypervisors in place
• Processor architecture
• CPU core count
• Infrastructure such as storage configuration or technology
• Management frameworks and tolls for monitoring OS configuration and file versions
• Cloud technology

All of those concerns can be divorced away from the application.  So instead of moving a virtual machine and attempting to make it fit in a new environment, with AppZero you configure a machine – virtual or not – with all the infrastructure requirements and , using a VAA, simply move the app in on top of it.  This approach is a far simpler solution than configuring a system, trying to reconstruct an entire system or OS.  If you have ever tried to do this with a VM type migration, you understand the issues involved and how hard it can be to do.

The fact is that a VAA is simply much smaller than a VM.  A VAA can be 10 to 100 times smaller than the typical 50GB VM we see out there.  Moving the VM to a public cloud can literally take days – but with a VAA we’re talking hours.  Also you can deploy a VAA to an SE – run it instantly – then do a simple copy to the customer’s machine for a trial.  No reconfiguration for different hypervisors … all that gets left behind.  You simply copy and run.  We bring extreme simplicity – you can use the same configuration each time.  And if you want a VAA gone, simply delete it.  There is no need to uninstall.

It’s not better – it’s different.  Most people line up around the hypervisor approach to virtualization in which the application, the artifacts that come with it, and the OS are packaged up together.  VM images tie OS and apps together forever and must be managed as a whole.

AppZero breaks the application out of its siloed environment, separating the application from the OS.  We’re not competition to the VM approach, we solve a different set of problems than the Virtual Machine does.  For instance AppZero lets you break your application into smaller Lego-like pieces that lets you combine them into many instances, simplifies patching, and helps with consolidation – allowing many applications on an OS.

You can script when a VAA is docked.  So, for example, if there’s a specific configuration item that your app needs to know about when it’s moved to a new environment, that could be scripted here.  For instance, if an app wants to have the machine IP address in a registry entry, you can write a little script that catches the machine IP address and write it into the VAA at docking – into that part of the registry.  And, of course, if the VAA were to be moved, that script would be run again and you’d automatically have the new IP address in it.  So there are things like that that are really handy to do to accommodate an application’s configuration requirements.  Scripting is especially useful when you move an app to a new environment.  There is a Run command that is also useful in automation.  You can say on the command line, “Dock.  Run”.  If it’s a database server everything runs immediately.

The first step involves “Docking” a VAA.  Docking establishes the VAA context prior to starting any applications.  Once a VAA is docked, “Run” starts the VAA’s primary application. Dock is useful to run application configuration tools, upgrade applications, and run other products in the app context, including the command prompt.  Dock/undock are fully scriptable to gain control when a VAA is moved.

AppZero has an "Appliance Zone" with precreated VAAs available to serve as examples. These examples are virtualized open source products.  If a template is desired, it can be generated from these VAAs, but they may also be used ‘as is’ for deployment.

For products that require a license, the process is a bit different. While AppZero does support templates, we usually describe each application's configuration in a cookbook document so that the details of the creation process are visible and easily understood. Here we also document any scripting that has been added in case there is a reason to modify it. As an example, SQL Server requires a crypto key to be generated in a script when a VAA is moved to a new machine. This type of detail can be useful knowledge and documenting it eliminates the need for a user to parse through templates looking for such info.

AppZero's technology can be integrated with existing frameworks such as OpenStack or Eucalyptus to create a "store" where apps may be simply downloaded and run. We are looking at creating a more comprehensive approach to this capability in the future. To date, we have created a proof of concept demo that demonstrates a simple Web-based drag and drop user interface for moving application instances among servers. Behind this interface, a simple framework moves the VAAs from server to server and starts them as needed.

Depending on the application, there may be some changes required to use a VAA when it is moved to a new machine, such as specifying a unique IP address. AppZero has features to support this type of activity including network identity settings and full scripting capabilities if custom changes are necessary.

Two features we support are the ability to move a dedicated IP address with a VAA to a new machine, as well as the ability to dynamically specify an IP address to be used by a VAA. However, in the case where the IP address needs to change and configuration files need the new address, a script would generally be used to do a search and replace in the appropriate files, such as web.config for IIS. This is a typical use case and we have a simple script we can share. Another example of a scripted configuration change is the case where the app stores the machine name somewhere in its configuration and it needs to be changed when the app is moved.

The process of deploying a VAA will automatically handle the transition from a 32 bit to a 64 bit target machine without any user interaction. This occurs during the deployment stage we call "dock", which precedes “run”. Docking allows AppZero to prepare an app after it is moved if necessary. After docking, the app can be run, which is execution of the application code. Once a VAA is docked, it can stay docked to be started and stopped, and then started again. The VAA itself will still run as a 32 bit app, but the AppZero runtime in use will be 64 bit in this case.

A properly created VAA can simply be copied and run. The VAA size is roughly the size of the installed application after compression. Apache and MySQL are not too large and the setup time generally is dictated by the small amount of time it takes to move the compressed VAA across the network in use. Compressing and uncompressing the VAA as part of the transfer might take 30 seconds or so depending on CPU speed and disk throughput.

We have successfully packaged MSSQL. This can be done in a half hour or so beyond the basic SQL install. We recommend you talk to us for guidance since there is some complexity in the Microsoft environment that can be challenging for a new user to figure out during the creation process. Most of this complexity revolves around the WMI management interfaces.

The application downtime associated with a P2V can be eliminated.  Once an existing application has been captured and tested, it is easy to repeat quickly at a later time.

As long as the VAA files are accessible through the file system, it may reside in any location.

Infrastructure elements such as security, management, monitoring, backup etc. may be different among servers.  They do not affect migrating an application with AppZero.

Because AppZero sits on top of the OS, we are not affected by hypervisor changes, available memory, processor architecture, core count, storage technology or other OS specifics.

Application virtualization is light weight.  We track what files, registry setting, etc. an app needs and provide those from the VAA when the app asks for it.  Everything else operates normally so AppZero has little performance impact.

If there were a special DLL you wanted to bring along, you’d put it in the VAA and the app would look for it first in the VAA.  The intercept layer looks first in the VAA for a file that is requested.  If for some reason, you choose to bring a part of the OS along – an OS DLL – we’ll see it there as well.  It can be picked up by the creator process or simply added into the file structure later.

The VAA is expanded into a normal directory on disk from the single VAA file.  Once there, items can be added, deleted, and upgraded as needed using normal tools such as Explorer or the command line.

There are two basic setup options for what we call “VAA creation”:

1. The first option is appropriate for a brand new application installation. In this case, a snapshot of the system is taken before the app is installed. After installation, the VAA is created by referencing the original snapshot, and capturing changes that are made to the system and found by the AppZero creation tool. If the app is configured beyond its basic install, those changes are also captured.  This approach allows the use of normal configuration tools to create specialized configurations, such as pre-populating databases, setting up custom security, and so on. There is no need to manually create XML to capture keys or files; the creation tool takes care of all of that.
2. The second option for capturing apps is called "learn" mode. In this case, the creation process watches all of the files, registry entries and other items that an app uses during operation to capture its full configuration. This approach is typically used when a fresh install is not possible. Learn mode depends on the app being used in a comprehensive way so that all of its files, keys and the like are accessed during operation. As a result, it requires more application knowledge to capture the complete app using learn mode than snapshotting. If an item is missing, it is simple to add it to the VAA later on by copying it into the VAA. AppZero is continually investing in this technology to improve its effectiveness and ease of use.

The virtual appliance (VA) – which is an application installed into and distributed with a VM – is very common in the Linux world today.  It is not common in the Windows world because of restrictions Microsoft has on distributing its OS. 

Compare and contrasting AppZero VAAs with the VM-based VA, you get the following similarities:  Both allow for fast provisioning, simplified test and development, and reduced life cycle cost.  There the similarities end.

The VM is not for Windows.  The AppZero VAA accommodates Windows apps today.  The VM-based VA only works on virtual machines, the VAA is at home on physical and virtual machines without any changes.  When an ISV uses the VM approach, they take on ownership of maintaining, not only their own application, but the OS as well – an arrangement not all customers will appreciate.  Because the VAA separates out the app from the OS, the ISV is responsible only for their own application – the customer’s IT takes care of the OS.

The difference in size between an AppZero VAA and a VM is huge – gigabytes that translate into days of difference in time.  And, last of all – the VAA is immediately ready for any cloud without alteration.  This fact is of particular interest if someone is concerned about lock-in or if someone wants to move to a managed cloud provider.

For software vendors, the VAA has impact and applicability across the sales cycle.  We start with the ISV sale rep out looking for the pot of gold.  Doing a demo on his portable device – or the SEs, the VAA can be copied and run immediately to the customer environment – on premises or in the cloud for a PoC.  No installation – they are instantly running and working at the customer’s issues.  Any work that gets done on the PoC can be moved over effortlessly into a trial, which in turn can transition into a departmental go live implementation.  Time, money, and effort are saved along the way – impressing the customer, and giving the ISV resources more time to actually work with the customer rather than spending a day or so configuring the PoC environment.

Increased revenue:  Win more PoCs; Accelerate sales cycle/time to revenue

Decreased costs : Lower cost of sales; Decrease cost of acquiring customer

Maximize resource and process effectiveness: Support your application, not the underlying OS;  Reduce the number of application/ technical environment combinations you have to test and maintain; Run your app in any provider’s cloud – no change or lock-in

Non-intrusive: No change to technology of choice; No disruption to established business processes

The VAA can be copied onto an SE’s portable allowing him/(less often) her to have many copies on one device.  The application can be moved to a customer data center where it runs instantly, and of course, we can move it to the cloud.  This approach lets you run apps instantly for PoCs, demos … or if someone wants you to run a trial in their own data center, it saves you from having to worry about configurations in a different environment.  Instead, just provide your customer with a VAA and your application runs instantly without installation.

Unlike Racemi, AppZero does not bring along the OS and then try to reconfigure it. That can get messy in disparate environments.  AppZero recommends that a clean, appropriately configured OS be standardized for each target environment and then the application be moved onto this OS - no reconfiguration.

Unlike Rightscale, which does installs, AppZero can move existing configured apps.  AppZero does not require scripting for all operations.  Virtualization "discovers" what need to be brought along for an app.