Binaris is a cloud platform that enables developers to build entire applications out of serverless functions. In order to simplify invocation of cloud functions we have a built-in HTTPS gateway, and assign an HTTP endpoint to each function upon its initial deployment. This way, every function can be easily invoked using standard tools from other functions, other cloud components or client-side code.
How it works
Whenever a function is first deployed, it is assigned an HTTPS endpoint:
$ mkdir hello $ cd hello $ bn create node8 public_hello Created function public_hello in .../hello (use "bn deploy public_hello" to deploy the function) $ bn deploy public_hello Deployed function public_hello Invoke with one of: "bn invoke public_hello" "curl https://run.binaris.com/v2/run/.../public_hello"
public_hello was automatically assigned an HTTPS endpoint. These endpoints take the form of:
Whenever this URL is hit, the function is invoked and executed synchronously and the result is returned to the caller.
This makes it very easy to create backend functionality, that can be accessed from other backend components or from client code. To learn how to build a web backend check out our 5 Minute Serverless Backend Tutorial.
In the previous example we created a public function. Such functions have the
public_ prefix in their name, and can be invoked without needing authentication. Binaris provides a built in authentication mechanism, using an API key associated with each account.
Creating and deploying protected function is similar to the process we’ve seen above:
$ bn create node8 hello Created function hello in .../hello (use "bn deploy hello" to deploy the function) $ bn deploy hello Deployed function hello Invoke with one of: "bn invoke hello" "curl -H X-Binaris-Api-Key:$(bn show apiKey) https://run.binaris.com/v2/run/.../hello"
Note that when invoking protected functions, the HTTP request requires an additional
X-Binaris-Api-Key header with the account API key. Your account ID and API key can be found using
bn show accountID and
bn show apiKey respectively.
Binaris is designed from the ground up to be fast and responsive, so you can use serverless functions across multiple use cases. Specifically, it lets you build client facing (web and mobile) APIs with functions. Having a built in HTTPS gateway helps in achieving this low latency.
We benchmarked performance of Binaris against AWS Lambda, with and without API Gateway. We measure performance in percentiles, and show median latencies (which is what casual users will experience) up to the 99th percentile (which is what heavy users would experience). In order to eliminate Internet latency, we ran all tests from a nearby cloud server.
As you can see above, Lambda and API Gateway have a combined warm latency of over 100ms (cold start latencies are closer to 1 sec). This means that any responsive or real-time API can’t be implemented on Lambda. Binaris, being almost 40x faster (and with no cold starts), is fast enough to support these use cases.
Both Binaris and AWS Lambda are true serverless platforms, meaning they only charge you for the time your code is actually running. The pricing model between the two, however, is somewhat different. Below are current prices for 1 million invocations:
|Invocation cost [$]||0.200||–|
|Compute time (1) [$]||1.667||0.083|
|HTTPS Gateway (2) [$]||3.033||–|
(1) Compute time assumes 1GB of memory and 5ms CPU time consumed by the function (typical for API handlers) (2) On an API witrh average load (1 billion calls per month)
We can see that a Lambda based system would cost almost 60x more than one running on Binaris. Furthermore, the HTTPS gateway implemented by AWS API Gateway is a major part of that cost.
Learn how to build and deploy a web API from a Binaris function in our 5 Minute Serverless Backend Tutorial.