Skip to content

Resource

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

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

Elements of service component

  • 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 service component. 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 service component

Passive vs Active

If there is no image or infrastructure attached, we will treat that service component as a metadata object to store information from your customers and configure other service components. 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 service components to build more complex SaaS, ex - if you are building Kafka SaaS, you may have 1 service component to represent Kafka brokers and another service component to represent Zookeeper. Similarly, if you are building PostgreSQL HA SaaS, you may have 1 service component to represent Master and another service component to represent Replicas to configure Master and Replicas separately.

Infrastructure type vs Deployment type

Infrastructure type service components 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 service components 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 service components can be included in deployment resources to support serverless offerings.

Internal vs External (tenant aware)

A service component 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 service components as internal, and an application service component as external. In this case, Omnistrate will only expose 1 service component while generating the SaaS experience.

Note

Note that internal service components 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 service components

Your SaaS may have 1 or more service components 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 service component and an application server to host your PHP application as a third service component.

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