Hacker News Reader

Comment by orf | Hacker News Reader

> I wonder how much of serverless is just AWS firing at Google (and Heroku, DO, etc) and other competitors.

It depends on what you mean by "serverless". Serverless webapps? Sure, maybe a fair bit. But the real killer feature of the Lambda service is that it's a universal extension mechanism for other AWS services. Want to run some shoddy virus scanning whenever an object is added to a bucket for compliance reasons? That's a lambda. Want to manipulate Firehose records before they are sent to the sink? That's a lambda. Want to execute some crazy Python function from an Athena SQL query? You guessed it. That's a lambda.

So when you say "It certainly hasn't made my life as a developer easier" it means you haven't needed to do these bespoke gluing together of stuff, because "being able to do this somehow" is infinitely easier than "not being able to do it at all because AWS hasn't exposed an API for this use case".

View on HN

...You realize you can do 90% of those usecases on your own hardware, with your own tools, within your own infratructure, with complete visibility into every bit without Amazon right?

I think the true geniuses are the ones who spent so much time trying to sell people on "Server Admin is hard, lets hire it out!" as well as building the billing and metering systems.

In a gold rush, screw panning, sell shovels (and pans).

> ...You realize you can do 90% of those usecases on your own hardware, with your own tools, within your own infratructure, with complete visibility into every bit without Amazon right?

This statement is a red herring. People don't flock to AWS because they want to use lambdas. Lambdas are adopted by AWS customers who already have their data in S3 or DynamoDB and/or already use one of AWS message brokers, and happen to stumble on a requirement for a background that runs asynchronously in response to an event, such as someone uploading a file to a bucket.

When that usecases pops up, the decision process consists of either adding a brand new service to be ran on ECS, add a background task on a service already being developed, or simply write the event handler and deploy it somewhere for AWS to run without us bothering about scaling and maintaining stuff. Writing and deploying the handler is an order of magnitude simpler to deploy and maintain, which happens to win over some technical discussions.

I'd disagree. I chose AWS over GCP precisely because of the relative ease of deploying Lambda. That in turn led me to use DynamoDB and S3.

I started off with GCP, Cloud Storage and Cloud Firestore, but it was such a hassle and in the end, I couldn't even manage to run my Cloud Functions. The 10s cold start time was another non starter factor that led me to switch.

Honestly, I don't see myself staying with DynamoDB or AWS lambda. I definitely prefer local-hosted data stores such as on a DO droplet, and I would have started off with them were it not for their shoddy service. AWS service has been extremely strong so far.

A couple of years ago I was contracting for a company, and their CTO was so fired up about Lambda that that created a project to start using it - without having any other service on AWS (yet). Small sample size, but still.

If you don’t see the value that AWS (or any other cloud provider) gives you then that’s fine. However that doesn’t mean it doesn’t exist.

IAM (consistent identity and access control across all of your estate) and KMS (at rest encryption of all data, partitioned by service) are two examples of two things that would be very hard to replicate on your own hardware.

Achieving the base functionality is not hard, getting some of the most advanced features is more of a pain. Rarely I see aws services sold for their advanced features, though. Somehow aws became the default for hiring / learning how to do DevOps.

For example: Setting up different SSH keys when deploying a machine is not hard; getting granular ACL is more complicated.

Getting encryption at rest is very service specific, for example Postgres has TDE (free, with paid support if my memory serves correctly); I'm sure there are some services where EaR has been implemented by aws and there is no OSS alternative.

> Achieving the base functionality is not hard, getting some of the most advanced features is more of a pain. Rarely I see aws services sold for their advanced features, though.

Base functionality is relative. The base functionality of IAM is that every server, pod, user or AWS service has an centrally managed identity controlled via RBAC that is used to access any other AWS resource, requires no long-lived credentials, powered via a flexible policy engine that can rely on principal and resource attributes, with updates to policies applied in seconds across the globe. The actual advanced functionality is more complex and useful in certain situations.

If your benchmark for base identity functionality is “different SSH keys for different servers” then I’m not sure what to say.

The same for encryption - the point is that it’s not very service specific with AWS. That’s the base functionality: encrypt this data (queue, disk, object, database, backup, whatever) with this key. Done. Consistent, transparent encryption at rest for every service, access controlled through IAM roles and policies.

A concrete example might help. I worked at a shop that had a decent monthly spend on AWS and other hosting fees. One intermittent task was rolling up hourly/daily logs into monthly stats. We could have used our existing infrastructure to provision, run, and bring down the hosts on completion and that would have worked. Over time that could have been effective.

Instead I suggested writing a Lambda service in Go and to run it incrementally (I think it was hourly and monthly). It worked out to tens of dollars per month, basically free. [At first it cost much more than this because the original implementation wasn't specifying known sizes for initializing collections that was constantly being resized in several places in its pipeline resulting in copying/double consumption plus severe fragmentation.]

The development, in particular versioning and deployment sucked back then. It's surprising to still hear mention of challenges so much later.

I've found lambda helpful for adding bits of code in other languages to your stack. Want to use a NodeJS library from your Python app? Jam the NodeJS in a lambda and don't worry about maintaining/scaling it.

Lambda for the web is also really useful for little one-off tasks or webhooks that don't have a big domain model behind them. Lambda@Edge is also super useful for manipulating requests and responses.

So is the solution to avoid Lambda unless you have to? Don't use it to build regular software, just use it for AWS glue when necessary?

That’s the use case where it shines, but it can be an effective part of “regular software” as well.

It’s a hammer, and if it’s a good fit for your particular nail is very dependent on it’s shape.

> So is the solution to avoid Lambda unless you have to? Don't use it to build regular software, just use it for AWS glue when necessary?

That, and also offload some somewhat computationally expensive background tasks. Instead if screwing up your deployments by ramping up CPU and memory utilization to run a one-off task, just let he service fire a lambda and, if needed, just act when the lambda replies back.

Just want to pile-on to the other replies and say yes, absolutely. When you need them as glue they're a great option with basically no alternatives -- also means your lambda functions will be just a handful of lines of code, and then you can get on with your life.

Reply on news.ycombinator.com