Skip to main content

Introduction

Celerity applications are made up of a set of resource types that can be defined in a blueprint along with handler source code. A blueprint defines the components of the application and its infrastructure dependencies.

Compute resources make up the compute components of your application that can run on FaaS1 platforms, containerised environments, or other compute platforms without any changes to your application source code2.

Infrastructure resources allow you to define common components such as queues, databases and VPCs that an application depends on.

There are 5 main compute resource types for a Celerity application including celerity/api, celerity/consumer3, celerity/schedule, celerity/workflow and celerity/handler.

There are 7 main infrastructure resource types including celerity/vpc, celerity/sqlDatabase, celerity/datastore, celerity/cache, celerity/topic, celerity/queue and celerity/bucket.

In addition to these, there are also convenience resource types for shared handler configuration and application secrets. Each of these resources are versioned over time, the implementation of these resource types are spread across the Celerity runtime and build engine. The runtime and build engine projects will indicate which resource versions are supported for a given version of the software.

The celerity/api, celerity/consumer and celerity/schedule resource types can be composed together to make up a single application. Depending on the target environment, the Celerity build engine will ensure the necessary infrastructure is provisioned to support each of these resource types in a single deployable unit.

note

Blueprints are not exclusive to Celerity resources. The blueprint specification and core framework implementation are designed to be generic and can be used to describe any kind of resources, not just Celerity resources. You can even use the Blueprint framework as a part of a more general purpose deployment system for known cloud providers or any kind of resources that can be managed with an API.

Footnotes​

  1. Function-as-a-Service such as AWS Lambda, Google Cloud Functions, and Azure Functions. ↩

  2. Minimal configuration changes that feed into the Celerity Build process are required. Changes to your source code may be required if you are switching cloud providers and your application talks to vendor-specific services, such as AWS S3, Google Cloud Storage, or Azure Blob Storage. ↩

  3. Depending on the target deployment environment, celerity/consumer can be a composite of application config and infrastructure resources such as queues that subscribe to topics. Read more about consumers. ↩