You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The 12 defines best practices for building web applications with the
7
7
following characteristics: * Suitable to be deployed on cloud platforms
8
8
* Scalable by design * Portable across systems * Enablers of continuous
9
9
deployment and agility
10
10
11
+
The 15-Factor methodology identifies development principles for building applications that offer maximum portability across execution environments, are suitable to be deployed on cloud platforms, can be scaled, guarantee environment
12
+
parity between development and production, and enable continuous delivery.
11
13
____
12
14
TODO Add doc from https://12factor.net/
13
15
____
@@ -32,18 +34,28 @@ A cloud native application should consist of a single codebase tracked
32
34
in a version control system like Git. Each codebase must produce
33
35
immutable artifacts, called builds, that can be deployed to multiple
34
36
environments.
35
-
image::{figures}/image-7.png[Each application has its codebase, from
36
-
which immutable builds are produced and then deployed to the appropriate
37
-
environments without changes to the code.]
38
37
39
-
anything environment-specific
40
-
like configuration must be outside of the application codebase. In case
41
-
of code that’s needed by more than one application, you should either
38
+
image::{figures}/image-7.png[Each application has its codebase, from which immutable builds are produced and then deployed to the appropriate environments without changes to the code.]
39
+
40
+
anything environment-specific like configuration must be outside of the application codebase.
41
+
42
+
In case of code that’s needed by more than one application, you should either
42
43
turn it into an independent service or into a library that you can
43
44
import into the project as a dependency. You should carefully evaluate
44
45
the latter option to prevent the system from becoming a distributed
45
46
monolith.
46
47
48
+
Thinking about how your code is organized into codebases and repos-
49
+
itories can help you focus more on the system architecture and identify those
50
+
parts that might actually stand on their own as independent services. If this is
51
+
done correctly, the codebase’s organization can favor modularity and loose
52
+
coupling.
53
+
54
+
According to the 15-Factor methodology, each codebase should be mapped to an
55
+
application, but nothing is said about repositories. You can decide to track each code-
56
+
base in a separate repository or in the same one. Both options are used in the cloud
57
+
native business.
58
+
47
59
== 2 API first
48
60
49
61
The 15-Factor methodology promotes the API first pattern. It encourages
@@ -106,6 +118,26 @@ surrounding environment are the language runtime and the dependency
106
118
manager tool. This means that private dependencies should be resolved
107
119
via the dependency manager.
108
120
121
+
How you manage dependencies for your applications is relevant because it affects
122
+
their reliability and portability.
123
+
124
+
In the Java ecosystem, the two most used tools for
125
+
dependency management are Gradle and Maven. Both provide the functionality to
126
+
declare dependencies in a manifest and download them from a central repository.
127
+
The reason for listing all the dependencies your project needs is to ensure that you do
128
+
not depend on any implicit library leaking from the surrounding environment.
129
+
130
+
Both Gradle and Maven offer a feature to run the tool
131
+
from a wrapper script named gradlew or mvnw that you can include in your codebase.
132
+
For example, rather than running a Gradle command like gradle build (which
133
+
assumes you have Gradle installed on your machine), you can run ./gradlew build.
134
+
The script invokes the specific version of the build tool defined in the project. If the
135
+
build tool is not present yet, the wrapper script will download it first and then run the
136
+
command. Using the wrapper, you can ensure that all team members and automated
137
+
tools building the project use the same Gradle or Maven version. When you’re gener-
138
+
ating a new project from Spring Initializr, you’ll also get a wrapper script that’s ready
139
+
to use, so you don’t need to download or configure anything.
140
+
109
141
== 4 Design, build, release, run
110
142
111
143
A codebase goes through different stages in its journey from design to
@@ -206,14 +238,18 @@ username, and a password.
206
238
207
239
Environment parity is about keeping all your environments as similar as
208
240
possible. In reality, there are three gaps that this factor tries to
209
-
address: * Time gap—The period between a code change and its deployment
241
+
address:
242
+
243
+
* Time gap—The period between a code change and its deployment
210
244
can be quite large. The methodology strives to promote automation and
211
245
continuous deployment to reduce the period between when a developer
212
-
writes code to when it’s deployed in production. * People gap—Developers
246
+
writes code to when it’s deployed in production.
247
+
* People gap—Developers
213
248
build applications, and operators manage their deployment in production.
214
249
This gap can be resolved by embracing a DevOps culture, improving
215
250
collaboration between developers and operators, and embracing the "`you
216
-
build it, you run it`" philosophy. * Tools gap—One of the main
251
+
build it, you run it`" philosophy.
252
+
* Tools gap—One of the main
217
253
differences between environments is how backing services are handled.
218
254
For example, developers might use the H2 database in their local
219
255
environment but PostgreSQL in production. In general, the same type and
Copy file name to clipboardExpand all lines: modules/ROOT/pages/02-configuration/index.adoc
+31-1Lines changed: 31 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,12 +1,34 @@
1
1
= Configuration
2
2
:figures: 02-configuration
3
3
4
+
== Problem
4
5
Traditional applications were usually packaged as a bundle, including the
5
6
source code and a series of configuration files containing data for different environments, with the appropriate configuration being selected through a flag at runtime. The implication was that you had to make a new application build every time
6
7
you needed to update the configuration data for a specific environment. A variant of this process was to create a different build for each environment, meaning that you
7
8
had no guarantee whether what you ran in a staging environment would work the
8
9
same way in production because they were different artifacts.
9
10
11
+
With environment variables, you can externalize your application’s configuration
12
+
and follow the 15-Factor methodology. However, there are some issues they cannot
13
+
handle:
14
+
15
+
* Configuration data is as important as the application code, so it should be han-
16
+
dled with the same care and attention, starting from its persistence. Where
17
+
should you store configuration data?
18
+
Environment variables don’t provide granular access control features. How can
19
+
you control access to configuration data?
20
+
* Configuration data will evolve and require changes, just like application code.
21
+
How should you keep track of the revisions to configuration data? How should
22
+
you audit the configuration used in a release?
23
+
* After changing your configuration data, how can you make your application
24
+
read it at runtime without requiring a full restart?
25
+
* When the number of application instances increases, it can be challenging to
26
+
handle configuration in a distributed fashion for each instance. How can you
27
+
overcome such challenges?
28
+
* Neither Spring Boot properties nor environment variables support configuration
29
+
encryption, so you can’t safely store passwords. How should you manage secrets?
30
+
31
+
== Solution
10
32
Configuration is defined as everything likely to change between deployments (as per the 15-Factor methodology), like credentials, resource handles, and URLs to backing services. An application deployed in multiple locations will likely have different needs in each location and require different configurations. A key aspect of cloud native applications is that the application artifact will stay immutable across environments. No matter which environment you deploy it to, the application build will not be changed.
11
33
12
34
Each release you deploy is a combination of build and configuration. The same
@@ -34,6 +56,13 @@ sibly access control
34
56
* A server sitting on top of the data store to manage configuration data and serve
35
57
it to multiple applications
36
58
59
+
Imagine having many applications deployed in different environments. A configura-
60
+
tion server could manage configuration data for all of them from a centralized place,
61
+
and that configuration data might be stored in different ways. For example, you could
62
+
use a dedicated Git repository for storing non-sensitive data and use HashiCorp Vault
63
+
to store your secrets. No matter how the data is stored, a configuration server will
64
+
deliver it to different applications through a unified interface.
65
+
37
66
No matter how the configuration data is stored(i.e Git repository for storing non-sensitive data, HashiCorp Vault to store your secrets), a configuration server will deliver it to different applications through a unified interface.
38
67
39
68
image::{figures}/image-2.png[A centralized configuration server manages external properties for many applications across all environments.]
@@ -53,7 +82,8 @@ The three main strategies for defining configuration data for cloud native appli
53
82
| Characteristics
54
83
55
84
| Property files packaged with the application
56
-
| * These files can act as specifications of what configuration data the applica- tion supports. * These are useful for defining sensible default values, mainly oriented to the development environment.
85
+
| * These files can act as specifications of what configuration data the application supports.
86
+
* These are useful for defining sensible default values, mainly oriented to the development environment.
57
87
58
88
| Environment variables
59
89
| * Environment variables are supported by any operating system, so they are great for portability. * Most programming languages allow you access to the environment vari- ables. In Java you can access them with the System.getenv() method. In Spring you can also rely on the Environment abstraction. * These are useful for defining configuration data that depends on the infra- structure and platform where the application is deployed, such as active profiles, hostnames, service names, and port numbers.
0 commit comments