Ok I am feeling in a bit of a Bob Geldolf/Al Gore inspired mood today after catching a documentary on TV that talked about the design approach of “Cradle to Cradle” or C2C. Yes I know, this is a touchy subject for me, I work for an Airline and although I work for an airline my employer does have an awareness of sustainability.

C2C is interesting and brings up many pondering thoughts relevant to our current working world of the typical IT Landscape. C2C uses a design methodology that ensures that the item being designed is built with components and material that has a real recycling and reuse capability. You may think that programs such as the WEEE directive will take away your end of life hardware components, recycle them and then end up in a 12-18 month period as a new hardware component, but it appears not. WEEE Recycled items such hardware components experiences severe degradation and have a limited amount of reuse capability when they are recycled in this process, I would imagine this is the case for a large percentage of anything that is generally recycled.

So where am I going with this? The reality is this (unless I am missing something in the industry), the hardware within our IT landscapes is designed with very little consideration for initiatives such as a C2C methodology approach and has been this way inclined since the industrial revolution of IT began, we have removed a small proportion of our guilt factor when it comes to disposing of old hardware but it certainly isn’t a silver bullet. So with this thought in mind the main questions I have to IT Vendors are as follows;

• When will you begin to design your portfolio offerings with a design methodology that we see within examples such as C2C?
• When will the industry be able to buy Infrastructure that is infinite future generation compatible?

These Two questions probably indicates what I am getting at here…I want to see radical change in how my IT Infrastructure is designed. Most technology today basically lasts for Five years, most of which I would like to see radical transformation and this Infrastructure to be designed in a C2C fashion so it can reduce;

• The excessive volume of longer term environmental damage due to apparent loss of material quality in the Recycling process,
• Wasted cost to both the customer and also I expect the vendor with introductions of new generation of Hardware infrastructure
• Refresh programs that cost organisations and effect the environment in also indirect areas such as people and implementation costs,
• Removal of EOL or “Wear and Tear”, although not as prevalent in the Datacentre infrastructure landscape in the desktop space this is immensely problematic.

I am not aware that hardware vendors like Dell, EMC, HP and Netapp are designing infrastructure product offerings to meet a C2C Criteria, if you are then please comment. Lets just hope that for our future generations sake that we see a sharp radical volume of R and D from top tier organisations going into designing technology portfolio that is geared towards a C2C methodology for everyones benefit (including them). It is only a matter of time before we see yet another change in how IT sustainability rules are enforced which I am sure will be beneficial but will it be beneficial to actually make considerable amounts of difference to the planet that we all live and depend upon?

This post is by no means suitable for people to feed off of for technical resource on Inmemory DB or NoSQL, I am an Infrastructure Architect, not a DBA or Data Architect. However I do have usually quite a good idea about what goes on in the world of IT vendor acquisition and what the underlying business driver is for that relevant company who is buying the new tech.

Last week Springsource a division of VMware who are a division of EMC (Still with me?), recently acquired Gemsoft, when reading the jargon on how the core Gemsoft technology works I think its an excellent choice to go to market with. Gemsoft is an inmemory  DB that scales across multiple server nodes, with this having the goal of being able to start to remove dependency on the scale up RDBMS that so many Applications have today. And when you think about this what is one of the top barriers that get in the way within your datacentre when you want to Virtualise…..the RDBMS DB or more to the point should I say Oracle!

Oracle is One ISV that EMC/VMware really don’t get an opportunity to play nicely nicely with. As much as VMware hate to say it they really would love customers to have flexibility to run Oracle on a virtual machine with confidence (and I agree), and although I’m skeptical about some specialised DB Workload that are touted as being capable of being virtualised most DB workloads can be, when the business case is put together it falls short at how Oracle license there suite on virtualised environments. Gemsoft or a DB Caching layer may not completely mean you have to dump Oracle, it may mean that you can still use SQL if the application requires by stored conventional DB on disk and Gemsoft DBC driver connectivity, however it is inevitable that the goal is to completely ween off of DB’s like Oracle.

Licensing limitations are not the only barrier in the way of running Oracle applications/db on VMware, for those who were on the moon for the last 18 Months or so, Oracle bought Sun and several over companies who have Virtualisation technology within its portfolio. With the continual dominance that Oracle in the current marketplace has it will be only natural that Vmware begin to lose more and more market share due to Oracle portfolio technology being only supported on Oracle Virtual technology, so this I feel is a measure to stop the rot and is a dam fine way to start a pincer movement on Oracle and remove the monkey that is firmly on EMC and VMware’s back.

Based on the lack of blog posts over the last month you might have thought I was busy, and your right, i’ve gone through the stress of a house move, this post is based on Dan, the consumer who is moving house.

Being the technointernetaddictedcommunicationuber geek I am, the most important first thing on the To-Do list when moving was arranging transfer of existing Phone and Broadband connections. To start with I initialized migration of my phone line on April the 16th, (with me moving in on the 18th), when I arrived to my new property the BT line was already under use by the previous owner.

This ownership meant I had to be subjected to a wait of Two weeks to transfer the line and activate it for me, after waiting for the phone line I then had to request transfer of broadband to work on my new registered address which is hopefully going to be enabled on Monday. So this means its been nearly Three weeks without any form of communication to any of the services that are only and solely available with a phone line and copper or as some marketing divisions of technology providers like to call…the “cloud”!!!

Moving forward I kind of hope this situation improves, we have an emergence of technology that is building heavy reliance upon cloud based services, some of which have over the years had the roadmap visions of moving and operating your apps and data into a centralised Internet based cloud environmnt with nothing but a screen and internet connection in your home connecting to that.

I am sure processes that are required to move me to a new part of the provider Infrastructure is probably due to various antequeted business processes matched with an aging backbone network thats held together with loom and copper, however unfortunately without ubiquitous and seamless connectivity with Cloud services this type of length of effective outage will fail.

Whether communication methods such as IPTV and WIMAX can take off to support movement and fluidity between both your home and when you are out on the road when utilising such architectures is another question, however unless this improves in the next 2-3 years (which I suspect seeing as its been like this for 3-5 years it won’t) we probably are going to lack any serious development in such areas of technology for the consumer.

PaaS emergence

The Transition

• Code Optimisation – Throw poorly written and lazy code into a Metered cloud and it will end up costing you more money, developers will need to think thin and think economically when developing applications,
• Budget planning - Today if you experience poor performance with poor code you throw more Infrastructure resource at it. This resource (if virtualised) has been procured and is an available pool that can be used. In the Cloud because you have moved into an OPEX Pay per use model, budgeting can skew due to applications either consuming too much resource or taking longer to run,
• Testing and UAT – More emphasis will be required on testing the performance of an application targetted for Cloud than what is done in today’s world. I see emergence on testing being performed to ensure applications are more efficient rather than proving that they can scale to X amount of users and provide Y amount of resilience,
• Exit Clauses - The taboo of any hosted/outsourced agreement, this in my mind needs to apply in any agreement from day one as a defacto. Flexibility to be able to move between cloud providers and ensure that your data can be moved without vendor lock-in are paramount to achieving a beneficial cost reduction.
• RFI – Requesting information on what services can be offered by vendors/suppliers will be quite frankly a waste of time, if a cloud provider is a true cloud provider, sales “examples” and the gumph that comes with it should appear or be available to view on the providers website. RFIs will need to move into focusing less on the product and more on what the service being offered truly provides or more what it fails to provide,
• RFP - Quite a brash statement this one but in a cloud world is this going to be used? who is going to request and tender for a cloud based solution if my predictions on RFI becomes true?

As you can see i’ve noted just a few potential areas that may change dramatically when introducing IT strategy that is based around a cloud computing world. This is an exciting turning point for IT, I believe to succeed IT governance and policy control will still need to be emphasised strongly within IT departments in order for strategies to be successful and tangible. A lot of this process is done today but just needs to adapt to the model of Cloud computing, its an opportunity to not make the same mistakes made in previous incarnations of IT and lets hope this time its done right!

This post is a bit controversial (which posts on VMlover aren’t?), it is based upon discussing the recent discussing x86 hardware releases and there value prop of being capable of having more total RAM Density for Virtualised environment’s. When I say Virtualised I mean Server workloads that run business applications not VDI.

One of the reasons that this post could be classed as controversial is this, I question whether RAM density is really giving the customer excessive space and capacity that we are being led to believe it can, and when I say this I mean using a box with suitable IO/form factor that we would class as our sweetspot for Virtualisation based on the usual factors such as a comfortable level of Consolidation ratio, price per VM etc ?

Wind the clock back

Four or so years ago when 32 Bit memory address was de facto for a all OS’s, it was also the start of something good with the beginning of Server Virtualisation being accepted within most enterprise datacentres. At this time 64bit OS/Applications were only a twinkle on a distant roadmap or limited to high end Risc based platforms, the transition to running your applications hosted at the time on 32 Bit was also no way just a swing to x64 bit from 32, the vendors had to do large volumes of work for x64 to become a reality.

Today though datacentres are very different, we have 64bit versions of almost every x86 commodity OS going all capable of exploiting larger allocated RAM volumes to allocate for apps and these apps are compiled to  make best use of large quantities of RAM, one example being Exchange 2007 which is designed to make best use of RAM to cache as much feasibly possible without having to use disk and introduce the deadly bottleneck to virtualised environment of Disk I/O.

My controversial bit

So what am I getting at? Well I think we are still regardless of the excessive volume of RAM that is available to populate in recent x86 Hardware we are still unlikely to get the levels of consolidation ratio in the real world that the marketing from the manufacture uses as the key selling point.  I think we see a relative curve of new x64 gen OS and Applications requiring more higher volumes of RAM to run sufficiently as a baseline minimum requirement, we also have an explosion of growth in required RAM resource to operate applications on x64 bit due to demand for optimal performance and more concurrency.

In Virtualised server environments VMware vSphere allows assignment memory volumes to VM’s that are suitable to run Tier 1 workloads such as Exchange, SAP and Oracle. Again as with the OS/APP stack In the past, a Virtualised environment comprised of in earlier incarnations of smaller under utilised VM’s, now you have VM’s with 12-16GB of RAM which run extremely happily and the more RAM the merrier, so overall larger VM’s mean less VM density per Host. Within Virtualised environments you also have the factor of eggs in one basket scenario and implication of outages on hosts storing large density VM counts, from which has been discussed many times across the blogosphere, some architects and designers prefer a more risk adverse strategy to deploying with this generally being down to SLA expectancy from your business. Personally if you have a resilient and highly available environment built with failover in mind using a VM host with high capable density is certainly acceptable and something that can be implemented.

So to summarise my controversial view, I fill that OS/App and VM RAM sizing requirements is relative to how big the host grows so will not allow you to achieve what you think is possible due to this.

Some future solutions to this problem

I’m going to digress away from the existing facts I’ve stated effect the Host size against VM density argument, and talk about future directions that may ensure we can achieve higher density with hosts.

Removal of the OS or the level of bloat that is required to run an OS would be a start, this is something which has been a vision even back in 2007 by Mendel Rosenbaulm. Reduction of the OS means running the application on finely tuned minimal footprint operating environment which uses only what the application requires. This strategy is achievable today either with JeOS or dare I say it for Windows environments with 2008 Server Core, Remember though having a thinner less feature rich OS usually means it has no GUI and the admin needs to rely on pure CLI commands to operate the environment. In future vendors need to focus to the same way VMware has architected its management strategy with ESXi. ESXi has API to use externally controlled and managed management tools such as vCenter, PowerCLI, additionally it utilises open standard interfaces such as CIM and WS-MAN for managing hardware components.

An obvious is developers could of course work on making applications more efficient, this is tough though, the industry has a shaded past to shake off with apps being compiled to run within the Windows world. This however has had the flip side of meaning it is easier to manage and easier to deploy. My prediction is the next step to more efficient applications is within development of cloud based applications where metered OPEX cost of running applications will drive efficiency.

At a different altogether layer to approaching the problems of excessive memory consumption by the OS and Application, VMware vSphere includes great technology which can provide a more denser environment, this does so with the following key features

• Transparent Page Sharing – VMware environments can reduce the amount of memory used physically by sensibly knowing memory pattern allocation and sharing this between VM’s, this removes a large volume of noise that would occur in non TPS based environments such as Hyper-V and Citrix (for now) that can’t do this and can’t overcommit resource.
• Memory Ballooning – Working as a Virtual hardware driver within a VM, the driver responsible for Ballooning will manage memory allocation based on memory activity occuring within the VM, if memory is requested it works with the Host to provide requested memory (if available), if it isn’t requesting memory it will then interact with the Host to allow it to reallocate memory to another VM that needs it.
• Memory Compression – A future release that will compress memory pages, Scott Drummonds has detail on this http://vpivot.com/2010/03/01/memory-compression/
• Flash Caching – I wrote about this and how Oracle Exadata benefits last week, this provides disk caching but at a faster state than standard spinning rust provides

The above do have performance penalties in some shape or form, they are small but it is important to bear this in mind.

Summary

Maybe a bit controversial here but its my view, I am a realist and very rarely fall for marketing goop and excessive numbers touted on a spec sheet. I think its important that the industry look to make the workload more efficient instead of using Moores Law to make there products look attractive and better than other competitors.