Resilience as an architectural characteristic (Continuous Architecture in Practice)

I have mentioned several times the book "Continuous Architecture in Practice" as a worthwhile work on architecture. (posts: 1 and 2). Today I decided to share a brief sammmari on how authors approach the sustainability and reliability of systems. First, authors are defined with terminology.

• A fault is an accidental condition that, if encountered, may cause the system or a system component to fail to perform as required.
• A failure is when a system or system component deviates from its required behavior. So, a fault is something that has gone wrong and that may cause a failure to occur.
• Availability is a measurable quality attribute of a system, defined as the ratio of the time when the system is available to the overall time when it could have been available.
• Reliability builds on availability and adds the constraint of correct operation, not just availability. A widely used definition of the reliability of software is “the probability of failure-free software operation for a specified period of time in a specified environment.”

Next, the authors talk about the old approach to reliability, which was usually called high-availability It was based on the creation of application clusters, database clusters, the use of cross-site data replication. The essence of the approach was that in case of problems with one of the nodes in the cluster, the workload could move to another node. And if the cluster fell as a whole, it was possible to transfer the load to another cluster, which was always ready. (hot standby)which was already all (majority) Data replication through data replication. And everything would be fine with this approach, convenient for application developers, but These accessibility mechanisms are confusing and difficult to use.

• They're often quite expensive. (Even in terms of working idle hot standby) Failover processes can take a lot of time and require a lot of work During recovery, the system may be completely unavailable. In general, these high-availability approaches have been designed for monolithic on-premise systems and are poorly suited for distributed microservice systems that can be deployed both on-premise and in the cloud.

The authors then proceed to resilience It is another way to ensure reliability. In this approach, each part of the system is responsible for its own contribution to system-wide availability by adapting its behavior to ongoing faults, for example, recognizing failures and using repeated requests, automatically restarting processes, limiting the spread of error, correctly working with latency requests. As a result, engineers should know and use such reliability mechanisms, rather than relying on high-availability technologies from the past. If used correctly, the resulting system will be more resistant to errors and failures and will be able to adapt more flexibly to problems during operation.

It is interesting to consider these approaches in the context of standard indicators.

• Mean time between failures (MTBF) - average failure time
• Mean time to recover (MTTR) - average recovery time

In the high-availability approach, we assumed that the time between failures is long and when a failure does occur, we simply use high-availability mechanisms. And that was once a good approach. But in the current environment, failures of parts of systems can occur quite often, and here comes the MTTR and the ability of these parts of the system to limit the blast radius problems and not affect the overall reliability of the entire system.

#SRE #Software #SoftwareDevelopment #Architecture #SoftwareArchitecture #SystemDesign #SystemThinking