self contained app deployment

[Michael Neale]

I listend to the discussion/argument about deploying apps with everything baked in vs into a container - I have noticed a trend towards self containment. 

Recently we (cloudbees) only did container stuff for "cloud" hosting apps - but now host pretty much anything, and the self contained stuff is exploding. (thanks to play2 for a large part). 

Jetty seems to be popular as a way to bake things in - you know how it will work etc, and really, it isn't much bigger - app containers/servers tend to have lots in the case you use it, but often you don't. 

I have put up a few "quick start" stacks that people can use - occasionally juggling the order of them (http://developer.cloudbees.com) - but still the non container ones grow over the container ones (at least for new apps). 

My experience: 

Pros of self contained apps: 

* often smaller total footprint 

* can use non servlet tech (eg async, long running, non thread based)

* integration testing is a better reflection of the reality

* control freaks !

cons: 

* can't easily augment them at runtime with instramentation, monitoring (java agent can help here)

* wrapping things around like authorization and more is a tad harder at the process level

* errors/behaviour not always as obvious to track down.

My preference is for self contained apps always - because it is just another process. I like to think about design at the unix level - everything is just packages after all. 

[Moandji Ezana]

Which episode is this?

Moandji

[Mark Derricutt]

I'm guessing it was either 90 or 91 - nothing in the notes for either about deployment tho so maybe I didn't note that down?


On 16/11/2012, at 7:58 PM, Moandji Ezana <mwa...@gmail.com> wrote:

> Which episode is this?

[Rob Lally]

For me, the trend towards self-contained applications is just the next logical/natural step in the trend towards lighter and lighter tools that the Java community has been struggling through for the last decade.

Weblogic/Webshpere -> JBoss -> Tomcat -> Jetty -> <Nothing/Embedded-Jetty/Netty>

I suppose that if we hadn't started in such a crappy place, we wouldn't have had so far to go.

I know that I spent a lot of years in the banking world trying to drag people to the right, and the farther people moved, the happier they were with the end results. Here at Yammer/Microsoft we use Dropwizard [http://dropwizard.codahale.com/] for all our Java services, with everything squashed into a single jar  using maven-shade-plugin, and I've been really pleased with the work I've done using it.

One additional pro-point for all-in-one stacks is that they tend to be friendlier towards TDD: particularly if you favour the "Classical Approach" [http://martinfowler.com/articles/mocksArentStubs.html#ClassicalAndMockistTesting], as I do.

Rob.

[Matthew Farwell]

I think this is a very interesting point.

Personally, I've almost always used a container, mainly because that was what was expected from the client, but I can see the appeal of a standalone / self contained app.

Does a self contained app mean fewer configuration options for the end user?

For instance, if two apps share the same database, but run under the same tomcat, then you can share the connection pool for the database, thus giving the end user more options. This is assuming of course that the user wants to do this.

Containers also provide extra services, not just the big things like caching etc, but stuff like access logs. I don't know, but I suspect that doing access logs in a consistent manner is harder in a self contained app.

I don't understand the point about integration testing. When I develop a webapp, for my integration tests I run up a jetty in maven, and deploy the webapp, and then run the integration tests. Could you better explain what you mean?

Thanks.

Matthew Farwell.

[Michael Neale]

"For instance, if two apps share the same database, but run under the same tomcat, then you can share the connection pool for the database, thus giving the end user more options. This is assuming of course that the user wants to do this."

No I think they would be completely separate - if the apps were developed separately - then they would run completely separately - in this case the apps would be running in a config they probably won't developed for (for no advantage, perhaps).

"Containers also provide extra services, not just the big things like caching etc, but stuff like access logs. I don't know, but I suspect that doing access logs in a consistent manner is harder in a self contained app."

well - the OS can provide this - and has, for years - as ideally you would be consistent for all tech, not just java apps - part of the problem is containers thinking they are operating systems (which probably stems from wanting everything to run, including management, identically on all platforms - regardless of any existing solution). 

"I don't understand the point about integration testing. When I develop a webapp, for my integration tests I run up a jetty in maven, and deploy the webapp, and then run the integration tests. Could you better explain what you mean?"

I think what is meant is that those integration tests are even closer to production now - as you are running the SAME environment earlier on (ie in production you run jetty embedded). You can also wire things up programmatically, I guess making it easier to inject test mocks or whatever (I guess?)

[Matthew Farwell]

Just a note, the Java Posse did a session at the 2012 roundup on this subject:

http://javaposse.com/java-posse-403-roundup-12-dot-war-what-is-it-good-for

which covers some of the points raised, but goes a bit further, for instance talking about load balancing etc.

Matthew Farwell.