Cloud-Native Architecture: The 15+ Factors for Modern Applications

The Evolution of Cloud Architecture

The original concepts of what exactly cloud is, how it should or could be used and adopted, has changed over time. What started as simple server virtualization has evolved into a comprehensive approach to building and running scalable applications.

Monolithic architectures struggle in modern cloud environments. The shift to cloud-native requires new architectural approaches that embrace distribution, resilience, and automation.

Does a Universal Architecture Exist?

The Twelve-Factor App methodology, originally developed by Heroku, established the foundational framework for cloud-native applications. Kevin Hoffman later extended this to 15 factors in "Beyond Twelve-Factor App," and at Noblerr, we propose a 16th factor based on our experience.

Codebase

Dependencies

Config

Build

Deploy

Run

Scale

Monitor

The 15 Cloud-Native Factors

1. Codebase

One codebase tracked in version control, many deploys.

Single repository per application

Version control is mandatory (Git)

Same codebase deployed to multiple environments

Never share code between apps—use libraries instead

If you have multiple codebases, you have a distributed system, not an app. Each component should be a separate app following the twelve factors.

2. Dependencies

Explicitly declare and isolate dependencies.

Never rely on system-wide packages

Use dependency declaration manifests (package.json, requirements.txt, go.mod)

Isolate dependencies to prevent "works on my machine" issues

Include system tools if needed (e.g., ImageMagick)

3. Config

Store configuration in the environment.

Config varies between deploys; code does not

Strict separation of config from code

Store in environment variables

Never commit credentials to source code

Test: Could your codebase be made open source without compromising credentials? If not, your config isn't properly separated.

4. Backing Services

Treat backing services as attached resources.

Databases, message queues, caches, SMTP services

No distinction between local and third-party services

Swap implementations without code changes

Connect via URLs or credentials in config

Service Type	Examples
Data stores	MySQL, PostgreSQL, MongoDB
Message queues	RabbitMQ, Kafka, SQS
Caching	Redis, Memcached
External APIs	Stripe, Twilio, SendGrid

5. Build, Release, Run

Strictly separate build and run stages.

Build: Convert code to executable bundle

Release: Combine build with config

Run: Execute in the target environment

Every release should have a unique ID. Releases are append-only; rollback by deploying a previous release.

6. Stateless Processes

Execute the app as one or more stateless processes.

Processes are stateless and share-nothing

Persistent data stored in backing services

Never assume memory or filesystem persists

Sticky sessions violate twelve-factor

Store session state in Redis or a database, never in local memory. This enables horizontal scaling without session loss.

7. Port Binding

Export services via port binding.

App is self-contained

Web server library embedded in app

Platform assigns ports automatically

One app can become another's backing service

8. Concurrency

Scale out via the process model.

Processes are first-class citizens

Different process types for different work (web, worker, scheduler)

Scale by adding processes, not threads

Never daemonize or write PID files

Load Balancer

Web Process (x3)

Worker Process (x5)

Scheduler (x1)

9. Disposability

Maximize robustness with fast startup and graceful shutdown.

Processes can start and stop at a moment's notice

Minimize startup time

Shut down gracefully on SIGTERM

Handle unexpected termination

Design for failure. Processes will crash. The system should recover automatically without human intervention.

10. Dev/Prod Parity

Keep development, staging, and production as similar as possible.

Gap	Traditional	Cloud-Native
Time	Weeks between deploys	Hours
Personnel	Different people	Same team
Tools	Different stacks	Same backing services

Use the same backing services everywhere

Docker and containers make parity achievable

Resist the urge to use different services for convenience

11. Logs

Treat logs as event streams.

App never concerns itself with log storage

Write unbuffered to stdout/stderr

Execution environment captures and routes logs

Use log aggregation services (ELK, Splunk, Datadog)

12. Admin Processes

Run admin/management tasks as one-off processes.

Database migrations, console sessions, one-time scripts

Run in identical environment as regular processes

Ship admin code with application code

Use built-in REPL for languages that provide one

13. Telemetry (Beyond Twelve-Factor)

Instrument everything for observability.

Application Performance Monitoring (APM)

Health checks and readiness probes

Domain-specific metrics

Distributed tracing

In cloud environments, you can't SSH into servers. Telemetry is your only window into application behavior.

14. Authentication & Authorization (Beyond Twelve-Factor)

Security is not optional.

Implement RBAC (Role-Based Access Control)

Consider ABAC (Attribute-Based Access Control) for complex scenarios

Secure every endpoint, including internal ones

Zero-trust networking principles

Approach	Use Case
RBAC	Simple permission models, standard roles
ABAC	Complex rules, context-aware access
Zero Trust	Internal services, microservices

15. API First (Beyond Twelve-Factor)

Design interfaces before implementation.

Define contracts between services first

Use OpenAPI/Swagger specifications

Enable parallel development

Build for consumers, not just your current needs

Factor 16: Agile Organization (Noblerr Addition)

Conway's Law: Organizations design systems that mirror their communication structure. Your architecture will reflect your org chart.

At Noblerr, we propose a 16th factor: Agile company and project processes.

Technical architecture alone isn't enough. Consider:

Cross-functional teams aligned with services

DevOps culture and shared responsibility

Continuous improvement practices

Communication patterns that support your architecture

Culture

Values, trust, psychological safety

Organization

Team structure, communication

Process

Agile, DevOps, CI/CD

Technology

Architecture, tools, platforms

Conclusion

There are no universal solutions in software architecture. However, these 15+ factors provide reliable navigation for cloud-native development. They represent hard-won lessons from building and operating thousands of applications at scale.

Start with the basics — Codebase, dependencies, config

Design for failure — Stateless, disposable, observable

Automate everything — Build, deploy, scale, monitor

Think about security — Authentication on every boundary

Align your organization — Conway's Law is real

Partner with Noblerr

Building cloud-native applications requires more than just knowing the factors—it requires experience applying them in real-world scenarios.

At Noblerr, we help organizations:

Assess current architecture against cloud-native principles

Design systems that scale and evolve

Implement modern practices across your stack

Train teams on cloud-native development

Ready to go cloud-native? Contact us for an architecture review and see how these principles can transform your applications.