Attini Way of Working

The Attini Framework and the Attini CLI together create a way of working that helps you to manage your AWS resources using AWS CloudFormation.

Environment isolationq

A core concept in Attini is the complete isolation of IT environments. We achieve this by copying all deployment source files into the IT environment, then all the deployment logic is performed by serverless resources inside your IT environment. This means that every IT environment is self-sufficient.

With tools that run on virtual machines or in containers, it’s often too expensive and high maintenance to have a “worker node” running in every environment all the time, this means that you often run the worker nodes in a central location and share them cross environments. Even if you’re using a CI/CD SaaS service, you still have a central platform, you just don’t manage it yourself. These types of central platforms often result in scaling limitations and tight environment coupling.

Because Attini is 100% serverless, its easy and low cost to have one copy of all CI/CD resources per environment. This design also comes with performance advantages.

Advantages

• An incident/downtime/problem with your central build/deploy platform will never block you from managing your IT environment.
• Easy to experiment with test environments and be sure that you never affect any other environment’s CI/CD resources.
• Higher deployment speed and fewer queues.
• Much easier to maintain many environments (multiple test environments, global deployments, disaster recovery environments etc).

Stateful distributions

The Attini distribution is a zip archive that contains:

1. Name and id (version).
2. All source files needed for the deployment.
3. Instructors on how to execute the deployment.

Attini distributions are inspired by how container images bundle all its dependencies into one image. Similarly, the Attini CLI helps you to package as many dependencies as possible into one distribution. This means that you will have all your templates, code, configuration, and any other files you might need, gathered in one place.

The Attini CLI also helps you to run scripts on a copy of your files, so you get a natural place in your workflow to:

• Get automatic configuration (for example, to freeze software version or AMI ids).
• Fetch centrally managed files (standard temples, global configuration, software libraries etc).
• Build your code.
• Etc…

The goal is to make the distribution as static as possible so that your deployment will be as predictable as possible.

Managing multiple environments

When we run multiple environments, we often have two contradicting requirements:

1. We should be able to do things in one environment without affecting the others.
2. All our environments should look the same.

This is a contradiction because if we do things in one environment, that environment will divert from our other environments.

To work around this contradiction, we need to be able to do 3 things:

1. Individually managed every environment.
2. Find discrepancies between environments.
3. Put the environments back in sync.

With Attini every environment has its own set CI/CD resources so it’s easy to individually work with one environment for development or incident mitigation (hotfix or rollback).

You can find discrepancies between environments by comparing distribution versions that are currently running in your environments. We recommend that you use a git commit (or part of the git commit) as your distribution id (or part of the id). This way you will also get a changelog via your git commit messages.

If you find discrepancies between environments, it’s easy to promote the distribution with the correct version to the out-of-date environment. Normally this means that we promote new features to production or other test environments (from development to staging), but it’s also very handy if you need to rollback a development environment after failed tests.

The Attini deployment plan

The pipeline that you are using when designing a hands-off deployment is critical for your success.

Here are some of the most important requirements:

1. Automatically configured so that you can maintain them on a bigger scale.
2. They have to be fast so that your development and incident mitigation can be fast.
3. Full-featured process logic like parallel actions, choices, re-tries, etc.
4. Plenty of services integrations (features).
5. Mange dependencies.

The Attini deployment plan is always automatically created and updated by the Attini init deployment so it’s just as easy to maintain 1 deployment plan as 10 deployment plans.

The Attini deployment plan is an abstraction on AWS StepFunction with comes with a lot of advantages:

1. Familiar syntax.
2. It’s very fast.
3. It is low cost for this use case.
4. Full of features and flexible process logic and error handling.
5. Lots of native AWS Service integrations.

But the AWS StepFunction needs a few more features to manage all our requirements, so Attini added:

1. Our own state types like AttiniCfn and AttiniMergeOutput to better integrate with AWS CloudFormation and to simplify common use-cases.
2. Standard Payload that manages dependency’s and run-time configuration.

In addition to this, Attini have managed to make most of our deployment logic event-driven, which is a big performance improvement.

Attini in your workflow

To make it easy to adopt Attini, we made 3 important design decisions:

1. No new authentication (we use your current AWS credentials).
2. Make the packaging (build) portable with the Attini CLI.
3. Move all deployment logic into the IT environment (Attini deployment plan).

Attini only uses your AWS credentials, so there is no need for another login or SSO configuration, your current AWS IAM roles and users will work out of the box (they might need the attini-cli-user-{region} IAM policy that is created by the attini-setup).

This also means that AWS CloudTrail will log everything Attini does, find mroe information here.

If you run all your build scripts via the package section in the attini-config. It will be easy for you to run the same code from your local computer that your build server does. This enables you to bypass git and your build server during development, which improves development speed.

The Attini CLI also has features that are designed to help you to mock your build server configuration so that your build scripts can run unchanged.

Because we moved all deployment logic from a central CI/CD platform (Build server, Deployment SaaS solution, etc), and because you can install the Attini CLI anywhere, you can always extend any tool you currently use with Attini.

Getting started

To get started with Attini, see our Quick start.