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.

Services

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.

Components

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
parameters:
  DB_USER:
    default: test
    description: Root username for the components database
  DB_PASS:
    required: true
    description: Root password for the components database
  DB_NAME:
    description: Name of the database housing the components state

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

# components can have N services registered. Services are
# private to the component.
services:
  my-database:
  	image: postgres:11
    environment:
      POSTGRES_USER: ${{ parameters.DB_USER }}
      POSTGRES_PASSWORD: ${{ parameters.DB_PASS }}
    interfaces:
      postgres:
        port: 5432
        protocol: postgres
  my-api:
    image: registry.architect.io/test/component:latest
    interfaces:
      main: 8080
    environment:
      DB_ADDR: ${{ services.my-database.interfaces.postgres.url }}/${{ 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
interfaces:
  public:
    description: Expose the API to upstream callers
    url: ${{ services.api.interfaces.main.url }}

Platforms

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.

Environments

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
components:
  test/component:
    # environments can assign localized values for component parameters
    parameters:
      ROOT_DB_PASS: test-password

    # environments can control replicas of individual services
    services:
      api:
        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.
interfaces:
  app:
    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.