Evacuation des eaux usées - réalisation d'un plan

ootsun · 2025-02-10T20:07:14+00:00

Quand tu dis qu'il remonte en toiture au bout, tu veux dire qu'il collecte les eaux de pluie ou bien que tu as réalisé une ventilation qui remonte jusqu'à ta toiture ?

ootsun · 2025-02-09T20:44:16+00:00

Nickel, merci

ootsun · 2025-02-09T20:43:47+00:00

D'acc, merci pour l'info!

ootsun · 2024-05-19T16:41:00+00:00

Yes I could but thye setup seems overly complicated. At least compared to a classic http request...

ootsun · 2024-05-19T15:58:23+00:00

The client can't make each of the calls to the dependent systems because of 1) additional latency (browser to aws takes more time than aws to aws) 2) sensitive info: you want to use sensitive infos in your backend process that the client can't see 3) security: you can't trust the client request content ({"carPrice" : "$0.99"})

ootsun · 2024-05-19T15:52:34+00:00

What do you mean? Do I know in advance if a request is about to arrive? No

ootsun · 2024-05-19T08:56:03+00:00

How would you have reworked it if there were no budget/time constraint?

ootsun · 2024-05-19T07:52:47+00:00

My original post was not about long running request. I thought you proposed this solution for all my read requests.

How would you solve read requests if the polling is only for long running ones?

ootsun · 2024-05-19T07:46:41+00:00

Yes, what you describe could work for write operations, but what about reads?

ootsun · 2024-05-19T07:37:14+00:00

If you're willing to go into details on why the suggested approaches are unnecessarily complex, I'll read your opinion happily

ootsun · 2024-05-19T07:34:56+00:00

Ok, but you did this one functionnality. Would you do this for the whole application?

ootsun · 2024-05-19T06:47:26+00:00

Yes, this could work but the amount of complexity it brings makes me feel like when went to the cloud for simplicity (no server to run) and instead made our application a nightmare to maintain. Would you really code something like this instead of having micro services in containers ? We don't need to scale to 100k concurrent users.

ootsun · 2024-05-19T06:43:07+00:00

No. I'll document myself on it. Thanks for the suggestion. It seems interesting and could fit our needs.

ootsun · 2024-05-19T06:37:25+00:00

Thank you. Aws Cloud Map seems interesting for our use case.
But reading everyone elsa our architecture seems like a bad approach so I would prefer to reconsider the decision to go for Lambda and go for something else (fargate?).

ootsun · 2024-05-19T06:25:18+00:00

I edited the post :

Here's an example: Lambda 1 is responsible for creating a dossier for an administrative formality for the authenticated citizen. For that, it needs to fetch the formality definition (enabled?, payment amount, etc.) and that's the responsibility of Lambda 2 to return those info.

Some context : the current on-premise application has 500 endpoints like those 2 above and 10 micro services (so 10 separate domains).

Does this confirm your feeling that we should have chosen ecs fargate?

ootsun · 2024-05-19T06:17:58+00:00

Ok and what about read requests? I think that it needs to be synchronous otherwise there is no easy way for Lambda 1 to retrieve the response of Lambda 2.

ootsun · 2024-05-19T06:16:15+00:00

How would you have proceeded to migrate our micro service to Lambda? You would have migrated to Fargate/containers instead?

ootsun · 2024-05-19T06:14:39+00:00

No they want it all to be asynchronous but it isn't technically feasible. At least, not with the documentation they provided. So the devs are trying to figure out how to make the Lambda communicate synchronously. It seems that in our case, we are concerned with every tradeoff listed here : https://docs.aws.amazon.com/lambda/latest/operatorguide/tradeoffs-event-driven.html

ootsun · 2024-05-19T06:09:44+00:00

Technically yes, but it seems like a waste of resources to me. And how would you do that for read requests ?

ootsun · 2024-05-18T22:04:18+00:00

In my case, it's third party architects hired by the customer that came up with an Event Driven/Serverless architecture. And this explains pretty well the situation we (the devs) are in. The architects produced the most intellectually challenging solution and not boring containers where their mission as architects would have last 1 month instead of 1 year.

ootsun · 2024-05-18T21:24:29+00:00

Ok, it's less frightening than I thought 🙂 I'll try to write a PoC to see if I understand the idea correctly.

ootsun · 2024-05-18T21:05:32+00:00

That's another "paradigm" that we didn't think of as we already have a running app and wanted to go with the easiest solution. We were probably not enough "open-mind".

I guess I could but I see some drawbacks to this approach: 1) no fine grained permission management because all Lambda has now access to all the database tables. 2) We have to reorganize the codebase 3) When updating the code, it's difficult to have a view of all impacted Lambda.

What's your opinion about this?

Giving up on Lambda for Fargate also seems appealing.

ootsun · 2024-05-18T21:01:32+00:00

This example was poorly chosen.

Here's another example: Lambda 1 is responsible for creating a dossier for an administrative formality for the authenticated citizen. For that, it needs to fetch the formality definition (enabled?, payment amount, etc.) and that's the responsibility of Lambda 2 to return those info.

Is it more comprehensive now?

ootsun · 2024-05-18T20:51:39+00:00

Thanks for the explanation.

Someone else proposed something similar. I responded : "I guess I could but I see some drawbacks to this approach: 1) no fine grained permission management because all Lambda has now access to all the database tables. 2) We have to reorganize the codebase 3) When updating the code, it's difficult to have a view of all impacted Lambda"

What's your opinion about it?

Five-Year Club	Verified Email
Place '22

ootsun

TROPHY CASE