Observability Done Right: Best Practices and Anti-Patterns for Effective System Monitoring

-
Image
  WHAT Observability is a concept that refers to the ability to gain insights into the behavior and performance of complex systems. In the context of software engineering, observability involves the collection, analysis, and visualization of data from software applications, infrastructure, and other components of a system. In the animal kingdom, observability plays a critical role in survival, allowing animals to monitor their surroundings, detect threats, and find food. Dolphins use echolocation to observe their surroundings. They emit high-frequency sounds that bounce off objects, allowing them to create a 3D map of their environment. Thanks for reading Knowledge Cafe! Subscribe for free to receive new posts and support my work. Subscribed WHY In today's era, architectures are becoming increasingly large, complex, and fast-paced due to the faster development and deployment of software by distributed teams with the help of DevOps, continuous delivery, and agile development methodo...

Container Patterns

-

 

Why we need Container Patterns:

Due to popularity of microservices and distributed computing, containerization has become a major trend in software development. It involves encapsulating or packaging software code and all its dependencies so that it can run uniformly and consistently on any infrastructure. 

In distributed architecture which consists of many microservices, we want our microservices business focused and keep non functional aspects like security, service discovery, proxy, logging and platform configuration etc out of our microservices code, container patterns evolved. 

There are 2 popular patterns:

  1. Sidecar
  2. Ambassadors

Sidecar pattern: 

In this pattern, we schedule a workload on the same hosts which is intended for specific things that don’t concern your application. There are various use cases for sidecar patterns like request authentication/authorization, service discovery, adding HTTPS to legacy service. 

Usecase: We will discuss here example of updating static website content on webserver without rebuilding docker image in kubernetes cluster.



Kubernetes pod supports multiple containers with shared volumes. We are going to make use of this concept to accomplish our requirement. That is, we would be creating a separate container called sidecar which is responsible for downloading the latest content from repository periodically or on demand based on configuration. Once it is downloaded, it will place the new content for the application server container to access in the shared volume and all our clients will be able to see latest contents without rebuilding container image. 

Ambassadors:

An ambassador container brokers interactions between the application container and the rest of the world. As with other single-node patterns, the two containers are tightly linked in a symbiotic pairing. It transfers the responsibility to distribute the network load, retries, or monitoring to something else. Here the containers are coupled means without ambassador pattern, the application cannot contact the outside world. This is the pattern you'd use when you want microservices to interact with one another. They don't know exactly where other microservices are; they just know they can find them by name. And for that, they need a service discovery. This discovery could be at the DNS level, or it could be at an application level.



Usecase: Lets assume we have one database server which is not able to handle the application load. We want to shard the data but without changing application. 

Sharding splits up the data into multiple disjoint pieces, each hosted by a separate machine. One approach is to build all of the sharding logic into the sharded service itself. In this approach, the sharded service also has a stateless load balancer that directs traffic to the appropriate shard. Effectively this load balancer is a distributed ambassador as a service. The alternative is to integrate a single-node ambassador on the client side to route traffic to the appropriate shard. We can introduce an ambassador container that contains all of the logic needed to route requests to the appropriate storage shard. Thus, your front end or middleware application only connects to what appears to be a single storage backend running on localhost.


Another interesting applications of an ambassador-type container is in the deployment architecture called Canary: let’s imagine we want to test the deployment of a new version of our microservice, transferring only a small percentage of the total requests. This deployment mode can be managed with a container ambassador who rotates the desired percentage of traffic to the new container.


In nutshell, Whether it is to extend the functionality of our microservices or to mediate access to a service on which it depends, the most suitable solution is to introduce a dedicated, business logic independent and reusable container. There are lots of different use cases and implementation pattern available when working with microservice architecture, we need to choose wisely whatever is suitable to our use case.  

Popular posts from this blog

Chain of responsibility using Spring @Autowired List

-
Image
There is a way in Spring 3.1 to auto populate a typed List which is very handy when you want to push a bit the decoupling and the cleaning in your code. To show you how it works, I will implement a simple chain of responsibility that will take care of printing some greetings for a passed User. Let start from the (only) domain class we have, the User: package in.softcaretech.springchain; public class User { private final String name; private final char gender; public User(String name, char gender) { super(); this.name = name; this.gender = gender; } public String getName() { return name; } public char getGender() { return gender; } } Then we create an interface that defines the type for our command objects to be used in our chain: package in.softcaretech.springchain; public interface Printer { void print(User user); } This is the generic class (the template) for a Printer implementation. The  org.springframework.core.Ordered  is used to tell the AnnotationAwareOrderCo...
Explore more »

Iterate Through a HashMap

-
The  HashMap  is one of the most useful data structures in the Java programming language. Once you have a HashMap filled with data, you may want to iterate through its keys and values. Below are three different ways to iterate through a Java HashMap. Sample HashMap Here is our sample HashMap. The key is an Integer and the value is a String: HashMap <Integer, String> hm = new HashMap<Integer, String>(); hm.put(0, "zero"); hm.put(1, "one"); hm.put(2, "two"); In the above Java code, we first declare the HashMap. Then we add the values "zero", "one" and "two" with the keys 0, 1 and 2 respectively. Now that the HashMap has data, we can try to iterate over the keys and values. Iteration Example 1 for (int i=0; i < hm.size(); i++) { Integer key = hm.keySet().toArray()[i]; String val = hm.values().toArray()[i]; System.out.println("key,val: " + key + "," + val); } In this example, we use a  for  loop ...
Explore more »

Under the Hood: Understanding the Gossip Protocol in Apache Cassandra

-
Image
  Gossip Protocol Apache Cassandra is a highly scalable and distributed NoSQL database management system designed to handle large amounts of data across many commodity servers. It was developed at Facebook and later became an Apache Software Foundation project. Cassandra offers a number of key features, including: Linear scalability, high availability, Predictive data consistency, flexible data modeling and high performance. What is Gossip Protocol The Gossip protocol is a key component of the Apache Cassandra distributed database system. It is used for node communication and failure detection within the cluster. The following is how it works: Each node in the Cassandra cluster maintains a list of all other nodes in the cluster and information about their status. The Gossip protocol operates in rounds, where each node sends its state information to a randomly selected set of other nodes. The receiving nodes update their state information based on the information received from their...
Explore more »