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:

enter image description here

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?

enter image description here

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.