12 factors: Stateless process

 Keep your microservices stateless so that it can utilize cloud native benefits (such as scaling)

Characteristics:

• The process running in the environment should be stateless. 
• Should not share anything with other process. 
• No sticky sessions

What should do or don’t do. 

• Don’t store any data in a local file system. 
• Sessions: 
• Store your sessions if any in a distributed session storage db, such as Redis. 
• No sticky sessions. 
• Create stateless services. 

12 factors: Build - release - run

 Summary: 

Build: Application code gets converted into an artifact such as a war file. 

Release: the artifact now understands the environment - QA, Dev, Prod

Run: the app gets released in the specific environment. 

Characteristics

• Strict separation between the build, release and run stages of the application. 
• Every release must have a release id such as a timestamp or a incrementing number
• 1-click release - using CI/CD tool. 

What should you do: 

• Use a CI/CD tool, Jenkins, Concourse etc.,

Best Practices:

• Create smoke tests to ensure the app is running fine after deployment. 

12-factor (Externalize configurations)

Externalizing configurations (keeping env configs) out of source so that it follows build once deploy anywhere approach. 

 Motivation: 

• How do we manage properties: application.properties, application.yml, system.properties, 
• environment variables export SERVER_PORT=8080 
• passing via command line: -Dserver.port=8080
• variables specific to env and why you should not have in local source. - server.port

What is Cloud Config server: 

Its a way by which we can externalize the property values by moving out of the project. Primarily kept for properties that you normally override or keep secret values out of the project src. 

Motivation:

• Externalize config data from the applications across all environments. 
• Store crucial information such as password for DB in a centralized place. 
• Share data between different services. 
• See who changed which property and when and why. 

What should you do to use Spring cloud config

1. Application configuration: 
• Manage app configuration in a git hub or a local file system. 
2. Config server
• Point the location of GIT or local file system where the app config is located (i.e., GIT URI)
• @EnableConfigServer
3. Config client
• Use it normally as how you would read from the properties file 
• @Value or 

Features

• Many storage options including Git, Subversion. 
• Pull model
• Traceability
• @RefreshScope for allowing properties to refresh. Calls the constructor of the beans and reinitializes it. 
• @ConfigurationProperties alternate for @RefreshScope which does reinitialize the Bean that is annotated with @ConfigurationProperties. 
• Encrypt and decrypt property values. 

Usecases for Cloud config: 

• Change log level in the properties. 
• Environment config - containing passwords. 
• Toggle a feature on or off. 
• Using @RefreshScope
• @ConfigurationProperties. 

Order in which the Cloud config looks into the properties files. 

• Config server. 
• Command line parameters
• System properties.
• Classpath: application.yml file
• Classpath: bootstrap.yml

Things that you can try: 

• Simple example to demonstrate properties in Git and reading from config server and client 
• Using maven profiles specific properties in Config server in Github. 
• Managing log levels in the Config server
• Using @RefreshScope and @CofigurationProperties. 

Best practices: 

• Config server communication with the Git hub, pull every time when client requests for properties file. Use a Jenkins job which will push the properties to a Config server properties (clone). 
• Single repository for all teams, subdirectories for different environments. 
• Source code maintenance, having branch per release vs always using the master. 
• Managing encrypted values for secure data, using JWT with Config server.
• Use Spring cloud bus to refresh all the services which listens to the rabbitmq.

Note: 

• Store only things that need to be externalized, I.e., Resource bundles for internationalization should be at the project level. 

Questions: 

• How do I refresh all the instances of a service when a configuration is changed. 
• Manage different repositories for dev and prod. 
• What should I do so that I don’t have to say refresh in every services. 
• What is encrypt and decrypt endpoints in Config server. 
• Real time example of how the config properties look like, how do they maintain. 
• What is the difference between Spring cloud an dSpring cloud services in maven.