# TiDB Cloud Primary Components Described + How is TiDB Cloud organized? + TiDB Cloud Architecture Layers: + Platform - Microservices + Infrastructure – Kubernetes objects, Infra API objects, controllers to reconcile the API objects + Observability- Diagnostic data collection link and centralized storage system, and log collection agents + TiDB Cloud Segments: + Dev Tier – single TiDB Cluster available for free for one year + Managed Manually- AWS and GCP accounts, external apps such as Zendesk,Auth0, Salesforce, etc + Infrastructure as Code (IaC) + CICD - CICD Combined Practices of continuous integration bridges gaps between development and operation activities (Concepts and Continuous Integration) + Managed by TiDB Cloud – TiDB manages TiDB components as described earlier (PD, TiDB, TiKV, TiFlash, TiSpark) + Transport Layer Security (TLS) certificates used to secure website connections ------------------------------------------------------------ This is a very complex process. In this introductory class we will not go into full detail about every component. VPC – Virtual Private Cloud TiDB Cloud can be divided into Platform and Infrastructure in terms of architecture, and there is a bypass Observability Stack; which is summarized as follows: - Platform: A set of microservices, with the Infra API as the capability cornerstone, control, encapsulate, and authorize, structure and integrate various Cloud as a Service capabilities of TiDB to facilitate users to UI or OpenAPI to use TiDB and related ecosystem services on the cloud ; - Infrastructure: Same design pattern as Kubernetes , storing declarative API Objects centered on the Infra API, plus a set of controllers responsible for the Reconcile of these API Objects. In terms of responsibilities, it shields the upper layer from the details of cloud basic resource management, and provides TiDB Cluster, TiCDC VPC Peering orchestration capabilities; - Observability: It consists of a diagnostic data collection link and a centralized diagnostic data storage system, including log collection agents and indicator collection agents in each Kubernetes cluster, and collects logs and indicators at the VM/container/application level and summarizes them to the central storage. Provide external diagnostic data and abnormal alarms including TiDB Cloud management plane and TiDB cluster; Infra API Open API Kubernetes (K8) Dev Tier Managed Manually Infrastructure as Code (IaC) simplifies app development, configuration and runtime by managing and provisioning the infrastructure through code, instead of manually. IaC is an IT practice that leverages code to: - Automate infrastructure provisioning, deployment, configuration and management - Orchestrate the operation of all infrastructure components, such as hardware, software, networks, virtual machines, containers, databases and cloud infrastructure elements - Configure, monitor and manage all infrastructure components and systems With the vast adoption of workloads, containers and cloud computing, IaC is an important part of DevOps, enabling automation and continuously monitoring the entire application lifecycle, from integration and testing to delivery and deployment.  It is also an important aspect of application and container security, as well as overall workload protection. CICD Managed By TiDB Cloud TLS Certificates TiDB VPC (Virtual Private Cloud) For each TiDB Cloud cluster, all TiDB nodes and auxiliary nodes, including TiDB Operator nodes, logging nodes, and so on, are deployed in an independent VPC. TiDB Cloud Central Services Central Services, including billing, alerts, meta storage, dashboard UI, are deployed independently. You can access the dashboard UI to operate the TiDB cluster via the internet. Your VPC You can connect to your TiDB cluster via a VPC peering connection. Refer to Set up VPC Peering Connection for details. High Availability with Multi-AZ Deployments TiDB uses the Raft consensus algorithm to ensure that data is highly available and safely replicated throughout storage in Raft Groups. Data is redundantly copied between storage nodes and placed in different availability zones to protect against machine or data center failures. With automatic failover, TiDB ensures that your service is always on. TiDB Cloud clusters consist of three major components: TiDB node, TiKV node, and TiFlash node. The highly availability implementation of each component is as follows: - TiDB node TiDB is for computing only and does not store data. It is horizontally scalable. TiDB Cloud deploys TiDB nodes equally to different availability zones in a region. It is recommended that you configure at least two TiDB nodes in each TiDB Cloud cluster for high availability. - TiKV node TiKV is for storing data. It is horizontally scalable and the number of nodes should be at least 1 set (3 nodes in 3 different availability zones). The data in TiKV of each TiDB Cloud cluster has 3 replicas, and each replica is stored in three different TiKV nodes which are distributed in three different availability zones. - TiFlash(beta） node As a columnar storage extension of TiKV, TiFlashbeta is the key component that makes TiDB essentially a Hybrid Transactional/Analytical Processing (HTAP) database. In TiFlashbeta, the columnar replicas are asynchronously replicated according to the Raft Learner consensus algorithm. To save the cost of data transfer between TiFlashbeta nodes, TiDB Cloud deploys all TiFlashbeta nodes of one TiDB Cloud cluster in one availability zone in a region. It is recommended that you configure at least two TiFlashbeta nodes in each TiDB Cloud cluster and create at least 2 replicas of the data for high availability in your production environment.