AJR/TechradarDev
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Updates timo (#99)

Browse Source 
[update] Move "Resilient Thinking" and "Dependency Update Scan" to adopt
This commit is contained in:
Timo Fuchs
2022-09-06 13:57:33 +02:00
committed by GitHub
parent fe32442bd5
commit 1be851fee9
2 changed files with 30 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
radar/2022-03-28/dependency-update-scan.md Normal file
View File

@@ -0,0 +1,12 @@
---
title: "Dependency Update Scan"
ring: adopt
quadrant: methods-and-patterns
---
Tools for automated dependency updates continue to offer a big productivity gain when integrated well into the build workflow.
Nonetheless, this comes not without a word of warning.
While it's great in theory, constant updates might quickly lead to a bombardment of merge requests.
It is crucial that the chosen tools work reliably and are really well integrated. Otherwise, this might become overwhelming for teams.
As an alternative, we also had good experience with disabling automatic merge requests and just manually triggering a job when we wanted to take care of the updates.

18
radar/2022-03-28/resilience-thinking.md Normal file
View File

@@ -0,0 +1,18 @@
---
title: "Resilience Thinking"
ring: adopt
quadrant: methods-and-patterns
---
Resilience is the capability of an application or service to resist different error scenarios. Especially for distributed systems - where a lot of communication between different services happen - it's very important to explicitly think of implementing resilience.
There are a lot of different resilience patterns and it is also a matter of the overall software design. Typical patterns and methods used are:
* Do not hide API calls or any other external communication in your application (for example with unnecessary abstraction) - instead make it explicit that an external communication happens - e.g. by using the Facade Pattern. On the one hand, this makes it obvious that a potential slow and error prone communication is going to happen, and it makes it easier to implement error handling.
* Detect errors explicitly: Check the response message format and configure proper timeouts for external communication
* Handle errors in a smart way: Show a nice error message to your customer or, even better, graceful degrade features - e.g. by showing some fallback text
* Use message-based communication where useful ([Decoupling Infrastructure via Messaging](/methods-and-patterns/decoupling-infrastructure-via-messaging.html))
* Use circuit breakers to isolate errors and allow systems to recover
* Use short activation paths in your strategic architecture - so that there is only a minimal set of communications between your services required for certain features or business requests
"Embrace Errors" should be the mindset - because it is not a question if errors appear - it's just a question of when.