• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

How does '12-factor app' principles apply to Java ?

 
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello Gurus,

I'm a long time reader, but this is my first time posting on the forums
I recently read an articled titled 'The 12 factor app' (http://12factor.net), its a methodology for deploying apps to a cloud platform like Heroku.

Below are my comments/questions regarding how these steps apply to Java :
--------------

1) One Codebase tracked with Version Control
* I use Git

2) Dependencies
*I use Maven for Java Dependencies

3) Config
* Strict separation of config from code
* Stores config in environment variables
* Mentions that grouping properties into groups for environments ('dev', 'test') doesn't scale

I'm a bit confused about this requirement, I store my configuration in .properties files and then use a Maven Profile to select the correct files.
I don't understand why this is a bad practice, in my projects we usually only have a few environments (local, dev, dev2, test, test2, acpt, prod).
Also I'm not sure if I like the idea of using environment variables. Would I pass these variables into the JVM by using '-Denv_var=$MY_ENV_VAR' ?


4) Backing Services
*Services are Databases / Message Queues / External services
*Services are accessed via a URL or other locator/credentials stored in the config
*Should be able to swap services without changes to code, with only config changes

5) Build, release, run
*Build stage - source code to Build Artifact
*Release stage - Build Artifact + Config
*Run stage
*Impossible to make changes to the code at runtime
*Deployment tools

From a Java point of view would Building & Releasing be the same ? We usually end up with 1 artifact (jar/war) with everything inside of it.
Also I like to use Managed Beans to be able to tune my application while its running in a test environment, does this violate the 'Impossible to make changes' principle?


6) Processes
*Execute the app as one or more stateless processes
*Twelve-factor processes are stateless and share-nothing
*Any data that needs to persist must be stored in a stateful backing service (Database)
*Sticky sessions are a violation of twelve-factor

I normally develop web applications with Spring MVC and deploy to a single Tomcat. Up until now I have the application running on 1 server at a time per environment.
How doe Java Sessions work across distributed environments ? Don't we need Sessions, how else can we remember if the user has logged in (with cookies?) ?
Is there a framework that will allow our Sessions to be distributed across all deployments?


7) Port binding
*Export services via port binding
*The twelve-factor app is completely self-contained and does not rely on runtime injection of a webserver into the execution environment to create a web-facing service

Does this mean I should be embedding Jetty into my web application instead of deploying into a server like Tomcat?

8) Concurrency
*Applications must also be able to span multiple processes running on multiple physical machines

I'm pretty lost on this one... normally I tend to use a JMS Message Qeue to distribute my work load. Can anyone elaborate?

9)Disposability
*fast startup and graceful shutdown
*started or stopped at a moment’s notice
*Hanlde SIGTERM signal

Makes sense, although sometimes the Spring framework takes a while (~30 seconds) to start up.

10) Dev/prod parity
*Keep development, staging, and production as similar as possible
* time gap / personnel gap / tool gap

11) Logs
*A twelve-factor app never concerns itself with routing or storage of its output stream
*It should not attempt to write to or manage logfiles
*writes to stdout

How does this apply to Java applications using Logging frameworks like Log4j. Do we continue using the libraries but simply send to stdout?

12) Admin processes
*one-off administrative or maintenance tasks
*One-off admin processes should be run in an identical environment
------------

I welcome your feedback! Happy News Years

-Michael
 
author & internet detective
Posts: 42103
933
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Michael,
Welcome to CodeRanch! This is an interesting question. The 12 factor app is referring to cloud. Cloud is not a specific language. Which means it can apply to Java exactly. In fact, you can deploy Java to Heroku.. I'm still going to reply to your question, but not exactly in the "how does this apply to Java" space.

3) Config
* Strict separation of config from code
* Stores config in environment variables
* Mentions that grouping properties into groups for environments ('dev', 'test') doesn't scale

I'm a bit confused about this requirement, I store my configuration in .properties files and then use a Maven Profile to select the correct files.
I don't understand why this is a bad practice, in my projects we usually only have a few environments (local, dev, dev2, test, test2, acpt, prod).
Also I'm not sure if I like the idea of using environment variables. Would I pass these variables into the JVM by using '-Denv_var=$MY_ENV_VAR' ?


Maven puts the properties inside the war file by default. This isn't good because it requires a redeployment to change them.

5) Build, release, run
*Build stage - source code to Build Artifact
*Release stage - Build Artifact + Config
*Run stage
*Impossible to make changes to the code at runtime
*Deployment tools

From a Java point of view would Building & Releasing be the same ? We usually end up with 1 artifact (jar/war) with everything inside of it.
Also I like to use Managed Beans to be able to tune my application while its running in a test environment, does this violate the 'Impossible to make changes' principle?


From the description of item 5, they are talking about separating activities. For example, they list adding in the config files (if any) during the release step.

6) Processes
*Execute the app as one or more stateless processes
*Twelve-factor processes are stateless and share-nothing
*Any data that needs to persist must be stored in a stateful backing service (Database)
*Sticky sessions are a violation of twelve-factor

I normally develop web applications with Spring MVC and deploy to a single Tomcat. Up until now I have the application running on 1 server at a time per environment.
How doe Java Sessions work across distributed environments ? Don't we need Sessions, how else can we remember if the user has logged in (with cookies?) ?
Is there a framework that will allow our Sessions to be distributed across all deployments?


Some application servers have session replication. The 12 factor app does not want you to do this. Everything is stateless. Yes, you would use a cookie to remember the user logged in. Some newer frameworks like Play support completely stateless apps.

The idea here is that users can go to any server in the cloud at any time. And if a server goes down, no user data will be lost.

7) Port binding
*Export services via port binding
*The twelve-factor app is completely self-contained and does not rely on runtime injection of a webserver into the execution environment to create a web-facing service

Does this mean I should be embedding Jetty into my web application instead of deploying into a server like Tomcat?


I don't think so. You can use servers provided by the cloud. Heroku does support Tomcat. I think they mean that you should write your web service to listen directly on the port. This could happen within Tomcat. I

8) Concurrency
*Applications must also be able to span multiple processes running on multiple physical machines

I'm pretty lost on this one... normally I tend to use a JMS Message Qeue to distribute my work load. Can anyone elaborate?


I think "The share-nothing, horizontally partitionable nature of twelve-factor app processes means that adding more concurrency is a simple and reliable operation." is the core of the message on concurrency.

11) Logs
*A twelve-factor app never concerns itself with routing or storage of its output stream
*It should not attempt to write to or manage logfiles
*writes to stdout

How does this apply to Java applications using Logging frameworks like Log4j. Do we continue using the libraries but simply send to stdout?


Yes, you can log to stdout with Log4J.
 
Michael Gomez
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
thanks for the feedback Jeanne, your answers cleared up some doubts I had.
 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
@Jeanne can you give a little more information on factor #6? I am still confused about sticky sessions
 
What does a metric clock look like? I bet it is nothing like this tiny ad:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
reply
    Bookmark Topic Watch Topic
  • New Topic