GoogleCloudPlatform / microservices-demo

Sample cloud-first application with 10 microservices showcasing Kubernetes, Istio, and gRPC.
https://cymbal-shops.retail.cymbal.dev
Apache License 2.0
16.7k stars 7.11k forks source link

Re-structuring the code/microservices according to the best practices #225

Closed bhajian closed 5 years ago

bhajian commented 5 years ago

I believe the current repo structure encourages bad practices for microservice development and repo structure for CI/CD.

As stated in these blogs, microservices should be independently deployable.

This makes each service to be easier maintainable. If we are encouraging the community to use the best practices we should follow the best practices and organize the code with the best practices. in https://12factor.net/codebase code base requires us to develop each service in a separate repo. However, I think that could be too much for a sample app like this. I suggest the middle ground: 1- Instead of developing each microservice in a separate repo, we develop each microservice in a separate folder as is in /microservices instead of /src 2- each microservice should be self-contained. That means each microservice should contain the dockerFile as well as deployment scripts and kubernetes/Istio manifest files. This way we will be able to treat each service as a plugin. This educate the audience of this repo to learn the best practices for not only developing microservices but also how they can organize their CI/CD code in a separate repo.

My suggestion:

root

|--- /microservices

   |--- cartservice
   |--- adservice
   |--- ...

each service should contain: e.g.,

   |--- cartservice
           |---src
           |---test
           |---...
           |---deployment
                  |---dockerFile
                  |---kub-cartservice.yaml
                  |---istio-cartservice.yaml
                  |---build.sh
                  |---dockerFile
ahmetb commented 5 years ago

While some of your your points are valid, overall this simplifies the demo app and keeps discovery smooth for people visiting the repo.

we develop each microservice in a separate folder as is in /microservices instead of /src

each microservice's source code is already isolated, and directory name doesn't matter (in fact, /microservices is a worse name).

2- each microservice should be self-contained. That means each microservice should contain the dockerFile as well as deployment scripts and kubernetes/Istio manifest files.

Each service's directory already contain dockerfiles.

I don't agree with moving deployment manifests to src/{service}. How a service is deployed is independent of the source code is manifest (e.g. code and config are separate, while you can still treat the config as code, but you don't have to maintain them coupled).