One of the many useful abstractions that AWS offers is scalability. Your function automatically scales up and scales down depending on the amount of workload that it has to deal with. This is not only cost effective but now developers don’t have to think about scaling. Because, of course, that’s one of the nastiest problems to think about.
Thankfully, AWS takes care of that, if the traffic increases by ten-folds, then your function starts running in ten times as many containers as before. The containers divide the workload among themselves and work together like numerous little ants lifting a heavy sugar cube.
This is known as concurrency. By default, AWS throttles the number of concurrent executions to 1000 across all your functions, in a given region. If your service encounters traffic more than your AWS throttle limit can allow, the newer requests get either queued for being processed later or they get dropped. You can know more about throttling behavior here.
Essentially, the reason behind a certain function’s throttle could come out of limitations set by your configurations or because of limitations imposed by AWS on your account.
Throttling aside, this kind of scaling, where you scale linearly as your workload increases or decreases, is what we desire. This gets difficult when considering stateful applications.
The stateful conundrum
Before we get into statefulness, let’s begin with a simpler stateless scenario. Loosely speaking, a stateless application or service means that there is no persistent or changeable data stored somewhere in our infrastructure. The function is invoked by a trigger event and responds to that event in a predictable manner. If the exact same event happens twice, the response would be the same for both the cases. Any piece of information that your service might need is provided by the event itself.
Stateful applications, on the other hand, are written to be aware of multiple factors apart from the trigger event. Here’s an example. If you have a database that a user is trying to access, then the outcome of that action is determined not only by the user’s request but also by what is stored in the database. The state of the database.
Throw concurrency into the mix and we have a bunch of edge cases to handle. Going back to the database example, if one user tries to read a particular record and another user tries to modify it then we can’t do both the operations concurrently. Only after one user is done with the record does the other get to have their turn at it. The operations need to happen in sequence, one after the other. Even if processes are running concurrently we are still stuck waiting. The benefits of concurrency are still there, but are limited by the design of your software. We have to take everything into account, including the sequence in which requests arrive and which kind of requests we receive. As you can see, there are too many moving parts.
#aws #concurrency #synchrony
