Skip to content

Resource

Resource (aka Resource) is a unit of functionality that can be run independently like a microservice.

A Resource is comprised of several elements like image, infrastructure, configuration, capabilities etc. Let's go over each one of them in detail next.

Elements of Resource

  • Image - allows you to configure image for this resource. Each resource can have a maximum of 1 image.
  • Infrastructure - allows you to configure infrastructure for this resource. Note that you can also parameterize your infrastructure based on the API parameters. Each resource can have a maximum of 1 infrastructure.
  • Environment variables - Environment variables define a set of environment variables to configure your docker image. These environment variables can be static values or could be dynamic values based on the Input parameters. In addition, we have also defined some dynamic system parameters for your convenience. For more details, please see this page
  • Configuration - allows you to specify a configuration needed to run your docker image. Like environment variables, configuration can have static values or also dynamic values based on the Input parameters. For more details, please see this page
  • Capabilities - each component can be configured with set of capabilities as defined here
  • API parameters - Your SaaS API parameters define a set of parameters that you want to take input from your customers. You can define the type, constraints, limits and we will make sure that those properties are honored in your generated control plane. For more details on API parameters, please see this page
  • Action hooks - these are custom logic that you may want to run at different stages of your Resource. As an example, if you want to install an extension to your PostgreSQL cluster, you can simply run an extension command on the post CLUSTER_INIT stage. Another example could be to run a rebalance command on adding a new node or removing a node. We will make sure that these commands are run reliably or alert you if we find any issues. For more details on action hooks, please see this page

Types of Resource

Passive vs Active

If there is no image or infrastructure attached, we will treat that Resource as a metadata object to store information from your customers and configure other Resources. As an example, if you are building PostgreSQL SaaS and want to allow your users to input some of the PostgreSQL parameters, you can define a parameter-groups component to let your users specify list of parameters. We call such components as passive components.

If image/infra are attached, we call such components as active components and automatically take care of the full lifecycle of such components as well. You can also combine different Resources to build more complex SaaS, ex - if you are building Kafka SaaS, you may have 1 Resource to represent Kafka brokers and another Resource to represent Zookeeper. Similarly, if you are building PostgreSQL HA SaaS, you may have 1 Resource to represent Master and another Resource to represent Replicas to configure Master and Replicas separately.

Infrastructure type vs Deployment type

Infrastructure type Resources support the underlying architecture and are crucial for the scalability and reliability of the service. These include Load Balancers, which can be of two types: Layer 4 (L4), which are TCP port-based and Layer 7 (L7), which are path-based and provide more advanced routing capabilities based on URL path. Additionally, file storage solutions are included as infrastructure resources, with current support limited to AWS.

Deployment type Resources are the core building blocks of a SaaS provider's offering, integral to the data plane of the service. These components are essential for the operation and delivery of the service, handling the actual processing and management of user data. Additionally, serverless proxy Resources can be included in deployment resources to support serverless offerings.

Internal vs External (tenant aware)

A Resource can be internal or external. In your SaaS stack, there might be some components that you may want to directly expose to your customers while others may be technical details that you don’t want to expose to your customers. Omnistrate platform will build a SaaS experience such that only external (tenant aware) components will be exposed to your customers.

In the above example, you can mark caching and database Resources as internal, and an application Resource as external. In this case, Omnistrate will only expose 1 Resource while generating the SaaS experience.

Note

Note that internal Resources doesn't imply that you can't open a port for your customers for those components. It just means that your control plane will not expose that resource to your customer to directly provision or other management operations. In fact,

  • You may have external ports open for your customers to interact.
  • Alternatively, you may have no ports open for your external service.

Connecting Resources

Your SaaS may have 1 or more Resources to form a multi-component application SaaS potentially dependent on or linked with each other.

Example

Let’s say you want to build a LAMP stack based SaaS, you can define Memcached as your caching component, MySQL as a database Resource and an application server to host your PHP application as a third Resource.

You can then connect them by marking caching and database Resources as dependencies to an application Resource. We will use this information to provision, scale, recover, patch different Resources accordingly.