> That's not what microservices means. You're intentionally equating all services to microservices, which is not the case.
Eventually everyone provides a service to someone, I guess, but there is a clear division between those who serve end users and those who serve the servers. The service that places your food down on the table at the restaurant is not thought of in the same was as those who get to the food to the restaurant. The latter camp is often known as a supplier, but we in tech call them a microservice instead. There is no suggestion that all services are microservices.
Microservices is defined to be extreme decomposition, which is not the same as a service. And the biggest pitfall of microservice architecture, is the creep of loose coupling.
Right now I work in an environment, where user account information is copied to every single microservice's internal DB... to minimize access time to that information...
Restaurant provides you with a service - one single interface.
Imagine if a restaurant used a microservice architecture? You'd be spending your time going from the fridge to the cooks, moving your food from one to another(because no cook will do the whole recipe), then going to the dish storage, having a separate cook arrange your food on your plate, etc.
> where user account information is copied to every single microservice's internal DB... to minimize access time to that information...
In terms of access time, what does that gain you over a bog standard shared database? With careful planning, you can likely achieve the lowest access times using a shared database. There is so much more room for optimization at every level.
The reason actual microservices (teams only communicating via API contracts) must carry out this practice of duplicating data is because a shared database requires non-API communication for various things, like enabling schema changes. If you can call up someone on another team to talk about how to upgrade the database and reach a shared understanding, what do you need API-only communication for?
Did your organization become confused about why they are doing that and then invented a performance argument to justify it?
You're not allowed to have a share DB with microservice architecture. Every microservice is completely self contained...
The architecture of my organization was created by ardent microservice advocates, that took the definition of a microservice and treated it like a bible. Based on the conversations I had here, there are still people that treat microservices as sacrosanct.
The more I work with microservices, the more I'm convinced that microservice first architecture is garbage.
The copying of the data is the solution to data access latency.
> You're not allowed to have a share DB with microservice architecture.
The law won't prevent you, but indeed it is impractical. As I said before, things like schema upgrades become impossible if you don't have the ear of other teams. When you can't call up another team you also lack trust, so security becomes an issue as well. This is why teams who operate in independent silos must ultimately have their own databases.
The practice has nothing to do with performance, though. Microservices has little to do with technology at all. It is about people.
> The more I work with microservices, the more I'm convinced that microservice first architecture is garbage.
I personally steer clear of organizations so large that they need to silo their teams internally, but I have had a positive experience using services provided by other companies with the only communication between us being API contracts. The concept works well enough. At least so long as the product does what you need of it.
If you try to force big business practices into a small organization, you're no doubt in for a bad time. That said, I don't get the impression you are talking about microservices at all, just a bad case of over-engineering.
Eventually everyone provides a service to someone, I guess, but there is a clear division between those who serve end users and those who serve the servers. The service that places your food down on the table at the restaurant is not thought of in the same was as those who get to the food to the restaurant. The latter camp is often known as a supplier, but we in tech call them a microservice instead. There is no suggestion that all services are microservices.