To be honest we tried to avoid the monorepo but it was hellish. Maybe if each microservices was larger and our team was larger but then are they microservices any more?
Giving up and dumping everything into a monorepo, that's not going to help at all. At that point probably better off just giving up any hope of carefully split up and individually managed services
Wouldn't this urgent need mean that they put this code into the microservice that needs this urgent update as opposed to going through the effort to make it available for everyone to use?
Same with our consistent logging system.
Libraries are better than unique code everywhere for the same task - allows you to fix a bug once and to do consistency checking.
The problem is an not-ideal "the code which is in libraries shared by different services is tightly-coupled to particular services". e.g. changing the shared library might break some service which depends on it.
Obviously, you don't want code like that. But it's easy to write code which is slightly coupled; and then when you're in a hurry, to increase the coupling.
Anyway, it sounds like you have a distributed monolith. If you cannot maintain and deploy a microservice independently, it should not be a microservice.
The main difference between SOA and microservices is dump pipes vs smart pipes. Not service size. As explained in that book.
Most people trying to implement microservices seem to have not read much about them outside of blogs.
People not reading the literature then implementing it badly isn't problem with the idea. In the same way that not studying calculus then doing badly isn't a problem of calculus.
Most of these issues around microservices like how to split them so they don't cause issues, are known and solved problems. Just people have not read the literature other than the odd "blog". Like don't do microservices, for your first iteration. Backwards compaitble apis, and understand your bounded contexts from your first iteration before you try.
They end up creating chatty nano services with tons of version fixed cross dependencies.
We can maintain and deploy them independently, but it was annoying to try to track which version was deployed where and having to check it out independently, etc.
The overhead was incredibly high. So we plopped them all into a single monorepo as sub projects. We can still update each one individually but we know what is live on the website is what is in the head of that branch.
As someone whose last website was a monolith (Clara.io), we do feel we are getting the benefits of micro services with little of their downsides now. It is like night and day.
It may be we have a lot of micro services for the size of our team - 20+ micro services and a team size of around 12.
One microservice per team, so you cut down on intra-team friction, and the team can manage their own releases.
(In other words, you're 100% spot on!)
This is comparable to CloudFormation or Terraform in terms of determining whether something is up-to-date, but more general purpose.