Why our team cancelled our move to microservices

My team of 5 has 5 services. 3 of those are tiny function-as-a-service APIs. 2 of those are Azure App Services, where our involvement in the infrastructure is minimal. And we're about to add a 3rd one of those. That sounds like a lot but we wanted the flexibility of making those capabilities independently updatable and deployable. And only one of those has an API used by other teams, so as far as the rest of the company is concerned it's like we have only one service.

At one point we had twice as many teams and almost twice as many services. The team had grown too large for optimal performance. When it was time to divide the team, we were able to categorize our services in two ways by the path of the data (deep back-end data processing for internal customers vs product services). Then we were able to assign a category to each team so that we have minimal dependencies and no code conflicts between teams.

I have a very strong objection to this line of thinking.

Effective use of microservices depends upon a strong, meaningful boundary between the services and that boundary should be business driven, not code driven. As soon as you start dealing in packages of code[1], there’s no longer a meaningful boundary between your services, instead the boundary is completely arbitrary and each service becomes a microservice in name only.

If every microservice knows about the business logic for generating basket prices, whether the code comes from a package or not, you no longer have microservices… you have a lot of monoliths.

I joined a company that did this and it was one of my worst experiences as a software engineer, I would never recommend it.

[1] specifically packages containing business logic. Packages containing functionality for cross-service communication etc. are very reasonable.

We? I'm sorry I don't understand.

> One function cannot access the memory space of another function any less explicitly than one process can access the memory of another process.

You're mistaken. The operating system largely prevents cross-process memory access. Of course, CPU vulnerabilities can circumvent these protections, but even then your micro services can run on distinct machines while monoliths can't.

> The only way this would be helpful is if your whole goal is to make something (breaking the contract) as hard to do as possible

Yeah, that's the idea. "defense in depth".

> And in that case, I really have to ask, who are your teammates that you trust them so little as to literally enforce separation this way? No healthy organization should have to resort to this kind of civil war.

(1) not all attackers are internal

(2) some attackers are internal and many very profitable organizations do restrict employee access to secrets (and in many cases this is required by compliance).

> Many "Monoliths" can be run on something as simple as a desktop emulator.

I'm not sure what a "desktop emulator" is, but a lot of micro services can run as native processes or in a VM. There's nothing about micro services that fundamentally restrict where they run--they're just application processes at the end of the day.

> my use of the term "distributed means that if AWS East has your DB instance and your web server is stored in an entirely different region, you app goes down anyway, but your front-end team can maybe still deploy updates... Which is not really a dramatically productive gain for a customer running a restaurant web site.... On the other hand, if you're running a massive video streaming site, it might be a good thing to base it on micro service architecture. Each use case is different.

I mean, that's one scenario but the inverse could be true--your custom emoji service could go down but everything else--your payment service, etc could stay up. More than that, you can play it fast and loose with deploying to your emoji service while your important core services get more scrutiny. With monoliths, any change could take down core services so you have to use the same scrutiny when deploying changes to the emoji features. Moreover, you don't need to coordinate with a bunch of other teams to deploy--your team can deploy its own service whenever it needs to. You can use whichever language is best for your component. Etc, etc. But we are agreed that micro services aren't fit for every use case--if you only have a few teams then you probably won't benefit much from micro services.

> I'm resisting the pressure to be drawn into a debate about which one is better, that's not what I'm out to do... What determines which solution is better is the business case it seeks to resolve. Neither is inferior or more obsolete, the two ideals both can and often do run on identical/similar code bases... It's the configuration and potential uses/application/benefits that differ.

You're back pedaling pretty quickly from the tone and claims of your original comment, but I accept all of this--neither is a silver bullet. :)