Once I saw an also very interesting talk by some tech guys who were responsible for introducing verticals into their organization which explicitly have a "shared nothing" approach. They put Ops in every team independently and use cloud services for storage. That company is doing e-commerce, so they have a different background, I know. They explicitly stated that they considered to have a dedicated infrastructure team as an anti pattern, while they also admitted that not having one has some drawbacks. And they have standard UI components across verticals, and said that they have to take a lot of care for them so that this dependency at the UI level does not create problems :-) They said that they solve the related problem by dedicating a certain amount of time across teams ("horizontally") at the level of tech responsibilities (all Ops across teams), without any authority to make tech decisions outside of the teams which need to be involved. It is of course not the same pattern, but somewhat related, in that the coupling is attempted to be reduced by distributing the software in such a way as to work more independently by successfully avoiding the distributed monolith. With their approach of "verticals" they moved the dependencies fully away from the tech teams to the organizational level alone, concluding from the talk. But if I got that also right, it also slowed them down, when the bottlenecks were fully shifted to the organizational level. So we have seen here that a company can of course opt out of that to avoid this "accidental" fragmentation :-D I guess that the best solution is what works best in the given environment, with a lot more constraints than only technical ones ... but are microservices then maybe really mainly a technical slicing after all? Are the domains, or contexts, mainly defined on a technical level, when applying this pattern? Always wondering about that question. And what is their actual architecture there, how did they "interpret" that pattern, what is the architecture of their services? It was hugely interesting to watch this, thank you.

I don't know, but it sure didn't help them build a stable mobile app. As both a software developer and a Spotify user, I'm considering anything Spotify does an anti-pattern.

KZread is my favourite podcast platform 😊

Spotify needs to stop investing musicians profits into defense contractors and actually pay musicians fairly. CEO is a real piece of 'work'

@blackjackjester

Ай бұрын

It's a public company, which means that paying more than they need to or are required to is not going to happen. Doesn't matter who the CEO is

@rosshoyt2030

Ай бұрын

​@@blackjackjester Yea, that's where government regulations come in.

Very excellent video! Makes me want to work for Spotify.

I invest in Microservices in order to scale in logical complexity. Chop up big problems into manageable smaller problems. Rinse and repeat 😊

@jangohemmes352

Ай бұрын

Logical complexity can be chopped up in monoliths without introducing the downsides of microservices. How big is your company? Microservices are really a way to scale up the number of people that can work on a project, dividing up the workforce into small, independent teams

@dominikvonlavante6113

Ай бұрын

@@jangohemmes352 No. The logical complexity comes from around 15 delivery teams doing Enterprise Process services for around 50 loosely coupled Business Units. Independent deployment of the various services is absolutely key for maintaining some semblance of sanity.