Techniques Thoughtworks Technology Radar them fully into the development process. In the past, we’ve highlighted techniques that perform a “shift-left” for security and cross-functional requirements; one perspective on this technique is that it achieves the same goal for accessibility. 14. Operator pattern for nonclustered resources Assess We’re continuing to see increasing use of the Kubernetes Operator pattern for purposes other than managing applications deployed on the cluster. Using the Operator pattern for nonclustered resources takes advantage of custom resource definitions and the event-driven scheduling mechanism implemented in the Kubernetes control plane to manage activities that are related to yet outside of the cluster. This technique builds on the idea of Kube-managed cloud services and extends it to other activities, such as continuous deployment or reacting to changes in external repositories. One advantage of this technique over a purpose-built tool is that it opens up a wide range of tools that either come with Kubernetes or are part of the wider ecosystem. You can use commands such as diff, dry-run or apply to interact with the operator’s custom resources. Kube’s scheduling mechanism makes development easier by eliminating the need to orchestrate activities in the proper order. Open-source tools such as Crossplane, Flux and Argo CD take advantage of this technique, and we expect to see more of these emerge over time. Although these tools have their use cases, we’re also starting to see the inevitable misuse and overuse of this technique and need to repeat some old advice: Just because you can do something with a tool doesn’t mean you should. Be sure to rule out simpler, conventional approaches before creating a custom resource definition and taking on the complexity that comes with this approach. 15. Service mesh without sidecar Assess Service mesh is usually implemented as a reverse-proxy process, aka sidecar, deployed alongside each service instance. Although these sidecars are lightweight processes, the overall cost and operational complexity of adopting service mesh increases with every new instance of the service requiring another sidecar. However, with the advancements in eBPF, we’re observing a new service mesh without sidecar approach where the functionalities of the mesh are safely pushed down to the OS kernel, thereby enabling services in the same node to communicate transparently via sockets without the need of additional proxies. You can try this with Cilium service mesh and simplify the deployment from one proxy-per-service to one proxy-per-node. We’re intrigued by the capabilities of eBPF and find this evolution of service mesh to be important to assess. 16. SLSA Assess As software continues to grow in complexity, the threat vector of software dependencies becomes increasingly challenging to guard against. The recent Log4J vulnerability showed how difficult it can be to even know those dependencies — many companies who didn’t use Log4J directly were unknowingly vulnerable simply because other software in their ecosystem relied on it. Supply chain Levels for Software Artifacts, or SLSA (pronounced “salsa”), is a consortium-curated set of guidance for organizations to protect against supply chain attacks, evolved from internal guidance Google has been using for years. We appreciate that SLSA doesn’t promise a “silver bullet,” tools-only approach to securing the supply chain but instead provides a checklist of concrete threats and practices along a maturity model. The threat model is easy to follow with real-world examples of attacks, and the requirements provide guidance to help organizations prioritize actions based on levels of increasing robustness to improve their supply chain security posture. We think SLSA provides applicable advice and look forward to more organizations learning from it. © Thoughtworks, Inc. All Rights Reserved. 16