Understanding Concepts

In order to use Axebow effectively, it is crucial to grasp its fundamental concepts and underlying principles. These concepts serve as the bedrock upon which all functionalities, interactions, and operations are built.

Familiarize yourself with these basics to enhance your proficiency in using the platform but also gain a deeper insight into its capabilities and potential applications.

This section aims to provide a clear and concise overview of these foundational platform concepts, empowering users to leverage its features with confidence and efficacy.

1. Infrastructure Model

Internally, we organize the data about the infrastructure in a hierarchical way:

Model

An Organization has a set of Tenant. The meaning of each Tenant depends on each organization, some organizations have a tenant for each geographical area, others by business areas.

Inside each Tenant, the users can manage several Accounts. Each Account contains several Deployment Environments.

1.1. Organization

Represents an Axebow client. An organization owns a set of Tenants.

In essence, the functionality associated to an organization must guarantee that Axebow mechanisms allow issuing tokens so that tenants can be associated with organizations, potentially with spending amount limits.

1.2. Tenant

Organizational units in which a client could divide its IT. The meaning of each Tenant depends on each organization, some organizations has a tenant for geographical area, others by business area.

There is a special tenant called Freemium provided by Kumori as a sandbox for testing purposes. In this tenant you can deploy applications and integrate any third-party resources you need, free of charge. This tenant is limited to 2 vCPUs and 4 GB RAM for each user, what means, you can deploy a set of microservices which total resources consumption doesn’t exceed 2 vCPUs and 4 GB RAM.

IMPORTANT

The Freemium tenant is a sandbox for testing, all the deployed services will be deleted daily.

All activity in the platform is referred to a tenant. It is within tenants that roles of users are defined.

1.3. Account

Identifies an IaaS provider, as well as configures the credentials (tokens) needed to act on the IaaS provider to recruit resources (expenditure).

An account is also used to establish various limits on expenditures of resources, as well as to establish the characteristics of the various resource provided by the target IaaS (which machine flavors to use, or what storage providers to employ)

1.4. Environment

An Environment is also known as Deployment Environment. It is a logical division of the computational resources available in an account.

A deployment environment refers to a given Account IaaS provider infrastructure setup, where Kumori Platform is installed. The applications and services are deployed and run on that Kumori Platform.

1.5. Infrastructure Costs

Infrastructure costs refer to the expenses associated with using the IaaS provider infrastructure in which the deployment environments are setup.

1.6. Label

Labels are key-value pairs that can be used on Axebow to group related resources.

Examples:

  1. You can use labels to group Environments in categories such as production, staging, or development so that you can filter the resources that belong to each development stage.

  2. Use the labels to group Environments in categories such as azure, aws, google, or ovh so that you can filter the resources that belong to each cloud provider.

  3. Labels allow to group Environments in categories like process-A, process-B, or process-C so that you can filter the resources that belong to each end-to-end process.

1.7. Limit

A limit sets the maximum number of resources a Tenant, an Account or an Environment could consume. There are two limits, soft and hard.

  • Tenant Limits set the maximum total accumulated number of resources that its Accounts can consume. The addition of all resources consumed in all Tenant Accounts cannot over exceed Tenant Limits.

  • Account Limits set the maximum total accumulated number of resources that its Environments can consume. The addition of all resources consumed in all Account Environments cannot over exceed Account Limits.

  • Environment Limits set the maximum resources can be consumed by services deployed within it.

There are four types of limits:

  • CPU

  • Memory

  • Storage

  • IaaS Costs

2. Component

A Component is just a program that can be autonomously ran within its own environment. When ran, such a program becomes a microservice. Moreover, in a microservices environment, running a Component may actually result in the execution ot several autonomous instances of that program. This makes sense when we need the aggregated power of those in

3. Service

Services are thus formed by running multiple microservices within the constraints of the Service deployment architecture, describing the intercommunication patterns among those services.

When a service is first activated, one of the problems that needs to be solved is ensuring each one of the microservices can find those microservices with whom it needs to communicate. This is often referred to as service discovery.

4. Service Application

In a nutshell, a service application brings together the set of components that will form a service, together with the interconnections that must be established so that their instances can discover each other.

In addition, a service application also declares the set of configuration parameters it expects, as well as the set of resources it needs to be provided with.

5. Client Channel

A client channel represents a dependency on some other microservice.

6. Server Channel

A server channel represents a functionality provided by the component through an endpoint.

7. Deployment

Also known as Deployment Configuration of components and services.

To be able to actually deploy a component or a service application, we need to make sure that all configuration parameters for all the roles are set to concrete values.

The Deployment Configuration is a specific element to represent a deployment action of a service application.

8. Inbound

Protocol and port definition for allowing a microservice or an application to be reached from the outside (usually from the Internet) through the given registered protocol, port and domain. There are two inbound types:

  • TCP. Allows TCP connections to a port. There can be only one inbound registered in a given port.

  • HTTP. Allows HTTPS requests to a domain name. There can be only one inbound registered with a given domain. All the HTTP inbound uses the same port 443, Kumori Cluster will route to target application or microservice by domain name.

9. RBAC

Role Based Access Control

Below the model for user roles in Axebow:

  • Plain User. Any registered user. This role allows to deploy services and register resources on any Tenant, Account, or Environment to which the user belongs.

    The resources a Plain User can use depend on the Tenant, Account, or Environment limits.

  • Owner. When a Plain User creates an Organization he adcquires the role Owner for that organization, all the tenants, accounts, and environments that belong to that organization.

    The Owner can manage and monitor the organization accounting data, its resources, and its users by granting permissions to other users assigning the role owner, admin, or plain user on the tenants he owns.

    When a Plain User creates a Tenant he adcquires the role Owner for that tenant, all the accounts, and environments that belong to that organization.

    The Owner can manage and monitor the tenant limits. Addionally, the user can assign any of the tenants he owns to any of the organizations he owns.

  • Admin. As the name suggest, these users can manage the tenant, including granting permissions to other users assiging the role admin or plain user on the tenants he manages.