I’ve gone through the forums endlessly and while I’ve seen a lot of mentions of cross-stack references but I havent been able to find a good example. I really need this as I’m hitting the limit on max resources allowed by cloudformation. I want to move to a full microservices architecture where each service has its own stack/template, and I can do deployment through one master serverless.yml file.
Here are the steps, that I’m following:
I use serverless to deploy the first stack with some services - this gets deployed.
I then go to s3, get the template that serverless has made in the bucket, and add that template URL to my serverless.yml file in the following format:
Is this the right way to do it? If not, what would be massively helpful, as a lot of people are requesting this from what I’ve seen is if someone could provide the steps that are required and then what to input in serverless.yml.
I’m aware there are nested templates, but I believe cross-referenced templates are a much better approach. Would love to know if anyone has a different opinion.
Thank you!
@rowanu On all the threads that I’ve seen, you’ve been really active with this issue, I hope you dont mind me tagging you - but if you could provide some guidance here - it’ll be really really helpful. Thank you
Unfortunately I don’t think you can have what you’ve described, and do a deploy though a single master serverless.yml file. The output of a serverless.yml is a service, so it doesn’t make sense to manage multiple services in it…
Nested stacks sound like a good idea when you first hear of them, but don’t work as well as I would expect/hope for a variety of reasons; if a nested stack has an issue then the failed status applies to the parent stack (because the nested stack is a resource of the parent stack, and if a resource fails to deploy then the stack has failed). Nested stacks usually result in highly coupled stacks, because their definitions are so intertwined - not something you should want in a microservices architecture; You want your services to be loosely coupled.
What you want is what is described in this docs page. By specifically Outputting (and Exporting them) the values you want to share between stacks you end up declaring your interface between your services, which encourages loose coupling I mentioned earlier.
The trick with cross-stack references is that they must be unique in the account + region they are in. The easiest way to do this is to include the stack name in their name, but that then becomes another parameter you would need to pass. This has the added benefit of meaning you can point to specific versions, and upgrade them at a later date by changing the name/version of stack/service you point to.
I think cross-stack references also lend themselves well to the layer cake approach to CFN, which is a tried and tested strategy that I don’t see used nearly enough. Unfortunately I don’t have any template I can share showing all these things together, but I will do a blog post on it soon.
Personally, I don’t try and be too pedantic about the “micro” in microservices. The smallest unit of functionality is a (Lambda) function, and I have no issues re-using functions where it makes sense/does not make them too complicated.
