Note: After starting to write this blog post series, AWS announced that API Gateway HTTP APIs could now route requests directly to five new services including Amazon Kinesis Data Streams. As a result I adapted the content of this series to account for that, however, it is possible some remnants of prior versions exist in the text.
If you notice any such sentences or fragments, please let me know on Twitter (my DMs are open or tweet me publicly).
This blog series has the following goals:
provide one take of serverless application design and philosophy;
discuss serverless design space options at a very high-level but we will choose a specific path so we can build a working application more quickly;
introduce Kinesis Data Streams and Firehose concepts linking to supplemental materials for a deeper dive;
A serverless philosophy
The term serverless means different things to different people. Depending on who you ask, it can mean anything from using specific AWS resources a certain way to leveraging any programmable "cloud" technology to dynamically scale up and down (all the way to zero) based on customer/user demand.
For the purposes of this blog series we will take the latter position yet we happen to leverage AWS resources (since I have more experience using AWS resources to build production serverless applications).
Scaling down to zero is an important part of the idea of serverless from an operational economics perspective.
I wrote some musings about cloud computing infrastructure previously if anyone is interested in a personal historical take.
Problems with data streams:
poison pill messages (getting stuck)