3 ms·
Nothing new here on the complexity. AOL had a similar service dependency graph around 2004 or earlier. Paypal had a considerably denser graph I made post-D3 in
by lanstin 5y ago
Nothing new here on the complexity. AOL had a similar service dependency graph around 2004 or earlier. Paypal had a considerably denser graph I made post-D3 in I don’t 2012? 1000 services by name (some segregation by QoS so maybe less code than that implies). The core graph or central service dependencies (removing all the services that just called other services and weren’t themselves called, repeatedly till nothing could be removed) was like a hundred, with many loops.
- lanstin 5y agoHaving read the whole article, not sure what the point is. Focusing on the problem before the capabilities is good, but so much energy is spent working around missing capabilities, “this service won’t propagate the debug header and the team won’t fix it” that it is natural. I will say design is useful - the AOL graph was mostly hub and spoke. App Routers -> domain specific orchestrators -> single coarse grained functional API. Paypal was more poi;t to point to point. AOL encouraged devs to take some time just mulling over a new problem or new servers until a sensible approach seemed feasible. Few weeks for a 3 month project, few months for a year long project. and in the 90s good software had observability. Metrics and logs and tracing, all on the fly to enable or disable prospective msgs (you had to turn off a certain log msg on the fly when a dev accidentally left would should be a tracing level msg at like an always log level).