Hacker News Reader

Comment by jknoepfler | Hacker News Reader

The success of this product is dependent on torpedoing aws lambda from a usability and reliability perspective imo (not hard). After using twilio to build the sms side off of an app I've been quietly rooting for them (and betting on them actively)

If they built this ON lambda then I'd bet against it very strongly, but I can't imagine smart engineers doing that in 2017 (ha...)

View on HN

You are thinking about this wrong.

Serverless functions on Twilio (or any other platform for that matter) is not competing with Lambda.

The point of serverless functions is to take your Twilio app that you were already creating and to completely eliminate the back-end.

Now you can make a fully functioning Twilio app without messing around with heroku.

That's like suggesting that heroku isn't competing with aws on things like database management. It is.

Does the mattress industry compete with the hotel industry?

In a vague roundabout way both industries are used for sleeping.

But the connection is so remote that the answer is no.

So Lambda and Twilio functions are similarly "competing". But in reality there is less than 1% of situations where someone would seriously be deciding between the two.

But that backend you were building could have already been built on Lambda. Granted, you'd have to plug in some other AWS products like API Gateway, but the cost would still be the same or cheaper than what Twilio is selling.

I would be willing to be that they're using Lambda under the hood. The handler function signature looks identical.

Edit: It is using Lambda!

That could just mean they based it off Lambda's.

Nope, it is 100% using AWS Lambda. I just created an account and created a function that just logged out process.env and it had all of the same variables:

  {
    "PATH": "/var/lang/bin:/usr/local/bin:/usr/bin/:/bin",
    "LANG": "en_US.UTF-8",
    "TZ": ":/etc/localtime",
    "LD_LIBRARY_PATH": "/var/lang/lib:/lib64:/usr/lib64:/var/runtime:/var/runtime/lib:/var/task:/var/task/lib",
    "LAMBDA_TASK_ROOT": "/var/task",
    "LAMBDA_RUNTIME_DIR": "/var/runtime",
    "AWS_REGION": "us-east-1",
    "AWS_DEFAULT_REGION": "us-east-1",
    "AWS_LAMBDA_LOG_GROUP_NAME": "/aws/lambda/ZD0d695de3d9ecfaec4cf2567883f9202d",
    "AWS_LAMBDA_LOG_STREAM_NAME": "2017/05/25/[$LATEST]d60f87eb2f9d4617b861015e91b97a72",
    "AWS_LAMBDA_FUNCTION_NAME": "ZD0d695de3d9ecfaec4cf2567883f9202d",
    "AWS_LAMBDA_FUNCTION_MEMORY_SIZE": "512",
    "AWS_LAMBDA_FUNCTION_VERSION": "$LATEST",
    "_AWS_XRAY_DAEMON_ADDRESS": "169.254.79.2",
    "_AWS_XRAY_DAEMON_PORT": "2000",
    "AWS_XRAY_DAEMON_ADDRESS": "169.254.79.2:2000",
    "AWS_XRAY_CONTEXT_MISSING": "LOG_ERROR",
    "_X_AMZN_TRACE_ID": "Root=1-59274e98-8a866a3a26501e8e7ed9392f;Parent=156c08223cc7c0bf;Sampled=0",
    "AWS_EXECUTION_ENV": "AWS_Lambda_nodejs6.10",
    "_HANDLER": "enigma.handler",
    "NODE_PATH": "/var/runtime:/var/task:/var/runtime/node_modules",
    "AWS_ACCESS_KEY_ID": "ASIAIFI4J4GFZDKDKOSA",
    "AWS_SECRET_ACCESS_KEY": "BpwnBTtoCT2Gqhxm1nGMQAfduicLRBgPY2uRpFdk",
    "AWS_SESSION_TOKEN": "FQoDYXdzEPf//////////wEaDLQQsvN1Zq+ShXfc2SL7AQF7CQgXNgU77W5qzL+1GDXRR69xV//kPpdJ0FRAR8qZPyGxfUMRne2uahHL8NDTEKl7Cii0vwohYS/3oCo8IXF5+jmhB9K3WW3MVSfJcv+M4iR5jm+Kl4rvcSjaNCTCTzj4VhKMh4vRhG1b6Nvdyoq27mDGgpkIxd9GzFfuDnSzzq0o5CcCdV1vE2GA0JtyHkzjxw3pqrhaBAzd3gkOvFpVeQJBL8EJUDU0CDgCdW/5MCVMKQFyUJagowiCTq0JyD/ZByUn7wLvuhbzJn0AkQvSfmdFgUg7LQcslhvMsAgYwDZT9xZecgoyq6UqhE0vzOy/0C/XuTp+OzHDKNmcnckF"
  }

Not sure if you meant to leave your API keys in there...

They aren't my environment variables, they're Twilio's.

Well supposedly those are different for each customer so.....

Nice work, fascinating.

Lambda is far from the most easy to use platform, no argument there, but I don't see any justification for bashing its reliability..

Maybe I just don't have enough experience with the competitors but I had to spend significant time writing wrappers and tooling to make Lambda usable in a sane way. Off the top of my head, I added - prefix logging, controlled timeouts to prevent AWS's terrible auto-retry feature, continuation to work around AWS's low 5 min timeout limit, and local testing.

> continuation to work around AWS's low 5 min timeout limit, and local testing.

If you had to work around the 5 minute limit then lambda may have been the wrong technology choice. It's really neat for short quick bursts of compute, not long running processes.

You obviously have a strong dislike for lambda. I've never used it personally, but from afar it seems cool.

What are some of the shortcomings you ran into using it?

Reply on news.ycombinator.com