Mariusz Krzanowski blog

Category: Reliability

TCP limits that can break your Kubernetes cluster

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.

When retry never succeeds

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.

When aborted equals committed

The traditional SQL databases are used by developers as a fully safe storage. The ACID properties are intuitive for us and give us a sense of safety during application development. We know that if during a database transaction a network error occurred and we received an exception, the whole transaction would be rolled back as atomic part of process. To avoid network issues we can retry the operation later and it should solve the problem. It is true in most cases, but there is one when it is not so easy. Let me drill down this subject.

Powered by WordPress & Theme by Anders Norén