Team-as-Code: How to Apply Platform Engineering to DevOps’ Coding Stage

Why Apply a Platform Approach to the Coding Stage?

While both parts of the modern software development lifecycle, DevOps and platform engineering target distinct challenges.

DevOps focuses on integration and continuous delivery (CI/CD) and teams track metrics such as code deployment frequency, lead time for changes, change failure rate, etc.

Platform engineering aims for a broader scope: designing and managing the underlying platform that supports DevOps practices. Hence tracked metrics are typically CI/CD platform uptime, resource utilization, tool adoption rate, process automation level, etc.

Platform engineering has rapidly evolved from providing basic infrastructure to creating comprehensive, self-service platforms such as Internal Developer Platforms (IDP). In practice, the following domains are increasingly important from a platform perspective:

• Security: In terms of the need to improve both infrastructure and code security by embedding measures into the development lifecycle
• Developer experience: In terms of the need to reduce complexity and enable developers to focus on building software without worrying about the underlying infrastructure
• Analytics: In terms of the need to offer (AI-assisted) predictive and prescriptive analytics as well as intelligent automation to aid developers and leaders optimize resources and anticipate potential issues

In general, platform engineering contributes to the coding stage in an indirect manner compared to its impact on deployment, monitoring, and operations.

This is done, for example, by providing standardized development environments (e.g., via container registry), CI/CD services, self-service portals to resources and support, documented API and SDKs, as well as embedding security checks in pipelines.  

In this article, I explain how platform engineering can also be applied to defining an entire code development project, including the developers’ laptop setups, needed development resources and applications, infrastructure and code security policies, and the organizational policies related to the team’s onboarding, including budget planning and other predictive governance information. This allows organizations to automate the deployment and setting of an entire development effort.

This application aligns with the three axes that I mentioned above, notably: 

• Enforcing security and organizational compliance policies both from an infrastructure and code perspective before any code reaches the build pipelines
• Personalizing the developer experience to the level of each development device that is provided to them by the organization
• Leveraging analytics for the sake of governance and compliance to the execution of a project before it even starts

To enable platform engineering to address the above concerns, one can use the capabilities of secure Cloud Development Environments (CDE), an emerging technology that I have been writing about extensively in previous articles.

The Breadth of Secure Cloud Development Environments

The technology of CDEs has been identified recently in Gartner’s Agile and DevOps report as an emerging technology. I’ll start by briefly explaining the difference between CDEs and Secure CDEs.

CDEs and Secure CDEs offer distinct approaches to managing the development process, each with a focus on enhancing productivity, security, and governance within software development projects. Both provide a platform for software development that moves traditionally local development activities to the cloud with benefits explained here.

Secure CDEs, while incorporating the core advantages of traditional CDEs, place a strong emphasis on security measures to protect development assets. This approach is integral to protecting intellectual property and sensitive data from threats such as exfiltration and infiltration.

Also, I explain in this article that Secure CDEs are providing a renewed approach to DevOps core principles, namely the principles of flow, feedback, and continuous learning. Hence, their impact is not limited to bettering platform engineering automation.

Describing the full architecture of a secure Cloud Development platform — which delivers Secure CDEs — would take us off-topic. 

Breaking Down Access to the Desktop Monolith

Platform engineering aims at reducing the cognitive load of developers primarily to enhance productivity and focus, typically by fostering standardization and simplification of tools and processes. Key benefits include a heightened focus on core tasks, improved quality and consistency, enhanced collaboration, and my favorite one: increased innovation; i.e., by freeing brain cycles to experiment with new ideas.

Let’s look at an additional aim around reducing cognitive load that I did not include in the above list: faster onboarding.

While this is a concern addressed by platform engineering, notably by standardizing development environments, there are still numerous set-up tasks that developers and support teams must handle to onboard an entire project team.

This includes personalizing development environments to their liking (environment files, tool customizations, etc.), configuring their favorite tools, and more. In addition, support teams need to make sure that all security and compliance controls are in place. Take, for instance, how risk controls applied to internal and offshore teams are likely to vary significantly. This is where Secure CDEs provide additional granularity to enable automation in order to execute a secure and compliant onboarding, starting from organizational requirements, down to each developer’s personal preferences.

In a previous article, I explained that the use of Secure CDEs and, in practice, of a secure Cloud Development platform enables organizations to deliver an abstraction of a secure developer laptop, referred hereto as a workspace for simplicity.

In effect, a workspace replaces the use of a virtual desktop with data loss prevention to address security concerns over intellectual property protection (a typical approach by many organizations), while jointly providing additional security and productivity advantages delivered by Secure CDEs.

In the figure below, I depict how the abstraction covers concerns around developer experience, resource consumption, and data access control, as well as security policies attached to the operational aspects of the team. Hence the stakeholders to a virtual incarnation of the secure developer laptop are, at a minimum, developers, platform engineering teams, and security teams.

Figure 3: A workspace is an abstraction of a secure developer laptop that covers the needs of the stakeholders mentioned in the figure, namely developers, platform engineering teams (with concerns around resource usage, tools and data access, etc), and security teams.

In contrast, accessing a secured virtual desktop (think of Citrix VDI) is akin to providing a monolithic infrastructure component to developers and IT teams, where most of the set-up that I mentioned before is left as a burden to individual contributors.

Hence, the use of a template to configure Secure CDEs is the key to enabling Platform Engineering (API-based) programmatic automation to achieve the full onboarding of a development team. Essentially, it provides a means to implement a "team-as-code" concept.

In sum, the granularity of the template’s parameter metaphorically breaks the virtual desktop monolith.

While the actual parameters of the template are left to the platform’s implementation, I give a depiction of the common concerns addressed by the implementation of our own platform. In particular, we provide a text-based representation for the template in YAML such that templates can be easily edited and version-controlled.

How to Build and Deliver Your Team-as-Code

Now that the main technology components are in place, I’ll address the process automation aspect of implementing a team-as-code approach.

Platform engineering implementations often leverage the use of an API in order to choreograph successive operations realizing the automation. Here this approach works as well and the entire team onboarding and setup process can be laid out as follows:

1. Create a project within the organization that hosts the team.
2. Onboard the different users on the project with their respective roles.
3. Create a series of workspaces from pre-created templates that capture data access control permissions and security policies.
4. Assign the workspaces to individual users.
5. Authenticate the individual users to the resources assigned to their workspaces.
6. Personalize each workspace based on the individual user's preferences.

Note that, some of these steps are performed jointly but laid out as above for clarity. Also, executing such a sequence in practice using any one of the big Clouds (Azure, AWS, GCP, etc) takes under a minute.  

Finally, once workspaces are running users can log in to the platform and start coding.

Note that such an API sequence can be triggered from any Project or ITSM tool such as Altassian’s Jira or ServiceNow. The figure below illustrates the use of a project management tool to create the team setup via the API.

Figure 5: Create a team-as-code from your project management tool using a series of API calls that leverage workspace templates, and policy definitions and anticipate settings using analytics.

Approach’s Benefits and Opportunity for Analytics

The use of Secure CDEs provides granular access to platform engineering teams in typical governance topics that are assigned to them, for example: tool sprawl reduction, productivity improvement, policy enforcement, scalability increase, and security strengthening.

While many of the needs in these areas are addressed by Internal Developer Platforms (IDP), Secure CDEs allow organizations to tackle them starting from the coding stage with granular control over developer workspaces and the policies that surround the onboarding of a team on a particular project. Without access to a platform that manages Secure CDEs, such an early grip on project setup automation is out of reach from current IDP capabilities.

Here is a summary of the benefits of the approach to the aforementioned topics:

• Tool sprawl: Organizations can enforce the use of IDEs, with an approved set of plugins, and the use of a standard browser with approved extensions. In addition, Secure CDEs are automatically configured to use standard software stacks (the underlying container definitions) and a suite of DevOps and DevSecOps tools.
• Productivity: Secure CDE templates, as shown in one of the previous figures, enable users and teams to create complex workspace setups. These templates are readily available for self-serve access, significantly reducing the time needed to start or onboard a team on a new project in complex, pre-configured workspaces.
• Policy compliance: The templates also allow multiple stakeholders to enforce compliance rules using a single framework supported by the platform team. From DevOps teams to security teams, compliance around software stacks, dependencies, role-based access control, and data security are part of the team-as-code definition.  
• Security: Secure CDEs allow organizations to address security across multiple facets with a unified approach:
  • Security against data exfiltration by defining data loss prevention measures across the entire workflow of developers
  • Security against data infiltration by protecting against data that might be added to the project inadvertently (credential, licensed code, etc.) or maliciously (malware)
  • Code security measures by setting up the environment such that it enforces the systematic use of code and supply chain (SBOM) security tools

In addition to the above benefits, in my opinion, the most exciting aspect of moving code development online with Secure CDEs is the opportunity to collect both predictive and prescriptive analytics.

A simple example of predictive analytics is resource cost budgeting when onboarding a team in the scope of a time-bounded project. In that case, past workspace activities and resource allocation by the underlying infrastructure (e.g., Kubernetes) are leveraged to assess the likely cloud consumption by the project team during the time period. Platform engineers can implement the predictive analysis using API calls such as the one depicted in the figure.

Figure 6: The platform API allows organizations to retrieve a trove of metrics extracted from the workspaces and the underlying infrastructure. In turn, these metrics can be transformed into predictions and prescriptions for the project operations.

Another example of this time, prescriptive analysis is project resource sizing, i.e., figuring out the necessary computational resources to work on a specific project. In this case, the capability of our platform is to embed real-time collections of measurements during workspace activities.

These measurements allow organizations to estimate the necessary resources by comparing metrics such as the average project building time across the project timeline and align productivity expectations with best practices; e.g., to minimize idle time.

Conclusion

In conclusion, Secure CDEs provide a means for platform engineers to grab control of development project definitions, their associated needs around resources, and organizational compliance, in order to implement mechanisms to ensure productivity and governance.