I am wondering if I am missing something and microservices are perhaps more suitable for smaller projects / teams that I had originally thought.
Any advice would be fantastic.
Solution: one service per team, aka microservices.
(Occasionally there are technical reasons to have multiple services, e.g. one for loading data and one for processing data. But that's not really the same thing.)
Don't like monoliths? here's a "microservice architecture" for you, Java servlet API, circa 1997. Everyone can package their micro-service into a WAR file and deploy it to a service environment. That's right, Companies were doing this shit in the 90's. It probably amazes these same people to know there were servers and computer networks in the 1980's as well. Http was not even the first popular protocol of its kind.
What I hate are these managers who pretend they know what they are talking about saying, "microservices", but they are fucking faking it every step of the way.
With services you do need to have a good monitoring system in place. Also having ability to trace a request across services is a great boon. Helps in proper communication across teams.
These are of course only some of the reasons I could think but one thing should be clear that going Microservices route involves buy-in from the engineering org and a good enough developer population (I feel ~30+ is good to start)
In practice, it can mean responsive web sites that relies on AJAX end points or a collection of REST api:s. But you can never know that any two people mean the same thing when they speak about "microservices."
In order to really benefit from the use of microservices your organizational structure has to be non-monolithic as well (Conway's law), i.e. ideally you'd have cross-functional teams that take end-to-end responsibility for single microservices.