Last week I was in sunny Australia in the cities of Brisbane and Melbourne (pronounced Bris-bun and Mel-bun incidentally)...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Fun was had by all – I was there with none other than virtualization luminary Scott Lowe. I managed to bump into Scott whilst at London Heathrow so we got a chance over the week to shoot the breeze about this and that.
A couple of things came to me while I was away. Scott was presenting on the pros/cons of VMware HA “Stretched Clusters” and VMware Site Recovery Manager. I’ve seen him deliver on this topic throughout the year, and it's been interesting to see how this presentation has developed and subtly changed throughout the year. It probably shows how much Scott’s thinking has evolved over the year – about the advantages and disadvantages of both technologies – but also how if you do find yourself doing a similar presentation from one month to another you need to mix it up just for yourself – to keep it interesting. It was nice to see someone, other than me, improving VMware SRM for a change!
As for me I’ve been hawking an SRM5 “Futures” deck for most of this year. That became a “What’s New” in SRM 5.0 on the day of the GA. The back end of the PowerPoint still has some futures stuff in the presentation – about stuff coming down the pipe in 2012/2013. Some of that became more “concrete” to me in a recent roadmap/NDA session I did with guys at VMware at Frimley, UK. Anyway, informally I suggested to Scott that we do a VMworld 2012 session together on Stretched Clusters Vs SRM. With me taking the pro-stance on Stretched Clusters, and him taking the pro-stance on SRM (again mixing it up to keep it interesting – because everyone would expect me to be the pro-SRM guy!) He seems interested, so let's hope that happens.
As for the Oz VMUGs, the personal highlight for me was the breakout session on ThinApp Factory at the Melbourne VMUG. There was surprisingly little information about the product (which is currently just in Alpha) at VMworld. So I had high expectations for the session, and I wasn’t disappointed. Plenty of information and screen grabs, and it was a proper VMware deck, so it looks like the collateral is already in place to position & explain the technology. It hit a note for me because for the last couple of months I’ve been working on a new View5.0/ThinApp4.7 book with Barry Combs of virtualisedreality.com fame. The back of the book has a “futures” section that covers stuff like VMware Horizon, ThinApp Factory, Octupus, SocialCast, AppBlast and SlideRocket. Of course, much of the information is a bit thin on the ground. Horizon isn’t available outside of US boards because of export restrictions – and things like ThinApp Factory or AppBlast aren’t even in beta yet. So it was really nice to see a presentation that put more meat & potatoes around the subject rather than emphasizing the all-important business advantages/challenges or overly focusing on the end-consumer experience (pretty picture screen grabs).
The main idea I got from this session wasn’t as much technical as it was concept or analogy. I’ve got a couple of buddies who work in RF Comms area who have both been on the R&D side, and go-to-market process. One thing they have always stressed to me in their work is that no amount of technological innovation at the bench, is worth a cent unless it can be mass-produced with factory style economies of scale. So that started me thinking about if ThinApp has a “factory” what processes (both business and technical) must have taken place FIRST, before you can undergo a “mass production” of ThinApps. There are a couple of analogies around there too – where application packaging process becomes a “sausage machine” or “meat factory” or a “cookie-cutter” process. So what we're trying to achieve with ThinApp Factory is a move away from a bespoke, craftsman like approach to producing each ThinApp. An approach where each ThinApp is lovingly carved and created by hand. But to a process where an install .EXE goes in one side, and ThinApps come out the other side.
Of course, that’s quite idealistic. Any “production” process will have a % of error – and people who develop the product and manage factories have to make sure that the product that’s been manufactured is so well designed that it lends itself to such mass processes. That’s hardly the case with a generic .MSI file. SO going forward I’m beginning to see how ThinApp Factory will be used to create ThinApp for the vast bulk of applications that respond favorably to the sausage machine approach, the trick will be quickly identifying applications that need to be pulled off the conveyer belt and handled in the old-school way. That’s where service providers and packaging teams will continue to add-value…