Build services.
Configure environments.
Deploy.
Get all the benefits of infrastructure-as-code to reproduce environments with minimal configuration and maximum flexibility.
What you do...
1
Build services
Write your code
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.
Add a Dockerfile
Architect deployments are standardized to support Docker platforms and tools, so all services require a Dockerfile to be published.
Create a service config
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 use authentication service",
"language": "python",
"api": {
"type": "grpc"
},
"dependencies": {
"e-mart/payments": "v1.1"
},
"parameters": {
"DEFAULT_CURRENCY": {
"description": "Default currency for cart pricing",
"default": "USD"
}
}
}2
Configure environments
Exposed services
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.
Parameters
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": {
"ingress": {
"subdomain": "shop"
},
"parameters": {
"DEFAULT_CURRENCY": "GBP"
}
},
"e-market/shopping-cart:v1.1": {
"datastores": {
"redis-cache": {
"host": "postgres-instance.123456789012.us-east-1.rds.amazonaws.com",
"port": 5432
}
}
}
}
}3
Deploy
That's it! Just deploy your environment and Architect will take care of the rest!$ architect deploy arc-environment.jsonWhat we do...
1
Build your application graph
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.
2
Review proposed changes
We compare the target state with the current state of the environment to show and log a detailed view of proposed changes. This end-2-end comparison against existing environments allows us to change only what's needed.
3
Apply changes
Once changes have been reviewed we're ready to execute the deploy! Architect will deploy each resource as needed to support the new target state, automatically issue blue/green deployments to ensure zero downtime, and will show live updates each step of the way.
4
Store new and prior state
After each deployment, Architect stores the new and prior state in a detailed DB. This deploy history provides excellent insights into your application's history, and enables seamless rollbacks to any prior state.
