Non-Blocking JavaScript Engines: Vert.X and Node.JS
Abstract:
Network Management is based upon stateless protocols such as SNMP and ICMP. Network Management for Managed Service Providers really requires a asynchronous, non-blocking polling framework to scale to tens of thousands of managed devices. Client-side consoles are more often being built in asynchronous JavaScript. To build next-generation Network Management tools, some languages provide more fertile soil than others. JavaScript, being an event-driven language may be a future of network management, from a client and server perspective.
Node.JS
Node.JS is a server-side JavaScript implementation, based upon the Google V8 JavaScript web client engine. This comes with good and bad points. With Google V8 being primarily a client-side tool, cross-platform server support is extremely limited. Cross-platform POSIX support for SPARC is not-existent, with little community interest for [non Google V8] multi-platform support.
There was some movement, from Mozilla, to place a shim between NodeJS V8 API's and the Mozilla based SpiderMonkey, to bring cross-platform capability to NodeJS. A few in the NodeJS community took exception, to the Mozilla team's interest in bridging the NodeJS gap to Multi-Platform and Service Provider Grade software.
With a recent movement to support Windows, there is movement of NodeJS from an interesting development framework to the traditional desktop environment. This NodeJS upgrade had broken code shims built by Mozilla to bridge NodeJS to traditional Managed Services market, but the SpiderNode team seems interested in trying to get another working build.
Vert.X is a server-side non-blocking framework, based upon the Java Runtime. With the maturity of Oracle Java, in comparison to Google V8, this means the potential for better platforms support. More languages are supported, out-of-the-box, besides JavaScript. Managed Service Providers have a much greater opportunity for use & reuse of code developed in this environment.
A NodeJS compatibility layer seems to be getting built upon Vert.X, but now there would be a new compatibility shim which would need to be maintained, to bring NodeJS to alternate platforms.
Vert.X is officially supported under various platforms and was suggested to run under SPARC Solaris, even though the web site does not explicitly indicate it will. This is a more advantageous than the NodeJS framework, which would require a third-party compatibility shim.
[Simple HTTP benchmark provided by Vert.X article]
Scalability
Knowing that NodeJS was built upon Google V8 may bring questions into one's mind whether or not the platform could scale as well as would be need on the server side. Knowing Vert.X is based upon Java may bring questions to one's mind whether it might perform poorly, since Java has an outstanding record for compatibility and scalability, but not necessarily for speed.
Some simple vendor tests seem to indicate that Vert.X may perform better and the ability to push blocking Vert.X workloads across thread pools might prove interesting for systems offering massive thread count of relatively slow individual thread performance (a typical workload profile for network management application.)
With Service Providers able to deploy servers with dozens of sockets and thousands of hardware threads - Vert.X may be a better end solution for network management, considering that Oracle is constantly pushing performance improvements of Java to ever higher numbers of parallel threads... if Vert.X decides to support it.
Both platforms do not seem to support asynchronous SNMP or ICMP libraries - critical to Internet Management. Additional protocol support such as FTP, SFTP, TFTP, Telnet, HTTP, HTTPS, and SSH (with Expect like qualities) would be desirable.
Vert.X seems closer to supporting SPARC and Crypto Engines, because the underlying infrastructure is Oracle Java Engine vs. Google V8 JavaScript Engine. Vert.X may be closer to filling-the-gaps, but the industry will have to see which JavaScript capable platform will come to maturity first.
Caveats
One might wonder whether the legal wranglings between Oracle and Google or the former Oracle employees who make up the NodeJS management might have something to do with lack of SPARC support - but community members seem to indicate this is not the case.
Vert.X seems to be a VMWare initiative. VMWare is owned by EMC. EMC and VMWare do not seem terribly interested in supporting Oracle SPARC. Xen, underlying Oracle VM for Intel, and LDoms underlying Oracle VM for SPARC, are both competing technologies with VMWare. Oracle also has a competing storage solution, so one might wonder whether this will impact the decision to support SPARC Solaris used by Service Providers.
These are not the 90's - where Open Systems reigned, and everyone developed to POSIX standards. This is a vastly more proprietary world, where toolkits advertize "openness" but are more proprietary since they do not develop to any objective standards on the host platform. We may never see true cross-platform kits from either of these platforms - even though JavaScript is a standard interpreted language. How ironic.
No comments:
Post a Comment