Dependency Tree in Maven

Dependency management is a core feature of Maven. Managing dependencies for a single project is easy.

Managing dependencies for multi-module projects and applications that consist of hundreds of modules is possible.

Maven avoids the need to discover and specify the libraries that your own dependencies require by including transitive dependencies automatically.

This feature is facilitated by reading the project files of your dependencies from the remote repositories specified.

In general, all dependencies of those projects are used in your project, as are any that the project inherits from its parents, or from its dependencies, and so on.

A project's dependency tree can be filtered to locate specific dependencies.

Maven is powered with Dependency plugin by default.With this plugin, we can have a better understanding and control over the list of dependencies used in a specific project.The plugin comes with several goals.

mvn dependency:tree  is the Command

The main purpose of the dependency:tree goal is to display in form of a tree view all the dependencies of a given project.

Contract Testing

 Contract testing is a methodology for ensuring that two separate systems (such as two microservices) are  compatible and are able to communicate with one other.

 It captures the interactions that are exchanged between each service, storing them in a contract, which can then be used to verify that both parties adhere to it.

Contract testing goes beyond schema testing, requiring both parties to come to a consensus on the allowed set of interactions and allowing for evolution over time.

Pact is a code-first consumer-driven contract testing tool, and is generally used by developers and testers who code. The contract is generated during the execution of the automated consumer tests.

A major advantage of this pattern is that only parts of the communication that are actually used by the consumer(s) get tested. 

This in turn means that any provider behaviour not used by current consumers is free to change without breaking tests.

Keycloak

 Keycloak is an open source Identity and Access Management solution targeted towards modern applications and services.

Keycloak offers features such as Single-Sign-On (SSO), Identity Brokering and Social Login, User Federation, Client Adapters, an Admin Console, and an Account Management Console.

Below are keycloak features:

1)Multiple protocols support

2)SSO support

3)Offers Web based GUI

4)External Identity Source Sync

In case when your client currently has some type of user database, Keycloak allows us to synchronize with such database. By default, it supports LDAP and Active Directory but you can create custom extensions for any user database using Keycloak User storage API.

4)Identity Brokering

Keycloak can also work as a proxy between your users and some external identity provider or providers. Their list can be edited from Keycloak Admin Panel.

5)Social Identity Providers

Additionally, Keycloak allows us to use Social Identity Providers. It has built-in support Google, Twitter, Facebook, Stack Overflow but, in the end, you have to configure all of them manually from admin panel. 

6)Customizations

Currently  Keycloak supports following distributions.

1)server

2)Docker Image

3)Operator

Link: https://www.keycloak.org/

Install and Use Gremlin in a Docker Container

Gremlin is a simple, safe and secure way to use Chaos Engineering to improve system resilience. You can use Gremlin with Docker in a variety of ways.

It is possible to attack Docker containers and it is also possible to run Gremlin in a container to create attacks against the host or other containers.

• Create a Gremlin account: https://www.gremlin.com/demo/

• Login to the Gremlin App using your Company name and sign-on

credentials.

• Identify “TeamID” and “Secret Key” by navigating to

Settings>>TeamSettings>>Configuration

• Issue below command to in docker to pull the official Gremlin Docker image

and run the Gremlin daemon.

docker run -d --net=host \

--cap-add=NET_ADMIN --cap-add=SYS_BOOT --cap-add=SYS_TIME \

--cap-add=KILL \

-v $PWD/var/lib/gremlin:/var/lib/gremlin \

-v $PWD/var/log/gremlin:/var/log/gremlin \

-v /var/run/docker.sock:/var/run/docker.sock \

-e GREMLIN_TEAM_ID="$GREMLIN_TEAM_ID" \

-e GREMLIN_TEAM_SECRET="$GREMLIN_TEAM_SECRET" \

gremlin/gremlin daemon

• Use docker ps to see all running Docker containers:

       sudo docker ps

• Jump into your Gremlin container with an interactive shell

     sudo docker exec -it <gremlin container_id> echo “Running”

• From within the container, check out the available attack types:

      gremlin help attack-container

Suite of Chaos tools for AWS

 Chaos Monkey is a software tool that was developed by Netflix engineers to test the resiliency and recoverability of their Amazon Web Services (AWS). 

The software simulates failures of instances of services running within Auto Scaling Groups (ASG) by shutting down one or more of the virtual machines.

Chaos Monkey works on the principle that the best way to avoid major failures is to fail constantly.

Chaos Monkey is not alone in the army. Since it was developed and its popularity rose, a whole suite of Chaos tools has been developed to simulate outages and test system response times.

Chaos engineers now have the Simian Army to work with and Chaos Monkey falls in ranks with:

• Chaos Kong drops a whole AWS Region.
• Chaos Gorilla drops a whole AWS Availability Zone.
• Latency Monkey simulates network outages or delays.
• Doctor Monkey performs health checks.
• Janitor Monkey identifies unused resources.
• Conformity Monkey identifies non-conforming instances based on a set of rules.
• Security Monkey tests for known vulnerabilities. End of life in 2020, with alternatives available.
• 10-18 Monkey detects configuration and run-time problems in instances serving customers in multiple geographic regions.

Spring Retry

Spring Retry provides the ability to automatically re-invoke a failed operation. This is helpful when errors may be transient in nature (like a momentary network glitch). Spring Retry provides a declarative control of the process and policy-based behavior that is easy to extend and customize.

To make processing more robust and less prone to failure, it sometimes helps to automatically retry a failed operation in case it might succeed on a subsequent attempt. Errors that are susceptible to intermittent failure are often transient in nature.

Retry should be tried only if you think that it may meet your requirements.

• You should not use it for each use case. This is something you don't build right from the beginning but based on what you learn during development or testing. For example, you might find while testing that when you hit a resource, it works one time, but the next time, it gives a timeout error, then works fine when hit again.
•  After checking with the downstream system, you're not able to find out any root cause or solution. You might want to build a Retry feature to handle your application's side, but the first attempt should be to fix the downstream side. 
• Retry may cause resource clogging and make things even worse, preventing the application from recovering; therefore, the number of retries has to be limited. 
• Retry should not be done for each exception. It should be coded only for a particular type of exception. For example, instead of putting code around Exception.class, do it for SQLException.class.
• Retry can cause multiple threads trying to access the same shared resource and locking can be a big issue. An exponential backoff algorithm has to be applied to continually increase the delay between retries until you reach the maximum limit.
• While applying Retry, idempotency has to be handled. Triggering the same request again should not trigger a duplicate transaction in the system.

Enable Retry:

Put the @EnableRetry annotation in the SpringBoot main class.

@EnableRetry

@SpringBootApplication

public class Demo {

 public static void main(String[] args) {

  SpringApplication.run(DemoApplication.class, args);

 }

}