Future App Servers -- Radically Different

I was lucky enough last week [22 March 2010] to moderate a panel at EclipseCon on the future of application servers. The panelists did a great job, but I thought were far too conservative in their views. I agree with them that many customers want evolutionary change from today to future app servers, but I see requirements driving app servers toward radical change. Inevitably.

The changes I see:

 

Requirement

Response

Get more value from servers, get responsive, get agile and flexible

Virtualized everything, dynamic provisioning, automated change management

Govern rising application stack complexity

Lean, fit to purpose app servers, profiles and other standard configurations, modeling and metadata-based development and deployment

Provide “Internet scale”

Scale-out app servers, data tiers, network capacity, modular/layered designs, stateless architectures

 

The result is “distributed virtualization” of application servers. Application servers will look a lot more like elastic application platforms than like today’s products. Today’s products are like transaction monitors; elastic application platforms are like fabrics or grids. I expect, as is usually the case, that vendors without a strong existing customer base to protect will lead development of the new app servers.  Paremus Service Fabric is a good example. I suspect Microsoft’s Azure will provide a cloud-based example.

I was tempted to declare in this post that the demise of the app server is at hand. But that would be a lame attempt at link bait -- and untrue.  As the new generation of app servers rises, today’s generation of application servers will continue to evolve and improve. I’ve been impressed by the reliability features in IBM WebSphere 7, for example, as well as JBoss Application Server 5’s container configurability and broad language support. And Greg Wilkins described very innovative uses of Jetty. These "traditional" application servers are still both useful and relevant.

Still, a new generation of application servers is beginning. If your requirements take you into the new features and characteristics they offer, don’t let your imagination be held back by undue loyalty to the prior generation of application servers.

Comments

Do you see the layering and componentization continuing?

This would seem to be the other side of the Oracle "new mainframe" strategy where a "middleware" fabric is everywhere and can be used and relied upon to deliver my execution and integration needs in a cost effective and performant manner.
About time says I.

Q: As these fabrics mature, it would seem to me that there is an opportunity to collapse the infrastructure and platform stack and consolidate the pieces to make the "weave" of the fabric less intrusive; increasing the horsepower and lowering the cost - Azure might be the first one.

Are you seeing this happen or is this just yet another layer and set of middleware components to add to the mix?

Consolidation take us back where we started?

Hi Gordon. Thanks very much for your comment. If I understand your question, I worry about too much function sedimenting into the new app servers -- unless that functionality can be configured to provide just what an app needs. One of the issues people have with today's traditional app servers is their heft, which is due to the many functions they provide. The new app servers have got to be more "fit to purpose", sometimes called lightweight.

Future App Servers versus Application Platforms

John, I do agree that there are interesting alternatives to the current set of app servers on the market. All the points you mention are essential, but I propose that for enterprise use -- in difference to pure e-commerce -- you are not looking at the necessary consolidation of current silos as well -- not just apps.

I propose that it is necessary -- as with our fit-for-purpose Papyrus platform -- to also include the necessary consolidation of ECM, CRM, and BPM to make it really attractive for a business to throw away its current set of old clunkers where they continue to throw good money after bad to 'protect the investment'. It has to be a real-world scenario that allows business people to act in SCRUM-like, short implementation and improvement cycles.

And more than anything else Papyrus provides true Empowerment:
- enable executives to define a business strategy in real-world terms,
- give analysts the means to design a business architecture,
- provide the business users with a user interface to create content and processes on the fly,
- support management to structure compliance with business rules and audit,
- and pull the customer in through the Web into the closed-loop business process for immediate participation,
- and provide IT with the management and monitoring tools to run a fault-tolerant system.

More on http://www.real-world-process.com

Would love to see a demo

Hi Max. Thanks for your comment. I was addressing only a portion of the stack in my post; your comment I think illustrates what's possible in a broader stack founded on a "fit to purpose" app server. I'm still eager to see a demo of Papyrus, and hope we can arrange one soon.

Consumerisation and Industrialisation of Middleware

Hi John,

Couldn't agree more with your ideas - in particular on the need to slim down middleware. Have written some further comments on my blog at: http://itblagger.wordpress.com/2010/05/06/cloud-platforms-and-future-mid... but thought I'd drop a comment here as well to express my support, lol.

Thanks

Ian