
Ask HN: AWS lambda pricing/lock-in concerns - prmph
We are building a data analysis app, and AWS lambda seems to offer a scalable, secure, and easily administrable engine for the computationally-intensive parts of the app.<p>The pricing structure is reasonable for now, but we are uneasy about becoming dependent and locked into lambda, should the pricing change dramatically in the future (this is Amazon, after all).<p>Is this a valid concern? And, if so, how can it be mitigated?
======
QuinnyPig
I track AWS pricing for a living. I’ve never yet seen a price for a released
service increase; they have historically only gone down.

That said, the cost of the data itself is going to likely drive where you go.
Porting functions to another provider is likely to be a challenge; each
implementation has special unicorn warts to it.

------
akhatri_aus
Use an abstraction like Serverless so that you can easily switch to another
provider.

~~~
dyeje
This is the correct answer.

------
idunno246
Lambda seems like a pretty easy thing to change. The interface is just a
single stateless function call, you could probably write a shim to any other
system if it came to that. In general my feeling on lockin is I'd rather get
the app done a month sooner, focus on my business at the small cost of being
locked in.

If the concern includes leaving aws in general, data is a bigger issue. It's
incredibly expensive to move data out of AWS, both in time(you probably have
to make something distributed) and money. Also, if you choose one of the
really native datastores like dynamodb, that could require a lot of code
rewrite. But actually leaving, especially for price, is not something Ive
heard many people do - often engineering time is worth so much more than
servers its gotta be significant to make sense.

~~~
prmph
Interesting. What makes it so much more expensive (in monetary terms) to move
data out of AWS? Is it that data egress is priced much higher than ingress?

~~~
idunno246
yea, ingress is free on the aws side, and egress is expensive.

The other thing is with a large amount of data you hit weird performance
issues. Say you want to copy all your files on s3. One typical way of doing
this is s3distcp in emr/hadoop, so you get distributed copying. But generally
listing is single threaded, and if you have billions of files your cluster
spends a noticeable amount of time idle while the master is doing the listing
operation. Also list api costs can add up. S3 inventory probably alleviates
this, it didnt exist at the time.

So ignoring 'BigData', how would you shift a mysql database out. its either
take downtime or do streaming replication or something. Gotta keep
consistency, not lose writes, etc.

moving stateless code around is so much easier than dealing with data. theres
basically zero straight monetary cost to the move, you just deploy it
somewhere else.

------
taf2
If you use node.js you can run on at least aws, gce and azure and have the
benefit of

1\. Cost saving because of zero cost for small usage each month

2\. Ha if one provider is down reroute to the other

3\. Reduces lock-in

Perhaps they will all eventually offer other languages as well, but at least
it used to be node.js 6.x that was common on all three.

