Intro to Components

Intro to Components

Ortelius manages microservices and other reusable objects as Components. Components are assigned to an Application even though they are managed independently. Assign Components to Applications to track a ’logical’ view of your software solution. In a monolithic approach, we performed this step during the software compile and link, or ‘build’ process. In microservices, they are loosely coupled and linked at run-time. Defining Components to Applications puts the Application in a ’logical’ view.

If you are an API or microservice developer, this will be where you do most of your work. However, application developers may also define Components that are used only by their specific Application. Components are microservices (containers), Database updates or files. By tracking the low level metadata for a Component, it can be easily shared in a consistent way across organizational teams and Environments.

Components change over time, and so Ortelius contains Component Base Versions and Component Versions.

• Component Base Version : The initial definition of a Component.

• Component Version : A child of the Component Base Version that represents changes.

Components and Domains

Components are organized by Domains. When you create a new Component you publish it to the Domain that defines the “Solution Space” the Component addresses. By organizing Components into Domains, you create a catalog that allows other teams within your organization to find and reuse your Components. The organization of Components by Domains support the Domain Driven Design of a microservices architecture. Before you begin publishing Components, you will need to have a Domain ready. For more on Domains see the Building Your Domain Catalog.

Components and Applications

Components are consumed by Applications. You track a ’logical’ view of your complete software solution by seeing which Components the Application uses. Defining Components to Applications is a “packaging” process done at the Application level.

There is a many-to-many relationship between Applications and Components. An Application can contain many different Components. A Component can be used across many different Applications. Components can be easily shared between Applications. Ortelius tracks and versions these Component relationships including to which Applications they have been assigned.

Sharing Components

If you want your microservice Component to be shared across your teams, publish your Component to a Domain that allows sharing. If it is defined to only your Application, then only your team will be able to see it.

Component Versioning

Ortelius uses a backend versioning engine to track your Components. Versioning tracks Component attributes including low level information that is needed for other teams to reuse your Component including:

• Gitrepo
• Git commit (Branch and Tag)
• CD Build / Workflow Number
• Container SHA
• Docker Registry
• Enviornment Vairaibles
• SBOMs
• CVEs
• Swagger and Readme
• Deployment Metadata (Helm Chart, Ansible Playbook, etc.)
• Any Attributes such as Key Value Pairs, environment variables, and database schemas.

This information is collected when you define your Component to the Ortelius catalog. The Ortelius Command Line Interface will automatically update this information via your CD Pipeline. When your Pipeline initiates a workflow for the Component, it indicates that a new version of the Component is being pushed across the Pipeline causing all consuming Applications to be automatically incremented to a new version number. If a Component changes, the consuming Application also changes. Both get a new version number. For more information see Using Ortelius with CI/CD.

When you first define your Component Ortelius tracks it as the Component Base Version. Subsequent updates to that Component creates a new Component Version which represent the updates over time. A Component Base Version is always the first one created, and it acts as a model for subsequent Component Versions. Otherwise they are identical types of objects.

Ortelius uses a simple versioning number schema starting at 1 and incrementing over time, for example: Myapp;1, Myapp;2. .

You can use your DevOps Pipeline to include variance in your versioning number (base name, variant, version). See Component Versioning Schema.