Sunday, January 10, 2010
Tuesday, December 01, 2009
“Making Modularity Manageable™”.
Or should that be "OSGi Mmm...." ;)
I am very pleased to announce the release of Paremus Nimble today. Nimble combines a feature rich OSGi shell with the industries most powerful dependency resolver. The Nimble release is not only a software release, but a landmark in our ongoing mission to making adaptive OSGi based systems simpler to develop and manage than the legacy they replace.
The most productive way to manage and interact with OSGi Frameworks that's currently available, you may download and use Nimble for free on a 30 day renewable license.
So whether you're new to OSGi, an experienced OSGi developer, or an administrator charged with deploying and managing sophisticated OSGi based composite applications, we suspect you'll find Paremus Nimble invaluable.
Given that you've read this far, you may also be interest in a couple of posts from the Paremus team including:
'55k download and 85 chars to run spring simple web app' & 'osgi file install nimble style'
Its also been well received in the twittersphere including comments such as
“very impressive http://bit.ly/7lzv3w Nimble by paremus #osgi #in” by @yanpujante.
Thanks Yan!
Please feel free to feedback experiences and comments to the Nimble Blog, or tweet us @paremus.
Merry Xmas (almost)
Richard.
Thursday, October 22, 2009
Complexity over time?
As an ex-Physicists, I'm naturally interested in concepts such as 'Complexity', 'Information' and 'Entropy'; and while I agree with Hal's sentiments, I feel uneasy when the 'complexity' word is used within such broad brush general arguments. Indeed; I find myself asking, in what way is a modular system 'simpler'? Surely a modular system exposes previously hidden internal structure, and while this is 'necessary complexity' (i.e information describing the dependencies in the composite system), the system is never-the-less visibly more complex!
For those interested, the following discussion between physicists at a Perimeter Institute seminar concerning 'information' is amusing, illuminating and demonstrates just how difficult such concepts can be.
- Structural knowledge is lost as key developers and architects leave the organisation.
- Documentation missing and / or inadequate.
- The inability to effectively re-factor the system in response to changing business requirements.
- The components used within the System are known
- The dependencies between these components are known
- The impact of changing a component is understood
- Explicit management of all components: Dependency resolution is 'frozen in' at development time. All required bundles, or a list of required bundles, are deployed to each runtime node in the target runtime environment; i.e. operations are fully exposed to the structural dependencies / complexities of the application
- Use of an opaque deployment artifact: Dependency resolution is again 'frozen in' at development time. Here the application is 'assembled' at development time and released as a static opaque blob into the production environment. Operations interact with this release artifact, much like today's legacy applications. While the dependencies are masked, as the unit of deployment is the whole application, this decreases flexibility, and if one considers the 'Re-use Release Equivalence Principle' partly negates OSGi's value proposition with respect to code re-use.
- The runtime environment - a 'Service Fabric' - is model driven. Operations release and interact with a running Service via its model representation; this an SCA description of the System. Amongst other advantages, this shields the operations staff from unnecessary structural information.
- The Service Fabric dynamically assembles each System resolving all modules AND context dependencies.
- Resolution policies may be used to control various aspects of the dynamic resolution process for each System; this providing a higher level policy based hook into runtime dependency management.
- The release artifacts are OSGi bundles and SCA System descriptions - conforming with the 're-use / release equivalence principle'.
- The inter-relationship between all OSGi bundles and all Systems with the Service Fabric may be easily deduced.
The short answer really is - "it depends on how you use it"!
Without a doubt, many will naively engage with OSGi, and will unwittingly increase operational management complexity beyond any benefits achieved by application modularization; see 'OSGi here, there and everywhere'. However, for those that implement solutions that maximize flexibility and code-reuse, while minimizing management, OSGi's value proposition is substantial; and the runtime used is a critical factor in realising these benefits.
How Substantial?
To date my only benchmark is provided by an informal analysis made by a group of architects at a tier 1 Investment Bank in 2008. They estimated the potential OPEX cost saving per production application, assuming that it were replaced with a Service Fabric equivalent; for the purpose of this blog one may equate Service Fabric to adaptive, distributed OSGi runtime.
Cost savings in terms of
- application release efficiency.
- ongoing change management,
- fault diagnostics and resolution,
- efficiency savings through code re-use
To turn this into some real numbers - consider the following. A tier 1 investment bank may have as many as ~1000 applications; each application typically costing $1m per annum. Lets assume that only 30% of the applications are suitable for migrating to the new world - we're still looking at a year on year saving of $200m. Migration costs are not included in this, but these are short term expenses. Likewise neither are the cost savings realized by replacing legacy JEE Application Server and middleware with the Service Fabric solution.
As always - 'mileage may vary' - but never the less, quite a value proposition for OSGi!
Monday, October 12, 2009
How do you scale your Spring DM or POJO applications without development framework lock-in?
"Cloud centric composite applications promise to be more disruptive and more rewarding than either the move to client-server architectures in the early 1990’s, or web-services in the late 1990’s. A successful Private Cloud / Platform as a Service (PaaS) solution will provide the robust and agile foundations for an organization’s next generation of IT services.
These Cloud / PaaS runtimes will be in use for many years to come. During their lifetime they must therefore be able to host a changing ecosystem of software services, frameworks and languages.
Hence they must:
• be able to seamlessly, and incrementally, evolve in response to changing business demands
• at all cost, avoid locking an organization into any one specific development framework,
programming language or middleware messaging product."
Want to know more? Read the new Paremus Service Fabric architecture paper which may be found here.
Wednesday, September 30, 2009
Saturday, July 11, 2009
How Nimble is your OSGi runtime?
Hands up all of you managing OSGi dependencies via an editable list of bundles. Easy isn't it! It just works right!?
Well actually - it 'just works' for a single application running in a small number of containers. From an enterprise perspective you are unintentionally contributing to an impending complexity meltdown; an explosion of dependency and configuration management issues. And if you are unfortunate enough to end up supporting your own composite creations, you may well end up envying the fate of Prometheus and rueing the day you learnt to code.
Possible harsh? But I'm not alone voicing this concern!
In his recent article "Reuse: Is the Dream Dead?", Kirk Knoernschild continues his efforts to educate the industry on the tensions between code 're-use' and 'simplicity of use'. Kirk argues that as you increase potential re-use via lightweight fine-grained components, the complexity of dependencies and necessary environmental configurations corresponding increase, so making these same components harder to use.
A simple concept, yet if unaddressed, an issue that will make your life as an enterprise developer increasing uncomfortable and help edge OSGi closer to that seemingly inevitable 'trough of disillusionment'.
Yet, from a development perspective the issue of dependency management is well understood.
Whilst initially found wanting, a number of projects now exist to address this; including the SIGIL eclipse plug-in which Paremus recently contributed to the Apache Felix project, (SIGIL leveraging Peter Krien's BND tool).
In contrast, the issue of dependency management in Production is less immediately obvious, its impact more profound and generally ignored.
* Will aspects of the runtime environment affect the runtime dependencies within the application?
* Will applications be isolated from each other, or might they run within the same JVM?
* How are the released artifacts subsequently managed in the production environment with respect to ongoing bundle dependency and version management?
Echoing Kirk's concerns, Robert Dunne started his presentation at OSGi DevCon Europe with the observation that; 'whilst modularity was good, its benefits are often undermined by dependency and configuration complexity'. The subject of Robert's presentation? The Paremus Nimble Resolver, which is our response to the concerns posed by Kirk.
Nimble is a high performance runtime dependency resolver. To deploy a composite application to a Nimble enabled runtime (i.e. the Paremus Service Fabric) one specifies:
* The root component of the artifact.
* And a set of associated policies and constraints.
Nimble then does the rest.
Presented with the 'root', Nimble dynamical constructs the target composite; ensuring that the structural dependencies are resolved in a manner consistent with both organizational policies and the runtime environment within which it finds itself.
Nimble's OSGi capabilities include:
* Fragment attachment policies.
* Optional import policies.
* Import version range narrowing.
* The ability to resolve dependencies on extender bundles (DS, 'classic' Spring, Spring DM, iPOJO).
With Nimble policies allowing:
* The configuration of selected extensions.
* Flexible constraint requirement -> capability matching.
* The ability to configure optional dependency resolution behaviors.
Not just OSGi, Nimble is a generic artifact resolver with a plug-able architecture. Any artifact type may be supported, with support currently available for:
* OSGi Bundles
* POJO's, 'classic' Spring & Spring DM
* WAR
* Configurations.
A Nimble enable runtime quite literally dynamically assembles all required runtime application and infrastructure service dependencies around the deployed business components! Specify a WAR artifact and Nimble will instantiate the appropriate Servlet engine dictated by runtime policy attached to the WAR; i.e. Tomcat or Jetty Sir? Specify a 'Configuration', and Nimble responds by installing the target of the configuration, and of-course its dependencies.