april: A Go repository from barbosaigor

Chaos Testing tool

April proposes to improve resilience in microservices architectures. It does chaos testing by randomly shutting down services, taking into account their importance.
April is similar to other tools, such as Chaos Monkey, Pumba, and Gremlin. But it differs by the selection algorithm, which considers services importances (weights). The selection algorithm firstly picks K services, then it picks N dependencies on those services. Heavy services are more likely to be picked.
A Chaos Server must be running to terminate instances, for that, we already have a Docker and Kubernetes Chaos Servers implementations. Though, due to April's design, a Chaos Server could easily do anything, such as terminating VMs, overloading a server, turning off a service network, or even destroying the world (this is very dangerous).

Why should I use April?

In a microservice architecture, we want to make sure that all services are fault-tolerant, primarily critical services.
The main goal of April is to direct your team energy to critical microservices, without losing the randomness needed to simulate unexpected failures in production.
So if we want to test if a service is fault-tolerant, we should nudge its dependencies by terminating some of them. That is what April is about, it terminates services dependencies.

Installation

go get -u github.com/barbosaigor/april/...

Design approach

April's design is split into two parts: April CLI and Chaos Server (CS). April CLI runs the algorithm and requests to Chaos Server to terminate instances. Therefore, we gain flexibility about technologies that manage instances. A Chaos server could terminate Docker containers, Kubernetes instances, and so on.

(Architecture) Eg. A Chaos Server implementation using any technology, such as containerization or orchestration

What is a Chaos Server ?

Chaos server hosts an API which terminates instances. It is used by April, which runs its algorithm and asks the Chaos Server to finish any selected instances. All Chaos Servers implementations must implement the interface defined in april/chaosserver package, so CSs must include that package and implement the ChaosServer interface, where the business logic to terminate instances should be defined.

Chaos Servers

Docker chaos server stop containers dockercs.
(Under development) Kubernetes chaos server terminates pods kubernetescs, in future it may terminate deployments and services.

Tools

Chaos test. Need a running 'chaos server' to terminate instances.
-f configuraion file path (Default is conf.yml)
-n maximum number of services to choose
-c chaos server endpoint (Default is localhost:7071)
-u username for chaos server auth
-s password for chaos server auth

april -f conf.yml -n 10 -u bob -s mysecret

Bare runs only the selection algorithm, returning a set of services.
-f configuraion file path
-n maximum number of services to choose

april bare -f conf.yml -n 10

Server hosts an API (HTTP) which apply chaos testing and bare algorithm. Need a running 'chaos server' to terminate instances.
-p port number (Default is 7070)
-c chaos server endpoint (Default is localhost:7071)

april server -p 8080  // will listen on port 8080

Configuration file

Fields
version: could be omitted, default is 1
services: describes a list of services
servicename: is the name of a service that April is going to work
weight: represents the service importance for the April pick algorithm
depedencies: describe a list of services which the service depends
selector: describe how Chaos Server must search for the service name, default is Infix.
E.g If you are using Docker containers and a framework such as Docker Compose, Compose will define the container name as a concatenation between your service name and a hash somewhere, in this case, it is better to look for the infix corresponding to the service.

# template
version: 1
services:
    servicename:
        weight: [0-9]+ (any natural number)
        dependencies:
            - [a-zA-Z\_\-]* (dependency name)
        selector: prefix|infix|postfix|exact (how should match the service name instance)

Example: ecommerce-conf.yaml

version: 1
services:
  payment:
    weight: 10
    dependencies:
      - profile
      - fees
    selector: postfix  

  fees:
    weight: 5

  profile:
    weight: 20

  inventory:
    weight: 15
    selector: exact  

  shipping:
    weight: 5
    dependencies:
      - inventory
      - profile

  storefront:
    weight: 20
    dependencies:
      - shipping
      - inventory
      - profile
      - payment
      - fees

# bare will just execute the algorithm, without calling CS
$ april bare -n 3 -f ecommerce-conf.yaml
> Selected Services:  [profile fees payment]