Comments on: Developing and deploying Java on middleware and in the cloud: rise of the Virtual Appliance? http://blog.xebia.com/2010/03/09/developing-and-deploying-java-on-middleware-and-in-the-cloud-rise-of-the-virtual-appliance/ Software development done right! Wed, 08 Feb 2012 14:41:38 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Andrew Phillips http://blog.xebia.com/2010/03/09/developing-and-deploying-java-on-middleware-and-in-the-cloud-rise-of-the-virtual-appliance/#comment-94379 Andrew Phillips Thu, 25 Mar 2010 16:04:07 +0000 http://blog.xebia.com/?p=4171#comment-94379 <em>@Solomon:</em> <em>> Cloudlets and its lack of support for XML and binary templating</em> If it reads as though I'm implying that Cloudlets does not support XML that was certainly not the intention. After all, they're text files, so you can use placeholders and template expressions perfectly well. What I was trying to point out is that "customization by config file templating" isn't always suitable, e.g. for systems with many config files which are not supported as a public API, such as WebSphere or WebLogic. Here, you'd presumably want to use the public administrative interfaces instead. Apart from binary files, which in aren't usually common in a Unix environment, one thing that's also not easy to do with file-level templating is specifying target-specific packages, e.g. a 32-bit version in Development vs. a 64-bit version in Test. Whilst these kind of configurations are regrettably still common, I think this is mainly due to "legacy" thinking. Having seen far too many "But it works in Dev! - Oh yes, but that's a different JVM version." problems, I strongly believe we should aim to be moving towards using the same environment setup everywhere, as I wrote. In that case, target-specific packages are thankfully not an issue ;-) @Solomon:

> Cloudlets and its lack of support for XML and binary templating

If it reads as though I’m implying that Cloudlets does not support XML that was certainly not the intention. After all, they’re text files, so you can use placeholders and template expressions perfectly well.

What I was trying to point out is that “customization by config file templating” isn’t always suitable, e.g. for systems with many config files which are not supported as a public API, such as WebSphere or WebLogic. Here, you’d presumably want to use the public administrative interfaces instead.

Apart from binary files, which in aren’t usually common in a Unix environment, one thing that’s also not easy to do with file-level templating is specifying target-specific packages, e.g. a 32-bit version in Development vs. a 64-bit version in Test.

Whilst these kind of configurations are regrettably still common, I think this is mainly due to “legacy” thinking. Having seen far too many “But it works in Dev! – Oh yes, but that’s a different JVM version.” problems, I strongly believe we should aim to be moving towards using the same environment setup everywhere, as I wrote. In that case, target-specific packages are thankfully not an issue ;-)

]]> By: Andrew Phillips http://blog.xebia.com/2010/03/09/developing-and-deploying-java-on-middleware-and-in-the-cloud-rise-of-the-virtual-appliance/#comment-94281 Andrew Phillips Thu, 11 Mar 2010 16:23:01 +0000 http://blog.xebia.com/?p=4171#comment-94281 <em>@Adrian: Chef Server REST API</em> - I think this could be useful if you're interested in using a Chef Server for configuration without wanting to have Chef clients on your images. I would imagine this is more likely to be an issue if you're in control of your image catalogue, but I'm not sure how common this scenario will be. I'd assume that you'd want to use Chef Client (or Chef Solo) if you're interested in actually executing recipies. But I guess you could use the API to talk to the server if you were focussing more on using the Server as a repository, potentially interpreting the data in a different way. <em>Pallet</em> - as far as I can gather, the main focus here is still on portability, i.e. running the same image (set) on different infrastructures. The "hook" to run shell scripts or recipies via Chef Solo is essentially what I had in mind when talking about "Optionally wired up by Puppet, Chef, cfengine, SmartFrog or any of the like.". Still, this is largely about the <em>how</em> of configuration, rather than the <em>what</em>. @Adrian: Chef Server REST API – I think this could be useful if you’re interested in using a Chef Server for configuration without wanting to have Chef clients on your images. I would imagine this is more likely to be an issue if you’re in control of your image catalogue, but I’m not sure how common this scenario will be.
I’d assume that you’d want to use Chef Client (or Chef Solo) if you’re interested in actually executing recipies. But I guess you could use the API to talk to the server if you were focussing more on using the Server as a repository, potentially interpreting the data in a different way.
Pallet – as far as I can gather, the main focus here is still on portability, i.e. running the same image (set) on different infrastructures. The “hook” to run shell scripts or recipies via Chef Solo is essentially what I had in mind when talking about “Optionally wired up by Puppet, Chef, cfengine, SmartFrog or any of the like.”. Still, this is largely about the how of configuration, rather than the what.

]]> By: Solomon Hykes http://blog.xebia.com/2010/03/09/developing-and-deploying-java-on-middleware-and-in-the-cloud-rise-of-the-virtual-appliance/#comment-94280 Solomon Hykes Thu, 11 Mar 2010 15:23:44 +0000 http://blog.xebia.com/?p=4171#comment-94280 Andrew, thanks for moving this conversation forward. A few comments: 1. You mention Cloudlets and its lack of support for XML and binary templating. We want to support this. I'm emailing you separately to get more details and start working on it. 2. I agree that service-driven deployment is the goal. I think smart images such as Cloudlets are a *necessary* building block to reach that goal. To cleanly address higher-level considerations such as SLAs, scale or multi-node deployments, you need to reference objects representing the behaviour of a configured node. These objects needs to be reusable and self-contained, regardless of *how* they were built and where they will run. That's the roadmap for Cloudlets, in a nutshell. Solomon Hykes @solomonstre Andrew, thanks for moving this conversation forward. A few comments:

1. You mention Cloudlets and its lack of support for XML and binary templating. We want to support this. I’m emailing you separately to get more details and start working on it.

2. I agree that service-driven deployment is the goal. I think smart images such as Cloudlets are a *necessary* building block to reach that goal.

To cleanly address higher-level considerations such as SLAs, scale or multi-node deployments, you need to reference objects representing the behaviour of a configured node. These objects needs to be reusable and self-contained, regardless of *how* they were built and where they will run. That’s the roadmap for Cloudlets, in a nutshell.

Solomon Hykes
@solomonstre

]]> By: Andrew Phillips http://blog.xebia.com/2010/03/09/developing-and-deploying-java-on-middleware-and-in-the-cloud-rise-of-the-virtual-appliance/#comment-94279 Andrew Phillips Thu, 11 Mar 2010 11:39:57 +0000 http://blog.xebia.com/?p=4171#comment-94279 <em>Update:</em> I wrote that I was curious about Spring/VMware - well, it looks like <a href="http://www.springsource.com/newsevents/springsource-unveils-tc-server-spring-e" target="_new" rel="nofollow">something is on its way</a>... Update: I wrote that I was curious about Spring/VMware – well, it looks like something is on its way…

]]> By: Adrian Cole http://blog.xebia.com/2010/03/09/developing-and-deploying-java-on-middleware-and-in-the-cloud-rise-of-the-virtual-appliance/#comment-94269 Adrian Cole Tue, 09 Mar 2010 17:30:15 +0000 http://blog.xebia.com/?p=4171#comment-94269 Great summary of what's going on today, and what's addressing the concerns. What do you think of these "cloud templating" developments? 1. pallet - flexible cloud bootstrapping http://github.com/hugoduncan/pallet 2. chef rest api - cookbooks in the sky ;) http://wiki.opscode.com/display/chef/Chef+Server+REST+API -Adrian founder jclouds Great summary of what’s going on today, and what’s addressing the concerns.

What do you think of these “cloud templating” developments?

1. pallet – flexible cloud bootstrapping
http://github.com/hugoduncan/pallet

2. chef rest api – cookbooks in the sky ;)
http://wiki.opscode.com/display/chef/Chef+Server+REST+API

-Adrian
founder jclouds

]]>