Introduction

The MVP version of a platform definition is a common good practice starting point, which we can build on as adoption scales. We are weighing things such as ease-of-adoption and standardization against effort to implement. This is as hands-on experience of the platform is a paramount component of successful adoption. Instead of creating a so-called “big bang release”, which requires significant investments in regards to effort and people, we ensure we have just enough platform features to start getting experience with automating real life use-cases.

Overview

Zoom into this picture for details.

Overview

People

  • It is common that the people who operate and maintain the platform has other jobs and do not work dedicated on the platform. Even though we do not yet require a dedicated platform owner or platform engineering team, we should already start thinking about that.

Process

AAP Platform processes

Processes related to the AAP platform itself.

  • Incident management - We need a standard process for managing technical incidents for the platform. What will we do if something breaks?
  • Life Cycle Management - It is important that we communicate when we plan to update our platform. This in a form of a life-cycle management plan. At this point, if you do not know much about this, you can copy the Ansible Automation Platform life-cycle management plan, which you find here: Red Hat Ansible Automation Platform Life Cycle
  • Backup and recovery - We need to have a standard process for doing backups and recovering from those backups. Life cycle management and incident management depends on this.
  • Upgrading - We need a process for how to perform upgrades of our platform. This may also include how to handle updates of Red Hat Enterprise Linux or Red Hat OpenShift Container Platform.
  • Capacity management - How do we monitor the capacity of the platform and act as we need to expand the capacity? Put in place a process to deal with this. It’s normal that the process at this point is manual.

Onboarding process

  • Manual onboarding - The onboarding process is commonly not automated. When new people or teams get onboarded, the people who works with the platform are responsible for this process. This process is very simple in its nature, lacking assessment of who and what is onboarded and training. Because of this - our onboarding throughput is very limited. If you need to onboard more than a few teams, you need something more advanced.

An overview of a common onboarding process can be viewed below. Please note that the graphics describes all three advancement levels of onboarding. Overview

The steps for the MVP version of the onboarding process follows:

  • Users provided access to landing page - The landing page is referenced and described in the overall operational model. It is a page where users can go and get information such as platform documentation, descriptions of process (such as the onboarding process itself) and documentation and training materials/links.
  • LDAP groups created - If your organization is using an LDAP solution for identity, create some standard LDAP groups which you can connect to the AAP RBAC system. It’s good if you create some type of standard naming here, such as: aap-(team name)-admin, aap-(team name)-user, etc. The team in question can then own these teams and do user management themselves.
  • Users added to group - Users are added to the groups in question. This may be done by the team who are being onboarded.
  • Organization created - A common approach to a multi-tenant setup of AAP is that each team gets their own organization to create automation content within. This reduces overall complexity as teams then freely can create content without having to consider who may see or be able to use automation. If automation is to be shared with other teams (in other organizations, that is still possible, but then always need to be done as a separate action.
  • LDAP configuration in-place in AAP - To map a LDAP group to a role or team in AAP, you need to configure that in AAP. In AAP 2.5+ the feature is called “Authentication mappings”.
  • Git repository created - This can either be done by the different teams themselves (that is likely simplest) or by the central AAP team (which then risks to become a bottleneck).
  • Users provided access to git repository - Users need to be provided read or write access to the repository. It’s good if the default is that all users can view each others code. Write access can be limited to the team which owns a specific piece of automation. Keep in mind that if you want to re-use code in the form of Ansible roles, then it simplifies if those users have read access to the repository in which you store the role.

Development processes

  • There are no standardized processes yet. That also puts some limitations for how much we should scale at this point, as that would risk racking up a lot of technical debt.

Technology

AAP architecture

Architectural decisions related to Ansible Automation Platform.

Infrastructure design

Infrastructure related decisions.

  • Availability - We need to design our platform so that it can meet our requirements for availability. If you want some tips, look at the Ansible Automation Platform - Tested topologies documentation
  • Security - We need to design our platform so that it also meets requirements for security, that includes hardening practices for operating systems or Kubernetes, network planning, etc.
  • Monitoring - To ensure availability and security, some type of monitoring needs to be put in place.

Onboarding

Technology implementations related to onboarding.

  • Landing page - When someone gets onboarded to your platform. They need a place to start their onboarding process. This is typically a wiki page or webpage maintained by the core platform team.
  • Platform documentation - A common part of a technical platform implementation, you have documentation which describes to other people how the platform works.
  • Link collection - A good way to help people who get onboarded is by maintaining a list of useful links.

AAP design

Design of how to use Ansible Automation Platform features

  • Organizations - Give some thought how to use organizations. One team per organization is a popular choice.
  • Projects - How to use a project in AAP? Perhaps everyone should use “sync on launch”, etc.
  • Inventories - How to use inventories? Perhaps it’s best to let different teams decide on this for themselves at start. Allowing freedom is also a decision.
  • Credentials - How should people use credentials? Should everyone use a central credentials store? Or can you use locally defined credentials?
  • Secrets - How to hide secret information in Ansible automation? Ansible vaults or a central secrets store?
  • Templates - Starting off, people can probably decide, but there are many things here which can be standardized, such as naming of templates.
  • RBAC - How do you configure RBAC? This much relates to onboarding, so give it some thought.

Development tool chain

Design related to the development tool chain.

  • Git organization - How do you organize the automation in your version control system? Do you gather all repositories in the same group, or something else?
  • Git repository structure - When people start developing Ansible, they will wonder how to structure things. Do you put all things in a single gigantic repository or do you have some type of standard here to follow? One role, one collection often maps to one git repository. One collection of playbooks maintained by a single team often also maps to a single git repository. If you have something which is somehow sensitive, it’s often better to put it in it’s own repository, so you can maximize transparency for everything else.
  • Best practice organization - It’s a good idea to create some standard repositories, to show people how things can look like in regards to structure and documentation.

Platform management

Administrative features which helps with the development or maintenance of the platform.

  • Service Level Agreement - Select what the SLA for your platform should look like.
  • Operational Level Agreement - Select what the OLA for your platform should look like (if you use OLAs).
  • Feature planning - Make sure that as you plan and prioritize the different capabilities of your platform. A good start is to benchmark yourself against the model and then prioritize the different features across the MVP, 2.0 and Advanced levels. Except for creating more structure for the platform building process - this allows you to communicate detailed information about future feature, to the users of the platform.