My current employer has a single namespace into which all microservices for all projects are deployed.
Projects A, B and C all use microservice x in this common namespace:
Rather than each design and implement their own microservice that performs the same behaviour (for example for some common domain object CRUD operations against a database), Projects A, B and C all use and claim shared-ownership of a common implementation - microservice x - and service it in accordance with their project requirements.
Projects are upsetting the shared ecosystem for each other when deploying revised versions of x (downtime, breaking changes).
I am unclear if this is an example of what Kubernetes best practices considers to be an example of an "overcrowded namespace" anti-pattern - I am thrown by the fact that each project utilises a common microservice and I thought one of the points of microservices was to expose common things in a kind of public way like this?
Is it appropriate for this "public exposure" to manifest as a single service instance in a common namespace?
Or should the namespaces split apart and they all have their own deployment of microservice x like this?
