Thanks for the props in your comment. I’d be inclined to recommend a virtual appliance rather than a hardware appliance in this case. Being able to move a managed RabbitMQ VM (or AMI or EMI) around, and retain your application addressing, makes it much much easier and cheaper to keep communication going in an “elastic” setting, i.e. as you scale and as applications come and go in the cloud.

alexis

Realistically, with all the stuff out there that “hooks” into all the OSes out there does make such a vision challenging from a migration standpoint. After all the “hooks” are the interfaces that makes it challenging, similar, to pulling out a gasoline combustion engine and replacing it with something that does something with a non-gasoline source of fuel to enable movement. Also, the dark forces of OS provders are like the gasoline providers too. They will fight us and try to kill us. All the same, having given 23.5 years of my career to a large OS provider with three letters I sure will fight back and quite well since I think I deserved another 7.5 years with them. So, the game does continue for me.

Long time ago, ok a short time ago, there was what was called a Universal Turing Machine (UTM). It took something simple and produced something simple. It enabled one to use it to create another UTM that did something else and produced something else. As we evolved, we started layering these UTM and splat now we have VMs. Maybe, that magical future OS could indeed be modelled on a UTM. I think I need to flush that thought out anyhow.

Interestingly, there are so many billions and billions of lines of code (ahh, one day will we talk about the billions and billions of objects too) that invariably will have to be migrated (ok, one means of migration is to throw all that away). That could be challenging since the enterprise has to keep its lights on and all their business logic is buried in that code. Think COBOL. Either way, all the people that know COBOL are rapidly fading away.

Interestingly, our schools teach people how to write some interesting code (usually, something like Java, Python etc). The rarely focus on how to read code. Today, IT spends maybe 80% on maintenance (think read) and 20% on development (think write) while our future readers (of code) are probably 0% while our writers (of code) are probably 100%. Obviously, after my 30 years in IT I think I can read and write code somewhat quite well. So, I think I will just not fade away, for awhile.

Anyhow, here is my process to migrate abstract … albeit, an abstract since the details are indeed my means of livelihood.

Anyhow, I vote for python to be the cloud language. It seems cool. Then again, there are lots of cool languages. So, maybe we need something basic like Backus Naur Form (BNF) or ALGOL to develop our “glue” to squash the bloats (OSes). I think I need to flush that though out too.

Good post.

Derik (never blogs just lurks and comments)) Pereira

So long as developer productivity is tied into the changing world of

“Adding to this brew, mind boggling number of open sources libraries and tools crept into OS.”

I see:

“Sadly, instead of wiping out the cancer bits in the operating environment, all the junk packaged into VMs.”

as being persistent? Maybe JEOS, and brilliant just in time ones such as Randy B suggested can clean up a lot of the bloat, but I do not believe JEOS can clean up all dependancies/drift/etc?

So when you say:

“We need paradigm shift in the way we architect and deliver “services”.

And-

“The Container layer will be the point of qualification on both sides: each new variation of hardware will be qualified against a single Container layer, and all software will be qualified (quite literally, providing a fast lane change mechanisms development, test, staging and production (Continuous Integration & Continuous Deployment) against that same Container layer.”

My question is, how do you adapt to change? If a hot new must have developer tool/library/Swifter comes out you can either tell your developers, sorry not in our package plan (Google’s method) or play catch up once they build it in. Even a skinny container will have change management complexity.

*

Also are there chances to pick of certain parts of the service delivery and harder code them? @monadic from Rabbit MQ tells me you could actually make hardware/ASIC just for delivering his messaging software. Does anything like that start to come into play as you get to hyper-scale on an application?

@wattersjames