Staff Engineer Archetypes (2020)

> Originally, Twitter ran their public APIs through a single Ruby-on-Rails application (“Monorail”), which had grown into one of the largest Rails codebases in the world. And so it was increasingly difficult to update. By 2014, Twitter went the route of microservices, migrating the API service to a set of 14 microservices, running on an internal Java Virtual Machine (JVM)-based framework (“Maccaws”).

> “While the microservices approach enabled increased development speeds at first it also resulted in a scattered and disjointed Twitter API,” Cosenza said. Independent teams designed and built endpoints for their specific use cases with little coordination. This led to fragmentation and, inevitably, a slowing of developer productivity.

Microservices don't make a lot of sense to me unless you can print money or have a public infra offering. It points to an engineering org that doesn't know what they are doing. Turning O(N) code complexity (virtual complexity) into O(N) operational complexity ("physical" complexity) points to an org that doesn't understand where their complexity is coming from or how to minimize it.

> creating a new feature shouldn’t require back end refactoring.

The argument I was making is that it doesn't matter if it gets better. Once momentum is stopped by poor architecture, inertia is too high to get moving again.

> I know how at least one of the newer services work at AWS and how many existing back end existing services it depends on and that if anyone outside of AWS had the resources, they could build it themselves by calling publicly available APIs.

Yes they product-ized their services which is absolutely brilliant. I think the fact that amazon can print money plays a very key roll in why they won while other companies lost. They scaled early in the game rather than scaling too late and reaped incredible rewards for doing so.

> And let’s not pretend that Google for instance is any better at product development.

Google is famous for developers "just shuffling protobufs between services." While it's generally said derogatorily, that means that developers are generally not in the weeds and minutiae of what they are trying to accomplish, but are actually working on the higher level concept they are trying to achieve.

> It’s failed at everything it’s done not related to advertising

gsuite, maps, search, adsense, analystics, gcp, youtube, play, android, pixel, chromebook, news, docs, project zero, etc.

I don't agree that failure is the rule. Cutting lackluster offerings rather than pouring investment in them shows at the very least a sane short term strategy with the weakness of potential harm for long term consumer trust. That's a reasonable trade off to make with good arguments for both sides.

Yes, you are telling me the point I was making. Product-izing your microservices is a justification for microservices.

> 5. All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.

That is the property that makes microservices make sense. Without that property, technical leadership is setting themselves up for failure.

> Your information about Twitters current architecture is way out of date.

The only point I was making about twitter architecture, of which I know far too little about, was that as you stated previously "Every indication is that the code base was horrible" leads to loss of momentum and inability to innovate, so it's not surprising their growth stagnated for, what I believe, are primarily technical reasons. It doesn't matter if they got better if they went through a period which stopped momentum.

> That’s not the point. The point is that new internal initiative starts from a blank slate at any large tech company. There is already infrastructure in place to build on top of even when that underlying infrastructure isn’t publicly available.

The point I'm attempting to make is that if underlying infrastructure is poor, that's not a fertile ground to grow new product so innovation becomes stifled because resistance to new functionality is too high. If maintenance costs are too high resources must be spent maintaining rather than innovating. I've seen developers stumble around for a week because they put `30` instead of `10` in a config file. I've watched an entire team waste months of effort because production was not advanced enough for what they wanted to do. I've watched an entire engineering organization lose hours every day to a poor dev environment. Time was spent fighting infrastructure, not creating features, so it's not surprising when new products and features weren't created and growth didn't meet expectations.

> google stuff...

We have different definitions for failure. You said google wasn't able to develop products. Google is clearly able to develop new products/services, maybe not monetarily successful ones, but google as as a company has a disproportionate effect on my life and how my life works past showing me some ads.