undefined | Better HN

0 pointsjrowley8y ago0 comments

Just to be clear, all of your functions exist inside one mono-repo, correct? You don't use git submodules at all?

Looks like a pretty solid build process. Thanks for the insight!

0 comments

Yes, we have all of our functions in a single mono repo, broken into projects, and then folders for each function, similar to this:

- src/project1/function1/

- src/project1/function2/

- src/project2/function1/

- src/project3/function1/

- src/project3/function2/

- src/project3/function3/

Deploying the functions is done by project, so we deploy all of one project, then move to the next, and so on and so forth.

greendata8y ago

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? I'm also running into the Gateway throttle limits and I think deploying many micro-services (like you have done) to 1 APIG is the best solution.

Prefinem8y ago

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 API Gateway issues, so far, we have a few things that are something we have to watch out for.

- All lambda endpoints through APIG are lambda proxy type. This means we can have a framework handle standard request / response stuff. The downside is that we can't support binary endpoints easily because they haven't fixed that issue yet.

- HTTP proxy pass through endpoints have to be added to the swagger somehow before we deploy. This is a little annoying, but not a huge issue

- Merge vs Override for deployments. We merge in beta, and override in other environments. This allows us to keep endpoints exactly as they are, but allow flexible testing in beta

1 APIG for 1 micro service isn't great IMO at scale since we run all our endpoints under on domain and mapping all of them would be a pain.

1 more reply

j / k navigate · click thread line to collapse

0 comments

Prefinem8y ago

Yes, we have all of our functions in a single mono repo, broken into projects, and then folders for each function, similar to this:

- src/project1/function1/

- src/project1/function2/

- src/project2/function1/

- src/project3/function1/

- src/project3/function2/

- src/project3/function3/

Deploying the functions is done by project, so we deploy all of one project, then move to the next, and so on and so forth.

greendata8y ago

Prefinem8y ago

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 API Gateway issues, so far, we have a few things that are something we have to watch out for.

- HTTP proxy pass through endpoints have to be added to the swagger somehow before we deploy. This is a little annoying, but not a huge issue

- Merge vs Override for deployments. We merge in beta, and override in other environments. This allows us to keep endpoints exactly as they are, but allow flexible testing in beta

1 APIG for 1 micro service isn't great IMO at scale since we run all our endpoints under on domain and mapping all of them would be a pain.

1 more reply

j / k navigate · click thread line to collapse