App Manageability blog

» Performance characteristics of virtualization led server consolidation

Virtualization is red hot these days -- everyone, and his mother, is not only talking about but also investing in it.

But what happens to performance characteristics, such as throughput and response time, of applications that get shoved on a single physical server? This paper authored by VMware (and questioned by some) comparing VMware and XEN virtualization performance claims that the virtualization overhead of VMware is actually less than 5% for a variety of tasks. The results are based on observing runtime performance of a number of specialized benchmarks. But we all know how well such results published by the vendor itself correlate with real life observations!

So I was quite excited to find two papers published by IBM on performance characteristics of WebSphere Application Servers (WAS instances) running under VMware virtualization. One of these papers are actually available from VMware sites.

The first one, Using VMware ESX Server with IBM WebSphere Application Server, published on July 24, 2006, compares response time and throughput of a simple webapp running within a WAS instance deployed on physical machines and virtual machines under different configurations. The second one, Performance Characteristics of Virtualized Systems with the VMware ESX Server and Sizing Methodology for Consolidating Servers, extends the analysis and comes up with some useful guidelines on consolidated server sizing.

Although you must read the papers to really understand what was tested and under what conditions, I venture to state some of my consclusions/observations anyway:

As per the first paper, the performance overhead of running four Linux VMs, each running a WAS instance, compared to 4 instances of WAS natively running under a single copy of Linux on a 4-CPU system is not very signficant (throughput degrades from 224 pages/sec to 201 pages/sec under virtualization and the response time actually improves from 80ms to 78ms). However, increasing the number of VMs to 8 on the same 4-CPU machine degrades the response time signficantly (from 78 ms to 164ms).
The second paper reports only throughput (don't know why) on Windows VMs and compares throughput when a single instance of WAS is running natively and under VM on a 1-CPU and 2-CPU machines. The throughput under VM is 73% of the corresponding number on the native OS for a 1-CPU system and 69% for a 2-CPU system.

These two observations may appear to be conflicting at first but are not. Running multiple apps (WAS instances, in this case) under a single OS incurs signficant overhead, very similar to what multiple VMs incur under a hypervisor and in this case the hypervisor overhead itself may not be that significant. However, there is a definite overhead of the hypervisor for a single app running at full capacity within a single VM, as shown in the second paper.

These observations actually strengthen the argument for virtualization in server consolidation situations when apps don't fully utilize the infrastructure resources. At the same time, one must be careful about going the virtualization route for apps that need as much processing power as possible! Even then, the flexibility offered by virtualization may be worth the cost.

One thing I found missing from both the papers was discussion on memory utilization under different scenarios. I would assume sceanrios using VMs to use more memory than the one with native OS, for the hypervisor and the separate copies of OS will consume extra RAM. Also, WAS instances running in different VMs will have no opportunity to share code with other instances, as would be possible within a single OS image. This can't be good for memory hungry applications. Exactly how much memory goes towards these is hard to estimate as the hypervisor typically do perform sophisticated memory management and might be mapping different pages with same bytes read by different VMs to the same RAM locations.

I would also have preferred information on response time comparison with and without virtualization in the second paper. The response time is relevant even when the system is not fully loaded and a significant degradation due to virtualization would not be good news.

30% virtualization overhead reported in the second paper for 1-CPU and 2-CPU systems may not be of much consequnce to most enterprise data centers that prefer to run multi-CPU servers and average utilization is in the order of 10-15%. However, it is signficant if you are an ASP and plan to run farms of inexpensive 2-CPU machines at near full capacity. It is also signficant if you plan to rent computing power from a service like EC2 that uses some form of virtualization and making cost comparisons with native systems. I actually did this once for one of my hobby projects!

The key lesson, at least for me, is that you got to be careful about your deployment to minimize the overhead of virtualization. The best, of course, is to do perfoirmance testing under virtualization and identify the bottlenecks. More on this later!

» Read the full content

Posted by Pankaj Kumar on Friday, August 24, 2007 at 6:10:00 PM

Permalink | Trackbacks (0) | Comments (0)

» SOA is great, but you need to pay attention to certain aspects

The Feb. 2007 issue of acm queue has an interesting article titled Is Your SOA (Service Oriented Architecture) DOA (Dead on Arrival)? It begins with a hypothetical story of Marty the Software Manager who gets fired on a failed and over-promised SOA project.

Like any software project, a SOA project could go wrong due to a multitude of reasons: inadequate analysis of the problem space, wrong level of abstraction, over-reliance on vendor promises, lack of buy-in from stake holders and so on. It is important to keep in mind that SOA is just an architectural style and not a panacea and substitute for good old engineering principles. In fact distributed and shared nature of SOA systems heightens some of the traditional problem areas such as availability, versioning, recovery-on-failure etc.

A strong governance program, aided by software tools like HP Systinet, can go a long to address some of these issues.

» Read the full content

Posted by Pankaj Kumar on Wednesday, February 14, 2007 at 4:01:00 PM

Permalink | Trackbacks (0) | Comments (0)

» Is the era of open standards-based products over?

Came across two items on the web within a span of few minutes supporting the hypothesis that we may be entering into an era of closed, non-modular and proprietary products:

Nicholas Carr's interesting and insightful blog entry titled the strange world of digital music, citing Microsoft's proprietary Zune system and the recent partnership between RealNetowrks and SanDsik and quoting extensively from Clayton Christensen's famed book The Innovator's Solution, claims that the industry of digital music industry seem to be defying the Clayton's logic that " ... once the technology matures and becomes good enough, industry standards emerge. That leads to the standardization of interfaces, which lets companies specialize on pieces of the overall system, and the product becomes modular."
End of Life FAQ for Adobe SVG Viewer (ASV) from Adobe. The FAQ essenetially says that the Adobe is abandoning its support for open SVG standard in favor of its proprietarty Flash technology acquired through Macromedia acquisition. This may be the death-nail for the struggling SVG, which has found support in browsers like FireFox, Opera and Safari but not with the market leader Internet Explorer. It should be noted that SVG is an estanlished W3C standard for graphics on web browsers, works well with other technologies such as XHTML, W3C DOM and CSS, could really turbo charge AJAX based web applications but is being abandoned in favor of propriaetory and closed systems.

Now, two examples don't make a trend, but then, I haven't looked hard enough for other examples.

» Read the full content

Posted by Pankaj Kumar on Monday, September 18, 2006 at 6:22:00 PM

Permalink | Trackbacks (0) | Comments (2)

» Delving into point-to-point integrations

Point-to-point integrations are routinely denounced as being complex, unmanageable, ridden with all sorts of problems and, in general, an antithesis of the kind of agile architectures promoted by Service Oriented Architecture (SOA). But what exactly are these point-to-point integrations and why are they bad? Is it about the style of interaction among participating entities or something else, for even the services in a SOA get consumed by clients that invoke them, or send messages and the interaction can be thought of as point-to-point.

This, and similar other issues, resulted in a long and lively e-mail discussion among several of us at HP. The result was a much better group understanding of various things at the core of enterprise integrations including interactions at different layers, infrastructure to support the interaction at any given layer, the style of interactions themselves and the process of creating the integrations that result into these interactions.

The whole discussion might have got burried in our InBoxes along myriad other company-internal communications, had it not been for a few good folks who took the time to convert the raw e-mail messages into a much more readable article. Thanks to them that most of the points have been captured and presented in the online article Moving from point-to-point Integrations to SOA based Integrations.

If you find the organization and flow a bit non-smooth at places, you now know the reason -- it was not written for publication to start with. Nonetheless the points made are quite valid and go much deeper than most high level corporate-speak or marketing literature.

» Read the full content

Posted by Pankaj Kumar on Monday, September 18, 2006 at 5:45:00 PM

Permalink | Trackbacks (0) | Comments (0)

» The right development platform for web applications

Joel Spolsky, a well known entrepreneur and blogger within the software development community, claims, in his latest blog post The Language Wars, that the best development platforms for web applications are C#, Java, PHP and Python, and among these, the one that you know most. The post also has some unkind remarks on an emerging platform, Ruby on Rails, and hence has generated significant amount of buzz in the blogosphere.

At one level, I do agree with Joel. However, Joel doesn't quite explain what he means by "you" and "know" in the phrase "you know most". Most enterprise development is done by teams and there are usually multiple teams involved. So, "knowing" a platform is not about the ability of a single devloper to design, code and troubleshoot. It is also about the ability of a team to collectively develop, and other teams to deploy, operate, support and manage. As the teams in the second category, that is, those who deploy, operate, support and manage, have to work with multiple software systems, it is clear that the "you" in "you know most" has to be the whole IT department of the enterprise.

The collective "know"ledge of an enterprise evolves as it creates policies around I18N support, supported hardware and operating systems, software to manage the applications, employee training, preference of its customers and myriad other such things. In fact, certain platforms can easily be ruled out based on just the last one. If you are an ISV developing software for enterprises and want to support as many platforms as possible, then you probably aren't going to write in C#. Similalry, if you care about your app being managed by leading management software then PHP or Python is not a great choice. No wonder, most ISVs love Java, the only one that is left from the initial list of four after applying the requirements from majority of potential customers.

Of course, the same constraints do not apply if you develop for small businesses or individuals who may want to deploy the software on a shared host under an inexpensive hosting plan. PHP is quite popular among such developers.

So, may be the right platform is not "what you know most" but "what your objectives and constraints" allow, one of the contstraints being "what you know most".

» Read the full content

Posted by Pankaj Kumar on Friday, September 01, 2006 at 6:01:00 PM

Permalink | Trackbacks (0) | Comments (1)

» Integrating events with OpenView Operations

Most integrations with Openview Operations (OVO, in short) to monitor and manage the events involves feeding event data to OVO. As explained in Mark Secrist's excellent column on integrating JMX notifications to OVO, you have a number of options to do so: use of SNMP traps, through opcmsg command or C API, or using OpenView Interconnect (OVI). Each option has its own pros and cons and you must do a careful analysis in the context of your situation before running with a particular approach. Thankfully Mark's column presents advantages and disadvantages of each approach as well and makes your job easy.

This is not to say that you will find answers to all your questions (can any how-to guide ever make that promise?). A number of additional points became apparent to us while discussing the exact same topic with a customer who wanted to feed their JMX notifications to OVO and who had strict perforamnce requirements. I list them below:

Not all options are available to you in every situation. For example the opcmsg interface, either using the command line or C API, is available to only those programs that run on a "managed node" (ie; a machine that hosts OVO Agent), whereas OVI can be used by any network connected program.
There exists a Java version of the opcmsg API. This is implemented as a JNI wrapper around C API. In fact OVI uses this Java API.
Local agent reduces network traffic. Integration through opcmsg interface means that the message will be processed by the local OVO agent, possibly applying filtering rules and reducing network traffic.
All communication between OVO agent (HTTPS agents only) and OVO server can be secured using OVO mechanisms. Using OVI or SNMP traps to transport the notifications may require additional setup for security (assuming security is improtant to you in this context).

The additional insights based on the above points wilol come handy when you design you own integration with OVO.

» Read the full content

Posted by Pankaj Kumar on Monday, August 28, 2006 at 2:22:00 PM

Permalink | Trackbacks (0) | Comments (2)

» JavaScript: the MFSL (Most Favored Scripting Language) for Java

Lately there has been a lot of talk about scripting languages within two main development environments -- Java and .Net. This is a welcome thing, for scripting languages have their place in any development toolset and most enterprise products. However, what did concern me for some period was the over-abundance of choice -- groovy, jython, jruby, JavaScript (Rhino), BeanShell - among many others. Yes, too much of a good thing could be bad! How so? Because it can make it difficult for fence-sitters (those who aren't already a big supporter of any of these languages and believe me, the vast majority of Java programmers would fall in this category) to make any choice.

So I was delighted to find the Mozilla Rhino JavaScript engine within the JDK in the latest release (JDK 1.6 beta2). The presence of a JavaScript engine right in the JDK tilts the scale immensely in its favor and makes the choice a no-brainer for most of us.

There are other things giving momentum to JavaScript: a JavaScript interpreter is available on virtually every desktop in the world as part of the browser; the language is witnessing a vigorous uptake (thanks to Ajax) and it is not as crappy as made out to be by most language enthusiasts.

Personally I am beginning to prefer JavaScript over scripting options such as Perl, Python or even Ruby for small programs and utilities. It lets me use the familiar HTML and CSS for user interface for client side programs (those running within a browser, here is an example) and powerful Java libraries for server side programs (those running within Rhino). This reuse of knowledge counter-balances all the hoops I have to jump for writing OO JavaScript (those who have looked at prototype.js, a wonderfully written OO JavaScript library, will know what I am talking about).

Although documentation on JavaScript abundantly available on the Web, the same is not true for JavaScript and Java integration within Rhino and further, within JDK 1.6. SO, I thought I will include some references to help the curious get started.

References

Scripting Java: A brief but very useful writeup on using Java classes and objects within a JavaScript program or shell.
Java method overloading in JavaScript through LiveConnect: A little bit advanced stuff, but useful nonetheless.
Invoking JavaScript code within a Java program: A Java.net article on scripting in Java.
A. Sundararajan Weblog: He has a number of posts on JDK and Rhino integration, though finding the relevant posts could be a challenge. Here are the ones that I spotted: JavaScript debugging tips (for Mustang context), More Javascript debugging tips, Self, JavaScript and Rsadapter, Using Apache DB Derby from JavaScript, AJAX and Mustang, Using script shell plugin with console
JavaScript functions provided by JDK: These are not available in Rhino.

» Read the full content

Posted by Pankaj Kumar on Wednesday, August 16, 2006 at 7:47:00 PM

Permalink | Trackbacks (0) | Comments (0)

» What does an Integrated HP OpenView mean to you?

I was attending HP Software Forum last week at Miami and had a chance to directly hear various perspectives on what people thought would make an Integrated HP OpenView. This is of particular interest and importance to me as my main job is to work with partners and make sure that the same integration approach that we use internally is made available to partners for their integration as well.

Those of you who have tracked the OpenView product portfolio for any length of time would recognize that this portfolio is much more than NNM, OVO/U, OVO/W, OVPA, OVIS, OVTA, OVR, OVPM etc. and has grown to include products from various acquisitions/mergers such as Radia Configuration Manager, Select Identity, Select Access, Select Federation and Peregrine Service Center, Asset Center, Enterprise Discovery as well as organically evolved products such as OVBPI, OVD, OVAI, SOA-M and so on. The Wikipedia OpenView entry provides a brief (but good) overview.

Coming back to the main topic of the post, let me list down what I heard about expectations about an integrated HP OpenView:

There are too many products that individually need to be installed, configured and operated. I should be able to install OpenView from a single set of CD/DVDs in one go and use them as an integrated set.
OpenView products should be able to collaborate with each other to solve my problems without requiring so much configuration.
Web services based APIs are fine but they require the client to know or discover the provider. In some cases, it is more appropriate to have a publish/subscribe mode of interaction.
Web Services don't "gurantee" message delivery. What do you recommend to address that.
OpenView has the technology to "push" software on servers then why can't it use the same technology to "push" its the agent software.

And though I realize that creating such an integrated OpenView is an engineering challenge, the expectations seem quite reasonable!!

» Read the full content

Posted by Pankaj Kumar on Monday, June 26, 2006 at 5:42:00 PM

Permalink | Trackbacks (0) | Comments (1)

» More on ESBs ...

Came across this blog entry from Mark Little, project Lead for JBossESB (and a former colleague at HP during HP Middleware days), talking about JBoss's acquisition of Rosetta ESB. Therein lies the claim that ESBs are the development and deployment platforms for SOA in the industry. It also has a section that talks about Rosetta's capabilities:

Support for a variety of messaging services, including JBossMQ and MQSeries; a transformation engine to bridge data formats; a service registry; a persisted event repository to support governance of the ESB environment; a base transport mechanism; pluggable architecture; and a notification service to allow the ESB to register events and signal subscribers.

Notwithstanding the debate on compatibility between SOA and ESB, anyone who has spent time on integrating enterprise legacy applications would readily agree that these are useful capabilities for any non-trivial integration project. But at the same time, I can't help thinking that ESBs are more like duct-tape for the enterprise than the first class SOA infrastructure. This is not to say that ESBs not useful, or inferior to other infrstructural elements, but just that they promote a different style of integration than envisioned by SOA. In a true SOA interaction, the consumer locates the provider, makes a request, gets the response and a real world effect is produced. The provider need not concern how many consumers are what kind of consumers it serves. The producers and consumers can come and go independent of each other.

ESBs imply a different programming model by hosting artifacts that know about the two interacting end-points, such as transformation logic that transforms the output of one end point to the input of another end point or vice-versa. A change in either end point would require a change in this hosted artifact as well. This allows two incompatible end points to interact with each other without requring any of them to change. However, if a large no. of endpoints are getting connected in this way by hosting endpoint aware artifacts in a single ESB then things could get complicated and somewhat rigid.

» Read the full content

Posted by Pankaj Kumar on Thursday, June 15, 2006 at 7:03:00 PM

Permalink | Trackbacks (0) | Comments (0)

» What exactly is an Enterprise Service Bus (ESB)?

I started hearing about ESBs about a year ago in context of Web Services and SOA and everytime wondered what it might be. Is it something that was always there and somehow I just managed to miss it? Apparently not. Recently introduced Google Trends confirms that the term Enterprise Service Bus is fairly new, gained mindshare rather quickly in the middle of 2005 and is now on decline.

So last week I decided to get rid of this ignorance by googling, reading, playing around, listening and just plain talking to folks in the know. What I learnt was quite illuminating. Here are the main points (in no particular order):

According to Dan Foody, CTO of Actional (recently acquired by Progress Software, parent of Sonic Software), SOA and ESB are two different solutions to the problem of enterprise integration.
Microsoft doesn't see ESB as a separate product category but a bundle of capabilities that are or will be available in its WCF and BizTalk Server.
David Chappell, a VP of Sonic Software and Author of the ESB Book, responds to cliamns against ESBs in a SOAWebServices Journal article.
Anne Thomas Manes of Burton Group has following to say in her report Enterprise Service Bus: EAI in Transition -- Enterprise service bus (ESB) refers to a segment of the integration software market that addresses the intersection of message-oriented middleware (MOM) and web services. ESB products provide seamless interoperability with established relaible-messaging MOM protocols such as IBM WebSphere MQ, TIBCO Rendezvous, and SOnic SOftware SonicMQ. Meanwhile, the superplatform vendors and other web services platform vendors are adding ESB functionality to their systems based on inter-operable WS-Reliable Messaging specification.
As per my experiements with ServiceMix and Celtix, two opensource ESBs, they appear to some sort of software that allow creation of WS end-points (platform capability), access to JMS destinations and transformation and routing of messages.

I don't think I really answered the question posed in the title of this entry, but hopefully got more knowledgeable about it.

» Read the full content

Posted by Pankaj Kumar on Friday, May 12, 2006 at 7:32:00 PM

Permalink | Trackbacks (0) | Comments (0)

» From statically typed languages to scripting languages

Scripting or dynamically typed languages that avoid the compile step from the normal development cycle of write --> compile --> execute have gained a lot of traction recently. More and more people have found good reasons to embrace scripting languages for serious programming. I am no exception. In fact, my expereince may be a very typical one.

I started programming with Lisp during my sophomore year, learnt Pascal as part of a course, moved on to C and did most of the course work and early programming during 1987 to 1997 in C/C++. Like most people, the transition from C to C++ was gradual and perhaps never complete. Don’t recall ever using C++ templates and STL. By the time these became widely supported by compilers, I had moved on to Java — a language that has stayed with me since then.

I did learn and played around with few sceipting languages during this time. Most notables are Perl, Python, PHP, JavaScript, BeanShell and Ruby. These have been out of necessity, meaning I was working on a project or playing with a product that mandated their use than any particular reason at one time or other.

Among all these, I am most excited about JavaScript and Ruby. JavaScript is in a unique position in the sense that it has no competition for writing DHTML and AJAX based browser apps. Also, now that J2SE 1.6 (Mustang) is packaging Mozilla Rhino (a JavaScript implementation for JVM), it is bound to gain in popularity. I have used it for some of my personal projects and have liked it for its early support of E4X — EcmaScript for XML.

Similarly, Ruby enjoys a unique position for creating DB backed webapps, mostly because of Ruby on Rails. As a language, Ruby has the same strenghts as Perl minus all its baggage and syntax idiosyncracies plus the excellent object orientation. As a programming environment, it has all other essential pieces. eRuby is very similar to PHP in terms capability and the DB integration with ActiveRecords is just phenomenal. XML support through REXML is somewhat similar to E4X and much more simpler than whatever you may find in the Java land.