There’s nothing simple about defining middleware to begin with, but that process gets far more complex when the goal is to paint a broad picture of trends around such a nebulous set of tools. Despite the enormity of the task, HPC analyst group, Intersect360 Research, tied together a wealth of findings around a comprehensive definition of middleware, bringing to light the diversity of the segment, as well as where the momentum tends to lie.
According to Intersect360’s Dr. Chris Willard, capturing what classifies as middleware comes with the inherent risk (and need for) overlap–not to mention room for debate. Generally speaking, however, the software category can be parted across two clean lines. On the one hand, there are the wide range of packages that address specific computational problems (structural analysis, CFD, computational chemistry, and so forth). At the other end is another, far broader array of packages that are very loosely defined as anything the end user deals with directly that is not part of the operating system—software that extends the OS like schedulers, for instance. Again, a lot of room for debate in terms of what fits, but as Willard told us, his group let the respondents classify their own sense of middleware status, simply by focusing on functions versus definitions.
Added to the extensions of the operating system and the specific applications is another part of Intersect360s encompassing definition, which are the many elements of programming environments. This can include compilers, parallel programming tools, optimization and testing capabilities, and even some elements that can count in multiple middleware camps like MATLAB, depending on the end use.
Overall, when looking at the table below, the companies and packages and named span the entirety of Intersect360s holistic approach to what is defined as middleware—from programming environments, schedulers, applications, and other tooling:
Couple the above findings with a few other key takeaways from the Intersect360 report, including the results that turned up over 300 unique supplier packages as primary middleware that might have been in the running for the list above. To make that more interesting, consider that over half of these vendor packages were only mentioned once in the series of questions.
What’s also worth noting is that these findings clearly go beyond the workload management and scheduling side of the house. Programming environments and compliers were the two main categories for middleware packages.
And speaking of diversity, as you can see in the chart above (and as Intersect360 has spelled out), while there are some clear leaders, the combined share for those at the very top of that list still only account for a mere 13.5% of the overall middleware market.
This massive amount of diversity in middleware, in both the general sense and in the sub-categories, is fed by a couple of long-standing trends, says Willard. First, the barriers of entry to the market are quite low. For some developers, their code emerges by filling in gaps in existing tooling and either open sourcing or commercializing it. On the open source front, a great deal has been pushed by those who want to get around the limitations of proprietary packages, thus work together for more collective, shared solutions. Further, this diversity reflects a much larger trend—the growth in complexity of systems and the constellation of tooling required.
In terms of open source versus more locked-down proprietary packages, keep in mind that out of all the responses across the middleware spectrum, only a small 5% slice of users were using commercial middleware. Open source was the leader here with 42% share.
“Computer science isn’t defined by physical laws,” described Willard as we commiserated on the challenge of defining this category and piecing together survey information that split across multiple middleware segments (as in the MATLAB example). “You write a program and it can do whatever you want it to…that’s the challenge. We are imposing segmentations and definitions on a set of concepts and abstract ideas for which there are no hard and fast rules for what they are.” A great deal of the research that went into analyzing responses, he said is that they had to deal “with what people have versus what they think they’re using…as long as it works and they can tell someone what it does, they’re happy but we can’t make everyone talk the way we’d like them to about it for market research purposes.”
All of this is to say that while it may be easy to take issue with some of the category splitting, Intersect360 has provided some deep insight into what users are choosing across the board, how they’re using these packages, and what the broader adoption momentum seems to be between commercial companies and open source approaches. As implied earlier, if there’s one takeaway, it’s that for every need there are five different options available. This has created a very diverse ecosystem in all of the middleware segments Willard and team set forth.
As Intesect360 concluded in their full report, “For middleware, diversity of offerings will continue to be the name of the game, driven primarily by the focus of academic research on middleware programming. With many of these research endeavors ending up as products delivered via open source, there is continual pressure on commercial suppliers to add value. Today our research indicates commercial sites still value ISV-supported products as the majority of mentions were for commercial products in almost every segment. Product quality and support are maintaining their value.”