I like the idea of everything is in production. e.g.: All the code is running on production servers. It's just that development code is not available to all users.
e.g.: Instead of the following cycle:
write code locally -> push to staging server -> test on staging server -> promote to production server
We simply have:
write code locally -> push to server: limit access to local -> test -> unlimit: access.
What this means is that instead of thinking in releases, we start thinking in terms of access. There is no release in the traditional sense of the word. Rather we just make code that has been running all along available to a larger audience.
Now where this gets tricky is that, because you are removing the coupling, one can end up with a lot of the different versions of something running. Which can be a little complex to manage.
So, I was thinking, as a very simple approach to this .. what if we used port numbers as a means of versioning. For example: we might launch a process with the following port convention:
:[service_id][service_version]
For example, if we had the following services and versions:
| Service | Project ID | Version | Port |
|----------------|:-------------:|---------:|---------:|
| UserService | 1 | 1 | 8101 |
| UserService | 1 | 2 | 8102 |
| ProjectService | 2 | 11 | 8211 |
| ProductService | 4 | 300 | 84300 |
| ... | ... | ... | ... |
| ACMEService | 100 | 101 | 8100101 |
Note:
- I padded the port here with 8 .. just so that, by default, it should be running on, at the lowest: port 8100 (project_id: 1, version: 0)
Benefits:
- Just be looking at a process you can tell which version it is (and consequently consider terminating it etc etc).
- Predictable service/process locations based on just
product_idandversion - It also helps you to generate fairly unique ports ...
Does this make sense? Could this be a good idea?
Feels like there might be some negative side-effects that I'm not thinking of ...