The Big Picture, Part I

Introduction

Unlike some CDKs and IaC tools, Octo operates on an abstracted layer of infrastructure. The code you write is to manipulate the models which is then translated to individual Resources and Shared-Resources. It is these Resources that represent the real infrastructure, and Octo is responsible for translating them into the real infrastructure.

This transformation is done in a transaction, so that the state of the infrastructure is always consistent, and developers have the opportunity to rollback changes if something goes wrong. At the end of the transaction we also generate a State, which is used to track the state of the infrastructure.

Libraries

The Octo ecosystem consists of many smaller sets of libraries - each building a different functionality on top of each other.

octo

The octo library is responsible for providing model definitions, transaction management, state management, diffs, serialization, and other common functions.

octo-aws-cdk

The octo-aws-cdk provides definitions for Models, the individual Resources and Shared-Resources, and their respective Actions.
Any octo-*-cdk library enhances the octo library to fit individual cloud providers, such as AWS, Azure, and GCP. We currently only support AWS, with future support to come for Azure, GCP, and other cloud providers.

octo-build

The octo-build library provides a helper utility - octob, which helps build applications using YAML configurations.

octo-event-listeners

The octo-event-listeners library provides few common listeners to listen and process Octo events. E.g. logging listener can provide logs to debug Octo.