Reading Time: 3 minutes
For 12 factor application the No. 1 principle is one source code base. Today I was thinking about this topic: one sets of source code for one app, and use configuration for language, region or other different settings for different customers. And this reminded me of some of the articles I read (such as this one: Building a versioned UI deploy system for fast, stable deploys and rollbacks, actually this one “Managing Customer Releases with Feature Flags instead of Branches“, both from Blend Labs, that’s why I was a bit confused 😐 ) and a few apps I worked on in last 3 or 4 years: note those apps include both monolithic, cloud native apps and somewhere in between.
At current place, I noticed one thing odd. We have different code bases for different locale (country) for one of our key apps: basically two sets of code (mostly identical) for apps for 2 countries. This seems to me not good architecture and a bit unusual. Without going into all the details and history (I was new to the team, and it’s also not good to point fingers anyway). So the direct cost I see now is to maintain two sets of code bases (very similar) and two apps: in other words thinking along the lines of the cost of developer, admin and infrastructure and so on.
On the contrast, at a former place I worked at, we have many white label customers, and we serve them on one set of code base and one set of apps (for the most part). All the differences between customers are addressed via System Maintenance (a web based configuration app). Web services for all the customers is running on one app on multiple servers (load balanced). The customer facing website is similar with one caveat: at one time we realized for one country the customer has traffic spikes from time to time, so that app for that country is put on dedicated “overflow” server: still the same code base with the difference in the configuration.
And at today’s world, we also increasingly hear more about multi tenant(s). The scenario I described above, as well as the medium article mentioned at the first paragraph, is along the same lines. And during Covid, at the former place I worked (a healthcare provider, to be more precise, the No. 2 US based hospital chain in terms of size), we developed a Covid screen app, for internal, as well as external customers (for example, Indiana Pacers). At the very beginning, we speed up the development by deploying the same code base to different org / spaces (essentially each customer has its own database). Later on we consolidated quite a bit, by changing the code to handle multiple customers (multi-tenant, if I may). In both cases, the source code is the same. The difference being in the early days, we used more resources because each customer has its own database, and its own app. And there is maintenance headache as well, for example, deployment and validation will take hours.
PS: one more thing. Once I did copy and paste of javascript code because I was not very good at javascript and I did not know how to do either inheritance or composition in js. The downside of doing this is also obvious: if there is bug in the code, we need to change it in 2 places. This is just a small example of why we don’t want to duplicate code.
PS 2: now I recall another company. This company is the No 1. medicaid provider in the nation, and has operations in probably 20 to 30 states in the US. Note medicaid is administrated by the stat, unlike medicare which is administrated by the federal government (CMS). I saw two issues one is re: code and another one is re: infrastructure. So because each state will have its own customization, what they did is they branch out code for each state (so basically a master branch and let’s say 20 branches for each of the state). On the infrastructure side, they scale up horizontally, so basically each state has its own database server (Oracle), and its own application server and so on (this is also dedicated by the source code). So this is their implementation of “multi-tenant”. Not very flexible to say the least. They also have a horrendous interview process and work culture too, which I won’t delve into.
