Maybe I'm misunderstanding the question, but you may want to have a look at Envoy: https://www.envoyproxy.io
Ask HN: How do you keep track of releases/deployments of dozens micro-services?
51–56 of 56 posts
Re: Ask HN: How do you keep track of releases/deployments of dozens micro-services?
#52Earlier quoted context omitted.
That's a great model. Do you use cloudformation each for deployment? If so, have you thought of creating a single cloudformation template for the whole deployment so you can do the entire deployment in one stack update? Have you encountered any issues to watch out for when only using one APIG for each environment (150 micro-services). Have you encountered any downsides to doing this versus 1 micro-service to 1 APIG?…
We don't use cloudformation because honestly, it sucks. It's hard limits are a pain in the ass to get around (with 150 lambda functions, we need hundreds of resources, so that means nested stacks, which just suck) and it managing the api gateway just doesn't do what we want. We have a custom script to deploy our own API Gateway using the AWS SDK and we generate a swagger file from simple json config files. For the AP…
That's very valuable advice. Thank you. I've been following the serverless.com model of 1 APIG to 1 lambda, but that quickly puts you over the AWS limits when trying to manage hundreds or thousands of micro-services.
Re: Ask HN: How do you keep track of releases/deployments of dozens micro-services?
#53Earlier quoted context omitted.
We don't use cloudformation because honestly, it sucks. It's hard limits are a pain in the ass to get around (with 150 lambda functions, we need hundreds of resources, so that means nested stacks, which just suck) and it managing the api gateway just doesn't do what we want. We have a custom script to deploy our own API Gateway using the AWS SDK and we generate a swagger file from simple json config files. For the AP…
That's very valuable advice. Thank you. I've been following the serverless.com model of 1 APIG to 1 lambda, but that quickly puts you over the AWS limits when trying to manage hundreds or thousands of micro-services.
Yup yup, I went down that path and converted our then very basic deployment process to use serverless and instantly hit hard limits.
Re: Ask HN: How do you keep track of releases/deployments of dozens micro-services?
#54We use gitlab CI for pipelines which is great. You can figure out when everything was deployed last etc. We even built our own dashboard using gitlab api that shows all the latest deploys, just so its easier to track down what was recently deployed if we are investigating issues.
Did you opensourced it? I'd love to use that too :)
Re: Ask HN: How do you keep track of releases/deployments of dozens micro-services?
#55Earlier quoted context omitted.
Thanks for adding more color to your original answer. I like you enforce the commit/ticket relationship. Is this purely an agreed process or do you use other measures to keep things consistent? E.g. we typically add the ticket ref to each commit but at times that gets omitted. Also, I think that (internal) release tool is something crucial as the team grows. Will check shipit a bit further. Would you mind expanding a…
Sure my pleasure. > I like you enforce the commit/ticket relationship. Is this purely an agreed process or do you use other measures to keep things consistent? E.g. we typically add the ticket ref to each commit but at times that gets omitted. We're not enforcing it but we might in the future if the team grows and this gets out of hands. At the moment we're just reminding people that they should and it works great so…
Thank you!
Re: Ask HN: How do you keep track of releases/deployments of dozens micro-services?
#56We use gitlab CI for pipelines which is great. You can figure out when everything was deployed last etc. We even built our own dashboard using gitlab api that shows all the latest deploys, just so its easier to track down what was recently deployed if we are investigating issues.
Did you opensourced it? I'd love to use that too :)
No. Its currently very specific to our org. But i'll consider making it more generic and open sourcing it now.