Microservices Challenges

One of the big advantages of microservices is scaling/migrating the databases behind each service independently. If you need transactions across multiple services then one could argue that either your API endpoint is doing too much, or your services are doing too little. It's not perfect, and certainly not always convenient, but it's a balance. Microservices with a common DB is asking for trouble. The monolith is a better option in that case IMO.

As long as microservices don't share database, then all is fine.

Seems to me you are talking about a database access layer instead of microservices.My understanding of microservices is a bunch of loosely connected services that can be changed with minimal impact to the othersProblem with the ideal is in reality this never works as complexity grows the spaghetti code moves to spaghetti infrastructure ( Done a network map of a large k8s / istio deployment lately ? )

For what it's worth, what you are describing is a pretty well known failure mode. It was known in the days of CORBA and DCOM, and then again in the days of SOAP web services. Microservices as a distributed monolith is not how you partition things if you want to gain productivity and be successful. Literally everything you mention other than updating shared libraries are problems that our team does not have and yet we have around 100 autonomous back end components and over 20 web application

If you place things in the right service, the need for service-to-service communication is low. I know companies that straight out banned it. If you treat each service as a database table. Sure, you will be in for a ride. If you then are lenient about breaking changes, then you will have real problems. But microservices is a service architecture. Each service is almost a product. Each service covers an entire problem. Parts of that problem is not in another service. A service is not a task.

What kind of issues you faced while working with microserviceS?

That's a lot of microservices. How do you handle changing the interface of a service in a backward incompatible way? Or updating a dependency across all services?

I'd avoid having separate services share a DB. Besides the overhead, you get scary hidden dependencies that way. If this approach is considered not micro but rather an in-between, the article should mention it as an option.

I think you might just have a badly architected backend. get rid of your microservices first and then we'll see how you're feeling

Not if you depend on another microservice (which you will). It just pushes the complexity to another layer - and might even increase it (IPC is non-trivial, tooling is worse (no cross-microservice refactor), etc)