People and process
Boundary requires thoughtful considerations around people and processes in order to maximize its value. It is also necessary to rethink how an important platform technology such as Boundary is positioned and offered. Changing culture and processes can be difficult, as can organizational and political challenges. Our observations across the industry give us a glimpse into what "good" looks like, which we share below. Please keep in mind that no two organizations are the same, and your specific circumstances may require you to choose how you organize your teams.
Internal developer platform
The Internal developer platform (IDP) has emerged to address the challenge of reducing development cycles and organizational complexity, especially as cloud computing and IaC have drastically cut down infrastructure provisioning times.
The IDP builds on the time-tested shared service model, improved by adding a product management approach. In this model, a Platform team works with developers to build golden paths that development teams can consume in a self-service model.
Access to infrastructure for developers and other stakeholders is a critical component and hence an Access Management service is an integral part of any IDP. We recommend that the team with ownership of the IDP (aka the Platform team) also take ownership of operating Boundary, with the Security team and other related teams providing governance.
With this approach, two key roles are identified: producers and consumers. The terms “Producer” and “Consumer” are used to define the roles and responsibilities within a shared service or IDP provided by a Platform team.
Note
While we talk of the “Platform team” as a singular team, it is possible that the “Platform team” is composed of multiple sub-teams with separate areas of responsibility. For example, Access Management components of the IDP might be owned by a separate team than Infrastructure provisioning components. These sub teams will however collaborate closely to ensure that developers in the various business unit app teams can easily access these shared services.
Producers
In a shared service model, the Producers have a role in configuring the system to meet the needs of the different consumers. Their responsibilities include:
- Operating Boundary and ensuring it is available as a tier-0, mission-critical service.
- Ensuring workflows are clearly defined for application teams.
- Set up integration between Boundary and Vault for dynamic credentials.
- Work closely with cross functional teams to identify and targets/hosts to Boundary.
- Offering necessary enablement to the consumers.
The Producers ensure that the shared services are readily accessible and efficiently utilized by the consumers, empowering them to leverage the benefits of the Boundary platform effectively.
Consumers
In a shared service model, consumers refer to any team within the organization that utilizes the shared services provided by the Platform team. These teams have responsibilities that include:
- Initiating requests for access to targets in Boundary.
- Perform tasks on target systems accessed via Boundary.
Consumers play a crucial role in leveraging the shared services to meet their specific needs and requirements while adhering to the guidelines and standards set by the Platform team.
Platform team
The Platform team is responsible for overseeing the overall implementation and management of the shared tools and services to enable golden workflows, and driving its adoption within the organization. When a Platform team matures, they will tend towards providing their consumers an integrated user experience (that implements golden workflows) using the IDP.
In the context of Boundary adoption, the Platform team ensures efficiency and standardization by establishing and enforcing standards and best practices, promoting consistency across project teams and minimizing the risk of errors and inconsistencies that can disrupt operations. They enable scaling and reusability by enabling automated “golden workflows” for common user workflows that streamline operations and reduce redundant efforts. These golden workflows include and are not limited to the setting up of Boundary organizations, projects, hosts and host sets (including dynamic host catalogs), credential libraries, credential stores and integrating them with Vault for dynamic credentials
By providing valuable knowledge and expertise in Boundary to the consumer community, they serve as a centralized resource for expert guidance. This reduces the learning curve for project teams and ensures consistent application of knowledge throughout the organization.
Automation and integration are facilitated by the Platform team, automating common tasks using IaC and integrating it with other DevOps tools. This streamlines processes, increases speed, and reduces manual errors. They also address the security aspect by ensuring adherence to security best practices in infrastructure setup and maintenance, reducing vulnerabilities to cyber threats.
Moreover, the Platform team significantly reduces the time to market for new features and applications. With a mature IaC/Terraform service, they expedite the deployment of new infrastructure, management of the various components of Boundary enabling faster time to market.
Automation/Tools team
The automation/tools team is a tactical component of the Platform team. They manage and maintain the automation and tools required for systems and services to operate effectively. They enable/implement "golden workflows'' for consumers to leverage the shared services and tools that are part of the platform. As this team matures, they become the product owners and implementers of the IDP.
There could be multiple teams within the Automation/Tools team, each responsible for a different tool or group of tools. The CCoE provides overall strategic guidance for this team, and they collaborate with the consumer community to ensure that the services or workflows they enable meet their needs.
In simpler terms, the Automation/Tools team is responsible for making sure that the tools and automation that are used by the Platform team are working properly. They also work with the consumer community to make sure that the services and workflows that are enabled by these tools meet their needs.
Golden workflows
A golden workflow is a standardized, repeatable process for completing a specific task or achieving a specific outcome. It is typically well-documented and tested, and it is designed to be efficient and effective. Golden workflows are often used in software development, IT operations, and other business processes.
- There are many benefits to using golden workflows. They can help to:
- Improve efficiency and productivity
- Reduce errors and mistakes
- Ensure consistency and quality
- Improve communication and collaboration
- Accelerate onboarding and training
- Facilitate automation
With Boundary, the Platform team enables golden workflows for federating identity and enabling secure access to remote target systems. The Platform team empowers AppDev and other teams to independently access target systems and perform their tasks bound with a session time-to-live (TTL) and dynamic ephemeral credentials while maintaining centralized management and control. The Platform team oversees and governs these workflows, ensuring compliance with policies, security requirements, and best practices.
Consumer workflows
These workflows are enabled by the Platform team but used by various consumers including but not limited to various application/development teams.
- Developer Workflow: In this workflow the developer is enabled to access remote target systems and perform their operations.
- Target onboarding workflow: This foundational workflow involves onboarding a target to Boundary. This involves attaching credential libraries and credential stores to a target, setting up automated target discovery workflows if applicable and setting up RBAC policies. This workflow will be leveraged by teams looking to onboard newer hosts for secure remote access.
- Credentials onboarding workflow: For dynamic credentials, this involves determining the location within HashiCorp Vault where secrets for a particular credential will be stored and ensuring the credential library can consume those secrets. This workflow will be leveraged by security teams responsible for the governance of HashiCorp Vault to setup dynamic credentials.