Migrating from PubNub Functions v1 to v2: What You Need to Know
By 28th of February 2025 all users using PubNub Functions v1 will get automatically migrated to Functions v2, this migration won’t generate any downtime. And after the successful migration users will get a new and updated v2 interface enhanced with a new Packages/Revisions/Deployments structure.
PubNub Functions v2 introduces a lot of new capabilities and improvements over Functions v1. This article outlines the changes, highlights the advantages of upgrading, and provides guidance to ensure a smooth transition for developers and teams currently using Functions v1.
Function Assets
Unchanged assets (v1 and v2)
Function - PubNub single serverless function of a certain type i.e Before Publish, After Presence, On Request etc.
Deprecated assets (not in v2)
Module - set of functions for 1 keyset
New assets (introduced in v2)
Package - A collection of functions grouped together, typically for a single use case. Packages can be versioned using Revisions.
Revision - A version of a Package, that might be different in content in content such as the code and configuration of Functions (at least one), the number of Functions, or their types.
Deployment - A Revision of a Package assigned to a single PubNub tenant (keyset) it can be Stopped or Runningi.
Want to test Functions v2?
Key Updates in Functions v2
Account-Level Packages:
- In Functions v1, modules were tied to specific keysets, requiring duplication for multi-keyset use.
- Functions v2 introduces Packages, which are account-level entities that can be versioned and seamlessly deployed to multiple keysets (1:n).
Versioning for Functions: Packages in v2 support Revisions, enabling developers to version their functions and roll back to previous versions if needed.
Enhanced UI: A completely revamped user interface provides an intuitive and efficient workflow for managing functions, Packages, and Deployments.
New Management API: A robust API (link to documentation) allows for programmatic management of functions, streamlining integration into CI/CD pipelines.
KV Store and Secret Management via API: The new API also supports management of the Key-Value (KV) Store and Vault (Secret storage), empowering developers to externalize variables and configurations for better control and more use cases.
Seamless Rolling Updates: Deploying a new Revision is a zero-downtime process. Both revisions operate simultaneously for average 10 seconds ensuring a smooth transition. Messages automatically stop flowing through the previously deployed version and seamlessly start flowing through the new version, with no loss or interruption of functionality.
Updated Permission Model:
- Roles have been restructured:
- App/Keyset-specific Function roles like Function Admin/Operator/Viewer for App/Keyset are removed.
- Account-level roles (Function Viewer and Function Developer) are introduced to better align with account-level assets like Packages and Revisions.
- Deployment-specific permissions (e.g., deploying or stopping Deployments, Revisions or Packages including all revisions) are now associated with App or Key Viewer/Admin Roles
User Roles - Functions v1 vs v2
Functions v2 introduces two distinct levels of function permissions:
Deployment Permissions
- These permissions define where Packages can be deployed. Depending on the scope, roles include App Admin/Viewer and Keyset Admin/Viewer.
- Note: The Account Admin role inherently holds all permissions, regardless of specific function-related roles.
Package Management Permissions
- These permissions apply to the management of Function Packages at the account level.
- Function Developer: Create, Read, Update, and Delete (CRUD) Packages and their Revisions.
- Function Viewer: Read-only access to Packages and their Revisions.
| Functions v1 | Functions v2 | Comment |
|---|---|---|
| Account Admin / Account Owner | Account Admin / Account Owner | Both in v1 and v2 they have full Function privileges |
| Functions Operator - for an App | - | No adequate role - allowed to start/stop without editing function - user needs to be either Function Developer or Viewer |
| (additional role needed App Viewer or higher) | ||
| Functions Operator - for a Keyset | - | No adequate role - allowed to start/stop without editing function - user needs to be either Function Developer or Viewer |
| (additional role needed Keyset Viewer or higher) | ||
| Functions Developer - for an App | Function Developer (additional role needed App Viewer or higher) | User will be additionally able to CRUD Packages at the account level |
| (additional role needed App Viewer or higher) | ||
| Functions Developer - for a Keyset | Function Developer (additional role needed App Viewer or higher) | User will be additionally able to CRUD Packages at the account level |
| (additional role needed Keyset Viewer or higher) | ||
| Functions Viewer - for an App | Function Viewer (additional role needed App Viewer or higher) | User will be additionally able to View Packages at the account level |
| (additional role needed App Viewer or higher) | ||
| Functions Viewer - for Keyset | Function Viewer (additional role needed App Viewer or higher) | User will be additionally able to View Packages at the account level |
| (additional role needed Keyset Viewer or higher) |
Advantages of Functions v2
Versioning - Ensures robust lifecycle management for Functions, allowing for easy rollbacks, updates, and iterations.
Rolling Updates - Ensures zero downtime and smooth user experiences during function updates - now any new Function version can be deployed directly to already deployed one without the need of Starting and Stopping and without losing messages in the process.
One Package, Multiple Keysets - Simplifies management by enabling a single Package to be deployed across multiple keysets, reducing duplication and maintenance overhead.
Publicly Available management API - thanks to new API to manage Packages, Versions, Deployments but also Secrets and KV you can build more robust implementations, and automate your Functions creation and operation.
Worth to know:
- Remember that type of Functions, path, and channel is now part of Revision configuration
- To improve using Function for automated Use Cases we plan to release a CLI in 2025
- When migrating from v1 to v2 currently existing version of Module (Set of Function) will become its initial revision
Post Migration Must-Do
- Adapting to the New API (if you were using our Legacy API): Developers using the v1 API will need to transition to the v2 API for managing functions and KV stores. - Documentation
- Reassigning Permissions: Account Administrators need to assign roles and permissions at both the deployment and account levels to align with the updated permission model.
Best Practices after Migration
Optimizing your Function Setup:
Consolidate functions that vary only by variables and share the same channel/channel pattern into a single function using the KV Store or Secret API. This reduces duplication and leverages the KV Store for configuration management. This is not only recommended but allows to greater flexibility as variables can be managed using external API without need of restarting your function
Leveraging the API for Development Workflows:
Use the new API to integrate functions into your development pipelines, enabling automated deployments and version management.
Centralizing Logic on PubNub:
With developer-friendly features and improved tools, you can offload more business logic to PubNub Functions. This allows for faster execution in one of PubNub's points of presence around the world, minimizes latency, and reduces backend infrastructure requirements, enhancing both scalability and performance.
By adopting Functions v2, developers can optimize setups, enhance operational efficiency, and unlock the full potential of PubNub’s real-time infrastructure.
