OpenCore 6.0 - Software Resource Metering & Metric Monitoring


News: OpenCore 6.0 - Software Resource Metering & Metric Monitoring

  1. After 16 months of design, development, testing and significant performance benchmarking we are pleased to announce the official release of OpenCore 6.0.

    OpenCore is the most scalable application performance management runtime on the market today with the lowest runtime overhead thats thousands of times more efficient than all other well known solutions tested.

    Low Latency
    OpenCore is the only measurement runtime on the market that has been found to be a viable solution for comprehensive monitoring of extreme low latency environments such as banking & trading platforms.

    New Approach
    OpenCore is the most versatile, extensible, and ambitious software resource metering and metric monitoring runtime ever designed. It truly is a next generation solution offering an entirely new approach to performance management built upon an activity based costing & metering runtime complimented with a fast and scalable metric collection runtime.

    More Information:

    Threaded Messages (6)

  2. Openness[ Go to top ]

    In what sense do you feel the product is Open?

    Or are you just trying to capitalise on people's fondness for all things "open"?

    I had a hard time finding any license details on the site.  Only when I downloaded the beta, did I find a JInspired license, which seemed like a restrictive product license, with requirements for performing audits, conditions of payments, references to purpose of use, etc.

  3. Maybe I am showing my age here but Open has never been about access to source code (which from my experience is rarely open in terms of accessibility & extensibility) or for that matter FREE which is how it is equated today by most newer comers.

    For software to be Open means (in the classical sense) it has been explicitly designed to be extended & reused in different contexts and environments via integration (extensions) and plugins. It can also mean it offers the ability to have multiple implementations which again is supported today by OpenCore via service provider plugin points. Whilst it is pretty easy to make software open sourced you will find it is an incredibly hard task to make it Open.

    During the summer I spent 6 weeks in the valley trying to get backing from major players around a standardization of OpenCore with the current API elements (not package naming) serving as the basis for such a standard that would go beyond Java itself. I have also met up with various cloud computing vendors trying to get greater awareness of the need for cost information to be exchanged at service entry points which we refer to metering points. Questions and answers regarding license are brought up in the tech talk I gave at Google HQ during this time. Note that licensing is not just about free in terms of financial liability. You won't believe how hard this actually is especially as many are less open than what is projected in the media and community. I would like to see our metering (Probes) & Metrics API's make it into all runtimes including Java which is why I have discussed our technology with all major JVM vendors. Hopefully they will do the right thing and move on this before other platforms do.

    OpenCore is open (accessible) in many ways including the wealth of information we have published on its data formats and API usage - all public without any community login. I doubt you will find as much information in any comparable open source project.

    Parts of the license that ships with the distribution relate to a commercial licensing of OpenCore or its derivative products - JXInsight and Metrica.

    Both the metering & metrics runtimes will measure & collect information for up to 30-45 mins which should be suffice for most developer needs. I rarely find anyone will to wait longer for the results of a benchmark unless its in a test or pre-production environment.

    The goal here is for OpenCore's API (or its standardized version) to be implemented in part by platforms and runtimes or other third parties, to be extended by runtimes in terms of registration of meters, to be used solely by management agents and tools for metering & metric collection, to be used by customers to demarcate activities (probes) and possibly register higher level business metrics and meters (kpi's). I think if we could end the constant re-invent a new stop watch class or straw man performance management solution we would have increased the productivity of many teams around the world.

    I am not interesting in taking what is today and making that the defacto standard just because we made it free for someone like yourself. The goal here is to increase awareness of our vision, CARS (cost/consumption aware runtimes & services), and to possibly refine it with contribution from customers, management vendors and platform vendors. I personally would like to see the whole execution stack all the way down to the networking layer being metered enabled with each layer defining standard activities (probes), meters (execution context consumption counters) and metrics (typically derived from metering).

    I believe in innovation & competition which is why OpenCore is versatile, extensible, highly configurable, and carefully designs in terms of interface contracts to support diverse implementations underneath.

  4. Interface versus Implementation[ Go to top ]

    I wanted to add that your confusing around the license stems for our inclusion of both the Open API interfaces and actual implementations in the same downloadable distribution.

    The packages com.jinspired.jxinsight.metrics and com.jinspired.jxinsight.probes are the interfaces which we intend to license to runtime/tooling vendors or a standards working group. The packages com.jinspired.jxinsight.server.metrics and com.jinspired.jxinsight.server.probes are our actual commercial implementation of the Open API and eventual standard. This is software that has been designed from the very start to be Open with very clean (and flexible) separation between interface and implementation. You will also see this in how our default implementation is configured with numerous system properties specifying particular behaviors not in anyway expose or betrayed in the Open API interfaces.

    Again Open (in terms of design) is much much harder than most people will ever imagine. You have to start at some future point you can just about make out and then work backwards whilst ensuring decisions at each step ensure you will still be able to move forwards at a later point.

    I like to think I am bring Open back to what it original stood for before people started innovating in terms of business models.

  5. CARS - Comment[ Go to top ]

    I recently posted a blog entry on "Cost (Consumption) Aware Runtimes and Services" that discusses the huge potential metering has to offer by better enabling software to prioritize, predict, provision, protect, problem diagnose and govern resource consumption – in real time.

    I also posted a lengthy response to a comment on licensing which references an effort that is ongoing at this moment to publish the Open API interfaces & 2 bootstrap classes under an open license.

    Our particular implementation will be available under a commercial license along with a free development edition usage license as is the case today.

    Other companies (open source or commercial) will be able to offer service provider implementations of OpenCore's measurement runtimes ensuring ongoing innovation (under the hood) and competition.

  6. Open ? - of course not.[ Go to top ]

    <<Maybe I am showing my age here but Open has never been about access to source code ...>>

    No, you're not "showing your age" by writing that nonsense.  You are simply being dishonest. 

    Feh.  Too many salemen in the world.

  7. Openness[ Go to top ]

    Thanks Ethan for taking time out to make your very first message posting on TSS. We must be doing something right and have something of great value to elicit action. I am going to assume your response is genuine though I have no basis for such. I would appreciate it if you would offer the same respect (leaving aside your ignorance of my long standing work & experience in this industry as an engineer) especially as you have not being present at any of the TECHNICAL discussions we have had with JVM vendors starting with IBM in early 2008 around a standardization of our metering invention.