The Pensieve - Masoud Kalali's Blog

My personla blog where I share notes and thoughts about software technology landscape. Covering subjects ranging from tech strategy, leadership, software architecture, cloud native, and software development in general.

Solve the Right Problem at the Right Level

This is one of the common principles that not only software developers are adhering to, but also the whole of civilization is attempting to adhere to. But it is sometimes not as easy as it may sound to figure out the right problem, and, more importantly, what is the right level. A simple example is a pull request fixing a small bug that should not be blocked because of an architectural decision made a year ago and has about 5 engineer years’ worth of work built around it.

Microservices Runtime Fragmentation

Fragmentation of Java runtimes in a microservices-based architecture There are many many differences between the monolithic architecture and microservices-based architecture. One of them is the number of independently deployed bits of software, with a monolith there are usually many replicas of the same distribution running on many machines, virtualized or not. With the Microservices the number of independently deployed software systems grows as the different contexts raise… or an already existing context boundary grows enough to be split.

Kubernetes Active Active Clusters and Application Fault Tolerance

From Monolith to Microservices Having redundancy in application space is pretty common. We have all seen them for decades in different ways. Hardware, software layer 4, or layer 7, etc. All of them what they do they direct traffic based on a given decision-making rule to a destination. Being weighted round-robin, resource/load-based metrics, etc. All they do is reliably direct traffic to a healthy node in the destination. In a very simple and basic view with VMs and data centers, if VMs fail the load balancer will direct loads to identical VMs, all nodes more or less can handle any of the incoming requests (ignoring stickiness, etc.

How to plan the architectural attributes?

Last week I was talking to a former colleague, he is running a SaaS startup now, and our conversation went around SRE, production, and reliability. We talked a lot about architectural attributes that relate or impact the incidents, from detection to recovery, and on to prevention. I thought to put some of my thoughts around architecture into a blog post since that was the core of our conversation. The next post I will cover more details on architecture for fault tolerance.

Why not task based teams?

What I have learned about successful teams is the trust and the belief in the team’s mission. Trust in the mission, baring some issues like ill-fitting team members, etc. is the single most important factor for success of an individual, a team or a team of teams. When the group of individuals that are part of the said team cannot see a mission they trust, going through the famous steps of Forming, Storming, Norming, and Performing will be harder.

Smooth Developer Onboarding is as Important as Code Readability

When a new hire joins a team dealing with the development or sustaining of a large-scale application there are a few things that they would need to form a basic understanding of the system: Deeper understanding of what the business about Get a view of the system’s architecture for the software system and the deployment view. Get a bird’s eye view of the system’s dependencies. At least the immediate dependencies. History lessons, how the system came to be at the current state.