[sime2009]

We've been doing this too for some "logical" services. For example, we might have a service which has a REST API and but also needs to do long running processing in response to requests via said REST API. The code for both lives in one repo and can share code, data structure definitions, databases etc. One container is made but we deploy it twice with different args. One is set to run the REST API,and the other runs the processing. Both are closely related, but in the cloud we can scale and monitor them separately. It gives a lot of the benefits of "standard" microservices with much less of the code and repo level screwing around. It relaxes the general microservices approach that: one service == one git repo == one database == one container == one deployment in GCP/etc.