1 of 16

Tech Radar

Arch Study Group

Nov 10, 2020

This meeting is recorded.

Review ThoughtWorks’ & Assess edX’s

2 of 16

What is a Tech Radar?

In General

A visual tool for understanding the usage of techniques and technology.

Blips, Quadrants and Rings

How does ThoughtWorks create its Radar?

Who is Thoughtworks?

The Secret Sauce

Does edX have its own radar?

YES!/NO!

Assess latest radar and its applicability to edX

First pass: See if any blips stand out as relevant for edX. Start with discussing those.�
Questions to consider for each blip that is relevant for edX:

Is edX already consistently following this recommendation? (includes hold, adopt, etc)
Would edX benefit from following it?

Techniques

Dependency Drift Fitness Function - We’re really close to this with all the package upgrade management we have in place. +2
Tailored service templates
Data mesh
Diagrams as Code - would be nice to see more of this in our docs, potentially easier to keep up to date +3
Zero Trust Architecture +
Parallel run with reconciliation - we’ve talked about this before, but a Python tool for it seems to have matured since then: https://github.com/joealcorn/laboratory (inspired by GitHub Scientist, which is for Ruby) +3
Security Policy as Code: We have it for edx-platform for XSS, but not for much else (we’ve looked at using it w/ tfsec) +1
Distroless Docker Containers: We have a lot of stuff in our docker containers, even more than just the distro. Maybe multistage builds would let us compress our existing (or our newly built) containers to have smaller layer footprints?
Log Aggregation for business analytics: Are we still building any business analytics off the raw event logs? Can/should we prioritize moving those into dedicated events and/or using DBT to extract consistent data from the tracking logs? +
Microfrontend Anarchy - where is edX with this? Seems relevant to us. +1
Kube-managed cloud services - I think prefect is one of these

Platforms

+1 Node overload - Node has come up several times recently, and it’s worth noting that it shouldn’t be blindly adopted for the wrong reasons.
JupyterLab - heard good things about this but fuzzy on how it differs from Jupyter Notebooks +
Backstage seems potentially useful, this also came up when we were looking at how other places do “devstack” +2
Pulumi - they seemed to like this as a Terraform alternative that addresses some of its drawbacks, is it something worth considering at this point?
Tekton - Kubernetes-based CI/CD platform, is this useful to us? Travis and Jenkins aren’t a great fit in this space. (Argo is a pretty good fit though) +1

Tools

Airflow - Though we are using Prefect and Argo currently
Dependabot - Though we don’t use dependabot, should we be considering different dependency management (I techniques to better use off-the-shelf tools here? (I thought we did use dependabot…?) +
Helm - Specifically Helm 3 +
Kustomize
Trivy - this came up recently, seemed pretty easy to turn on (it’s on now) +
Concourse - this came up previously as a compelling alternative to Travis and Jenkins for CI/CD, they rate it even stronger now +2
ShellCheck - for shell script linting, this routinely trips us up for new scripts +1
LGTM - looks for coding patterns prone to security problems
Yarn
Sentry - We don’t use this yet (some engineers have used it at previous organizations) +

Languages & Frameworks

+1 single-spa
Rust - we don’t use this yet, but it keeps moving up the scale (now at Trial) and has some nice properties +1
+1 Redux - Our findings seem to mirror Thoughtworks’.
Recoil - We don’t use this yet, but may want to access it too.
LitElement & web components in general
Testing Library