Microservices are Technical Debt

0:00 - Intro
1:20 - Why Microservices?
6:29 - Developer Productivity
9:31 - Microservices are tech debt
17:36 - Was it worth it for Doordash
22:36 - Programming Principles
26:40 - Hot takes
29:27 - Programming Advice

#neetcode #leetcode #python

[NeetCodeIO]

Here's my original DoorDash video:

Here are the links Matt mentioned:

[mykal]

Neet, this is a good niche if you can pull it off, talking to architects where they share their war stories, its entertaining and educational. You could possibly enter the top ranks of hardcore tech tubers if you did this.

[MichaelZijlstra]

This made me think of Conway's law - the structure of a system reflects the structure of the organization that makes it. They had to split into micro-services because their organization became too large.

[chrismeiklejohn]

In my Ph.D. dissertation, I said that microservices have fundamental issues because they are a technical solution to a socio-technical problem. However, during my Ph.D. defense, I made a slip of the tongue (and error in my slides) and said "microservices are a socio-technical problem" and... it sort of caught on. 🤣

[ashlebeau]

Now instead of someone pushing code and breaking things for everyone else, we push code and break things for everyone else but they just don't know it yet

[enkindel]

Start with a monolith. Scale only if it’s needed. Benchmark your application. Don’t create solutions to problems that don’t exist.

[polvoazul]

Another double edged sword of microservices: Teams own services. So, changing your own service is pretty easy, but changing other people's service's can be very hard (if there isn't an explicit push for a collaborative culture). In a monolith, everyone feels like they softly own parts of the code, but you can change anyplace (say, during a refactoring). Try refactoring some global stuff in a business using microservices... There are two ways: sending MR for every repo yourself (which is not trivial, because you don't even have access to them), and people can and will ignore you. Beg people to do it, which is such a failing strategy because they don't have any incentives to do it. So you probably need some strong company process / culture that enables global changes (I've never seen it in real life).

[Sanchuniathon]

Any time a system becomes more complex than the problem it is seeking to solve, then it's time to rethink the system because you'll spend more time on the system than on the problem. That's a good thing when the system can elegantly address problems you encounter. It's a bad thing if you end up focusing more on the tool than the issue at hand.

[rogerdeutsch]

Great talk. This video reveals a core truth of IT - There are as many Best Practices, Software Architectures, & Great Ideas as there are software development teams. Each team does what works best for them & then most (many) of them start yelling that "we've found The Way to develop software! You must follow our process. Oh, if we codify this and slap a name on it, we can sell books." Agile, Scrum Agile, Software Patterns, Enterprise Patterns, Clean Coding, KanBan, Six Sigma, ISO 9000, AI, Monolith, Microservices, etc. ad infinitum.

[matowang]

Love this talk by someone who actually works in the trenches
Too much theory talks about microservices out there

[IanSherratt]

One 'third way' is the traditional 'monoliths where well defined modules are owned by teams' - effectively this is how much of software that exists works - e.g. everything that makes use of the hundreds of shared libraries on your desktop. Network calls, isolated infrastructure etcadds a whole level of complexity to maintenance and devops...

[onaspnet]

His advice was awesome: Dive into your libraries. Understand dependencies or try to avoid them. Value craftsmanship and know what good means contextually. Avoid dogmatic beliefs.

[abghjd]

The problem is Architectural Extremism (a subset of development dogma) whereby nothing in between a monolith and a microservice is allowed. Something in between, e.g. a "Multiservice" would alleviate issues like dependency conflicts and callgraph clutter that come with a pure microservice-based architecture. Premature optimization is the root of all evil but how many headaches, time and money could have been alleviated during Doordashes microservice transition if they had prematurely optimized. Further, what issues could be addressed by not migrating from one polar extremity to the other by using Multiservices as the default and Microservices only when they are absolutely necessary. Grug says Monolith Bad, Multiservice good and Microservice helpful only when necessary.

[shashank]

re: "stepping on each other's toes":

I was a SWE at Facebook (I refuse to call it Meta) between 2015 - 2018. Around 2016 IIRC, we increased the release frequency for the PHP/Hack monolith (internally known as "www") to 3X/day. I remember being blown away by this. Mind you, this was most likely the world's most used monolith (it still maybe?), with 10K+ developers often committing multiple times to it daily.

A key mechanism that enabled this release velocity was *feature flagging*, which allows decoupling of code deployment from feature enablement. I'd argue that feature flagging is a necessary ingredient for scaling a monolith, and combined with high quality automated testing and telemetry, might even be sufficient.

[JohnSmith-qywm]

As someone on a small team (at a small company) with 400+ microservice that has spent years updating them for a single specific reason, let alone just maintaining them, yes I agree. We're maintaining a "scalable" architecture that we don't even need. In our case, it's never-ending technical debt because we do not have the capacity to knock out all the updates before more updates are needed.

[JogoShugh]

This is so honest and refreshing. I experienced these exact problems within "a large European technology giant". It was supposedly mitigated by the famous proxy from Lyft. But, was it really? No, not really. It was still point-to-point calls with a distributed call graph of synchronous calls -- for the most part. There were some more resilient parts utilizing pub/sub techniques.

Thanks for speaking out on this!

[iejelliott]

It's cool to see this kind of content on YouTube. Matt seems like he knows his stuff and would be fun to work with and learn from. The anti-dogmatism and focus on craft was refreshing.

Also, this tip was supposed to be 5AUD. Does YouTube take a cut?

[phoenix-walker]

29:20 There is SOA architecture.

Basically before micro services came about, SOA tried to encpasulate business functionality into a single service. There wasn't a stringent rule on not sharing databases.

However, there will never be a "clean" and perfect solution for every problem. There will always be tradeoffs.

It's up to us as software engineers to figure out which tradeoffs we will have to live with and how long. Then accordingly pivot as our technical capabilities and requirements change.

[nicholastanzillo]

I don’t comment often… but this is an incredible video! If you can, I hope you’re able to get more people like this on the channel!

[andrewmarek]

This is a cool video! I feel like everyone has read that blog (independent of your channel) or a blog similar to it, and having someone come back and reflect on it is really valuable.