Your service's code is just that - entirely yours. Architect has no runtime presence, meaning you can write using whatever languages, frameworks, and tools you desire.
Architect deployments are standardized to support Docker platforms and tools, so all services require a Dockerfile to be published.
Write a manifest file outlining your services interface, parameters, and dependencies. Architect uses this to index your service and build dependency graphs at deploy-time.
name: e-mart/shopping-cart description: OIDC compliant user authentication service language: python dependencies: e-mart/payments: 1.1 parameters: DEFAULT_CURRENCY: description: Default currency for cart pricing default: USD
Services are already aware of the dependencies they need in order to run, so all you need to focus on is which ones need to be exposed to users and how. Just name a service, give it an ingress rule, and we'll take care of the rest.
Because service configs include the details of how they can be configured, operators are free to set those parameters unique to each environment.
services: e-market/frontend:v1.2: interfaces: main: subdomain: shop parameters: DEFAULT_CURRENCY: GBP
$ architect deploy arc-environment.json
With each deploy, Architect builds a graph of all required dependencies and merges it with the existing environment to produce a new infrastructure-as-code template representing the target environment.
This static representation of the target state allows for bullet-proof reproduction of the environment, rollbacks, and audit trails to protect your application and your business.