Reliability – Decoding the code

Introduction

Microservices solutions are more and more popular. Docker, Kubernetes are more and more popular, even the hardest opponents start to give up. Unfortunately we – Software Developers – usually do not like to focus on network protocols. That ignorance can sometimes be a blessing, but sometimes can hit us hard in the most painful time. In this article I want to focus on the Transmission Control Protocol protocol limits of source and destination ports size and why it can be painful for us.

Introduction

Software development is a craftsmanship in which we are trying to satisfy clients’ needs. Resiliency is one of those needs. We are aware that sometimes database connection can fail or we can have other transient errors like being chosen as a deadlock victim. In case of transient errors a good practice is to retry a failed process, to try to succeed in the next try. In .NET world many developers use e.g. Polly https://github.com/App-vNext/Polly to add a retry policy for chosen methods.

Problem with IoC and Scoped Lifecycle

A bug we found a few months ago in the legacy code has proven that developers usually are focused on success scenarios and do not spend a lot of time on failure analysis in advance.

Mariusz Krzanowski blog

Tag: Reliability

TCP limits that can break your Kubernetes cluster

Introduction

When retry never succeeds

Introduction

Problem with IoC and Scoped Lifecycle