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.
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
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.