What is the 12-Factor App methodology and why is it relevant to cloud deployment?

Direct Answer

The Twelve-Factor App is a methodology for building deployable software-as-a-service applications. Its factors cover one codebase, explicit dependencies, configuration in the environment, attached backing services, build/release/run separation, stateless processes, port binding, concurrency, disposability, development-production parity, event-stream logs, and admin processes. It guides portability and operability but does not guarantee them.

Code Example

// application.yml with environment variable substitution
spring:
  datasource:
    url: ${DATABASE_URL}  // Factor III: store config in environment
    username: ${DB_USER}
    password: ${DB_PASSWORD}
  profiles:
    active: ${SPRING_PROFILE:dev}  // default to dev if not set

logging:
  pattern:
    console: "%d{yyyy-MM-dd HH:mm:ss} - %msg%n"  // Factor XI: logs to stdout

@RestController
public class OrderController {
    private final OrderRepository orderRepo;  // Factor IV: explicit dependency
    
    // Factor VI: stateless process - no session state in memory
    @PostMapping("/orders")
    public OrderResponse createOrder(@RequestBody OrderRequest request) {
        var order = new Order(request.userId(), request.items());
        orderRepo.save(order);  // Factor XII: state in database, not local variables
        return new OrderResponse(order.id(), "CREATED");
    }
}

Common Mistakes & Pitfalls

• Hardcoding configuration in source code: writing database URLs directly in Java code or committing application.properties with production passwords to GitHub—violates Factor III and creates security risks when the repository leaks.
• Writing logs to local files: using FileAppender in Logback to write logs to /var/log/myapp.log works on one server but breaks in Kubernetes where containers are ephemeral and lose files on restart—Factor XI says write to stdout and let the platform aggregate logs.
• Storing session state in memory: using HttpSession to store shopping cart data works with one server but breaks when scaling horizontally because the second server doesn't see the first server's memory—use Redis or database-backed sessions instead.