The document discusses the twelve-factor app methodology for building cloud-native microservices. It describes the twelve factors including codebase, dependencies, configuration, backing services, build/release/run stages, processes, port binding, concurrency, disposability, development/production parity, logs, and admin processes. It then demonstrates how to build a twelve-factor app using MicroProfile specifications and Kubernetes, with a live coding example of two microservices. References are provided for further reading.

1. COPYRIGHT (C) 2020, ECLIPSE FOUNDATION, INC. | THIS WORK IS LICENSED UNDER A CREATIVE COMMONS ATTRIBUTION 4.0 INTERNATIONAL LICENSE (CC BY 4.0) 1
12 May 2020
Emily Jiang, Liberty Microservice Architect @IBM
Twitter: @emilyfhjiang
Building 12-factor Cloud Native
Microservices

2. Contents
Basic concept of 12 factor app
Live coding 12 factor microservices using MicroProfile

3. 12 Factors in a nutshell
– A Methodologie
– Best Practices
– Manifesto
https://12factor.net/ by Heroku

4. Why 12 factor?
• Define the contract between applications and infrastructure
Application Infrastructure

5. What is a Twelve-Factor App?
In the modern era, software is commonly delivered as a service: called web apps, or software-as-a-service. The
twelve-factor app is a methodology for building software-as-a-service apps that:
Use declarative formats for setup automation, to minimize time and cost for new developers joining the project;
Have a clean contract with the underlying operating system, offering maximum portability between execution
environments;
Are suitable for deployment on modern cloud platforms, obviating the need for servers and systems
administration;
Minimize divergence between development and production, enabling continuous deployment for maximum
agility;
And can scale up without significant changes to tooling, architecture, or development practices.
The twelve-factor methodology can be applied to apps written in any programming language, and which use any
combination of backing services (database, queue, memory cache, etc).
From https://12factor.net

6. THE FACTORS
1. Codebase
2. Dependencies
3. Config
4. Backing Services
5. Build, Release, Run
6. Processes
7. Port binding
8. Concurrency
9. Disposability
10.Dev / Prod parity
11.Logs
12.Admin Processes

7. How to build 12-Factor App?

8. MicroProfile and Kubernetes come to rescue!

9. Community
Driven
Lightweight, Iterative
Processes
Specs, APIs, TCKs
NO Reference
Implementation

10. MicroProfile Community
● Over a dozen vendors and
Java user groups
● Around 178 individual
contributors and growing
● Around a dozen
independent
implementations

11.  Open specifications
 Wide vendor support
 REST Client
 OpenAPI support
 Security
 Fault Tolerance
 Configuration
 Metrics
 Health
 Open Tracing
https://wiki.eclipse.org/MicroProfile/Implementation
Quarkus

12. 12
MicroProfile 1.0 (Fall 2016)
JAX-RS 2.0
CDI 1.2
JSON-P 1.0
MicroProfile 1.1 (August 2017)
microProfile-1.0
Config 1.0
MicroProfile 1.2 (Sept 2017)
MicroProfile-1.1
Config 1.1
Fault Tolerance 1.0
Health 1.0
Metrics 1.0
JWT 1.0
2017
2018
MicroProfile 1.3 (Dec 2017)
MicroProfile 1.2
Config 1.2
Metrics 1.1
OpenApi 1.0
OpenTracing 1.0
RestClient 1.0
MicroProfile 1.4 (June 2018)
MicroProfile 1.3
Config 1.3
Fault Tolerance 1.1
JWT 1.1
Open Tracing-1.1
Rest Client-1.1
2019
MicroProfile 2.0.1 (July 2018)
MicroProfile 1.4
JAX-RS 2.1 // Java EE 8
CDI 2.0 // Java EE 8
JSON-P 1.1 // Java EE 8
JSON-B 1.0 // Java EE 8
MicroProfile 2.1 (Oct
2018)
MicroProfile 2.0
OpenTracing 1.2
MicroProfile 2.2 (Feb
2019)
Fault Tolerance 2.0
OpenAPI 1.1
OpenTracing 1.3
Rest Client 1.2
MicroProfile 3.0
(June 2019)
MicroProfile 2.1
Metrics 2.0
Health Check
2.0
Rest Client 1.3
MicroProfile 3.2 (Nov
2019)
MicroProfile 3.0
Metrics 2.2
Health Check 2.1
2020
MicroProfile 3.3 (Feb
2020)
MicroProfile 3.2
Config 1.4
Metrics 2.3
Fault Tolerance 2.1
Health 2.2
Rest Client 1.4

13. I. Codebase
• Dedicate smaller teams to individual applications or microservices.
• Following the discipline of single repository for an application forces
the teams to analyze the seams of their application and identify
potential monoliths that should be split off into microservices.
“One codebase tracked in revision control, many deploys.”
Use a single source code repository for a single application (1:1
relation). Deployment stages are different tags/branches
i.e. use a central git repo (external Github/GitHub Enterprise
also suitable)

14. II. Dependencies
A cloud-native application does not rely on the pre-existence of dependencies in
a deployment target.
Developer Tools declare and isolate dependencies
• Maven and Gradle for Java
“Explicitly declare and isolate dependencies”
Each microservice has its own dependencies declared (e.g.
pom.xml)

15. III. Config
“Store config in the environment”
 Changing config should not need to repackage your application
 Use Kubernetes configmaps and secrets for container services
 Use MicroProfile Config to inject the config properties into the microservices
App Password=blah

16. MicroProfile Config
Why?
– Configure Microservice without
repacking the application
How?
– Specify the configuration in
configure sources
– Access configuration via
• Programmatically lookup
Config config =ConfigProvider.getConfig();
config.getValue(“myProp”, String.class);
• Via CDI Injection
@Inject
@ConfigProperty(name="my.string.property")
String myPropV;

17. IV. Backing services
“Treat backing services as attached resources”
Application
My SQL Amazon S3 Twitter

18. MicroProfile REST Client
BA
@Inject
@RestClient
private SystemClient
defaultRestClient;
@Dependent
@RegisterRestClient
@RegisterProvider(UnknownUrlExceptionMapper.class)
@Path("/properties")
public interface SystemClient {
@GET
@Produces(MediaType.APPLICATION_JSON)
public Properties getProperties() throws
UnknownUrlException, ProcessingException;
}
io.openliberty.guides.inventory.client.SystemClient/mp-rest/url=http://localhost:9080/system

19. V. Build, release, run
“Strictly separate build and run stages”
 Source code is used in the build stage. Configuration data is added to define a
release stage that can be deployed. Any changes in code or config will result in a
new build/release
 Needs to be considered in CI pipeline (e.g. Tekton)

20. VI. Processes
“Execute the app as one or more stateless processes”
Stateless and share-nothing
Restful API
From “CERN Data Centre Evolution”

21. VII. Port binding
“Export services via port binding”
 Applications are fully self-contained and expose services only through ports.
Port assignment is done by the execution environment
 Ingress/service definition of k8s manages mapping of ports
 Use MicroProfile Config to inject ports to microservices for chain-up invocations
port=80
@Inject @ConfigProperty(name=”port”, defaultValue=“9080”)

22. VIII. Concurrency
“Scale out via the process model”
 Applications use processes independent from each other to scale out (allowing
for load balancing)
 To be considered in application design
 Cloud autoscaling services: [auto]scaling built into kNative
 Build microservices

23. IX. Disposability
“Maximize robustness with fast startup and graceful shutdown”
 Processes start up fast.
 Processes shut down gracefully when requested.
 Processes are robust against sudden death
 Use MicroProfile Fault Tolerance to make it resilient

24. MicroProfile Fault Tolerance
A solution to build a resilient microservice
 Retry - @Retry
 Circuit Breaker - @CircuitBreaker
 Bulkhead - @Bulkhead
 Time out - @Timeout
 Fallback - @Fallback

25. X. Dev/prod parity
“Keep development, staging, and production as similar as possible”
 Development and production are as close as possible (in terms of code, people,
and environments)
 Can use Operators to deploy in repeatable manner

26. XI. Logs
“Treat logs as event streams”
 App writes all logs to stdout
 Use a structured output for meaningful logs suitable for analysis. Execution
environment handles routing and analysis infrastructure

27. XII. Admin processes
“Run admin/management tasks as one-off processes”
 Tooling: standard k8s tooling like “kubectl exec” or Kubernetes Jobs
 Also to be considered in solution/application design
 For example, if an application needs to migrate data into a database, place this
task into a separate component instead of adding it to the main application code
at startup

28. THE FACTORS
1. Codebase
2. Dependencies
3. Config
4. Backing Services
5. Build, Release, Run
6. Processes
7. Port binding
8. Concurrency
9. Disposability
10.Dev / Prod parity
11.Logs
12.Admin Processes

29. How to get started?
https://start.microprofile.io/
https://appsody.dev/

30. Demo
Service-a
Service-b

31. 12 factor app
• Use MicroProfile and K8s to build a microservice => 12 factor app
microservice
Infrastructure

32. THE FACTORS
1. Codebase
2. Dependencies
3. Config
4. Backing Services
5. Build, Release, Run
6. Processes
7. Port binding
8. Concurrency
9. Disposability
10.Dev / Prod parity
11.Logs
12.Admin Processes

33. References
• https://microprofile.io
• https://openliberty.io
• https://quarkus.io
• https://www.12factor.net/
• https://kubernetes.io/
• https://start.microprofile.io/
• https://appsody.dev/
• https://github.com/Emily-Jiang/vsummit-12factor-app-a
• https://github.com/Emily-Jiang/vsummit-12factor-app-b
• https://github.com/Emily-Jiang/vsummit-12factor-deployment
microservice
Infrastructure
K8s
@emilyfhjiang

34. Thank you!
COPYRIGHT (C) 2020, ECLIPSE FOUNDATION, INC. | THIS WORK IS LICENSED UNDER A CREATIVE COMMONS ATTRIBUTION 4.0 INTERNATIONAL LICENSE (CC BY 4.0)
@emilyfhjiang