Thread by @championswimmer

Over the last few years, having seen and been part of tech teams that have grown and scaled (in size of team and in userbase), I've come to my own set of conclusions on microservices, microfrontends, monoliths, team communication and DX (developer experience).

A 🧵thread 👇🏽

As we enter into 2020, a few hyped up words and terms in the info-system ecosystem are

- microservices
- microfrontends
- serverless
- cloud-native
- containers
- orchestration

All of these terms are in the bucket of "the better way to do things" as per the mainstream today

I think we often do the mistake of looking at trends from the lens of pure technology, when we should be looking at them as a function of work culture, team communication, and the way companies are growing and working at this time

These "trends" are more abt org struct than tech

So, let's take a look at tech work culture of this era.

Lots of product startups, mostly B2C e-com or gig economy frontends. These have all in recent times have seen a phase of 10k to 1M users in 1 year kind of growth.

Uber pioneered it, but it is an entire era now.

A big hallmark of these types of "things" are that these haven't exactly crystallized into a single "product". It is UI (app or website) which has somehow landed on the lap of a million users, and now the business is throwing feature after feature at it, waiting for some to stick

The team structure is built around this culture of hundreds of small hyper-agile, hyper-lean, pods. Each driven by a PM (p stands for product not project), sometimes a mildly experienced lead engg and a bunch of mid-to-junior devs.

Each team is driven at a crazy pace, churning out feature after feature, trying to make things stick.

Google making a messaging app a day is this.

Facebook pasting stories everywhere is this.

Random games popping up in ecom/payment apps is this.

At smaller (and esp, younger) companies, this leads to the ones who are taking engineering calls to try and avoid responsibility as much as possible. No one wants their team to be one responsible for the downtimes.

Since they don't know any better, they prefer isolation.

Isolation comes in many forms.

Login Team: Let us make this fully independent login conponent in Svelte.js with 100% coverage and ship it off. It's soooo lightweight, everyone else can just plug it in as a webcomponent.

Payments Team: So let's make this completely separate "SDK" for the app team. Our SDK will be black box with a well defined API, and contain no business logic at all. Just start a payment and our module will handle the txn. We will publish with semver for internal usage.

Comms Team: So we need phone verification for orders, for SMS updates and for app registration? Well, we have this scalable dockerized microservice, completely independent of everything else. Just call the API with a phone number and wait for the verification callback webhook.

Now, while all of that sounds great, here's the reality of tests - unit tests hardly fail. In fact the rate of system failure has 0 dependency on the number of unit tests written.

When systems fail at scale, it is failure at integration, not at unit.

The more and more you hive off things in microservices and modular frontends, the less and less your teams communicate.

Now you have 10 teams with extremely good idea of 10 different 10% of your product, but no single person with any clue of how the 100% works.

This keeps unravelling. Whenever the glue between two of your services/modules comes undone, your team leaders are looking at ways of saying "but my service didn't fail, the input didn't conform to the contract", and get away with it. And they do too, and they are right often.

In a bigger picture of things, the costs keep adding up.

Not just financial costs just - which ofcourse is often the biggest.
The overheads of containerization is often 15-20% of your overall infra cost (no kidding).

Microfrontends on app/web increase build times.

"Real testability" suffers at the hand of "isolated testability".

Each service or each frontend module works fine independently. With mocked up data and mocked up connections.

But actually spinning up your entire infra has now become impossible on localhost.

Your mobile and web apps need 20 git submodules to build. Sometimes they don't because one of the modules isn't shared as code, but deployed to the internal package repository. But the S3 IAM user doesn't work outside the company VPN or you don't have access.

Teams are now simply considering mocked tests of their own modules and docker containers as the gold standard and shipping hard and fast. PMs are happy, new releases every week.

The only "integration test" of the entire system happens now at the hand of the users.

It is not easily apparent, but your frontend release managers and your backend SRE teams are now your only engineers who actually have visibility and context of your entire architecture.

But they have no time out of firefighting to actually give any arch inputs even.

When you take a step back and look at it, none of the original promises of modular architectures have actually been kept

If the user service changes the structure of user obj, every one else has to remodel. Only now, *everyone* has a separate user model or protobuf def to update

Just dropping a reminder that many OG tech companies, which have bigger teams that you can imagine, spread across continents, shipping really fast on really big products are monoliths and/or monorepos.

Google and Facebook famously are monorepos.