
Building storage-first serverless apps with HTTP APIs service integrations - kiyanwang
https://aws.amazon.com/blogs/compute/building-storage-first-applications-with-http-apis-service-integrations/
======
abraae
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
"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
Simple old business systems require resilience too.

------
talawahtech
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
What I want is a storageless-first serverless connectionless computerless
apps.

~~~
wolfgang42
I think you may have just invented the whiteboard.

------
koluna
This is all nice, but here is the important part you gotta remember - the more
you take dependencies on AWS and its integrations, the harder it will be to
actually have any flexibility and say in your own systems design. AWS is
interested in taking your money first and foremost as well as having you
depend on it from one side to another of your stack. Instead I’d look at
containerizing my workflows and only using cloud tools on the edge (like load
balancing).

------
throwawaysea
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.

~~~
jedberg
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.

~~~
ryukafalz
> Would you say the same thing to someone building all their software to
> compile on Intel?

If they’re targeting Intel processors only and not x86 more generally? Yes, I
would.

Otherwise, there’s at least one credible competitor (AMD) that’ll gladly sell
you compatible processors, who I’m sure would be happy to see the increased
sales if Intel jacked up their prices.

~~~
jedberg
AWS has two competitors, so I'd make the same argument back to you.

~~~
ryukafalz
As a sibling comment pointed out, applications built for x86 PCs don't even
need to be recompiled to run on compatible processors by another manufacturer.
(Heck, even across architectures you can usually recompile relatively easily
provided the software is written in a high-level language with a compiler
available there.) That is very much not the case with cloud providers' APIs;
they're largely provider-specific.

The closest equivalent in the cloud provider ecosystem is probably Kubernetes;
there are provider-specific extensions (and I recommend avoiding those where
possible) but largely things work the same across providers.

I'd say a more representative example of lock-in in the PC ecosystem is that
of proprietary OS vendors. If you're targeting specifically iOS/Android (w/
Play Services)/macOS/Windows/etc, then yes, you're beholden to the vendor (to
varying degrees in each case).

You may accept that risk, but you should always be aware of it.

------
deegles
How is the the SQS pattern bidirectional?

