The Lifecycle of an Asset & Architecture (V2)

This article explores:
The lifecycle of a platform in a virtualized/cloud ecosystem
The architecture behind TechZone that makes it possible to deploy your asset at scale.

Lifecycle of an Asset

Below are the key stages in a general overview of how to get started with the lifecycle of an asset or environment:

1. Build & Develop

Once your request has been reviewed and approved, you can begin building your collection. This stage requires knowledge and understanding from the following areas in TechZone:

• Collections
• Base Image
• Tutorials
• Content Audit
• Standards

These are key rules and standards that need to be reviewed and implemented into your asset and resources in order to be compliant with the regulations. They should be taken into consideration as part of your development process.

2. Testing

Once the collection is set up and the environment tile is visible for testing purposes, it's time to test your asset. Depending on the type of environment you are building, there are several different testing frameworks. Before going to production, your environment needs to be successfully deployed at scale and secured:

• environment can provision sucessfully over consistent time period
• environment can work across multiple regions
• environment follows TechZone Content standards and has been security scanned

Once you have met the criteria to launch into production, testing can be completed and the asset can be moved to production.

3. Production

Congratulations, your asset is now in production!

4. Maintenance

Now that you are up and running, let's make sure we are all doing our roles in maintaining your asset up and running. We know maintenance can be dull, however we will try to make it as easy as possible for you!

Ensure you are reserving and monitoring your provision metrics board, regularly to ensure the smooth running of your asset.

Architecture Behind TechZone

To streamline the lifecycle management of assets, a robust portal is required. Below is an overview of the architecture behind TechZone. In order to keep this straightforward, the details of the services involved in the provisioning will be simplified.

As a content contributor, knowing what is happening behind the scenes, is a key item for success.

A pattern in TechZone is a Terraform configuration that triggers the provision of your asset based on the environment definition you have in your collection. Essentially, the environment definition populate at the pattern to create the desired asset or service you are building.

Once a configuration is passed through our environment tile on the TechZone Portal or through the options when you create your request, the Terraform pattern checks if that is valid and triggers the rest of the TechZone microservices that ensure your asset gets provisioned.

Layered Content Architecture with Content Modules

Your environment is defined using Terraform and TechZone patterns, but we are introducing a layered content approach that enables deeper customization at the application level. This is achieved through Content Modules, a new capability designed to run post-deployment scripts and playbooks on your environment.

What Are Content Modules?

Content Modules are an additional layer of automation that executes after your base environment is provisioned. They allow you to inject custom logic, scripts, or playbooks to tailor your environment beyond infrastructure—focusing on application-level configuration and integration.

• Purpose: Enable advanced customization without modifying the core Terraform pattern.
• Supported Technologies:
  • Bash scripts for lightweight automation.
  • Ansible playbooks for structured configuration management.

How to get started with Nextgen Content and Content Modules?

We have created a dedicated document outlining the user flow for what is required to be able to begin migrating and building with V2. A summary can be seen below:

Content Creator:

• Submit an Access Hub Request to be Content Contributor
• Log support ticket following the templated guide for GitHub repository creation.

Techzone Support:

• TechZone Team will review/approve access request
• create GitHub Repository
• create a GitHub Team and assign appraise access
• create Git Deploy Key for users
• copy requested sample environment to user’s collection pointing to the newly created repository
• confirming the completion of above steps

Content Creator:

• confirms access to GitHub
• confirms the v2 reservation and environment are present
• confirms a successful reservation

For full process, link and helpful pointers please review this document.

Who should use Content Modules?

Content Modules should be leveraged by contributors who need a way to further customise a Certified Base Image to add additional software and content. It's a way to automate manual workloads like installation and setup, alongside configurations for user specific experiences. It offers way to create an environment that will have an additional custom content layer on top of the Certified Image during creation/provision time.

This transition will affect all content currently present in TechZone. Our Beta users can leverage the available Beta collection to get started.

Types of Content Modules

We currently support three key modules, each designed for different execution contexts:

1. Terraform GitOps Post-Deploy

• Where it runs: Inside GitOps.
• Use case: Automates application deployment and configuration using GitOps principles.
• Status: This is the most widely used module because it integrates seamlessly with GitOps workflows, enabling declarative application management post-deployment.

2. Terraform Cloud Init Post-Deploy (Experimental)

• Where it runs: During cloud-init execution on the VM.
• Use case: Ideal for injecting initialization scripts at the OS level during boot time.
• Status: Experimental, internal use only.

3. Terraform OS Post-Deploy

• Where it runs: Directly on the provisioned machine via SSH.
• Use case: Perfect for applying OS-level configurations, installing packages, or running custom scripts after the VM is live.
• Status: Uses SSH connectivity to apply changes securely on VPC and OCP-V

4. Terraform Post-Deployer

• Where it runs: Directly on the provisioned machine or kubernetes pod.
• Use case: Ideal for packaging applications and dependencies, all while deploying in isolated, virtualized environments
• Status: For OpenShift and Kubernetes

Why This Matters

By introducing Content Modules, we provide:

• Flexibility: Customize environments without altering base patterns.
• Modularity: Add or remove post-deploy logic as needed.
• Scalability: Standardize advanced configurations across multiple environments.

Why Shift from Image Templates to Automated Software Deployment with Ansible?

Next Steps

Now that you understand how TechZone works behind the scenes, it is time to understand what patterns are available and how to choose the best one for your purpose.