Application Modernization Technical Conference 2019
Live Coding 12-Factor App
Emily Jiang Java Champion STSM, IBM Liberty Microservice Architect, Advocate MicroProfile Architect @emilyfhjiang
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
Application Modernization Technical Conference 2019
Emily Jiang Java Champion STSM, IBM Liberty Microservice Architect, Advocate MicroProfile Architect @emilyfhjiang
–
A Methodologie
–
Best Practices
–
Manifesto
Application Infrastructure
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
1.
2.
3.
4.
5.
6.
Community Driven Lightweight, Iterative Processes Specs, APIs, TCKs
NO Reference Implementation
https://wiki.eclipse.org/MicroProfile/Implementation
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
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)
“Explicitly declare and isolate dependencies”
Ø 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
–
Configure Microservice without repacking the application
–
Specify the configuration in configure sources – Access configuration via
Config config =ConfigProvider.getConfig(); config.getValue(“myProp”, String.class);
@Inject @ConfigProperty(name="my.string.property") String myPropV;
Application My SQL Amazon S3 Twitter
@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
Ø Source code is used in the build stage. Configuration data is added to define a
Ø Needs to be considered in CI pipeline (e.g. Tekton)
Ø Applications are fully self-contained and expose services only through ports.
Ø 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”)
Ø Applications use processes independent from each other to scale out (allowing
Ø To be considered in application design Ø Cloud autoscaling services: [auto]scaling built into k8s Ø Build micorservices
Ø 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”
v Retry - @Retry v Circuit Breaker - @CircuitBreaker v Bulkhead - @Bulkhead v Time out - @Timeout v Fallback - @Fallback
Ø Development and production are as close as possible (in terms of code, people,
Ø Can use Operators to deploy in repeatable manner
Ø App writes all logs to stdout Ø Use a structured output for meaningful logs suitable for analysis. Execution
Ø 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
1.
2.
3.
4.
5.
6.
https://start.microprofile.io/ https://appsody.dev/
microservice Infrastructure
1.
2.
3.
4.
5.
6.
microservice Infrastructure K8s
@emilyfhjiang
Thank You
Thank You @emilyfhjiang