Just read this article https://12factor.net and found out dev.to has a series of podcast on 12factor. I will manage to listen to podcast. While reading, I am also checking how many factors I have applied completely, partially, or even none on projects I have involved. Surprisingly, all these 12 factors, in my opinion, can be shown on projects. However, it is just the matter of how much we enforce each factor in projects.
Taking the codebase factor. We have tried to follow microservices architecture to organize projects. However, I still can see the duplicated functions or codes among projects. The bad thing about the duplications is that some of functions or APIs provided by a service are under very low utilization for any reasons, which are still maintained by developers. However, you cannot directly remove those functions from a service since there could be some coupling inside.
Another factor I think we can enhance is to minimize the deployment difference for dev, staging, QA, and PROD, which is Dev/prod parity factor. The problem we are facing in this factor is that the app must detect environment the app exists and then get or load proper configuration values to complete the app initialisation. This detection adds extras a bit meaningless test codes like mocking staging, or QA environments.
Top comments (2)
Hi!
I wouldn't see it as a necessarily bad thing. It depends on how big the duplication is. A function that converts a string to a date object it's probably going to appear in more than one microservice but is it worth it to isolate it in a service? That is probably over kill :D
If instead you see entire pieces of business logic replicated among services (regardless of the API on top of them) you might decide to group them in a shared repository (altough this adds packaging and shipping complexity becase now you have one more repository to sync). Or you can extrapolate such business logic in a separate service and migrate the two with the duplicate logic to the third one, one step at a time.
Just throwing ideas out there :D
12 factor is an interesting methodology with many good practices like version control, config management, build pipelines, logs as event streams. But some points are more opinionated like "concurrency through process model" or "port binding". IMO, they are too influenced by the language choice. Languages/runtimes like erlang, go, jvm can handle threads (light weight and native) well.