Blogs

Event driven architecture (EDA) is an architectural paradigm where behavior is composed by reacting to events. In this paradigm events imply a significant change in state.

A single container provides application isolation and mobility. However, a container by itself doesn’t improve the quality of your service—for example, in terms of load balancing or failover. This is where multi-container solutions come into play. However managing a handful of containers is completely different from managing production-scale containers, which may number from hundreds to thousands. To support container management, we need an easy way of deploying and handling these containers at scale. This is where container orchestration. comes into play. ...

An API Gateway provides a single and unified API entry point across one or more internal APIs. It mediates, routes, and invokes a respective endpoint after request verification, content filtering, authentication, and authorization.

Controllers create and manage pods. Controllers respond to pod state and health. Kubernetes lets you assert that resources such as pods are in a certain desired state, with specific versions. Controllers track those resources and attempt to run your software as described. There are a variety of controllers in Kubernetes, primarily ReplicaSets and Deployments. ReplicaSet - A ReplicaSet is responsible for reconciling the desired state at all times. The ReplicaSet is used to define and manage a collection of identical pods that are running on different cluster nodes. A ReplicaSet defines the image are used by the containers in the pod and the number of instances of the pod that will run in the cluster. These properties and the many others are called the desired state. If some Pods in the ReplicaSet crash and terminate, the system will recreate Pods with the original configurations on healthy nodes automatically and keep a certain number of processes continuously running. For e.g if you specified three Pods in a ReplicaSet and one fails, Kubernetes will automatically schedule and run another Pod for you. If elementary conditions are met (for example, enough memory and CPU), Pods associated with a ReplicaSet are guaranteed to run. They provide fault-tolerance, high availability, and self-healing capabilities. ...

Pods are an important feature of Kubernetes. A Pod is the smallest unit of work that Kubernetes manages and is the fundamental unit that the rest of the system is built on. Each pod contains one or more containers. Instead of deploying containers individually, you always deploy and operate on a pod of containers. Pods are always scheduled together (always run on the same machine). A pod is as an atomic unit. Even if a pod does contain multiple containers, they are always run on a single worker node, it never spans multiple worker nodes. All the containers in a pod have the same IP address and port space. They communicate using localhost or standard inter-process communication. All containers in a pod have access to shared local storage on the node hosting the pod. This shared storage is mounted on each container. Pods provide a great solution for managing groups of closely related containers that depend on each other and need to co-operate on the same host to accomplish their purpose. Pods are considered as ephemeral, throwaway entities that can be discarded and replaced at will. Any pod storage is destroyed with its pod. Each pod gets a unique ID (UID), so you can still distinguish between them if necessary. ...

Circuit breakers help to avoid one failing component tearing down other dependent services in a domino effect. The key idea is for a service to fail fast if a dependent resource is not available, as opposed to waiting for a timeout/error for each service invocation during the period in which the dependent resource is down.

The Reactive Manifesto describes how to design and architect Reactive systems according to your needs.Systems built as Reactive Systems are more Reliable, flexible, loosely coupled, scalable and resilient. This makes them easier to develop and amenable to change. Reactive systems are more tolerant of failure and when failure does occur, they meet it with elegance rather than disaster.

I have been working with multiple teams on containerizing their infrastructure using docker. A while back I needed to help a team understand Docker containers by getting them to dive in and get started rather than just talk and point to slide decks. We started by containerizing the simplest possible .net core console app. The first app we built was a simple console app that used a timer and printed the date and time every 2 seconds. The code and the output for this program is below ...

The retry pattern is an extremely important pattern to make applications and services more resilient to transient failures. A transient failure is a common type of failure in a cloud-based distributed architecture. This is often due to the nature of the network itself (loss of connectivity, timeout on requests, and so on). Transient faults occur when services are hosted separately and communicate over the wire, most likely over a HTTP protocol. These faults are expected to be short-lived. Repeating such a request that has previously failed could succeed on a subsequent attempt. ...

Bulkhead Isolation pattern is used to make sure that all our services work independently of each other and failure in one will not create a failure in another service. Techniques such as single-responsibility pattern, asynchronous-communication pattern, Circuit Breaker and Retry pattern help achieve the goal of stopping a failure propagating throughout the whole application. To implement this pattern, all our services need to work independently of each other and failure in one should not create a failure in another service. We also need to partition the overall system into a few isolated groups, so that any failure in one partition does not percolate to others. Containerization and microservices are an option for having partitioned and isolated systems. ...