Future of Deployment - Part 2.5 Getting your virtual appliance from development to production

Robert van Loghem

Virtual Appliance

In my previous post, "future of deployment, part 2", i talked about the new ear, which is an image, with an OS and your application.
Now before diving into part 3, which gets you going in creating your own virtual appliance aka "the image", there is one really big thing i forgot to mention; Some of the benefits of delivering a virtual appliance and getting it from your own development to the production environment! and i'll list the benefits for administrators/ops and developers.

Ask and thou shall receive, thy environment, immediately 😮

So you start developing your new application "CuteAnimalPark" (yes, we at Xebialabs like animals 😉 ), and you talk to the admins and ask them for 3 environments, Test, Acceptance and Production. They of-course respond, "that is fine, we'll have it up-and-running when you can deliver your application", aka "virtual appliance" and give you a link where you can download the Virtual Image where you can install your application on.

So what happened here? Well i wanted 3 environments and got none!? But i did get some image which is in fact the image that is going to run in production. The image is hardened, has got security enabled, all user accounts and file-system rights are in order and is tuned for real world serving the interwebs.

The job of the operators is to make sure applications get to production and run reliably and fast. They are the ones getting called out of bed if my application dies at 3 AM. So therefore they want to give you an image which is the SAME that is going to run in production.
That means IMHO, one of the day-time jobs of these guys and gals is to prepare the images (OS + middleware) for applications and give them out to development teams so they can in turn create virtual appliances.

Action #1 Get a production ready image to install the application on.
Benefit for Devs #1 You develop and deploy to "really-really-close-to" production system
Benefit for Ops #1 You get an application that is known to run on a production system

Running the production image aka virtual appliance in other environments then production

So when you have installed the application on the image you have to make sure it can be used in other environments then development. The application might need to connect to a database, now the database will mostly differ from one environment to the other, so as soon as the application is placed into the environment, you have to get in there and change the URL and most probably, username and password of the datasource the application is using so it will connect to the e.g. database in test and not the developers own MySQL database on his local machine.

Changing the way an application uses a database should be just as easy by changing the properties on a datasource, and most of the JEE containers make this fairly easy, but i've personally seen lots of other properties which are very environment specific which were in property files, in JAR files that needed changing when moving the application from one environment to the other. Not so easy then ;(

Make sure that when you design and develop your application that environment specific properties are easily accessible and can be changed by operators.

Action #2 for Devs Design and Build your application so it can exist in multiple environments
Action #2 for Ops This also applies to Operators, who have to be aware that the image they deliver will need to run in different environments (e.g. use hostnames when installing middleware and don't use IP-addresses)
Benefit for Devs #2 Your application is portable, it can be moved almost anywhere and administrators can do it without your help
Benefit for Ops #2 Easily move images to wherever you want, move stuff from your private cloud to the public, will be a lot easier! per application.

Deploy Virtual Appliance

After this step, it means that your virtual appliance can now be deployed to the various environments, which of-course are running some sort of virtualization hypervisor from some known vendor. Every time the appliance is deployed, before it is started the operators configure it. Making sure the Datasource connects to the right database, the Queues connect to the right Message broker, and so on.
After configuring the application you can start up the whole bunch and bask in glory. (make sure the ops know in how to properly start the application and how they can tell it works)

The flow from development to production is that simple, but wait! there's more, troubleshooting?

Again here is the flow from the 2 paragraphs above:
- Get a production like image
- Install your application on it
- Allow operators to move your virtual appliance from test to production (without needing your assistance)

But of-course stuff can go wrong in production, your application might break, has a race condition under extreme load, and you as a developer want to get your hands on production and find out what is wrong. But alas, the operators will not allow you to access production, most likely they'll send you the logs, thread and heap dumps but that is it. So wouldn't it be nice if you could have the access to production when it is not used in production?

With virtualization you can get a snapshot of the images running in production, transfer it to your local development environment and really get into finding the problem. There is always the trouble of generating real user requests but this is a very big step forward to get your hands where the real problem occurred.

Action #3 Whenever an issue pops up with an application, create a snapshot of the image and let the developer have access to it
Benefit for Devs #3 You can get to the source of the problem more easily
Benefit for Ops #3 You still don't need to give access to developers on production if you don't want to, just let them have a copy of the current state of production

Makes sense?

Well there you have it, this is what i think will be the biggest change in the way we deploy an application from development to production in about 3-5 years. As i mentioned before, post 3 will be about doing it yourself with the current tools available, from Xebialabs of-course and VMWare.

Comments (3)

  1. Luís Carlos Moreira da Costa - Reply

    August 16, 2010 at 3:22 pm


  2. Andrew Phillips - Reply

    August 17, 2010 at 1:20 pm

    > Every time the appliance is deployed, before it is started the operators configure it.

    Isn't this hugely time-consuming - in fact, wouldn't this significantly reduce the ability to "hot provision" anything, which is seen as one of the main benefits of virtualization? Providing a technical solution to this problem (cf. "Templates, not clones" in this post) would seem to be a critical development here.

    > With virtualization you can get a snapshot of the images running in production,
    > transfer it to your local development environment and really get into finding the
    > problem.

    Would you really recommend freezing a production image for seconds to minutes in order to take a snapshot? Not all hypervisors support memory snapshots.
    Also, given your previous point about configuring images for different environments, wouldn't you have to tweak or change the production snapshot to run on a non-prod environment? Or are you suggesting creating a production-like virtual environment (incl. databases and other external dependencies) for the debugging too?

    On a different note, for which kind of problems do you think snapshotting might actually work? I can see it perhaps helping with deadlocks, but with transient load-dependent effects, or race conditions, I don't see how you would be able to guarantee you hit the "Take snapshot" button in time.

  3. Robert van Loghem - Reply

    August 17, 2010 at 3:34 pm


    > Isn’t this hugely time-consuming

    Yes it is! but e.g. WebSphere still hasn't made an API or at least a document available which allows you to template such values. Perhaps Spring and VMWare are up to something, no? Therefore the only way to change such values is to get the Image + Middleware up and running and use public and known access methods (wsadmin, WLST for you Weblogic people) to change these values.

    On the other hand, if you have a Tomcat environment this is easily achievable.

    > Would you really recommend freezing a production image for seconds to minutes in order to take a snapshot? Not all hypervisors support memory snapshots.

    I would only recommend it on hypervisors which fully and reliably support this, like VMWare, which does not pause the running image, therefore in theory (remember, this is brand new stuff, i don't have knee-down-deep-mud-experience) this should work.

    I don't think you can store-snapshot evrything. But at least it is a big improvement over the tried and old, just send logs...You now have the entire system at your disposal.


Add a Comment