Techniques 16.Reachability analysis when testing infrastructure Assess When deploying infrastructure as code, we’ve noticed that a lot of time can be spent diagnosing and repairing production issues that result from systems being unable to communicate with one another. Because the network topology between them can be complex, the entire route may not be traversable even if individual ports and endpoints have been configured correctly. Infrastructure testing practices usually include verifying the right ports are open or closed or that an endpoint can be accessed, but we’ve only recently begun doing reachability analysis when testing infrastructure. The analysis generally involves more than simple yes/no determinations. For example, a tool might traverse and report on multiple routes through transit gateways. This technique is supported by tools across all the major cloud providers. Azure has a service called Network Watcher that can be scripted in automated tests and GCP supports Connectivity Tests. Now, in AWS, you can test reachability across accounts in the same organization. 17.Self-hosted LLMs Assess Large language models (LLMs) generally require significant GPU infrastructure to operate. We’re now starting to see ports, like llama.cpp, that make it possible to run LLMs on different hardware — including Raspberry Pis, laptops and commodity servers. As such, self-hosted LLMs are now a reality, with open-source examples including GPT-J, GPT-JT and LLaMA. This approach has several benefits, offering better control in fine-tuning for a specific use case, improved security and privacy as well as offline access. However, you should carefully assess the capability within the organization and the cost of running such LLMs before making the decision to self-host. 18.Tracking health over debt Assess Tracking technical debt is a perennial topic in software delivery organizations. What is technical debt and what is not? How do you prioritize it? And most importantly, how do you express the value of paying it off to your internal stakeholders? Following the Agile Manifesto’s manner of reasoning — “while there is value in the item on the right, we value the item on the left more” — we like the idea of tracking health over debt. The folks at REA in Australia share a good example of what such health tracking can look like. They track system ratings in the categories of development, operations and architecture. Focusing on health instead of debt is a more constructive framing. It connects a team to the ultimate value of reducing debt and helps them prioritize it. Every piece of tackled technical debt should ideally be connectable to one of the agreed expectations. Teams should treat the health rating the same as other service-level objectives (SLOs) and prioritize improvements whenever they drop out of the “green zone” for a given category. © Thoughtworks, Inc. All Rights Reserved. 17