# platform-blueprints

אפי שטיין

10/17/2022, 12:45 PM
Hey guys, I have some question I think are basic but I just can’t find any best practice, tradeoffs, whatever When working with lots of microservices, eash has it’s own requirements for infrastructure it always get to a time where one service infra depends on another service (in aws worls, one sqs depends on another sns for example) how do you manage it in integration environments ? • always deploy all the infrastructure ? • recursively deploy dependencies ? do you store the infra code with the service repo (same repo) ? in a centralized infrastructure repo? when having multiple “preview environments” / dynamic environments / ad hoc environments, how do you keep them in sync ? when having terraform code change, is it a different pull request then code changes ? how do you make sure it is deployed before other pull requests ?

Aleksandar Borkovac

10/17/2022, 8:50 PM
I would first separate app code and infra code in different repos. For example ‘order-service’ and ‘order-service-infra’ The ‘-infra’ code should ideally be simple usage of some reusable terraform (for example) module (oss or built in-house). I think this could work but only if you have team which is little bit more mature with cloud tech. You can kind of have internal oss and you share a bit responsibility between platform and app teams. In case you do not have mature teams, I would completely separate app code and infra. App code owners are the app teams and infra code owners is the platform team. I talked to a lot of app developers, presented both options but they simply don’t want to hear about terraform, they just want connection string (it was DB in my case).

Cruise Hall

10/18/2022, 12:09 AM
In the past I found it helpful to separate “stateful” from “stateless” stacks (even if deployed from the same repo technically) - you should be able to delete and recreate all of your stateless stacks without losing state

אפי שטיין

10/19/2022, 11:56 AM
Not all the problems I have now won’t be solved by splitting the code to infra and application I’d still have cross services dependencies which are hard to handle It even make stuff harder since service a code depends on service a infra It’s harder to version them separately
Specificity regarding stateful/stateless apps, I don’t have any issues in this area But I’ll give it a thought, thank you :)