12 Factors and the Strangler Pattern

 

 

Cloud native builds will mean that legacy applications, will need to be rebuilt to fit into cloud patterns.  An example of a pattern to use to rebuild applications in the cloud is the strangler pattern.  This is a method to refactor and rebuild the application over a period of time, strangling the legacy code and replacing it.  The strangler pattern would be set against a set of design considerations for cloud native. 

 

IBM’s architecture of the strangler pattern for an event driven architecture using APIs, MOM, Containers, Micro-services and related discrete data services. 

DiagramDescription automatically generated

 

The most common set of architecture principles for cloud native builds would be the 12 factors plus one.  The missing ‘one’ is testing.  Testing is a common pain point in cloud deployments including integrated security testing.  The 12 factors allow the Agile team to envision what a decoupled and componentised architecture will look like.  It serves as a useful guide. 

https://12factor.net/

 

The Twelve Factors

I. Codebase

One codebase tracked in revision control, many deploys

II. Dependencies

Explicitly declare and isolate dependencies

III. Config

Store config in the environment

IV. Backing services

Treat backing services as attached resources

V. Build, release, run

Strictly separate build and run stages

VI. Processes

Execute the app as one or more stateless processes

VII. Port binding

Export services via port binding

VIII. Concurrency

Scale out via the process model

IX. Disposability

Maximize robustness with fast startup and graceful shutdown

X. Dev/prod parity

Keep development, staging, and production as similar as possible

XI. Logs

Treat logs as event streams

XII. Admin processes

Run admin/management tasks as one-off processes

 

It is worthwhile to click through each of the above links and read the details on the associated ideas and patterns.  These can form the basis of a target operating model in the cloud and the related architectures.  It will also help teams imagine what a future state beyond a lift and shift with minor refactoring could look like, leading to a ‘digital transformation’ and new products and services.