Tony Wolski

JavaOne 2013 - Decompose that WAR!


Last night I watched the JavaOne 2013 session Decompose that WAR! Architecting for Adaptability, Scalability and Deployability. The presenter was Chris Richardson, the author of POJOs in Action, and in the talk he discusses how very large applications bundled into a single war, what he calls monolithic applications, can give you more headaches than the benefits they provide.

Problems with the Monolithic Architecture

First, he discussed the problems with a monolithic architecture…

I can certainly relate to a lot, if not all, of these points. I currently work on an accounting application that is integrated into a insurance application. Even, the accounting application on its own could be considered monolithic, but when the insurance project is built, it pulls in the entire accounts web application as an Ivy dependency and bundles the whole lot up into a single, huge ‘monolithic’ app.

Our development and QA team suffer from all of the issues mentioned above:

An Alternative: Micro-Architecture

Richardson suggests a better approach is decompose your applications into small, manageable services; an architecture he calls ‘Micro-Architecture’. The idea smaller, simpler applications that:

The bit I really like from the list above is the ability to build one service with one technology, and another service in a completely different development stack. As long as the interfaces are defined and implemented correctly, each service can be developed in whatever technology the developer chooses: Scala, Groovy, NodeJS etc. I love experimenting with different languages so this really hit the spot.

Of course, this approach is by no means a panacea. Problems Richardson highlights are:

Richardson goes into a high level overview about micro-architecture integration patterns, data formats and technologies like synchronous HTTP, asynchronous communication, JSON, XML, Protocol Buffers, Thrift etc. I’ll leave it up to the reader to check out the presentation for more details.

Tips about how to go from a 10M line monolithic app to a ‘nice’ architecture…

Strategy #1 - Make any new services a small, pristine services. Don’t just shove in new functionality with the rest of the monolithic application. Put an anti-corruption layer in between the monolith and the pristine new service/functionality.

Strategy #2 - Extract existing services. Spend some time describing what the ideal partitioned architecture is. Then Start extracting those parts into new, small, pristine services. Partition the system by verb or noun.

An in all a interesting talk and one well worth checking out.

Your thoughts? I'd love to hear them. Please get in contact.