“It's just a tool in a toolbox. I've described microservices as being an architecture of last resort.”

I mean, there was always, I mean, also in those sorts of environments. I mean, I was checking people at SoundCloud that's similar about that. And this is also like about a corporate culture and like what was acceptable. Like in that kind of environment, just go and do stuff. It's absolutely fine.

And I think that's why Uber, for example, went in. I just talked with Twan Palm, the C2 at the time, about like what was the real deal about microservices. And he said, Uber, like, he never really wanted that many services, but it was just more of a constraint because Uber had a monolith. The story was like, which he told on a podcast, we'll link it at the show notes below that Uber had this big monolith and it was really slow. It was slowing delivery down. And they needed to move fast because all the other competitors were out there. So they said, all right, like they wanted to get rid of the monolith and put together smaller services, but they knew unless they had a strong mandate that you cannot add new stuff to it, this will never happen. So they said the mandate was everything new needs to be your own service. You take care of it. We don't care. And suddenly so many independent services were born, which was not the goal. And years after the fact that when Uber decomposed the monolith, they're now looking at maybe sense to be merging based on business domain, et cetera. But this story wasn't really told at the time. It was just, oh, look, like Uber has thousands of microservices, almost one or two per engineer, right? And this is what the world saw.

Really?

Yeah, yeah, absolutely. Because it pushes you quite naturally to a more aggressive distribution of your state and everything else. And so you have to have a good reason. One of the best reasons to use microservices is if what you actually want is an organization with a high degree of autonomy. If what you want is teams who are able to act independently from each other, the microservice architecture is a fantastically good fit. But then really it's a mean. To an end, right? So that's often what a lot of people get wrong, I think, is they adopt microservices and they think some other magic stuff's going to happen. If you want organizational autonomy, that's what you're working towards. And this is just one of the mechanisms to get you there. And most of the enterprise organizations, the vast majority of ones I've worked with in this space, that's what they're after. They've got huge numbers of developers, lots of middle management. They're not getting much work done. They're thinking, what do we do? Organizational autonomy becomes, you know, the solution to all problems. Again, I don't always get to have to say whether or not it's a good idea. And I think that's where microservices can be especially useful. I mean, there are other exceptions as well. And so an organization like Uber, I mean, and I say, I know at Netflix as well, things like Domain Dream Design weren't talked about at Netflix, but the teams were already fairly well scoped around areas of product already. And so you had those natural high-level boundaries around the business domain. So those things flowed naturally. And so that for me was a logical kind of stepping stone. You also have the difference, and this is something I realized quite early on. When you go and do the work in the dot-coms versus the enterprise organizations, when you

say dot-coms, you mean the digital companies, tech companies.