A microservice, I’ve been told more than once, is a small service. In a few of those instances, the response was phrased to make me feel stupid for having asked. What makes a service a legitimate microservice, others have said, is its extensive usability across job functions, its scalability to any conceivable bounds, and its agnostic approach to APIs.
Then there is the Adrian Cockcroft definition — Cockcroft, of course, being recognized more and more as one of the fathers of microservices. He’s far more specific, adding the concept of ephemerality — the notion that a microservice may fail or be otherwise removed from the mix, without degrading the integrity of the application. He adds the ideals of agnosticism, in nearly all possible regards: to language, to the tooling used to create it, to monitoring tools. He suggests that microservices are pointless unless they can be easily discovered by other services, and easily observed by outside sources.
So there is some question as to whether a company called Pneuron, based in Boston, is offering a platform for what may be generally accepted as microservices. It is a kind of PaaS platform for hosting small, scalable services. But unlike every other PaaS, Pneuron hosts its own services, opening them up for use by applications, including those which clients are hosting on-premises.
Pneuron (originally founded as Pneural) calls this concept “microservices in a box.” But the company pre-empts any complaints it may receive claiming these aren’t really microservices, by publishing a white paper that distinguishes what it calls “classic microservices” (already the concept is old enough to have a “classic” form) and its own alternative.
“While staying true to many of the ‘classic’ microservices tenants, Pneuron went significantly further,” writes Tom Fountain, Pneuron’s CTO, in the white paper. “We foresaw that adoption of the techniques now called microservices would require extensive investment in new technologies, re-training of staff, and wholesale changes in management processes.”
“I was a CIO for over a dozen years, trying to reconcile what I had with what I wanted to have, or what the world was pursuing,” Fountain told The New Stack in an interview.
“It was a constant struggle to figure out, how do I continue to migrate the architecture in the direction of new technology, while still preserving that tested and proven logic, and protections and so forth, that I had in my installed base?”
Fountain contends that this question will never go away. While some of us may have dreams of building an extraordinarily scalable platform like the Netflix platform Cockcroft helped build, most organizations are struggling with integrating new technology into the services they have and that will not be replaced. He suggests that use cases such as Netflix will only pertain to companies young enough not to have an existing technology investment that has yet to fully amortize.
“The founders of the company were businesspeople, and they were frustrated by the time, costs, and complexity of solving a particular class of problems, where the elements of the solution — whether it be data, applications, files, web services, web sites — were very distributed, and in very disparate technologies,” said Fountain. “The whole premise of Pneuron, from the ground up, is to exist in that environment, and enable individual solution developers to be able to basically create a solution that would non-invasively interact with whatever is in your environment, or that you can connect to outside of your environment.”
Not So Neural
Fountain’s characterization of Pneuron’s founders as businesspeople may conjure images of commercial and institutional settings. While that wouldn’t be entirely inaccurate, one of those businesspeople is a one-time director of development for Lotus 1-2-3. In the intervening years, Dr. Chris McGrath found himself attempting to apply his knowledge of prescriptive neural networking to a systems integration project for an institution said to be plagued with old technology: the National Security Agency.
Dr. McGrath, said Fountain, “had this concept of these small, focused, mini-applications — call them ‘services’ — that are individually configurable, but interoperable with all others. We call these ‘pneurons.’ These services will accomplish a specific step of your value-added business process, and produce results. And that’s all they do.”
Back in 2010, during the company’s startup phase under its former name, McGrath gave a description of this technology to the Nashua “Telegraph” that sounded a lot more like the skill sets on his resume. “The software uses artificial neurons to break down the barriers between a company’s computer applications,” the newspaper wrote. “It mimics real neurons by temporarily integrating a company’s computer applications to bring together information that is useful to the business without moving or alternating the data.”
Tom Fountain’s later description of Pneuron’s platform loses the comparison to neural networks. (When I gave Fountain more than one opportunity to describe the connections between pneuron containers on the platform as “axons,” he steadfastly refused.)
“A pneuron is a configurable mini-Java application,” Fountain describes to us. “A cortex, which is a container, provides the execution context for that pneuron. At design time … with a simple drop-down, you can assign which pneuron will run on which cortex. Right out of the gate, you have the ability to distribute the processing by putting this cortex in various jurisdictions, various locations, on particular machines, etc. We can run happily inside of a VM, just like any other Java application. And with two clicks, you can reposition any of them to run on any of those installed cortices, because we manage a configuration database that says how these neurons are configured, which ones are connected to which, and how all those cortices are placed.”
The network of pneurons is now being described as a fabric, although occasionally the term “neural network” still pops up. Fountain tells us that it is this fabric that is scalable, so the applications constructed from this fabric are thus also scalable. The company’s basic library is comprised of about 55 types of pneurons. Many of these types are essentially bare database queries. At design time, pneurons are given wrappers that provide the specifics of their functions — for instance, the criteria for their queries.
The arrangement of pneurons within a cortex is for high availability and scheduling purposes, enabling individual pneurons to be phased out, or to be replaced in case of failure. Custom Java apps can be added to the net by wrapping their JAR files in an executable that the rest of the fabric treats as though it were another pneuron.
“Pneuron A doesn’t know or care what pneuron B or C or D does, or where it is,” says Fountain, “because the only thing that’s passing between the two is a self-describing XML message that carries the results from A to B. So you can go from a query pneuron to an analytics pneuron to a JMS Publish pneuron, and none of those gives a hoot about what came before or what comes after. It just totally focuses on doing the query, or separately the analytics, or separately the JMS Publish operation.”
Fountain describes the XML messages as key/value pairs that are easily decipherable by human eyes. They are not, however, RESTful API calls or responses.
The wiring of pneurons to one another is done graphically, using a tool Pneuron calls Design Studio. Once a pneuron has been programmed to execute a query that retrieves multiple fields (represented on-screen by tags), that creates a kind of output pattern (Fountain avoids using the term “interface”). That pattern is then used to wire the connections between pneurons that share the same data. That wiring, in turn, helps the platform to determine a network routing pattern for locating pneurons within the fabric.
It’s not a completely scalable system. But Fountain draws a landscape of sorts containing a fabric that can be deployed on cloud platforms (Pneuron’s partner of choice is HP Helion) and that can be scalable even when the underlying systems upon which they rely, are not.
From Neural Net to Ecosystem
Pneuron pitches this system as “microservices for the rest of us” — for organizations whose pre-existing scale, ironically, may prevent them from being able to scale their new applications up.
“There’s a good, healthy debate going on about classic microservices versus the expectations of more reuse, and so forth,” Pneuron’s CTO acknowledges, “and building services that can be used in multiple places. We’re definitely more of the latter. I know, in some cases, people talk of microservices as a component of a single application, and that’s all they do. But with our capability to permission the use, creation, or edits of these services, or of networks as a whole, we want to provide the opportunity for an enterprise to build some proven, tested logic, and then have it be reused or built upon by others.
“So we’re not really a pure, classic microservice, vertical-only mindset,” continues Fountain. “We try to maintain that degree of horizontal, so that you can get the broader reusability.”
Fountain suggests that reusability is not really all that good unless it can be applied beyond one client’s own borders. One possibility he genuinely foresees (though nothing has been firmly decided yet) is a kind of “pneuron marketplace” — a kind of repository where organizations publish the microservices their developers build, for use on the Pneuron platform. But instead of a free-and-open-source utopia, Fountain suggests that pneurons can be rented, perhaps on a per-transaction basis, enabling developers to recoup some of their costs by collecting per-use fees from other platform subscribers.
And since pneurons are loosely coupled — as microservices are, after all, supposed to be — renters would not have to manage their outside tenants directly.
“Rather than use just four or five pneurons to build something,” says Fountain, “they may be able to go to a marketplace and buy or rent or pay-per-use for a new pneuron type which may give you better performance, more optimal processing, all in a single pneuron.”
Metaphors are the trickiest components to manage in all of computing. They inevitably come to represent ideals, but those ideals inspire a handful of philosophies, and each of those philosophies inspires a truckload of methodologies. What’s more, when two ideals compete for the same metaphor (as may have been the case once before in the history of a company once called Pneural), one player finds itself shopping for a new one.
It may yet be decided that Pneuron’s model does not qualify as “true microservices” as articulated by some lofty ideal. (I seem to recall an argument about Microsoft Windows not “truly multitasking,” made by a brash, young fellow in “Computer Shopper” some 28 years ago. He had somewhat more hair back then.) But as OpenShift is proving for Red Hat, a good idea can drop its old metaphors and still keep its customers. We may end up calling Pneuron something else, but that doesn’t mean the ideal won’t sell.
HP and Red Hat are sponsors of The New Stack.