In developing a small concept of producing a DevOps server for the environment of a single Small Office/Home Office (SOHO) network, in the past couple of days I've reviewing a concept of installing Gitblit, JSPWiki, Roller, and Activiti, as web services, then to develop a minimalist web-based portal front-end for integrating those individual web service components into a single "User experience". These components would be installed, originally, to one of my old laptops, it serving a dual-purpose role as an old laptop retained of my own purchase -- now a manner of a sentimental artifact, sure -- presently applied as a FreeBSD server on a SOHO Local Area Network (LAN).
The local web-type services, of course, would not be the only features of the same server's Service mix, as it would also publish a Git service from within a FreeBSD sandbox. The Git service, of course, could be published from a sandbox maintained in a manner separate from the host's web server sandbox -- that, as with a small amount of software to provide a filesystem bridge, between the two -- both sandboxes operating on the same computing machine, however, with both being procedural isolated from the "Sandbox controller" server. Even in so much as a design for such application of the FreeBSD sandbox, i.e jails framework, it might already represent a manner of a component-oriented software service design, though it is not yet in every ways a detailed software service design.
I've favored this design, due to its minimalist nature and its development singularly in the Java programming language. I'd begun the design, after reading a comment -- from 2012 -- by James Gosling, a positive comment about Gitblit [Gosling2012PapaMau] Of course, a positive comment by one of the original developers of the Java programming language may seem to carry for some mileage.
In my own small software design work, proceeding from a review of the Gitblit web services component, I'd even developed a clever name for the design, a DevOps portal design for my own LAN, but such that should be scaleable beyond the "Single use" -- naming the design, "Glister," after an artifact of the Heritage Universe, a series of science fiction books written by a physicist, Charles Sheffield. In a context of the story of the Heritage Universe books, Glister is an Artifact that appears early in the story. In a context of a SOHO network, Glister has been -- thus far -- simply an easy-to-remember name for a single service design. As I've developed a substantial amount of writing about the design, in my Evernote notebooks, it is not a design I would want to abandon hastily.
The design of the Glister DevOps server, in some ways, it mirrors the design of the EmForge Portal. In a manner, both designs would introduce a Business Process Management (BPM) component to the conventional service mix of a wiki, web log, issue tracking, and web-based source code review service -- as also seen, with some slight differences, in Edgewall's Trac, different at least in regards to the implementation of each service of the respective service mix. Of course, Trac favors the Subversion change management service, as does EmForge -- whereas Glister would apply Git, with a Gitblit web interface providing a light-weight localized service for immediate web-based source code review.
Of course, the issue tracking feature might not seem as apparent as the novel "Other features" of the architecture.
In the Glister portal, Activiti would provide a BPM management interface. Thus, it may seem to effectively mirror the the BPM component of EmForge.
Considering that the "Issue tracking" features of the Glister architecture may seem -- in ways -- very much obscured of the novelty of some of the other components of the architecture, perhaps the "Issue tracking" service could not be the main "Selling point", if it would be presented as all of a "Free beer" model.* Regardless, I've estimated that it may be relatively easy to develop an issue-tracking front-end for Activiti -- whether to emulate Bugzilla, Request Tracker, GNATS, or any other normative issue tracking service -- such that would be developed, originally, for issue tracking about individual Ports, such as available on the FreeBSD operating system and such as would be installed to an individual SOHO network.
Though I am not inclined to present it as if it was any manner of a "Zero-Sum Free Beer Return" process -- and well would such a process be a novelty, in itself, of all the spontaneous things -- I suppose that I could try to market it is as so, whatever I may eventually be able to develop of the Glister server baseline. Not as if to exploit "Free Beer," it is already a small effort at making use of a small number of existing software components, in developing a manner of an immediately "New" component -- so far, as to develop a "New", and in-some-ways "Unique" service design, then as to proceed towards an effort in producing and maintaining that design in its implementation, there in regards to some terms of real software integration, and documentation, and software distribution, and issue tracking. Maybe it would not seem immediately "Fun," in such a perspective.
I notice, presently, that the Jenkins server -- such that I may wish to denote as it being an alternative to an independent design of a DevOps server, such as Glister proposes to implement, and such as is implemented of EmForge -- that the Jenkins server has recently found an application in the FreeBSD project. If it is a project trusted by the FreeBSD project, and if it may serve a role in mitigating my own development burden, and as I may happen to personally trust the OS distributed by the FreeBSD project, in a far ways, thus I've begun to consider applying Jenkins, albeit then to an effect of by-in-large abandoning the Glister service design.
Though the Glister service design, in its exact and present composition, has not existed for any long period of time -- this specific design has been in development for all of a couple of days, now -- I'd thought it might serve as a manner of a "Go-getter" project, though, as well as a nice minimalist design for a convenient web service on a local area network (LAN). The note about Gitblit, I'd thought, it had seemed to convey so much of the original goodwill that was ever demonstrated of the Java developer community, at least as in the duration up to which the Sun Microsystems company -- the original "Shop" in developing Java -- was acquired by Oracle.
Whereas the latter corporate institution, Oracle, may -- in some manners of a metaphor onto science fiction -- that the Oracle company might seem to resemble an archetype much like the character of CLU in the TRON: Legacy universe, and though perhaps I'm the only person seeing it as so, but in no ambiguous terms: I miss the goodwill of the original Java developer community. That a programming language such as was originally developed to an effect of a web browser plug-in -- with regards to so much as the Java applet origins of the Java programming language -- that a single programming language, as such, has weathered all the tides of Enterprise trends and gone so far as to find an application in an embedded/mechatronic architecture presently continuing an expedition to Mars? Who could have expected such an outcome of a Java applet programming language?
In any linear, even post hoc analysis, how could such a thing have become? and what has been lost of the goodwill of the original Sun Microsystems developer community, in the years since the acquisition by Oracle? Moreover, how much of the original brainpower of Sun, in effect, had "Jumped off the ship" once the Oracle acquisition was finalized? and today, does Oracle still try to discredit the nature of free/open source software engineering, but that may be where they could find any of the staff that left Oracle? Have we not learned anything of this process, as yet?
Towards considering how the Glister service design might scale beyond a context of an individual LAN, it may be -- in that context -- that I might wish to entrust the Jenkins web services as for those web services to not only present a novel web-facing interface, but also ... but no, it may be simply the novelty of its web-facing interface that would draw my own attention more to Jenkins, as any alternative to the minimalistic design of the Glister service mix.
Candidly, I am a little worried about installing Jenkins on my own SOHO LAN, as -- even with its full free/open source codebase -- I do not know if it is such a kitchen sink I may actually need to install. Not to discredit its component-oriented design, though I am in any ways nonplussed by its marketing. I do not know if a Jenkins instance would actually "Do much" on my LAN, except if it may represent something of a novelty -- and yet, would the Glister design be any less so? If it may be any less of a novelty, and if it may be any more of a producible gain -- to my own manners of personal perspective -- but even if it may need "A lot more welding," as to "Put the thing together," for the "Thing" being a "DIY" component-oriented design of a lightweight DevOps server, maybe it's not too far past the sunset of Sun.
Personally, I think that a design strategy of "Everything and the kitchen sink" would not be ideal for a design of a light-duty/low-usage software service for an independent network services environment. Thus, personally, I've begun to "shy away from" so many Java Enterprise Kitchen Sink Portal architectures and the kitchen sink style of DevOps services, likewise, in considering any "Forward" designs for network services and -- in that context -- also web services.
I wouldn't want to seem too hasty in abandoning the concept of applying Jenkins, immediately. No sales lost of it, I would prefer to resume the Glister service design, and to keep my design table "Lightweight."
* The phrase resounds, even of free/open source software component systems: Caveat Emptor
No comments:
Post a Comment