InCa Terminologies

[anshulsao]

Let's make things simple before we talk about the future of "Infrastructure as a Catalog." First, we need to understand some key terms that will help shape our project. With a clear project goal in mind, let’s figure out the common terms we'll use.

[anshulsao]

Suggestion 1: Resources

In simple terms, the catalog will have items that need to be created or set up. These items could be things like a Cloud Account, VPC, Kubernetes cluster, services, databases, and so on. I suggest we call these items "resources." The reason is that the catalog will then be a collection of resources, and each resource will have details about its purpose and use. This makes the term "resource" general enough to cover all sorts of items that might be needed in the setup.

What do you think about this suggestion? Please share your thoughts and opinions to help us refine our terminology further.

[anshulsao]

Should we call them resource manifests instead so that they do not cause confusion with the actual resources that will be created per environment? @rr0hit @pramodh-ayyappan @vishnukv-facets ?

[pramodh-ayyappan]

I recommend using the terms Infrastructure Objects or simply Objects instead of resources. This will help avoid any ambiguity for end-users, whether they are referring to a deployed resource or a definition

Also opslevel uses the same naming convention for InCa - https://docs.opslevel.com/docs/infrastructure

[anshulsao]

Suggestion 2: Intents

Each resource has a type, which essentially represents an intention to create a resource of a specific kind. This intention, or "intent," includes everything a person needs and may or may not involve details about how to implement it. That's because there can be various ways to implement a given intent. For instance, if a user creates one or more resources with the intent to establish a Kubernetes cluster, their intent might specify things like the Kubernetes version. However, the actual setup of this resource could be done in different ways, such as using AKS, EKS, or another Kubernetes platform.

In simpler terms, "intents" describe what we want to do with each resource, but not necessarily how to do it, allowing for flexibility in implementation. What are your thoughts on this suggestion?

[rr0hit]

+1 for the term "Intent". It is critical that the documentation emphasises the notion that these are "record of intents" the same way Kubernetes objects are.

[rr0hit]

On second thought, would Intent be a better term to use for "Resource" (currently suggested). This is more consistent with the Kubernetes take of "record of intents" . And the various types can be Intent Type or Intent Kind.

[rr0hit]

Intents must be concrete enough to help user understand how to interact with it. So database is not a concrete enough to be an intent. But MySQL is.

[krishankirtifacets]

Suggest to use terms which are easily relatable instead of inventing something which can have some cognitive load on the users.

We can think of referring the tangible items in architecture as Resources and the JSONs that we keep as part of the catalog we can call them as Resource Definitions or Definitions.

[pramodh-ayyappan]

I suggest employing the phrases Infrastructure Object Type or simply Object Type. While Intents is a valid option, the use of Objects tends to favor Object Type over Intents Type

https://kubernetes.io/docs/concepts/overview/working-with-objects/

A Kubernetes object is a "record of intent"--once you create the object, the Kubernetes system will constantly work to ensure that object exists. By creating an object, you're effectively telling the Kubernetes system what you want your cluster's workload to look like; this is your cluster's desired state.

[anshulsao]

Suggestion 3: Flavors

Given an intent, there can be several ways to achieve it. For example, a "MySQL" intent could be implemented as a Helm chart in Kubernetes or as RDS in AWS, among other methods. So, to actually bring the InCa to life in an environment, users might need details about the implementation. Essentially, we could have a registry of implementations for a specific intent, and users can choose from them. Since these implementations seem like different variations of the same thing, it's fitting to call them "flavors." In summary, each intent can have one or more flavors, and users can select them at the catalog level.

In simpler terms, every intent can have different "flavors" or ways it can be implemented, and users can choose which one they want when using the catalog. What are your thoughts on this approach?

[anujhydrabadi]

This implies that there should be a method to record details specific to implementation in the catalog. Additionally, this feature should be optional and distinctly separated from the initial specification, which was neutral regarding implementation.

[anshulsao]

This is true and we will take care of this while defining fields for the intent

[rr0hit]

+1 for Flavors. I also put forward "implementation" which would be a bit at your face wrt the meaning of it.

[anshulsao]

Suggestion 4: Environments and Overrides

Any instances created from the InCa catalog definition, using any implementation, will be termed an "environment." Additionally, there will be flexibility to define certain parts of the specification per environment, and these will be referred to as "environment overrides." These overrides are necessary because often, aspects like sizing or flavor can change from one environment to another due to various reasons such as cost, manageability, or others.

[4adway]

How about something like 'setup', 'settings', 'state' or 'configuration' instead of overrides? Are we using overrides because it caters to the software community more? Other terms sound more generic based on the use case.

[rr0hit]

+1 on both

[anshulsao]

https://github.com/Facets-cloud/InCa/blob/main/docs/2_terminologies.md

Please go through the draft above and comment if something is missing or not inline with the discussions.

[anurag-facets]

If I wanted to add ingress rules in my InCa, will I define it as:
Intent/Resource - Ingress
Intent/Resource Type - ALB
Flavor - k8s

[anurag-facets]

In this case, will my intent definition have references to another intent type's definition?

[rr0hit]

Resource: application-ingress
Intent/Type: ingress
Flavor: ALB/GLB/K8s

[rr0hit]

A non tech anology would help here I believe. Think of a 3Bedroom Hall Kitchen house blueprint.

Blueprint for 3Bedroom Hall Kitchen = Catalog
Each room in Blueprint = Resource
Types of rooms in the Blueprint (Bedroom, Hall, Kitchen) = Intents

An actual house built with the Blueprint is an Environment.
Any customizations to the master bedroom in the actual house are overrides.

This is what is being proposed. Open to better words and definitions