Tech Radar at Wayfair – Wayfair Tech Blog


I have just hit the “publish” button on Wayfair’s Tech Radar. This is a manifestation of our commitment to transparently share how we think about the technologies we use to build our systems and applications. We are publicly sharing the exact same version externally that we use to guide internal discussions and decisions. You will get to see us working on these decisions in real time.

We didn’t invent this idea or visualization: it’s the very clever folks at ThoughtWorks who did. A tech radar is a two-dimensional classification of technologies into four quadrants and four concentric rings, so 16 buckets total. ThoughtWorks’ quadrants are “Techniques,” “Tools,” “Platforms,” and “Language & Frameworks”. Their rings are “Hold,” “Assess,” “Trial,” and “Adopt,” with Adopt at the center. They explain their thinking fully here, with some informative videos and visualizations, and an email list to subscribe to. They do their ring assignment quarterly, and publish a digest of what has changed and why. Because they are a prominent global consultancy, theirs seems like a statement about the tech industry as a whole, representing their own lens on a very broad swath of the world. But the concept is portable to narrower domains, such as “technologies we use at our humble-furniture-store/internet-juggernaut.” They suggest a process for making your own, and apparently lots of tech organizations have taken the idea and run with it. At this point there are many variations on the Tech Radar theme.

Zalando, the European e-commerce giant, published theirs, and that is the version we decided to use. Its rings are the same as in ThoughtWorks’ original, but the quadrants are different: “Languages,” “Data Management,” “Infrastructure,” and “Frameworks.” Zalando also crafted it as an open-sourced piece of JavaScript, using the library D3, to iterate on the visualization that ThoughtWorks had published. At a Wayfair hackathon a few months ago, two of our engineers drafted a Wayfair version based on the Zalando code. We liked it so much that we adopted it as the main published artifact of our Architecture working group. We’re big fans of this one-page distillation of a large array of technology choices.

Here are two thumbnails of the radars that have inspired us. Read the whole thing, if you have the time, behind both of these links. There is a lot of great work there.

We have made some variations of our own. On the surface, we changed two things. First (obviously!) we used Wayfair-branded colors for the rings. Heh. Secondly, there is a live link for each technology to a page explaining what we use it for. For example, we might say, on the PHP page, “Use PHP for web pages but not for long-running daemons because of its problems with memory management,” or, on the Python page, “Use Python for http services, data science, and operations research, but not for web pages.”

There is a more substantive difference as well, in addition to the continuous-vs-quarterly updates that we intend to do. We are treating the Trial ring as less of an accumulation of momentum and practices, and more of a cross-team collective piece of defined work. We evaluate whether the juice is worth the squeeze: whether the effort of supporting a technology is worth it to us. It’s a coincidence in terms of timing, but there’s nothing in ‘Trial’ right now. To give an idea of recent and prospective Trials, we just went through a period when Cassandra and Aerospike were in it together, in a bake-off, that Aerospike won. Aerospike is now in Adopt, and Cassandra is in Hold. We are currently considering what we would need to do with Golang to convince ourselves that it’s worth the effort of adding support (tooling, dependency management, excellent CI/CD, etc.) for a whole new language. If we can design that experiment, it will go into Trial on its own, without a bake-off partner. If it fails the POC, I doubt it would go straight to Hold. More likely it would stay in Trial, or go back to Assess, while we continue to use it in a couple of niches, and wait and see if we make central-resource support commitments.

Kubernetes is another thing where our treatment is perhaps eccentric. We have it in Adopt because we have decided to make very broad use of it. However, there are only a handful of applications and services that are live on it at this point. Other organizations would call that Trial, but as far as we’re concerned the trial is over, and even though we have not yet finalized the list of things that will eventually run on Kubernetes, we are pushing forward fast towards both clarity on that front, and a much wider rollout for the use cases that we already understand.

What have we learned from the process of putting this together? Given that the stakes and level of passion around these choices can be quite high, it is much better to be having the debate in the open than to be burying the relevant conversations in email threads and meetings. If we’re going to be doing that internally, we see a great upside to sharing it with you, beyond the walls of Wayfair.



Source link