INTERFACE, by apidays - APIs: the next 10 years June 8, 9 & 10 2022 How we built out governance layer on this thousand-year-old tech (trust), Shai Sachs, Staff engineer at Wayfair ------------ Check out our conferences at https://www.apidays.global/ Do you want to sponsor or talk at one of our conferences? https://apidays.typeform.com/to/ILJeAaV8 Learn more on APIscene, the global media made by the community for the community: https://www.apiscene.io Explore the API ecosystem with the API Landscape: https://apilandscape.apiscene.io/ Deep dive into the API industry with our reports: https://www.apidays.global/industry-reports/ Subscribe to our global newsletter: https://apidays.typeform.com/to/i1MPEW

1. How we built our governance
layer on this thousand-
year-old tech
Challenging Conway’s Law with trust
by Shai Sachs

2. 2022 SERIES OF EVENTS
New York
JULY
(HYBRID)
Australia
SEPTEMBER
(HYBRID)
Singapore
APRIL
(VIRTUAL)
Helsinki & North
MARCH
(VIRTUAL)
Paris
DECEMBER
(HYBRID)
London
OCTOBER
(HYBRID)
Hong Kong
AUGUST
(VIRTUAL)
JUNE (VIRTUAL)
India
MAY
(VIRTUAL)
APRIL (VIRTUAL)
Dubai & Middle East
JUNE
(VIRTUAL)
Check out our API Conferences
www.a pida ys .globa l
Want to talk at one of our conferences?
apidays.typeform.com/to/ILJeAaV8

3. 2
1. Problem: Thousands of
microservices
2. Solution: Welcome to the
Governance Layer!
3. Trust challenges Conway’s Law
Agenda

4. 3
Shai Sachs
Staff Engineer on
Wayfair Cloud Native team
● Designed Wayfair’s microservice governance layer.
● Currently standing up an enterprise API gateway.
● Live and breathe APIs, particularly love elaborate
bash-and-jq scripts.
● Avid cyclist, have a reading list longer than my arm.
ssachs@wayfair.com
https://www.linkedin.com/in/shaisachs/
Intros

5. Problem:
Soooo many
microservices

6. 5
Microservices
● Deploy autonomy
● Teams move independently
● Freedom to experiment
● Thousands of microservices
● Infra is no longer monolithic
Are great!
Sorta!
https://www.youtube.com/watch?v=y8OnoxKotPQ

7. 6
Autonomy
→
Teams should get to manage
their own resources!
→
What resources should
a team own?
→
We need a governance layer!
Whose stuff?

8. Solution:
A microservices
governance layer

9. 8
● Holds “policies” - associations between
services and the engineers who own them
● Records ownership changes
● Interfaces with IAM system of record
● Syncs to Kubernetes role bindings
Quick look at our governance layer
● Holds lists of all services
● Holds associations between services and
the resources they consume
● Interfaces with an internal dev portal to
make the above readily available to
engineers
Ownership Service Mokka

10. 9
1. Start with a good guess (service
creation metadata)
2. Backfill the rest (Kubernetes
namespace list, Git repos, …)
3. Incentivize “fixes”
a. Carrot: ability to self-manage
Kubernetes namespaces
b. Self-service mechanism to assert
ownership
c. Integrated into our internal dev
portal!
How we get the data right
Photo by JACQUELINE BRANDWAYN on Unsplash

11. How we used trust to
challenge Conway’s
Law

12. 11
“Any organization that designs a system (defined broadly) will
produce a design whose structure is a copy of the organization’s
communication structure.”
- Melvin Conway, 1967
Often simplified to: “you are doomed to ship your org chart”
Conway’s Law

13. 12
In our case:
● One team built out ownership
policy APIs
● Another built out integration
to service-creation services
and ingested legacy data
Step 0. Hack your way to Valhalla
Photo by Sara Ferreira on Unsplash
What most team interactions should look like →

14. 13
Which employees/team owns
application XYZ?
Step 1. Identify concerns. Nail down APIs.
Which resources does
application XYZ consume?
What are all the applications at Wayfair?
Ownership Service
Mokka

15. 14
Does the separation of concerns still
make sense?
Are these services actually distinct?
Do consumers have needs that cause a
lot of cross-talk?
Step 2. Monitor roadmaps
Photo by Chance Brown on Unsplash

16. Fit image to the box
A tipping point
Backstage
Resource
consumption
source of
truth

17. 16
a. Thinking out loud
b. Non-committal noodling around
c. Running it by your manager
d. Actually writing it down
e. Explaining your reasoning
f. Circulate your ideas slowly
g. Circulate them less slowly
h. Decision point!
Step 3. Decide we need to move things around
“We can accomplish our mission without
Mokka, but you can’t accomplish your
mission without Ownership Service”
If this separation of concerns doesn’t work... We’d better come up with another one

18. 17
1. Draft transition plan and circulate with team(s)
2. Reach out to stakeholders one-on-one
3. Github transfers, build pipeline transfers, ….
4. Transfer document ownership / Confluence
resources
5. Transfer monitoring assets
6. Trainings: overview, code walk-through,
operational walk-through
7. Roadmap overview
a. Decide what the “departing” team will wrap up
before handoff
8. Document architectural decision records if you
haven’t done so yet!
9. Gradual shift of maintenance responsibilities.
Quick shift of roadmap ownership.
10. When everyone’s ready: announce the shift!
Step 4. Handoff
Photo by Jill Sauve on Unsplash

19. 18
Results!

20. 19
1. Try some stuff
2. Draw lines around your concerns which you
think are correct
3. Try some more stuff, realize you were wrong
4. Figure out what you do need to ship
5. Redraw the lines around atomic teams that
you trust to ship the stuff you need to ship
Chase
weird problems.
Challenge
Conway’s Law.

21. 20
Trust

22. 21
Any questions?
Keep in touch!
ssachs@wayfair.com
https://www.linkedin.com/in/
shaisachs/
Thank you!