Now I’ll tackle the last 6 factors:

7) Port binding

They say that every application should internally provide it’s own network protocol servers and not rely on containers like Apache or Tomcat/JBoss.  I think this is kinda nutty, not just because I write apps that use containers, but because network protocol servers are extremely hard to do well.  Security, performance, scalability, standard protocol implementations, etc… are all very hard to do.  So presumably you’d want to roll in some sort of third party library for that, at which point using a container is the same or better.

8) Concurrency

Again, throwing Java and PHP under the bus, they tie back to “factor” number six where everything is stateless.  They also ban PID files, daemon processes, etc…  What they’re proposing is so far outside anything I’ve done or seen anyone do in a real world app I don’t even know how to respond.

I’m not sure how spinning up large numbers of processes on the same hardware works with the idea of having to vend all your own network servers.  How do you handle port binding, port conflict, and port discovery across a cluster?

9) Disposability

This ties back to “factor”s six and eight, stateless standalone processes which can spawn and die quickly without any impact to the overall system.  This forces you to avoid caching, anything complex, and so on.  I’d much rather have big powerful instances with caches, stateful data, a mature container, solid network systems, and all that.

Building a system around stateless job queues and assuming that instances can and will die often enough to warrant building a system around that seems like an odd place to spend your effort.  Big JBoss instances are VERY stable.  They run and they run and they run for months at a time without issue.  There’s no need to build complex queues and job management system, relying heavily on your external systems (like your database, message queues, redis, etc…) to handle all your state because you’re scared to do it yourself.  I’m not sure why relying on MySQL or RabbitMQ for long running state management is any better than just having your app do it.  Let parsing, network overhead, and re-work.

Continue reading →

There is a site I’ve seen around lately called The Twelve Factor App which lists 12 rules for building a web application.

The goals are noble: to build scalable, portable, easily deployable web applications, while being language and framework agnostic. Unfortunately I found several of the points to run against my experience and personal opinion, so I wanted to go over the 12 tenets they recommend and offer my thoughts on each.  Please keep in mind that much of my experience is on ATG, J2EE, and large complex applications.

1) Codebase

Overall this is pretty normal, but in some cases I don’t completely agree with the idea that shared code can only be handled through independently built-packaged libraries included via some sort of dependency manager.  I haven’t really used a good J2EE level dependency manager, perhaps Maven makes this easy?

2) Dependancies

I have several issues with this “factor”.  Firstly, Java doesn’t have a packaging system for distributing libraries and common app bundles.  Next, I’m not sure what a “dependency declaration manifest” actually DOES at the app level or what “dependency isolation tools” I should be using.  ATG has module dependencies defined within the MANIFEST.MF files which is great, but isn’t something you can use to handle extra-ear dependencies (JBoss, JDBC drivers, native apps, etc…).

Further they expect the app to provide/package ALL system tools it may need.  The examples they use are ImageMagick and curl.  This is crazy for many reasons: first, many of these tools are different on each platform, packaging/building/installing these tools on each different platform is a massive effort and not something easily bundled into your app, nor should your Java/Ruby/PHP developers have to deal with multi-platform C++ build issues, secondly most platforms have their own package installation and dependency management system (yum, apt-get, etc…) which ensure supported platform specific versions, which not only will work, but also may be required for support for Enterprise Linux distress for instance.

Continue reading →