Why should a 12 Factor app be self contained?

Question

In the 12 Factor article on Port Binding http://12factor.net/port-binding there is a requirement that every app be self-contained and not have a runtime injected e.g. Tomcat. For what reason is this advised... what are advantages of self-contained apps for microservices?

Urey

Answer 1

To understand rules around port binding and self-contained apps, it's helpful to view things from the perspective of the platforms designed to run 12-factor apps, like Heroku or Deis.

These platforms are scaling applications at the process level. When processes are scaled up, the platform tries to place these additional workers behind the routing mesh so they can start serving traffic. If the app is not self-contained and, for example, is tightly coupled to a front-end Apache server using mod_jk -- it is not possible to scale by running more isolated worker processes.

Port binding exists to solve the problem of "port brokering" at the platform level. If every application worker listened on port 80 there would be conflicts. To solve this, port binding is a convention whereby the application listens on a port the platform has allocated -- and which is passed in as a $PORT environment variable. This ensures a) the application worker listens on the right port and b) the platform knows where to route traffic destined for that worker.

Gahan

Answer 2

I think is because it gives you a great deal of flexibility when the time to scale up your app comes. If you use tomcat you'll have to copy your .war and drop it inside another tomcat and then load balance your requests to either of them.

Instead If your app has a self contained http server, you colud just run another instance in another port and forget about all that tomcat stuff. You would still have to load balance your requests to either of your app instances, but seems more straight forward.

Pariah

You could use embedded tomcat or embedded jetty to expose your service – Quadruplicate