It's definitely using AWS Lamba, I spun up a trial account and texted myself the output of JSON.stringify(process.env)...
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()
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.
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).
Another take on this is that they're creating value for customers by shifting the reliability requirements from the customers themselves to AWS / lambda
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.
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.
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!
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.
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.
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 :).
Just checked out stdlib.com. Looks awesome. Much appreciate you using Twilio to demo it. Would you drop me an email at gb@twilio.com? Would love to send you something.
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.
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.
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)?
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.
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?
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.
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.
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.
> 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.
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.
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?
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.
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.
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?
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.
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.
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."
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.
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.
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.
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.)
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.
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...)
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.
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.
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:
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.
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()