Skip to content

Instantly share code, notes, and snippets.

@ValentinMouret
Last active October 19, 2023 08:57
Show Gist options
  • Save ValentinMouret/b5cc417d39f4173f860618dc78635e85 to your computer and use it in GitHub Desktop.
Save ValentinMouret/b5cc417d39f4173f860618dc78635e85 to your computer and use it in GitHub Desktop.

RFCs, ADRs, and radar

Hello all!

Thanks for attending this 6th Hublo Growth! 🪴

On the menu today:

  • RFCs
  • ADRs
  • Radar

But first, a disclaimer

This is not a normative instance.

This is not cosmetic.

I am going to present widely adopted tools which solve real problems.

These are patterns and good practices, tune it to your own needs.

The problems

First, let’s try to understand the problems these tools aim to solve.

We are engineers

As engineers, we make decisions.

I need an ORM!

I need to interface with another system!

When the team is small and recent, we don’t feel the need to document much.

Now, one question for you:

How many engineering teams are there here at Hublo?

🤔

9

  • SRE
  • mstaff
  • institution
  • shift
  • network
  • QA
  • interop
  • care
  • archi

~40 people

📈

As time goes by and people come and go, a couple of needs arise:

  • How do we communicate clearly between teams?
  • How do we keep track of the decisions we make?

1) How do we communicate clearly between teams?

Sometimes, we need to make a decision that impacts multiple teams:

  • decouple using a message queues
  • handle database migrations

Slack channels don’t really scale that well when it comes to that.

2) How do we keep track of the decisions we make?

Even within a team, it’s often not clear why things are the way they are, and we might be reluctant to change things.

Why are we proxying calls to Chronos through a static IP on a random service provider?

(That’s often when we start pinging Thomas Schersach)

Thankfully

These problems are solved by a couple of tools:

  • RFCs
  • ADRs

RFCs

A Request For Comments (RFC) is a formal document that outlines a proposal for a significant change, which is reviewed and discussed by all relevant stakeholders.

The goal here is to nail a problem on a piece of paper and get people’s objective opinions on it to converge to a solution.

For example, RFC-791: IP protocol.

ADRs

An Architecture Decision Record (ADR) is a record that captures an important architectural decision made along with its context and consequences.

The goal is to address ambiguity in architectural decision-making and provide a history of decisions.

They help resolve conflicts by sharing ownership, stating the different points of view, decision drivers, and why a decision was taken.

How do we do them at Hublo?

Shiny new repository! hublo/docs

Make a pull request and get feedback from people.

Examples:

ADRadd export csv file to S3
RFC/ADRAirflow on Kubernetes

(teams own their ADRs and RFCs)

log4brains

Jeff even added a tool to make it easier to work with ADRs.

[demo here]

Diversity is normal

Different teams do different things, so we need different tools, and make different decisions.

However, there is an interest in re-using technologies:

  • knowledge is already there
  • we know how to operate it (deployment, monitoring)
  • we might have tooling around it

It’s «off the shelf».

However, it would be nice to organise our opinions on technologies and their future at Hublo.

Radar

Made popular by Thought Works, it’s a visual representation of the adoption status of technologies within a company.

We made our own here!

To suggest changes or additions, open a pull request and let’s discuss this in public.

(the architects own the radar)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment