posted on Wednesday, May 19, 2010 2:35 PM
There is an excellent article over on SD Times about multi-core programming and virtualization that delves into the approaches that application developers can consider to take advantage of multiple core CPUs. 
For those that missed it, I wrote a bit about this not so long ago. I was looking at multi-core from the perspective of how application developers could take advantage of the increased processing power, and why it is that few if any enterprises will bother.
But Mr. Handy is approaching the problem from the perspective of “should you bother” with Virtualization becoming so commonplace, and then talks about the different ways to tackle the problem.
I for one think Virtualization is the perfect solution if your app – like a web app for example – can use virtualization to circumvent multi-core programming.
And that might just require some explanation, coming from a bare-metal developer who grew up (or at least pretended to) and became a Technical Marketing Manager.
YOU MIGHT WANT TO EXPLAIN THAT
In your average enterprise, uber-geekery is reserved for your free time. The business doesn’t care to let you embark on a pet project that involves writing multi-core libraries that in five years no one in the department might be able to debug. This was a hard revelation for Lori and I when it came. We were doing some hardcore C/C++ work, and I finally came to realize that there were whole swaths of very good programmers who would not be able to follow our work. Time to rewind and simplify. This was the source of Lori and I’s first actual argument… Over indentation and line spacing in the coding standards I worked up. I won, for at that time I was the boss, but she still prods me about it ;-).
This is no less true for the current state of multi-core. The best app in the world is only as good as it can be maintained, and if one or two people hold the keys to the kingdom, that’s a liability to the organization that it should be taking steps to resolve. Not talking about taking steps, it should be managing that risk in the same way that security vulnerabilities or any other risk management topic are managed, for the death or resignation of one person in the bowels of IT should not cause major problems for the entire organization. If you’re a vendor? Yeah, there are key people in AppDev that could go and hurt a lot. But that’s true of every vertical market – the guy that knows every trick of hanging from his belt and working on High Tension power lines would damage the power company if he left, mostly in delayed service recovery. But someone in IT leaving the power company should be a momentary blip, not a screaming problem for a long time to come.
MAN HOURS ARE EXPENSIVE
Compare a complex set of interfaces that enable multi-core and the debugging hours required to figure out which thread is crashing and if it’s specific to the run environment with the world of “just start another VM”. The VM was already debugged (assuming it’s a clone of the one running that needs more processing power), the environment is dictated not by what else is running on the machine but by what the VM presents to the application. The development time, maintenance overhead, and overall cost in man-hours is significantly reduced. And in general, less complexity of code equals less bugs.
Problem is that you need an infrastructure to support this methodology. So some of the savings are shifted from one group in IT (App Dev) to another group in IT (networking). But there are tools out there like our BIG-IP LTM product line and VMWare VCenter Server that will help the network staff automate the spin-up and spin-down of VMs. BIG-IP can send requests using any load balancing algorithm desired to a pool of servers. VMWare VCenter can spin up a new instance of your app and all you’re missing is a way to add it to the pool. There are samples on F5 DevCentral to help you do just that at startup using iControl, there are other ways to do this using the variety of tools available in the two products.
But the point is that you can switch to virtualization as a stand-in for multi-tenancy, and there are tools to automate the creation of new instances. That’s what all the “automation” buzz has been about, and it’s real. Of course, not every application is well suited to this solution, there are no silver bullets in IT. Even virtualization is not good for every single problem, though it does come closer than most IT hype-cycle candidates.
WE CAN REBUILD IT. WE HAVE THE TECHNOLOGY
You can, however, write your code to be a bit more friendly to VM based multi-processing. Don’t assume you are the only instance running, store truly global variables in the DB, etc. For web apps this is not a huge change, much of this exists because of the nature of http interaction. For fat clients (yes, yes they are still developed in the enterprise, more than you would think), this would be a bit harder, but we managed it in SmallTalk wayyyy back in the 90s, so I promise it is not impossible, just more work than for a web-based app. On the bright side, making your application a spawnable VM will make it much more cloud friendly – for some cloud providers anyway.
I will go out on a limb and say that virtualization will win this one by default. It is in your enterprise, the changes to your application are all at the business layer, not the geek layer, and it is a faster development timeline – particularly for new apps, but for older apps also. Even if you don’t have products to help you automate the process, occasionally spawning a new instance versus having code that borders on incomprehensible to many IT staff, we know manual intervention is preferable, even at this time when we’re trying to avoid all manual intervention we can.
THE MORE THINGS CHANGE…
Until tools get completely automated. Give me a compiler than can analyze my code, determine what can be parallelized, and take care of it without me having to do a thing different from today, and I’ll change my tune – for if it costs nothing to do parallel programming and that resolves the problem, why worry about VMs. Until the processing power of an entire box is not enough anyway, and that’s a good problem to have, it means your app is successful.
Related Blogs and Articles
