Yesterday we announced the public availability of Functions, a new feature of the PubNub Data Stream Network that lets you move computation into the network itself, allowing your apps to go completely serverless. We couldn’t be more excited to see what you will build!
After the launch, we got a few questions about how Functions actually works. How does it secure potentially un-trusted code? How does it keep one app separate from another? How does it actually distribute computation around the global?
Creating a BLOCK
When you write a block, it’s running live. You can send messages to it through the Functions dashboard or from external code. When you press the deploy button, the code for your block is instantly sent to every part of the PubNub network around the globe. Any messages sent to your data channel will be handled by an instance of your block running at the data center nearest to the message.
When you update the code for your block, the update is applied to the entire network at once. There is no down time between the old block and the new one. No messages will ever be dropped. Every message will be handled by your code.
Security
For maximum safety and reliability, Functions uses multiple levels of security. Each block is run inside of a Node.js virtual machine built on the powerful V8 JavaScript engine. Functions have only a very restricted set of APIs available. Block code can never access the filesystem or host operating system. All database and network access is through a limited set of managed APIs (including a form of HTTP Request for accessing external web services).
In addition, the Node instance is running using cgroups to isolate each process from the others and the host operating system. The use of cgroups ensures a badly written or malicious block can’t consume all resources on the physical machine or access data from another developer’s block. It also provides extra hooks for monitoring and management.
Functions is built on top of the existing secure PubNub Data Stream Network so all communication with the outside world is secure and sensitive payloads can be encrypted on the end device for end-to-end security. The Access Manager APIs provide additional access control at the channel level, further protecting sensitive data streams.
The Distributed Key Value Store
Functions has a built in key value store. You can store and retrieve messages or any other JSON-like object in the datastore using a Promise based API. The datastore provides an eventually consistent data model so computation can continue without waiting for locks or synchronization. In the Key/Value Store tutorial you can see an example of using the KV Store to save and retrieve a random number to the store. The store can hold anything you want as long as it’s less than 32kb per item.
Maintaining Low Latency
One of Functions’ goals is to maintain low-latency response to real-time messages. We do this by moving computation to where the data is, instead of the other way around. The code for your block is sent to multiple edge nodes around the globe simultaneously — subsequently, messages are routed to the closest edge node.
All APIs are designed to minimize latency through the use of promises and lack of data locking. If your code needs to invoke an external webservice that might take a while to respond the event handler can both wait for the webservice callback and also send a message to the end user immediately. The immediate message gives the user the information they need right now. When the callback completes your event handler can send an additonal followup message with additional information.
Next Steps
Middleware Functions. It will change how people build real-time applications and services. We can’t wait to see what you will make with it. If you don’t already have it, get your free account now and start coding with Functions right away.
