9 ms·
>The whole idea of serverless is so you don't have to manage infrastructure That's one of the ideas. Serverless shines for burst-y traffic where the traffic ti
by discordance 7y ago
>The whole idea of serverless is so you don't have to manage infrastructure
That's one of the ideas. Serverless shines for burst-y traffic where the traffic timing is unknown. If I had known static high loads I wouldn't use serverless.
- Jack000 7y agoisn't that just a limitation of the current incarnation of serverless systems? ie. serverless is only effective for burst traffic because it's expensive. You would think that after you tailor the code to the platform and make it stateless, it would cost less for the cloud provider and not more.
- icebraining 7y agoIf Amazon has to dedicate a full server permanently to your applications, I don't see why it would cost them more or less depending on the statelessness of your application.
- jfoster 7y agoAre you sure your assumption that Amazon still has to dedicate a full server permanently to the application is correct?
- icebraining 7y agoIf you application, due to the requests it receives, consumes enough CPU time to occupy all the cores available in a server and/or most of its RAM, how can they not?
- cuu508 7y agoBursty or not, if the aggregated number of requests per day is in millions not hundreds, AWS API Gateway & Lambda is significantly more expensive than the more traditional options.
- ShinTakuya 7y agoNot if you have to serve 1 million requests in one second (with low latency) and then don't get any requests for the rest of the day. On the contrary, traditional options will probably end up costing a lot more since you'll need to have them ready in advance to serve the requests instantly and so you could be paying for the entire day of capacity or at least several hours.
- eternalban 7y agoSo possibly a good fit for IoT.
- jacquesm 7y agoYes.
- eternalban 7y agoSpecially considering the staggering effect due to predisposition to picking a cardinal direction - 0/15/30/45 minute - in the clock. This is a real issue specially for SaaS offerings in the IoT space.
- TickleSteve 7y agoNo. It depends on the IoT application. The one I'm involved with (smart metering) produces data at regular 15 minute periods 24/7. This is a very predictable and constant traffic load and not at all suitable for serverless/lambda. In fact, its the complete opposite. Many IoT applications are very predictable (anything with regular sensor-readings for example or with repeatable patterns such as people returning from work and turning things on).
- eternalban 7y agoWhat you need to consider [is] that there are a lot of applications like yours hosted by an IoT SaaS. (I work on one.) So the patterns are (obviously) predictable, but the 'dynamic range' of the load is extremely wide, ranging from stampedes on the cardinal points of the clock face (0/15/30/45 min) to crickets the rest of the time. Some form of elasticity is required unless you are willing to pay for idle servers sized for the episodic peaks.
- tedk-42 7y agoBurst traffic with high writes? --> Use a stream. Burst traffic with high reads? --> Use a cache. Large compute and memory intense stuff isn't suitable for serverless
- orasis 7y agoServerless works great for my apps. My traffic is driven by hourly notifications so I get 100x more traffic on the hour than the rest of the hour. I could write a bunch of ML to figure out load scaling but that is code I don't want to focus on.