Architect Core Concepts

Before you get started with Architect, it is important to understand the four different entities that are used to describe and compose applications and environments.


Architect services can be thought of synonymously with microservices or in the use of the term in "Service-Oriented Architecture" (SOA); a service represents a discrete unit of functionality that can be updated independently of others. The standout feature of an Architect service is they include references to services they depend on in order to complete their work.

All it takes to compose an Architect service is a config file that cites the service's Docker image and the service's dependencies. Once a config file has been created, Architect can automate the deployment of its dependencies, instrument service discovery, and enforce strict network security.


Architect components are collections of services designed to work exclusively together. All services encapsulated by a component are allocated privately. In this way, components are a great structure for pairing services with private databases or other stateful resources. Components are the main entity that get published to Architect's registry for use in multiple environments or by multiple users.

In order to control ingress traffic, components can also be registered with unique interfaces that broker traffic to individual services within the component. This control not only allows upstream callers to connect to a component's APIs, but also allows for a variety of customizable rewrite rules that developers can use as a personalized API gateway. Since components can control these gateways and expose unique interfaces, components can also be cited as dependencies of other components allowing developers to collaborate more effectively across teams.

name: test/component
description: Sample Architect component

# components can assert required parameters
    default: test
    description: Root username for the components database
    required: true
    description: Root password for the components database
    description: Name of the database housing the components state

# components can cite other components as dependencies
  test/payments: latest

# components can have N services registered. Services are
# private to the component.
  	image: postgres:11
      POSTGRES_USER: ${{ parameters.DB_USER }}
      POSTGRES_PASSWORD: ${{ parameters.DB_PASS }}
        port: 5432
        protocol: postgres
      main: 8080
      DB_ADDR: ${{ }}/${{ parameters.DB_NAME }}
      DB_USER: ${{ parameters.DB_USER }}
      DB_PASS: ${{ parameters.DB_PASS }}
      PAYMENTS_ADDR: ${{ dependencies['test/payments'].interfaces.public.url }}

# components can control ingress traffic to their services with interfaces
    description: Expose the API to upstream callers
    url: ${{ services.api.interfaces.main.url }}


Architect platforms represent deploy targets – clusters or cloud provider accounts that can be used to deploy resources and instrument application networking. Platform types include Kubernetes, AWS ECS, and even local hardware. Registering platforms with Architect is what enables our system to deploy components and their dependencies to your infrastructure on your behalf.


Architect environments are groups of components intended to be deployed together along with the configuration details needed to produce a specific runtime state. Environments can be thought of synonymously with infrastructure-as-code, but instead of a central template the environment pulls from the various component definitions in its spec and in the registry. All changes to an environment will automatically apply the required ingress/egress rules to broker traffic and environments can be applied to any platform.

# environments can list as many components as they want to be deployed
    # environments can assign localized values for component parameters
      ROOT_DB_PASS: test-password

    # environments can control replicas of individual services
        replicas: 3

# Creating interfaces for environments exposes it to outside traffic. Each
# interface gets allocated its own domain and can have N path rewrite rules.
    description: External API gateway
    url: ${{ components['test/component'].interfaces.public.url }}

Since components are aware of their own dependencies and networking, environments can never be deployed in an unhealthy state resulting from missing services or parameters. Architect both protects operators from preventable errors and logs the changes made to the entire environment with each deployment. This changelog not only provides a robust audit-trail, but also allows for seamless, automated rollbacks.