Skip to content

Arda Platform Structure

Top Level Structure

Arda’s Platform is the set of resources that, together, support the operation of Arda Products. The top level elements of the Platform are shown in the diagram below.

Arda Platform Structure

  • Source Repositories: Github Organization and Repositories that contain the source code and documentation of Arda’s Products.
  • Artifact Repositories: Library, Image and package repositories that contain artifacts used to build, deploy and configure the platform resources. They also serve as a proxy and cache for artifacts in public repositories used by Arda’s Products.
  • Platform Runtime: Cloud resources (compute, storage, networking, Ingress/Egress, etc…) that directly run Arda’s products.
  • DevOps Pipelines: Logic and resources that transform the source code into artifacts to be kept in Artifact Repositories and deployed to the Platform Runtime for operation.
  • Platform OAM: Resources that support the Operations, Administration, and Maintenance of all the elements of the platform, including itself.

This document describes the structure of the Platform Runtime. The other parts of the overall platform also have their own internal structure, including support for their own change and evolution (test resources, etc.).

Concept of Purpose

The concept of Purpose is not part of the structure of the Platform itself, yet it is central to understand how the Platform is defined and organized. A Purpose is the combination of processes, activities, and policies that serve a goal of Arda’s Organization. Purposes are defined by how the organization works and inform how resources are applied and allocated. Typical Purposes include:

  • dev - Activities to develop new features and products and test them. It may include individual, team or organization wide activities, which may lead to defining more specialized Purposes like dev-<team-name>, dev-integration, or others.
  • staging - Activities to support testing and evaluation of a complete system after changes have been made to it. It also includes activities to show the new system to other teams, Arda’s functions or others.
  • demo - Activities dedicated to showcase the capabilities of the system to prospective and current customers.
  • prod - Running the revenue generating operations of the system.

Other Purposes may be defined as needed, but it is not a common event as new purposes are the result of a change in the way Arda’s Organization works.

Purposes may influence all parts of the Platform. They inform what is implemented in the DevOps Pipelines and what Infrastructures and Partitions are created in the Platform Runtime.

Runtime Platform Structure

The Runtime Arda Platform is the complete set of runtime resources that support the operation of Arda Products. It has a global set of services shared across the runtime platform and multiple isolated Environments to support different processes for Arda’s Engineering and Operations teams (Purposes).

Arda Platform Runtime Structure

  • Root Services are the set of resources shared by across all the Runtime Platform. They include resources like root DNS domains, Cloud Credentials, licenses, API Keys, etc.
  • Infrastructure is a set of resources that, due to cost, complexity, or other operational reasons (e.g. Cloud Vendor restrictions) are best shared for different operational Purposes. Examples of these resources are VPC networks, Parameter or Secret Stores, etc.
  • Partition is the set of resources that are dedicated to a specific Purpose. They are provisioned, configured and managed to fit the needs of the Purpose they serve. Partitions can access resources of the Infrastructure they are contained in and the Root Services but not resources of other Partitions or Infrastructures.
  • Component is the minimal unit of deployment and management of resources. A component can only access resources of the Partition to which it is deployed, the underlying Infrastructure and Root Services. Components may also access certain resources of other Components in the same Partition, like API Endpoints. Cross-Component access is very limited and must be the result of an explicit architecture and design decision.
  • Resource (not shown in diagram) is the minimal unit of deployment and management that the underlying Cloud Provider or Platform supports. Examples are Cloud Formation Stacks, AWS Resources, Helm Charts, etc.
  • Environment is not strictly a structural element of the Runtime Platform, but rather a shortcut name to designate all the resources of a Partition, its Infrastructure and Root Services that a Component can access upon deployment. Environment is the target of a deployment process.

Runtime Element Naming

Simple Names (Scoped to their Parent Container)

Important

Naming relies on the definition of a Simple Name, which:

  1. Is a string following the Regular Expression: ^[a-zA-Z0-9][a-zA-Z0-9]{0,31}$
  2. Its equality criteria is case-insensitive for uniqueness evaluation.
  1. Root Services do not have a special designation other than Root
  2. Infrastructure has a Simple Name that is unique within the Platform.
  3. Partition has a Simple Name unique within the Infrastructure that contains it. It is recommended to use a name that indicates the Purpose it serves, like prod, dev, stage, etc.
  4. Component has a Simple Name that must be unique within the Partition that contains it. A Component strictly understood is a specific instance of deployment of a set of artifacts.

Important

In practice, Components are designated based on the set of capabilities that they provide when they are deployed, regardless of the Environment to which they are deployed and have a strong relation to the modules and other functional concepts they implement. Because of this, Component names should also be globally unique as their Simple name will in practice designate the same set of capabilities and behaviors in different Environments.

It is recommended to use a name that indicates the main functional module or modules it implements, e.g. accounts or items, etc.
5. Environment An Environment is designated by concatenating the names of the Infrastructure and Partition it refers to. The concatenation
6. Resource The name of a resource must be unique within the Platform. This ensures compliance with Cloud Provider naming rules. To achieve this, a Resource name must be unique within the Component it is contained in. It can be a Simple Name or a composite name, depending on the requirements of the underlying technology. E.g. Cloud Formation resources created with CDK typically have a composite name that includes the containment hierarchy of the CDK App, Stack, and Constructs that are deployed.

Fully Qualified Names

A Fully Qualified Name (FQN) of an Element is the result of concatenating the Simple Names of all the elements that contain it in the order:

  1. Infrastructure
  2. Partition
  3. Component
  4. Resource

The Root element is not included in the FQN as it is implicit in all names.

Note that an Environment Name is indeed its FQN, as it is the concatenation of the names of the Infrastructure and Partition it refers to.

Concatenation of simple names is done using a - (hyphen) as a separator except in cases where the underlying technology requires a different separator or no separator at all.

Special cases of concatenation due to technology constraints:

  • Resources inside Postgres Databases need to use _ (underscore) as a separator.
  • DNS naming resources use . (dot) as a separator and reverse the order of composition.
  • URL Path Resources use / (slash) as separator.

Runtime Platform Class Diagram

For completeness, we define a class diagram that reflects the containment structure of the Runtime Platform.

uml diagram

Comments