.arcfrees your architecture from infra and vendor cruft so you can focus on the real business logic of your app. Ship only the code that matters, iterate faster and enjoy unprecedented availability guarantees.
The iron age of compute began with racked physical servers. Early cloud compute evolved past physical servers into virtual machines.
Virtual machines eventually gave way to containers and quickly containers have given rise to cloud functions.
Each cycle has taught new lessons in software architecture and this most recent iteration brings new challenges.
- Config and tooling is designed for the last generation of metaphors
- AWS is massive and overwhelming with many similar — but not the same — products with divergent interfaces between interlocking services
- Deep proprietary knowledge is required to configure and maintain common infrastructure primitives
- Configuration and infrastructure can drift, leaving systems in states that are difficult to repeat / reproduce, and thus scale
- Painful manifest files; JSON is difficult to read, has no comments, and is unforgiving to edit; YAML isn't much better and is in some ways far worse (i.e. deeply nested statements)
Some of these problems have been tamed with infrastructure as code, creating repeatable and reproducible systems. The trade-off there is: you're committing AWS configuration knowledge into your revision control systems.
.arc views infrastructure as a build artifact. And we prefer to not check build artifacts in with our code.
The .arc file
architect defines a high level vendor agnostic plaintext format,
.arc, as a manifest file to solve the specific problems laid out above.
- Focus on defining your app architecture with a subset of service primitives as high level definitions
npxto generate local code, configure, provision, and deploy cloud infrastructure from the
- You can still safely use the console tactically to access and administer primitives defined in
- The format, parser, and tooling are completely open to extension
.arcis also entirely portable between cloud vendors. (However no ports to clouds other than AWS have been made as of today.)
The .arc format
.arc format follows a few simple rules:
- Comments start with
- Sections start with
- Everything between sections becomes instructions for generating AWS infrastructure
.arc files are made up of the following sections:
@app[required] defines your application namespace
@awsdefines AWS variables
@domaindefines DNS for a custom domain name
@eventsdefines application events you can publish and subscribe to
@httpdefines HTTP (i.e.
@indexesdefines table global secondary indexes
@scheduleddefines functions that run on a schedule
@slackdefines HTTP handlers to build apps for the Slack API
@staticdefines S3 buckets for static assets
@tablesdefines DynamoDB database tables and trigger functions for them
This is a complete
.arc file example:
# .arc @app hello @domain hello.com @http get / post /likes get /likes @events hit-counter @scheduled daily-affirmation rate(1 day) @static staging test-hello-bucket production hello-bucket @tables likes likeID *String update Lambda @indexes likes date *String
npx create in the same directory as the
.arc file above generates the following function code:
/ ├── src │ ├── http │ │ ├── get-index/ │ │ ├── get-likes/ │ │ └── post-likes/ │ ├── events │ │ └── hit-counter/ │ ├── scheduled │ │ └── daily-affirmation/ │ ├── tables │ │ └── likes-update/ │ └── shared/ ├── .arc └── package.json
The code was also immediately deployed to the cloud in fully isolated
.arc format is terse, easy to read, and quickly learnable to author. The expressions in a
.arc file unlock the formerly complex tasks of cloud infrastructure provisioning, deployment, and orchestration.