Blogs

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. ...

The Circuit Breaker pattern is a cornerstone of resilient systems, preventing a single component’s failure from causing a catastrophic system-wide outage. This deep dive explores its mechanics, the strategic benefits beyond simple failure handling, the nuances of configuration, and its crucial role in the modern microservices ecosystem.

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. ...

The Bulkhead pattern is a critical resilience strategy that prevents failures in one part of a system from cascading into a catastrophic, system-wide outage. By partitioning resources, it ensures that one misbehaving dependency cannot exhaust the resources needed to serve others, thereby protecting the overall health of your application.

Representing dates in an API is a common but often not well thought out functionality.We need to be very cognizant of representing dates, intervals, and periods in the API Payload. There are two generally accepted date formats for API’s.

JSON Web Token(JWT) is an industry standard for security tokens used to securely transmit information between client and server as JSON objects.It provides a solution to the problem of passing claims between parties. In this post we will create an Angular interceptor to introspect JWT tokens.

Creating API’s has a certain rigor to it right from the design phase which is different from a UI based Web application. One of the areas where this is very apparent is communicating exceptions to the client. In a web application exception are communicated to the client using the UI with the most common being a 404 page. This page has been elevated to an art form now. The image below is a 404 page on Pixar’s website. ...

OpenID Connect is a simple identity layer built on top of the OAuth 2.0 protocol. OpenID Connect is all about authentication while OAuth is an authorization protocol. In OAuth, authorization is delegated while in OpenID Connect, authentication is delegated. OpenID Connect allows clients to verify end users based on the authentication performed by an auth server. It is also used to obtain basic profile information about the end user in a standards-based, interoperable and REST-like manner. OpenID Connect provides a standard way to obtain user identity.A central part of the OpenID Connect specification is the ID Token. It provides an identity token with information about the user. It also defines an endpoint to get identity information for that user, such as their name or e-mail address. This endpoint is called the user info endpoint. The identity token is a simple JWT token signed by the OpenID provider(OP) through OAuth protocol to suit web, mobile, and browser-based applications.The Identity token is encoded into the base 64 URL-safe string that contains information such as subject (sub), issuing authority (iss), audience (aud), and more. It may also contain some extra information about the user or custom claims in a set of scopes. As OpenID Connect is built on top of the Oauth2 protocol, the flows are the same. It can be used with the authorization code grant and the implicit grant. It’s not possible with the client credentials grant, as the client credentials grant is for server-to-server communication.As part of the oAuth flow, Instead of only requesting an access token, we can request an additional ID token from the security token service (STS) that implements the OpenID Connect specification. The client receives an ID token, and usually, also an access token. The ID token is kept small with the minimal information in it. To get more information for the authenticated user, the client can then send a request to the user info endpoint with the access token. This user info endpoint will then return the claims about the new user. ...