Live Coding 12-Factor App Emily Jiang Java Champion STSM, IBM - - PowerPoint PPT Presentation

live coding 12 factor app
SMART_READER_LITE
LIVE PREVIEW

Live Coding 12-Factor App Emily Jiang Java Champion STSM, IBM - - PowerPoint PPT Presentation

Application Modernization Technical Conference 2019 Live Coding 12-Factor App Emily Jiang Java Champion STSM, IBM Liberty Microservice Architect, Advocate MicroProfile Architect @emilyfhjiang Contents Basic concept of 12 factor app On


slide-1
SLIDE 1

Application Modernization Technical Conference 2019

Live Coding 12-Factor App

Emily Jiang Java Champion STSM, IBM Liberty Microservice Architect, Advocate MicroProfile Architect @emilyfhjiang

slide-2
SLIDE 2

Contents

Basic concept of 12 factor app On stage hacking of creating 12 factor microservices using MicroProfile

slide-3
SLIDE 3

12 Factors in a nut shell

A Methodologie

Best Practices

Manifesto

https://12factor.net/ by Heroku

slide-4
SLIDE 4

Why 12 factor?

  • Define the contract between applications and infrastructure

Application Infrastructure

slide-5
SLIDE 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

slide-6
SLIDE 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

slide-7
SLIDE 7

How to build 12-Factor App?

slide-8
SLIDE 8

MicroProfile and Kubernetes come to rescue!

slide-9
SLIDE 9

Community Driven Lightweight, Iterative Processes Specs, APIs, TCKs

NO Reference Implementation

slide-10
SLIDE 10

MicroProfile Community

  • Over a dozen vendors and

Java user groups

  • Around 169 individual

contributors and growing

  • Around a dozen

independent implementations

slide-11
SLIDE 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

slide-12
SLIDE 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 201 8

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

slide-13
SLIDE 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)

slide-14
SLIDE 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)

slide-15
SLIDE 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

slide-16
SLIDE 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;

slide-17
SLIDE 17
  • IV. Backing services

“Treat backing services as attached resources”

Application My SQL Amazon S3 Twitter

slide-18
SLIDE 18

MicroProfile REST Client

B A

@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

slide-19
SLIDE 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)

slide-20
SLIDE 20
  • VI. Processes

“Execute the app as one or more stateless processes” Stateless and share-nothing Restful API

slide-21
SLIDE 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 MP Config to inject ports to microservices for chain-up invocations

Port=80

@Inject @ConfigProperty(name=”port”, defaultValue=“9080”)

slide-22
SLIDE 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 k8s Ø Build micorservices

slide-23
SLIDE 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

From “CERN Data Centre Evolution”

slide-24
SLIDE 24

MicroProfile Fault Tolerance

A solution to build a resilient microservice

v Retry - @Retry v Circuit Breaker - @CircuitBreaker v Bulkhead - @Bulkhead v Time out - @Timeout v Fallback - @Fallback

slide-25
SLIDE 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

slide-26
SLIDE 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

slide-27
SLIDE 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

slide-28
SLIDE 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

slide-29
SLIDE 29

How to get started?

https://start.microprofile.io/ https://appsody.dev/

slide-30
SLIDE 30

12 factor app

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

microservice Infrastructure

slide-31
SLIDE 31

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

slide-32
SLIDE 32

References

  • https://microprofile.io
  • https://openliberty.io
  • https://www.12factor.net/
  • https://kubernetes.io/
  • https://appsody.dev/
  • https://github.com/Emily-Jiang/qcon-12factor-app-a
  • https://github.com/Emily-Jiang/qcon-12factor-app-b
  • https://github.com/Emily-Jiang/qcon-12factor-deployment

microservice Infrastructure K8s

@emilyfhjiang

slide-33
SLIDE 33

Thank You

Thank You @emilyfhjiang