We will start by explaining Lyrid terminologies.
Lyrid user is a login into the platform that allows a user to utilize the platform.
Follow these following steps to create a Lyrid user:
An account is the entity in the platform where all Lyrid Applications are built, and how Lyrid monitors the charges to the platform. At least one Lyrid user must be associated with an account. An account can contain more than one Lyrid user, and each user can be assigned into roles in the account that represents user’s group or organization or company.
Access and Secret Key is a pair of string that identifies user and its account in the platform. This is used to access the Command Line and the REST API under Lyrid User and Account.
A role determines the user permissions within an account.
The role feature is not yet fully implemented; all users currently have full access to their account.
Lyrid Function is the base building block of the Lyrid application. A function is the code that is wrapped with Lyrid platform wrapper that is targeted to a cloud platform (AWS or GCP).
A Lyrid Module is a collection of functions that are managed and deployed together. A module has a strict association with a programming language, and only 1 programming language is allowed in a module.
A Revision is a tracked version of the Lyrid module; it is a version of the module that is currently serving the function in the platform. Users can submit more than one revision of the module into the system, but only the latest revision is used as an active revision to serve the Lyrid function.
The Lyrid App is a virtual construct that binds together the different Lyrid Modules. The Lyrid Function is made of the wrapped user’s code. The Lyrid App only uses the module that has an active revision.
In the future, the implementation will allow cross communication within modules and within the Lyrid App, a module can intercommunicate with another module without the need to authenticate. Outside the Lyrid App, a module will need to supply their authentication key to communicate with another module.
Lyrid Tag is a labelled pointer to a single revision of a module. We use this to keep track of the function deployed
A special tag of "latest" is a reserved label in the platform to identify the latest submission of the serverless function.
Lyrid Policy defines the behavior of the serverless function build, deployment and execution.
There's 3 different policy types:
Build - Settings related to building the Lyrid Serverless Functions.
Deployment - Settings related to deployments of the Lyrid Serverless Functions.
Execution - Settings related to behavior of the execution of the Lyrid Serverless Functions.
The policy features are partially implemented. Please check back in for more exciting updates!