Although Cdev is currently focused on Serverless development, it is built on a general purpose Cloud infrastructure framework. This framework is designed to track desired updates to a project and deploy those changes onto the Cloud.
Within the Cdev framework, a resource is a logical representation of a defined computing resource or service provided by a Cloud. Although this is an abstract definition, it encapsulates the flexibility of the resource model.
An important aspect to note is that a resource is a logical representation of an actual Cloud service. This means that the properties of the resource do not need to map one to one to the actual properties in the Cloud. This allows a resource to be shaped to meet the needs of different projects. Although the properties of a resource can be defined arbitrarily, the definitions should have a logical relationship to the final deployed Cloud service. This allows for resources like the Serverless Function that require tying together multiple services in the Cloud to be simplified into a single resource.
All resources must have three values: name, resource_id, and hash.
The resource_id (ruuid) is used to categorize resource that are of the same type (cdev::simple::bucket, etc). The structure of the ruuid is <organization>::<package>::<resource>. The organization is the highest level information about who created and maintains that resource. The package allows the organization to group and categorize different resources together. The resource is a logically appropriate name for the resource.
When creating a resource it must be given a name that will be used to reference the resource throughout the framework.
A resource can have any number of properties that define how the resource should be deployed. The hash is the identification of a specific configuration of the properties of a resource. If you change one of the properties of the resource, it should result in a change in the hash. This means that the hash can be used to track the desired state of the resource.
name of a resource should never affect the hash of the resource. This differentiation between the name and properties is a core principle of how Cdev tracks changes in resources.A component is a namespace for a collection of resources. The component provides a limit on the naming conventions for a set of resources. Within a component, a resource must be uniquely identified by both the pairs: <ruuid,name> and <ruuid, hash>. The following demonstrates different scenarios with components:
Bad (conflicting names in same component)
- Component A
- cdev::simple::function demo (hash -> 1)
- cdev::simple::function demo (hash -> 2)
Good (conflicting names in different components)
- Component A
- cdev::simple::function demo (hash -> 1)
- Component B
- cdev::simple::function demo (hash -> 2)
Bad (conflicting hash in same component)
- Component A
- cdev::simple::function demo1 (hash -> 1)
- cdev::simple::function demo2 (hash -> 1)
Good (conflicting hash in different components)
- Component A
- cdev::simple::function demo1 (hash -> 1)
- Component B
- cdev::simple::function demo2 (hash -> 1)
Since a resource must not have a conflicting hash within the same component, most resources will provide a nonce property. This property is used to differentiate resources with the same hash as different resources. For example:
bucket1 = Bucket("b1")
bucket2 = Bucket("b2", nonce='1')
The connections between the set of all resources create a resource graph. This data structure is created by understanding how resources share the output generated by the Cloud. The deployment of resources into the cloud is driven by the workflow of generating a resource graph and comparing it to the previously deployed resource graph.
cdev deploy command is responsible for executing this workflow. It generates a new resource graph based on the current state of your project then generates the differences from the previously deployed graph. Once you have approved the changes, it deploys them into the cloud.Updates to resources in the resource graph can be expressed as three types of actions: create, update, and delete. These three actions must be mapped to changes in the Cloud that reflect the desired change to the resource. Cdev provides a defined layer of abstraction between the actions on the resource graph and updating of the Cloud via the Mapper Api.
A Mapper is a class that is designated to handle updating the Cloud to reflect a desired change for a resource. Mappers are registered with the framework to handle deploying all resources from an organization, and for returning information about the deployed services on the Cloud.
Serverless Function, consist of many API calls to the cloud. If there is an error returned from the cloud, the deployment of the resource is considered failed, but the framework does not currently have the capability to clean up any potentially left over deployed cloud resources. If your project becomes unable to recover from a failed resource update, you can use the cdev remove-resource command to remove the tracked resource from the backend and redeploy a new version.As a project is developed, the current state of the resource graph must stored so that it can be referenced in the future to understand updates. Along with the resource graph the backend also stores all the output information generated by the Cloud. Within the Cdev framework, the backend should be the only place that state should be persisted.