By jasoncatsun on Aug 31, 2009
There's an increasing trend in the compute virtualization space to package apps with OS images as "virtual appliances." A great example is VMWare's virtual appliance library. As we continue to look at how the world of private cloud-like virtualization and public cloud computing starts to merge, looking at how we package and deploy apps is important.
For many IT shops in the enterprise, they may not get involved with basic cloud deployments on Amazon and such -- and frankly may not even be aware. Large-scale custom architectures are typically well thought and have lots of support from vendors and professional services -- they are high risk and deserved to be treated as such. But is everything custom?
This is the struggle -- the "urban planning" of the data center such that applications are zoned and deployed in environments created by TYPE vs single purpose. This has been the holy grail for some time, and projects like Sun's Dynamic Infrastructure, HP's Agile, etc attempts to address this. Increasingly cloud-like thinking is starting to come into play, with so called "private clouds." But this is really the same area that utility computing et al has been trying to solve for for a long time.
So how do we move forward? How do we start to package, restrict, automate, provision, change, adapt our applications in a model that makes sense moving forward in a very dynamically paced environment while maintaining some level of control over data, privacy, security etc?
Does it make sense to create this urban planning zone as a place to deploy these virtualized appliance stacks as a way to help standardize and deploy apps? What kind of "auto-deploy" features could you leverage some the entire stack didn't change every time you changed some code? We know the cloud model prefers to re-deploy vs patch -- going back to the virtual machine image "master" and making the changes, re-versioning the deployment, and hitting the deploy switch.
We could create virtual appliance stacks as a way to provide higher order application functionality -- e.g. app state clustering and other HA models, as well as providing better control of standards in the environment. Public cloud can be a free-for-all but we don't necessarily want that in production.
A couple of examples...
-- IDE to the cloud -- app stack appliances with standard operating environment (for more on SOE == look at DCRG here ) for application deployment -- e.g. glassfish or JEE or some other stack, where the IDE attaches and deploys to the stack. The stack exists in an environment that provides an SLA -- you don't want that SLA you choose a different "zoning." As the diagram above points out -- this may include even a higher order abstraction. Application elements (cluster instances) working together as a clustered app tier may require you to only deploy apps to the cluster manager and it helps manage the instances.
-- App and Enterprise Management to the cloud -- lot's of tools exist like Oracle's Enterprise Management suite of products that offer application management. These tools should be able to discover and attach to instances in this environment, giving the administrator an access point to admin higher order functions -- e.g. setting up clustering, DB configs, etc. But the basics of configuring a system via commandline etc should be taken care of by the deployment process.
(NOTE to those that build these types of products -- notice I said discover and remember things can change from time to time to IP address mapping is not sufficient. :) )