4 ms·

What does idempotency have to do with serverless? That seems more like a general systems principle.

by zmgsabst 4y ago

zoover2020 4y ago
Event-driven architecture going haywire, think S3 --> Lambda recursion
- zmgsabst 4y ago
  Right — I understand why idempotency is a good idea. What makes this “serverless” rather than just good design, even if your API is on a traditional server?
  - ldoughty 4y ago
    Failure rate is higher in cloud severless than on transitional machines or in VMs... Especially since many people do not do the extra steps necessary to skip going too the edge of the cloud provider and back in.. do they often go through additional services that can break that make never would when the requests are on the same box. We see something like .0001% failure rate with API gateway behind custom DNS, and supports response was "this is in SLA, try adding retry code" (which needs idempotency). So we have to do extra engineering, including idempotency and bypassing API gateway in some cases, to mitigate the issue.
layer8 4y ago
You are completely right, it has nothing specifically to do with serverless.
barbazoo 4y ago
They go into it a little bit by referring to AWS' 7 principles of well architected applications one of which is being event driven. From experience my gut feeling is a large number of services running on servers PaaS are event driven, therefore it's important to build them to be idempotent beause of the "at least once" property of many messaging systems.
westurner 4y ago
x ° x = x Idempotency > Computer science meaning https://en.wikipedia.org/wiki/Idempotence#Computer_science_meaning https://en.wikipedia.org/wiki/Idempotence#Computer_science_m... > Idempotence is the property of certain operations in mathematics and computer science whereby they can be applied multiple times without changing the result beyond the initial application. The concept of idempotence arises in a number of places in abstract algebra (in particular, in the theory of projectors and closure operators) and functional programming (in which it is connected to the property of referential transparency).
- westurner 4y ago
  "A comparison of idempotence and immutability" [immutable infrastructure] https://devops.stackexchange.com/questions/2484/a-comparison-of-idempotence-and-immutability https://devops.stackexchange.com/questions/2484/a-comparison... Ansible Glossary > Idempotency https://docs.ansible.com/ansible/latest/reference_appendices/glossary.html#term-Idempotency https://docs.ansible.com/ansible/latest/reference_appendices... : > Idempotency: An operation is idempotent if the result of performing it once is exactly the same as the result of performing it repeatedly without any intervening actions
ldoughty 4y ago
In my work in severless, we see 10-40 (known) dropped requests power day. I highlight known because many requests fail with transient network errors that never make it to our logs, and others fail somewhere in the cloud provider black box before we get a log, but the caller gets a response from the cloud providers load balancer. While 10-40 is not a lot in the scale of hundreds of thousands of requests per day (were not that large), when that request is a write event, that's very detrimental to customer perception/experience... It might even cost your business money (failing to turn off/delete something)... And the easy answer of "retry the request" fails with write events that are not idempotent... WHEN should you retry? A gateway error doesn't necessarily mean the back end didn't get the request.. just that your didn't get a response. It's even worse when what you'd expect to be internal communication has this same failure rate.. your back end processes getting a random 504 gateway error in places it never happened before.. breaking longer running processes.
- zo1 4y ago
  Welcome to the cloud. It has so many oddities and overall crappiness that's been excluded from all the marketing content. Places where you can engineer wrongly or shoot yourself in the foot. Sorry low effort response, I'm on a phone. But my experience resonates with your comment a lot!

What does idempotency have to do with serverless? That seems more like a general systems principle.

zoover2020 4y ago

Event-driven architecture going haywire, think S3 --> Lambda recursion

zmgsabst 4y ago
Right — I understand why idempotency is a good idea. What makes this “serverless” rather than just good design, even if your API is on a traditional server?
- ldoughty 4y ago
  Failure rate is higher in cloud severless than on transitional machines or in VMs... Especially since many people do not do the extra steps necessary to skip going too the edge of the cloud provider and back in.. do they often go through additional services that can break that make never would when the requests are on the same box. We see something like .0001% failure rate with API gateway behind custom DNS, and supports response was "this is in SLA, try adding retry code" (which needs idempotency). So we have to do extra engineering, including idempotency and bypassing API gateway in some cases, to mitigate the issue.

layer8 4y ago

You are completely right, it has nothing specifically to do with serverless.

barbazoo 4y ago

They go into it a little bit by referring to AWS' 7 principles of well architected applications one of which is being event driven. From experience my gut feeling is a large number of services running on servers PaaS are event driven, therefore it's important to build them to be idempotent beause of the "at least once" property of many messaging systems.

westurner 4y ago

x ° x = x Idempotency > Computer science meaning https://en.wikipedia.org/wiki/Idempotence#Computer_science_meaning https://en.wikipedia.org/wiki/Idempotence#Computer_science_m... > Idempotence is the property of certain operations in mathematics and computer science whereby they can be applied multiple times without changing the result beyond the initial application. The concept of idempotence arises in a number of places in abstract algebra (in particular, in the theory of projectors and closure operators) and functional programming (in which it is connected to the property of referential transparency).

westurner 4y ago
"A comparison of idempotence and immutability" [immutable infrastructure] https://devops.stackexchange.com/questions/2484/a-comparison-of-idempotence-and-immutability https://devops.stackexchange.com/questions/2484/a-comparison... Ansible Glossary > Idempotency https://docs.ansible.com/ansible/latest/reference_appendices/glossary.html#term-Idempotency https://docs.ansible.com/ansible/latest/reference_appendices... : > Idempotency: An operation is idempotent if the result of performing it once is exactly the same as the result of performing it repeatedly without any intervening actions

ldoughty 4y ago

In my work in severless, we see 10-40 (known) dropped requests power day. I highlight known because many requests fail with transient network errors that never make it to our logs, and others fail somewhere in the cloud provider black box before we get a log, but the caller gets a response from the cloud providers load balancer. While 10-40 is not a lot in the scale of hundreds of thousands of requests per day (were not that large), when that request is a write event, that's very detrimental to customer perception/experience... It might even cost your business money (failing to turn off/delete something)... And the easy answer of "retry the request" fails with write events that are not idempotent... WHEN should you retry? A gateway error doesn't necessarily mean the back end didn't get the request.. just that your didn't get a response. It's even worse when what you'd expect to be internal communication has this same failure rate.. your back end processes getting a random 504 gateway error in places it never happened before.. breaking longer running processes.

zo1 4y ago
Welcome to the cloud. It has so many oddities and overall crappiness that's been excluded from all the marketing content. Places where you can engineer wrongly or shoot yourself in the foot. Sorry low effort response, I'm on a phone. But my experience resonates with your comment a lot!