VDC High Level Architecture
VDC Core Service
The VDC Core Service is responsible for managing the core entities of VDC. For more information on VDC concepts, please refer to our VDC Overview.
This service is built using ASP.NET Core, a cross-platform, high-performance, open-source framework for building modern, cloud-enabled, Internet-connected applications. The service utilizes the latest .NET 8.
The service is hosted on Azure Kubernetes Service (AKS), a managed Kubernetes service for deploying and managing containerized applications.
For data storage, the service uses Azure Cosmos DB, a managed NoSQL database that offers comprehensive SLAs across throughput, latency, consistency, and high availability, including less than 10 millisecond write-and-read latency and 99.999 percent availability.
For storing ingredient release artifacts, the service employs Azure Blob Storage, a massively scalable and secure object storage solution for cloud-native workloads, archives, data lakes, high-performance computing, and machine learning.
The service also utilizes Azure Service Bus, a fully managed enterprise message broker with message queues and publish-subscribe topics. Azure Service Bus is used to decouple applications and services, providing benefits such as load-balancing work across competing workers, safely routing and transferring data and control across service and application boundaries, and coordinating transactional work that requires a high degree of reliability.
All our Azure deployments are deployed to an Intel subscription on a private Azure environment approved for Intel Top Secret Data.
VDC Web API
The VDC Core Service supports two main types of HTTP-based APIs:
VDC Web Portal
The VDC Web Portal is a centralized website that provides access to all VDC capabilities and features. The user interface is a single-page application written in Angular 18 using TypeScript. We utilize Kendo UI for Angular for the UI components.
VDC CLI
The VDC CLI is a .NET 8 console application used to provide simple VDC commands. The CLI is cross-platform.
Custom Pipelines
Custom Pipelines are user-defined pipelines in GitHub Actions, Jenkins, or Azure DevOps. Using these custom pipelines, users can benefit from all VDC workflow features like triggers, queues, progress tracking, and storage using simple APIs while still owning the entire business flow using their preferred CI/CD tools.
VDC Plugins
VDC Plugins are components that extend the core services of VDC, specifically the core features of the VDC workflow. There are three main types of VDC plugins:
Build Plugins
Build Plugins are components used to build new ingredient releases from a specific type. The IFWI & Unified Patch build plugins are good examples. IFWI and Unified Patch are both known VDC schemas, and based on these schemas, we can manage IFWIs and Unified Patches for all Silicons, Client and Server, and for all validation types. However, when it comes to building a new IFWI, clients and servers use different tools. Clients use mFIT, while servers use FITm. Although the two tools are similar, they have different binaries and APIs. The same applies to Unified Patch. Using build plugins, we can leverage the same core services for IFWI and Unified Patch Ingredients along with the core workflow services while allowing different teams to own the specific business logic for their low-level build logic.
Deployment Plugins
Deployment Plugins are components used to deploy software or firmware in the labs. These plugins bridge the VDC core deployment service to the underlying logic that knows how to install specific software, firmware, or even deploy a full OS image.
Test Plugins
Testing is at the heart of our validation work at Intel. Testing can range from running simple unit test frameworks to orchestrating post-silicon tests on dozens of systems in the lab. The Test Plugins provide an abstraction layer between the VDC core testing service and the underlying frameworks and tools used to execute the actual tests. The NGA Plugin is a good example, where VDC knows how to use NGA behind the scenes to send the relevant test cases, translate them into test lines, use the NGA API to run the test lines, and monitor the test execution using web-hooks sent back from NGA.