This, this, this! It's been said elsewhere in these comments, but the term "micro"-services really do them a disservice, like it's expected that you need to break your application up into little pieces, to eliminate complexity. But many applications are inherently complex, and splitting them up isn't going to get you anywhere.
I've been trying to advocate for a "solar system model of services", where you have a big core application in the middle (the sun), surrounded by helper services of various kinds. Your important business logic can be left alone, but the database, other data stores, functions, timers, queues, integrations with third-party systems, one-off jobs, and other things can all stay in orbit.
There are benefits that you get from multiple services that you don't get from a monolith: having to rely on service discovery instead of hard-coding addresses or passwords, being unable to assume that the server your code is running on will live forever, and requiring a concrete CI-CD pipeline to get your code up-and-running are all good things to have, no matter your model, so it's important to have a clearly-defined process for them. A service-oriented architecture can give you that — put down the pickaxe, you don't need to split the monolith in two.
Another aspect no one seems to talk about is whether your deployment is monolithic or fragmented. It seems like a lot of the pain of managing microservices comes from designing a coherent CI/CD pipeline, how to share libraries between various microservices, etc. If you have a monorepo, good build tooling, and a good infrastructure as code tool, I think much of that pain goes away, but none of those things are easy and the precise selection and combination of tools depends a lot on your organization (I wouldn't recommend Bazel or Nix--build tools--to a small or medium-sized organization, for example).
Honestly, that sounds like the devops team didn't communicate well with the business when they pitched them microservices. The business can't reasonably know that moving to microservices entails a change in infrastructure and tooling--you have to build that into your high level estimates.
Often, they didn’t. How many stories have we all heard about “wow.. transitioning to microservices was way harder than we expected” followed by a move back to monolith instead of fixing the issues.
That doesn’t mean a micro service architecture is wrong... just that you have to either learn from your mistakes or hire an amazingly talented team... that have learned from mistakes somewhere else.
I’ve been pushing for a similar model for years as well but called but used rings to model it. Might have to try your solar system model and see if I have better luck.
I've been trying to advocate for a "solar system model of services", where you have a big core application in the middle (the sun), surrounded by helper services of various kinds. Your important business logic can be left alone, but the database, other data stores, functions, timers, queues, integrations with third-party systems, one-off jobs, and other things can all stay in orbit.
There are benefits that you get from multiple services that you don't get from a monolith: having to rely on service discovery instead of hard-coding addresses or passwords, being unable to assume that the server your code is running on will live forever, and requiring a concrete CI-CD pipeline to get your code up-and-running are all good things to have, no matter your model, so it's important to have a clearly-defined process for them. A service-oriented architecture can give you that — put down the pickaxe, you don't need to split the monolith in two.