Twilio Functions – Public Beta(twilio.com)
twilio.com
Twilio Functions – Public Beta
https://www.twilio.com/blog/2017/05/introducing-twilio-functions.html
91 comments
Hey, Ricky from Twilio here.
In this case, while these environment variables appear to be sensitive, they are ephemeral keys, uniquely issued to the Function as part of running within Lambda. Their associated actions and permissions have been reviewed, approved and are required to run the Function. There is no risk of any Twilio customer’s Function being accessed or modified by disclosure of these keys.
That said, we much appreciate the community raising potential concerns. If y’all ever see anything that looks like a vulnerability, we’d love for you to submit it to our Bug Bounty program: https://bugcrowd.com/twilio
In this case, while these environment variables appear to be sensitive, they are ephemeral keys, uniquely issued to the Function as part of running within Lambda. Their associated actions and permissions have been reviewed, approved and are required to run the Function. There is no risk of any Twilio customer’s Function being accessed or modified by disclosure of these keys.
That said, we much appreciate the community raising potential concerns. If y’all ever see anything that looks like a vulnerability, we’d love for you to submit it to our Bug Bounty program: https://bugcrowd.com/twilio
Thanks for letting us know Ricky, it's great to see new functionality being released so often on Twilio. Playing with functions for a bit today, it would be great to be able to add additional nodejs libraries, is that a feature coming up any time soon?
It is great to see that the industry is moving from webhooks to Functions. We've seen this model succeed at Auth0 with our Rules feature [1] implemented 3 years ago. Recently productized this experience with Auth0 Extend [2]. It supports all node modules, a one-line of js emebeddable Editor, real time logs, vault to store secrets, custom programming models and crons.
[1] https://auth0.com/docs/rules
[2] https://auth0.com/extend/developers
[1] https://auth0.com/docs/rules
[2] https://auth0.com/extend/developers
just full disclosure. Woloski^ is the cto and founder of autho. They have a competing product in the serverless space. Click on the links to learn more. Here is the pricing page, https://auth0.com/pricing
Stoked to hear you've been playing with it. I can't make any promises on roadmap yet but we're excited to get feedback from the community while we're in public beta to help shape what Functions become for GA. If you keep hacking with it and have thoughts feel free to drop me an e-mail (ricky AT twilio.com).
[deleted]
... Are those actually Twilio's keys, or are they creating a new Lambda instance (with its own private access keys) for each customer?
Maybe they actually intend for people to be able to use all the functionality of Lambda, some of which (I guess) requires using the AWS access key?
Or are people naively assuming their own Lambda container is a reasonable sandbox for third-party code? If so, yikes.
Maybe they actually intend for people to be able to use all the functionality of Lambda, some of which (I guess) requires using the AWS access key?
Or are people naively assuming their own Lambda container is a reasonable sandbox for third-party code? If so, yikes.
It's likely using an IAM role with no permissions other than writing logs to CloudWatch.
OK, so they're effectively reselling Lambda, and creating a new Lambda account for each Twilio customer under the hood?
> they're effectively reselling Lambda
Another take on this is that they're creating value for customers by shifting the reliability requirements from the customers themselves to AWS / lambda
... which I think is brilliant.
Another take on this is that they're creating value for customers by shifting the reliability requirements from the customers themselves to AWS / lambda
... which I think is brilliant.
I hacked together a quick demo using Ruby, Sinatra, and Heroku with Twilio this last weekend and the whole time I was thinking "Heroku makes this easy, but having to host a server makes this harder to debug".
I feel like this new feature will make it super easy to work with Twilio. It's almost a no brainer.
I feel like this new feature will make it super easy to work with Twilio. It's almost a no brainer.
Or you can keep the Ruby stack and just use ngrok in dev. :-)
Trust me, I love Ruby and ngrok works well, but I think a serverless setup is a lot simpler (at least in my mind). I was actually using Twilio to test a Ruby library of mine and set up a text service for product registrations for a CRM. It works freakishly well.
But despite all that, I feel like setting everything up in one place would be a lot simpler.
Now if Twilio had a way to deploy serverless functions via git... that would be a clincher.
But despite all that, I feel like setting everything up in one place would be a lot simpler.
Now if Twilio had a way to deploy serverless functions via git... that would be a clincher.
[deleted]
It could all be under the same AWS account, and all using the same IAM role. It's just that the role doesn't have access to anything. It can write logs to its own function-specific log group and read from them potentially.
Also, a hell of a lot of work went into this feature. You can try setting this infrastructure up yourself if you think it will save you money. You already know they're using Lambda!
Also, a hell of a lot of work went into this feature. You can try setting this infrastructure up yourself if you think it will save you money. You already know they're using Lambda!
My comment wasn't intended as an attack. I was just curious about their approach to sandboxing, as it's my area of expertise.
Sometimes systems that are secure with two parties become horribly insecure when you add a third. I don't know a lot about IAM but generally I'd be very cautious about using standard access control mechanisms to implement sandboxing while running the code "in your account", as often you find resources are made available to "the whole account" with no further access control settings, because the system designers didn't imagine customers running true third-party code.
That said Amazon has some pretty thorough access control features and I'm sure Twilio has looked into it and figured out something reasonable.
Sometimes systems that are secure with two parties become horribly insecure when you add a third. I don't know a lot about IAM but generally I'd be very cautious about using standard access control mechanisms to implement sandboxing while running the code "in your account", as often you find resources are made available to "the whole account" with no further access control settings, because the system designers didn't imagine customers running true third-party code.
That said Amazon has some pretty thorough access control features and I'm sure Twilio has looked into it and figured out something reasonable.
While it seems concerning on the service, you have to imagine twilio made a conscious decision not to wipe the env variables, just as aws don't.
If you think about this product, you are paying for the service, so if you tried anything malicious, at worst you would do is impact yourself, and ultimately pick up a bill for your usage at the end of month, heh.
If you think about this product, you are paying for the service, so if you tried anything malicious, at worst you would do is impact yourself, and ultimately pick up a bill for your usage at the end of month, heh.
[deleted]
I wonder how they're doing this, are they invoking the Lambda functions using the synchronous API, or are they using something like API gateway?
From what I can tell API gateway costs $3.50 a month per 1m calls, so unless they've negotiated some deal with AWS or something...
From what I can tell API gateway costs $3.50 a month per 1m calls, so unless they've negotiated some deal with AWS or something...
Awesome play by Twilio. We've been working on StdLib [1] and an open specification for FaaS execution [2] for a while now, and demos with Twilio (sending text messages after automatically validating parameters, hooking into other functions in our ecosystem) have really helped developers grok what's possible. (We have a built-in SMS utility that actually uses Twilio behind the scenes [3]).
Happy to see we've come to the same conclusions about utility independently :).
[1] https://stdlib.com/
[2] https://github.com/faaslang/faaslang/
[3] https://stdlib.com/utils/sms
Happy to see we've come to the same conclusions about utility independently :).
[1] https://stdlib.com/
[2] https://github.com/faaslang/faaslang/
[3] https://stdlib.com/utils/sms
Just checked out stdlib.com. Looks awesome. Much appreciate you using Twilio to demo it. Would you drop me an email at [email protected]? Would love to send you something.
Gladly. We're big fans!
Interesting. Thinking out loud here, are Functions a new opening for Saas businesses? (tldr no).
If you have a big enough user base/set of use cases, the next step after opening an API to your service might be adding a Baas/Faas, so people with small use cases or prototypes can get started easily without using a server.
But it's not like Linkedin or Zenefits users would get more value out of "Linkedin Functions". It probably makes more sense if you can "eat" what would have been a separate (micro)service.
The one thing I don't see though, is if somebody is sold enough on Faas, why would they use your siloed Twilio Faas instead of AWS Lambda/whatever where you can interact with Twilio _and_ eg Shopify, Instagram, other APIs...
Maybe then an interesting idea for the big FaaS providers duking it out for market share right now might be an ability for SaaS providers to build "$YOUR_SAAS Functions" on top of their offering. The end-user would see Lambda/Function/whatever templates pre-filled with the right API calls an a UI for choosing the different API-related triggers. This could be like the AWS marketplace, but for Faas.
So I guess the answer to my clickbait-ey question at the top is mostly likely no, but maybe, let's see it play out. It definitely feels like a good way to sell more API usage.
If you have a big enough user base/set of use cases, the next step after opening an API to your service might be adding a Baas/Faas, so people with small use cases or prototypes can get started easily without using a server.
But it's not like Linkedin or Zenefits users would get more value out of "Linkedin Functions". It probably makes more sense if you can "eat" what would have been a separate (micro)service.
The one thing I don't see though, is if somebody is sold enough on Faas, why would they use your siloed Twilio Faas instead of AWS Lambda/whatever where you can interact with Twilio _and_ eg Shopify, Instagram, other APIs...
Maybe then an interesting idea for the big FaaS providers duking it out for market share right now might be an ability for SaaS providers to build "$YOUR_SAAS Functions" on top of their offering. The end-user would see Lambda/Function/whatever templates pre-filled with the right API calls an a UI for choosing the different API-related triggers. This could be like the AWS marketplace, but for Faas.
So I guess the answer to my clickbait-ey question at the top is mostly likely no, but maybe, let's see it play out. It definitely feels like a good way to sell more API usage.
;) The answer to your "clickbait-y" question is definitely "we'll see," and it's already playing out.
I am a (happy) twilio customer and I do not understand this:
"Today, we’re excited to announce Twilio Functions, a serverless environment to build and run Twilio applications so you can get to production faster."
I did just that ... I signed up for twilio, wrote a simple twiML[1] inside their web editor, and attached it to a phone number.
No servers were involved (I am not sure how I could involve a server) and I "got to production" very fast.
What would I do differently now ?
[1] "Ring Forever"
"Today, we’re excited to announce Twilio Functions, a serverless environment to build and run Twilio applications so you can get to production faster."
I did just that ... I signed up for twilio, wrote a simple twiML[1] inside their web editor, and attached it to a phone number.
No servers were involved (I am not sure how I could involve a server) and I "got to production" very fast.
What would I do differently now ?
[1] "Ring Forever"
Is there not functionality that can't be expressed in a twiML?
Like communicating to separate service or database within a given request from an SMS or Voice callback, etc... functionality that until today would have required web-hooks running on some other server (or cloud function)?
Like communicating to separate service or database within a given request from an SMS or Voice callback, etc... functionality that until today would have required web-hooks running on some other server (or cloud function)?
Yes, we pull data from our database to make dynamic responses. But I'm not sure if this services model helps that. You would have to create an API to interface with your own DB.
This is very similar to what we've done to bootstrap the Zapier CLI and developer platform -- especially relative to repurposing AWS Lambda.
Wrote a bit of behind the scenes just the other day https://zapier.com/engineering/behind-the-cli/ if this sort of stuff tickles your fancy.
Wrote a bit of behind the scenes just the other day https://zapier.com/engineering/behind-the-cli/ if this sort of stuff tickles your fancy.
good amount of comments here missing how hard it is for "normal" people to use twilio. the article is clear: twilio's many interface to your code is a callback URL. think about what it takes to have a callback URL you can input to the twilio website.
could they really set up an AWS account, lambda function, IAM role, API gateway, with cloud watch logs? ive done this in AWS. you have to use 5+ AWS services that have funny names and look nothing alike, and make them all work together.
or lets say you wanted to buy a domain, hosting for it, and put your code on there for twilio to hit with a callback URL. thats hard too.
if you are going to do either of the 2 approaches above, how many hours are you going to spend getting the callback URL foundation set up (and working) before you even get to use a twilio product?
could they really set up an AWS account, lambda function, IAM role, API gateway, with cloud watch logs? ive done this in AWS. you have to use 5+ AWS services that have funny names and look nothing alike, and make them all work together.
or lets say you wanted to buy a domain, hosting for it, and put your code on there for twilio to hit with a callback URL. thats hard too.
if you are going to do either of the 2 approaches above, how many hours are you going to spend getting the callback URL foundation set up (and working) before you even get to use a twilio product?
A counterpoint is that "normal" people should not be doing any of that at all. While I'm 100% in favor of making things easier for developers, you have to know what you're doing otherwise the easiest interface in the world will result in some "normal" people releasing a service which allows malicious users to abuse the service and rack up unlimited charges, potentially using it to harass unsuspecting victims with hundreds of calls per hour at 3 AM, for example.
If callback URLs, SSL, etc. are difficult to understand, I consider that a sufficient barrier which requires people to have a clue about what they're building and understand the implications of their choices.
If callback URLs, SSL, etc. are difficult to understand, I consider that a sufficient barrier which requires people to have a clue about what they're building and understand the implications of their choices.
Can Glitch help here? https://glitch.com/
Can the callback URL use an IP address, or does it need to be a proper DNS name? Can it have a self-signed certificate? Does it even need to be secured?
If the callback URL can use an IP address and doesn't require https, you could set up a Digital Ocean droplet for it in a couple of minutes. Or you could set up a port-forward on your router and run an HTTP server on your machine, but I think the Digital Ocean route might be quicker.
If the callback URL can use an IP address and doesn't require https, you could set up a Digital Ocean droplet for it in a couple of minutes. Or you could set up a port-forward on your router and run an HTTP server on your machine, but I think the Digital Ocean route might be quicker.
> Or you could set up a port-forward on your router and run an HTTP server on your machine
This, coupled with just giving them a raw IP address has been good enough for me so far.
This, coupled with just giving them a raw IP address has been good enough for me so far.
who are you expecting to understand this? there's tons of people out there who have no idea what these terms mean. DNS? Self Signed? IP address maybe... droplet? they are going to say "too hard, close tab"
At a quick glance, it seems like anything beyond a fire-and-forget SMS/fax done with Twilio requires a callback. My guess is that Twilio is expecting their customers to be able to write a callback and is willing to accept the associated barriers for entry.
I've loved being able to hack away on projects with Twilio for a while now. They're relatively easy to get started with, and this is going to make it even easier. 10,000 invocations free, with subsequent invocations priced at 10,000/$1 seems like a great model. No idea about how this scales financially, compared to other similar services. But as someone making relatively limited use tools, most without a business model, their pricing certainly keeps me feeling great about using them.
Well, to be honest, compute is becoming a commodity very quickly. We offer 100,000 invocations free and offer 50,000 per $1 [1] with a paid account. There are some pretty smart people who have talked at length about startups historically underpricing, but I think we're making a bet on the raw value of compute trending to zero. (This is a weird thing to say outright, our goal, generally, is to change the way people think about service composition and building things on the internet.)
Twilio is interesting because they're offering this as a business-specific offering i.e., integrate with Twilio directly (SMS, voice), which on its face is actually more valuable than, say, a "generalized compute platform" (which we've referred to ourselves as, at times). I think it'll be really interesting to see how Twilio markets + plays with this model --- theoretically if it sells their other services they could get away with this being a loss-leader, which is an intriguing concept.
[1] https://stdlib.com/pricing/
Twilio is interesting because they're offering this as a business-specific offering i.e., integrate with Twilio directly (SMS, voice), which on its face is actually more valuable than, say, a "generalized compute platform" (which we've referred to ourselves as, at times). I think it'll be really interesting to see how Twilio markets + plays with this model --- theoretically if it sells their other services they could get away with this being a loss-leader, which is an intriguing concept.
[1] https://stdlib.com/pricing/
> I think we're making a bet on the raw value of compute trending to zero.
I'm thinking you mean the COST of compute here. If that's the case, I actually disagree on cost trend direction. I think the raw cost of compute will slowly increase. Long story but most of it borders on the economics of cloud computing.
I'm thinking you mean the COST of compute here. If that's the case, I actually disagree on cost trend direction. I think the raw cost of compute will slowly increase. Long story but most of it borders on the economics of cloud computing.
Somebody above pointed out that they're using Lambda.
So you can figure out their loss/margin based off the public Lambda pricing model.
Lambda costs 0.00001667 per GB-s... so if each Twilio function used 1GB of memory and ran for 1 second, it would cost them $0.17 per month to serve you.
Since the max memory in Lambda is 1.5GB and the max runtime is 5 minutes... the worst case is that twilio is spending $75 for those 10k requests. I assume they were smart enough to use lower amounts of memory and set the maximum runtime of the Lambda function pretty low, like a few seconds.
So you can figure out their loss/margin based off the public Lambda pricing model.
Lambda costs 0.00001667 per GB-s... so if each Twilio function used 1GB of memory and ran for 1 second, it would cost them $0.17 per month to serve you.
Since the max memory in Lambda is 1.5GB and the max runtime is 5 minutes... the worst case is that twilio is spending $75 for those 10k requests. I assume they were smart enough to use lower amounts of memory and set the maximum runtime of the Lambda function pretty low, like a few seconds.
I was already doing this with their API on Lambda. If anybody is interested:
https://github.com/nathanjsweet/narthan
Good on them for integrating it.
Good on them for integrating it.
Is there some way to create an SMS based service using Twilio, and charge users? Like, the user gets charged on their phone bill and I, the service owner, get paid by Twilio or something.
Or is that just not a thing and it has to be done OOB?
Or is that just not a thing and it has to be done OOB?
It depends on the country. In the UK it's very common, and relatively easy to do the 'premium sms' that you describe.
It's not at all common in the US, and Twilio doesn't seem to support it anywhere.
It's not at all common in the US, and Twilio doesn't seem to support it anywhere.
I wonder if this is an independent effort or if it's built on top of AWS Lambda.
Also, anyone know why all these serverless environments that are coming out focus on Node.js?
Also, anyone know why all these serverless environments that are coming out focus on Node.js?
Fastest growing runtime, largest module ecosystem. That's it. The goal is to encourage adoption and validate a product quickly, so you ride the biggest wave.
AWS has the resources to grow teams around different languages / runtimes, smaller players (or recent IPOs) do not in the same capacity. Targeting anything other than Node would be "the largest" disservice to your customer base in the case of Twilio, and would artificially slow any other player.
AWS has the resources to grow teams around different languages / runtimes, smaller players (or recent IPOs) do not in the same capacity. Targeting anything other than Node would be "the largest" disservice to your customer base in the case of Twilio, and would artificially slow any other player.
In addition, Node seems to have beneficial performance characteristics when it comes to cold startup time, compared to say Java, which probably helps when it comes to pay-only-for-requests functions as a service that aren't always running.
https://forums.aws.amazon.com/thread.jspa?messageID=679050
https://forums.aws.amazon.com/thread.jspa?messageID=679050
My own hypothesis is that the teams building these FaaSes wanted to choose a runtime that has a good story for internal multitenant partitionability, so that they didn't have to either just-in-time spawn, or prefork, a new (containerized) copy of the runtime for each user, with all the overhead that implies. Node.js is such an internally-partitionable runtime. (So is Lua†, but like the parent says, Node.js is bigger and more people want it.)
For a visible-to-the-public-eye example of what I mean, look at how CouchDB uses Node.js for its view functions: the CouchDB daemon process spawn an unprivileged Node.js slave process, which uses Node's ability to drop or virtualize syscall-making APIs, along with Node "VM"s (https://nodejs.org/api/vm.html) —essentially the same kind of isolation as you get from distinct-origin browser tabs—to allow for the execution of arbitrary Javascript by multiple tenants. That's not too far off from a FaaS already. It's a good model to copy and extend.
I'm betting AWS Lambda, and Twilio's offering as well, are mostly built around such a model. Mind you, Lambda now also offers a "prefork" container-based stack for function execution, but it didn't at first, and for good reason: it's harder to build, harder to operate, and has much higher overhead than a cluster of regular processes with internal sandboxing. This is much the same reason that Heroku started with their Alpine stack—an cluster of internally-partitioned Ruby processes, and boy was that a feat—before building their container service.
---
† Given that you could pretty easily multitenant-sandbox Lua evaluation... it'd be quite easy to extend OpenResty (https://openresty.org/) into being a FaaS, wouldn't it? Anyone hacking on this?
For a visible-to-the-public-eye example of what I mean, look at how CouchDB uses Node.js for its view functions: the CouchDB daemon process spawn an unprivileged Node.js slave process, which uses Node's ability to drop or virtualize syscall-making APIs, along with Node "VM"s (https://nodejs.org/api/vm.html) —essentially the same kind of isolation as you get from distinct-origin browser tabs—to allow for the execution of arbitrary Javascript by multiple tenants. That's not too far off from a FaaS already. It's a good model to copy and extend.
I'm betting AWS Lambda, and Twilio's offering as well, are mostly built around such a model. Mind you, Lambda now also offers a "prefork" container-based stack for function execution, but it didn't at first, and for good reason: it's harder to build, harder to operate, and has much higher overhead than a cluster of regular processes with internal sandboxing. This is much the same reason that Heroku started with their Alpine stack—an cluster of internally-partitioned Ruby processes, and boy was that a feat—before building their container service.
---
† Given that you could pretty easily multitenant-sandbox Lua evaluation... it'd be quite easy to extend OpenResty (https://openresty.org/) into being a FaaS, wouldn't it? Anyone hacking on this?
We do exactly this with Lua inside our platform to drive workflow modules in a multitenant environment.
It's not using OpenResty though (although OpenResty is very cool)
We are going to be adding Node as well though, for the reasons you mention above around Ecosystem.
It's not using OpenResty though (although OpenResty is very cool)
We are going to be adding Node as well though, for the reasons you mention above around Ecosystem.
I would guess it's related to the prevalence of javascript combined with the low barrier to entry to build javascript app and the relatively low startup time of a nodejs app.
It is built on Lambda. I just created a function and logged process.env and it's got all the same Lambda-specific environment variables.
Other providers like Tropo have had this hosted scripting for years. Nice to see Twilio catching up.
I'm not sure why this comment was downvoted.
I worked for Tropo four years ago. You could write your code in JavaScript, PHP, Ruby, Python, or Groovy; upload it to our servers; and we'd run it on your behalf. It was literally zero infrastructure on your part and one line of code to answer a phone call.
Tropo certainly lacked some things compared to Twilio while I was there, but this is undoubtedly an area where Twilio is playing catch up.
https://www.tropo.com/docs/scripting/overview
I worked for Tropo four years ago. You could write your code in JavaScript, PHP, Ruby, Python, or Groovy; upload it to our servers; and we'd run it on your behalf. It was literally zero infrastructure on your part and one line of code to answer a phone call.
Tropo certainly lacked some things compared to Twilio while I was there, but this is undoubtedly an area where Twilio is playing catch up.
https://www.tropo.com/docs/scripting/overview
Pointing out "Company X already does this" when someone launches something new is a pretty douchey move...
Why? It's certainly useful to see what other companies are offering and what the differences between these offerings are. If just mentioning a competitor is bad then maybe the product is bad.
Whether it's a company launching a product or a developer showing off something they built in their spare time, it's really depressing to launch something you've been working on for months or years and to get back "well, X already does this."
I'd add that "X already does this" comments like this are a routine feature of Twilio HN threads, as long as the company's been alive. https://kev.inburke.com/kevin/six-years-of-hacker-news-comme...
I'd add that "X already does this" comments like this are a routine feature of Twilio HN threads, as long as the company's been alive. https://kev.inburke.com/kevin/six-years-of-hacker-news-comme...
Ugh, Twilio is the far and above market leader in this space.
I don't think they are to bothered by us pointing things out like this.
I don't think they are to bothered by us pointing things out like this.
true, but have you actually used tropo?
Their documentation is horrible and you are extremely limited when running the code on their servers. If you need to do anything complicated, you have to have things running through their WebAPI.
They have made breaking changes to their API without communicating with their user's.
Their documentation is horrible and you are extremely limited when running the code on their servers. If you need to do anything complicated, you have to have things running through their WebAPI.
They have made breaking changes to their API without communicating with their user's.
Yes, I've been using Tropo, Twilio, Plivo, Nexmo, (seems you have to end with 'o' to be in programmable telephony these days) for many years. Nothing too complicated with any of them.
Who are these people writing SMS apps? Why is Twilio so proeminent when no one uses SMS anymore?
Our customers at Dolly love receiving SMS. Also helps with low data connectivity locations. Not sure "no one uses SMS anymore" is accurate.
It's still the easiest universal way to reach people on their phones. You can replace it for people that you know, but not if you are ZZZ Pizza and you want to message a customer that their order's on the way.
I have the impression that everybody uses SMS for authentication. Everyone from Bank of America to Uber to even Whatsapp uses SMS to validate phone numbers or for 2-factor authentication.
> no one uses SMS anymore
Except for the 6 billion SMS messages sent each day.
https://www.smseagle.eu/2017/03/06/sms-mobile-statistics-2/
Except for the 6 billion SMS messages sent each day.
https://www.smseagle.eu/2017/03/06/sms-mobile-statistics-2/
[deleted]
Would be interested in the data or observations that no one uses SMS. I use SMS everyday with everyone who doesn't have iMessage.
I love the new popularity of lambda/functions as a service. each provider can now give you a custom code to do whatever you like, stripping away the needs for servers and that what i can really see as a full "micro-service"
I wish Twilio had free offerings for their other services. I didnt even dare playing around testing Twilio because I would be getting charged 2 cents per SMS sent
Totally understand that concern. Our goal's always been to have Twilio be free (or really close to it) while your app is in development.
We've got a trial account that will let you play around before spending any money. You'll only be able to text numbers that you've verified with us, but it should give you a feel for things (this is what the vast majority of students at Hackathons use).
If you want to give it a try: twilio.com/try-twilio
When you're ready to make the leap, $20 buys you about 2500 text messages in the US.
(disclaimer: work on Developer Community team)
We've got a trial account that will let you play around before spending any money. You'll only be able to text numbers that you've verified with us, but it should give you a feel for things (this is what the vast majority of students at Hackathons use).
If you want to give it a try: twilio.com/try-twilio
When you're ready to make the leap, $20 buys you about 2500 text messages in the US.
(disclaimer: work on Developer Community team)
The truth of the matter is if you have a hard time paying 2 cents to send a text message for a few beta / trial runs, you're probably not contributing to Twilio's bottom line in any reasonable fashion, and unfortunately, they don't care. Not because they don't want to, but because they can't afford to.
If every engineer with a six-figure salary decided they would pay the couple bucks it costs to test drive a product, the customer long-tail for dev products would add up to something appreciable and as a result you might actually see a lot more innovation around dev tools. As it stands, one of the best developer products of our generation, Heroku, even had a hard time pricing / selling to their long tail and we saw shutdowns of great products like Parse.
Twilio actually has a very reasonable model. $20 deposit, non-recurring, is way less than you'd spend on a Thursday night date, for example, and you get to build something with it. Hell, speaking of building, you've probably spent more on a Lego set. (I have. As an adult... for myself.)
(What actually ends up happening is developer companies go full OSS, give everything away for free for massive adoption, then AWS figures out how to productize it and sell to Enterprise. You can trace the points from Docker's inception to AWS Lambda processing trillions of trades per day.)
If every engineer with a six-figure salary decided they would pay the couple bucks it costs to test drive a product, the customer long-tail for dev products would add up to something appreciable and as a result you might actually see a lot more innovation around dev tools. As it stands, one of the best developer products of our generation, Heroku, even had a hard time pricing / selling to their long tail and we saw shutdowns of great products like Parse.
Twilio actually has a very reasonable model. $20 deposit, non-recurring, is way less than you'd spend on a Thursday night date, for example, and you get to build something with it. Hell, speaking of building, you've probably spent more on a Lego set. (I have. As an adult... for myself.)
(What actually ends up happening is developer companies go full OSS, give everything away for free for massive adoption, then AWS figures out how to productize it and sell to Enterprise. You can trace the points from Docker's inception to AWS Lambda processing trillions of trades per day.)
Over 95% of Twilio's users don't meaningfully contribute to their bottom-line. Their revenue is a fat long-tail dominated by outliers. I'd say Twilio does care about every developer because they have no idea which customers will become outliers.
they do have a testing environment where you can send SMS to only registered and verified phone numbers
I was just going to say this too. I just started working with it this last weekend and feels like magic.
This is an amazing move on their part. I think this lowers the barrier to use their services and it was already stupid simple to set up.
Well done!
This is an amazing move on their part. I think this lowers the barrier to use their services and it was already stupid simple to set up.
Well done!
Love hearing that about that "magic" feeling. Want to drop me an email at [email protected] and we'll shoot you a token of our appreciation?
It sounds like you have no need for their service. If you had a need for the service, their pricing model is very good.
Since you have no need for their service, not having your account on their system is best for Twilio.
Since you have no need for their service, not having your account on their system is best for Twilio.
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...)
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...)
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.
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.
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.
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.
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.
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!
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"
}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.
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?
What are some of the shortcomings you ran into using it?
[deleted]
Edit: adding linebreaks...
2nd edit: Realized there were AWS access tokens in there. It's probably not a good idea for those to be exposed to the environment they're running this user generated code in. They should probably be wrapping these in vm.runInNewContext()