CAP Theorem and external configuration in microservices

 Hi friends,

In this post, I will explain about CAP Theorem and setting external configurations in microservices.

Question 1:

What is CAP Theorem?

Answer:

• Consistency — A guarantee that every node in a distributed cluster returns the same, most recent, successful write. Consistency refers to every client having the same view of the data. There are various types of consistency models. Consistency in CAP (used to prove the theorem) refers to linearizability or sequential consistency, a very strong form of consistency.

• Availability — Every non-failing node returns a response for all read and write requests in a reasonable amount of time. The key word here is every. To be available, every node on (either side of a network partition) must be able to respond in a reasonable amount of time.

• Partition Tolerant — The system continues to function and upholds its consistency guarantees in spite of network partitions. Network partitions are a fact of life. Distributed systems guaranteeing partition tolerance can gracefully recover from partitions once the partition heals.

The C and A in ACID represent different concepts than C and A in the CAP theorem.

The CAP theorem categorizes systems into three categories:

• CP (Consistent and Partition Tolerant) — At first glance, the CP category is confusing, i.e., a system that is consistent and partition tolerant but never available. CP is referring to a category of systems where availability is sacrificed only in the case of a network partition.

• CA (Consistent and Available) — CA systems are consistent and available systems in the absence of any network partition. Often a single node's DB servers are categorized as CA systems. Single node DB servers do not need to deal with partition tolerance and are thus considered CA systems. The only hole in this theory is that single node DB systems are not a network of shared data systems and thus do not fall under the preview of CAP. 

• AP (Available and Partition Tolerant) — These are systems that are available and partition tolerant but cannot guarantee consistency.

 

Question 2:

How to do externalized configuration in microservices?

Answer:

Why do we need this?

With microservices, applications are split into several services (microservices), each one usually running in a separate process. Each process can be deployed and scaled independently, meaning that there may be several replicas of the a microservice running at a certain time.

Let’s say we want to modify the configuration for a microservice that has been replicated a hundred times (one hundred processes are running). If the configuration for this microservice is packaged with the microservice itself, we’ll have to redeploy each of the one hundred instances. This can result in some instances using the old configuration, and some using the new one. 

Moreover, sometimes microservices use external connections which, for example, require URLs, usernames, and passwords. If you want to update these settings, it would be useful to have this configuration shared across services.

 

How does it work?

Externalized configuration works by keeping the configuration information in an external store, such as a database, file system, or environment variables. At startup, microservices load the configuration from the external store. During runtime, microservices provide an option to reload the configuration without having to restart the service.

 

 

Implementing a configuration server with Spring Cloud Config

There are many ways to implement externalized configuration. Netflix’s Archaius and Spring Cloud offer ready-to-use and well-tested solutions. Cloud services and platforms such as AWS and Kubernetes offer similar services, as well. The demo application uses Spring Cloud Config which includes both the server and the client part of the equation.

Use the Spring Initializr to create a new Spring Boot application named config-server and include the Eureka Discovery, Config Server, Actuator (optional), and Config Server dependencies:

 

Open up the ConfigServerApplication class and activate the discovery client and the configuration server by using the following annotations:

@SpringBootApplication

@EnableConfigServer

@EnableDiscoveryClient

public class ConfigServerApplication {

   ...

 

}

Remove the application.properties file and create a new application.yml file with the following content

server.port: 8101

spring:

  application.name: config-server

  cloud.config:

    server.git:

      uri: https://github.com/alejandro-du/vaadin-microservices-demo-config.git

      default-label: master

eureka:

  client:

    serviceUrl:

      defaultZone: http://localhost:8001/eureka/

    registryFetchIntervalSeconds: 1

  instance:

    leaseRenewalIntervalInSeconds: 1

 

}

 

 

That's all for this post.

Thanks for reading!!