[HN Gopher] Building storage-first serverless apps with HTTP API...
___________________________________________________________________
Building storage-first serverless apps with HTTP APIs service
integrations
Author : kiyanwang
Score : 22 points
Date : 2020-08-29 18:55 UTC (4 hours ago)
(HTM) web link (aws.amazon.com)
(TXT) w3m dump (aws.amazon.com)
| throwawaysea wrote:
| There is so much dependency on proprietary technologies here that
| anyone pursue anything serious should just stay away from the
| suggested architectures. If AWS were to raise prices in the
| future or to kick you off the platform, it would be that much
| harder to move elsewhere.
| NomDePlum wrote:
| Are those scenarios more or less likely than AWS lowering
| prices and in the future not kicking you off.
|
| If it takes less effort and time to build something with
| proprietary technology surely that is a benefit? You can then
| assess whether removing that dependency improves your position.
| jedberg wrote:
| Would you say the same thing to someone building all their
| software to compile on Intel? What if Intel doubles the prices
| of their CPUs? Then what?
|
| The lock in argument is sort of silly. Everything has some sort
| of lock in. It's just a question of whether the benefits
| outweigh the potential costs of the lock in.
|
| In the case of AWS, they give you incredible velocity since you
| don't have to built any of the infrastructure before you get
| started.
| abraae wrote:
| These technologies are fascinating and make good sense for some
| APIs for sure. But if I look at our APIs, and I don't think we're
| unusual, they characteristically are not "fire and forget".
| Instead, the API call actually returns some data in the API
| response! Even for POST /widgets, I want to pass back an
| identifier for the just created widget, not a 200 code that means
| "request accepted and queued but no data available right now".
|
| The uses for APIs that don't return data seem pretty limited in
| our realm (SaaS). One example is handling incoming
| notifications/webhooks from other systems. By their nature these
| are asynchronous and the caller (the external system) does not
| usually expect a meaningful response, so for sure we can use SQS
| to buffer the incoming API calls.
|
| But for the APIs that we offer, virtually all of them have an
| online response. In my experience this is not an unusual pattern
| (for SaaS APIs anyway).
|
| I feel that these technologies are somewhat biased towards super
| scale systems that are highly decoupled and asynchronous -
| perhaps the sort of systems that Amazon are used to dealing with
| in-house - rather than simple old business systems.
| wgjordan wrote:
| "The advantage of this pattern is increased application
| resiliency", as spelled out in the first paragraph. So yes,
| these technologies are 'biased towards' systems that require
| this degree of resiliency rather than 'simple old business
| systems'.
| abraae wrote:
| Simple old business systems require resilience too.
| talawahtech wrote:
| This is awesome and long overdue. Providing a simple way to go
| directly from an HTTP endpoint to SQS, Event Bridge or Kinesis
| makes it much easier to build more robust webhooks or tracking
| endpoints.
|
| I have tried doing similar things in the past,using API Gateway
| and SQS without Lambda, and it was a huge pain.
|
| I wish they had skipped coining the "storage-first" buzzword
| though. I mean, I get it, but I feel like it hurts more than it
| helps.
|
| My first assumption was that they were just talking about writing
| data to S3 and then using Lambda to process after.
| xellisx wrote:
| What I want is a storageless-first serverless connectionless
| computerless apps.
| wolfgang42 wrote:
| I think you may have just invented the whiteboard.
| deegles wrote:
| How is the the SQS pattern bidirectional?
___________________________________________________________________
(page generated 2020-08-29 23:00 UTC)