Introduction to the core domain models of the Ant PaaS platform

Introduction to the Ant PaaS platform

The Ant PaaS platform supports the global expansion of Ant Group's business. Its domain models define the core architecture for its Platform as a Service (PaaS) products. As the foundation for commercial fintech solutions branded as SOFAStack CAFE, the platform provides application-centric support for the full development, runtime, and O&M lifecycle.

Core domain models and concepts of the IaaS layer

Region and Availability Zone (AZ)

Regions and Availability Zones are two core domain models that define the basic physical topology on Alibaba Cloud.

• Region: A region is a physical data center, usually located in a city, such as Hangzhou, Shanghai, Qingdao, or Beijing. Each region is physically independent and isolated from other regions. To connect regions, you must use an Express Connect circuit. Regions differ in product capabilities, security and stability levels, and resource prices.

• Availability Zone (AZ): An Availability Zone (AZ) is a physical area within a region that has an independent power supply and network. AZs in the same region are interconnected but fault-isolated from each other. The decision to place instances in the same AZ depends on your requirements for disaster recovery and network latency. An AZ is often referred to as a data center (IDC), as the concepts are the same.

  Note

  Alibaba Cloud uses regions and AZs to manage network latency. The network latency between different AZs in the same region does not exceed 2 ms.

• Finance Region (Gold Region): For financial industry customers with higher security requirements, Alibaba Cloud provides completely isolated regions that have a specially deployed portfolio of high-security cloud products. These regions are called Finance Regions (or Gold Regions). For example, the public cloud has three Finance Regions: Hangzhou Finance (cn-hangzhou-finance), Shanghai Finance (cn-shanghai-finance-1), and Shenzhen Finance (cn-shenzhen-finance-1).

  For more information, see Finance Cloud features and Finance Cloud product list.

Virtual Private Cloud (VPC)

A Virtual Private Cloud (VPC) is a private, isolated network on the cloud. You have full control over your VPC, including selecting IP address ranges, configuring route tables, and setting up gateways. You can deploy Alibaba Cloud resources, such as Elastic Compute Service (ECS) instances, ApsaraDB for Redis instances, and Server Load Balancer (SLB) instances, in your VPC.

A VPC defines a network border, which simplifies network customization and management on the cloud. You can define CIDR blocks for your virtual router (vRouter), configure route table rules, and create virtual switches (vSwitches) to configure subnets.

Alibaba Cloud has the following limits for the VPC model:

• A VPC cannot span across regions.

• A VPC can have only one vRouter.

• A vSwitch must belong to a single AZ.

• A security group can contain ECS instances from different vSwitches.

For related operations, see Virtual Private Cloud (VPC) and Network planning.

Core domain models of the PaaS layer

Application and AppService

The Ant PaaS platform abstracts the concepts of "Application" and "AppService" on top of underlying Alibaba Cloud resources to simplify the development and O&M of large-scale, financial-grade distributed systems.

Within a tenant, a single codebase corresponds to one application. An application has basic metadata, such as its technology stack, group, and classification. The application is a core concept of the PaaS platform. The entire Ant Group development and O&M system revolves around the application lifecycle, which includes development, publishing, operations, and monitoring.

An AppService is a core model in the CAFE deployment and O&M system. A business application often consists of multiple AppServices. An AppService represents a single deployment of an application in a workspace. A deployment requires an application image or deployment package, application configurations, and deployment resources.

For example, consider a scenario where multiple developers work on the same application. Each developer creates their own code branch and deploys it to the development environment. In the development workspace (Workspace: Dev), three developers might test and deploy different branches of the same application (App: paycore). This creates three different AppServices (AppService: paycore_dev1, paycore_dev2, paycore_dev3). Each AppService can be deployed on different servers and associated with different baseline configurations. However, in a production environment, an application cannot have multiple code versions deployed simultaneously because of the significant security risks.

For related operations, see Manage applications and Create an AppService.

Workspace, Region, and Availability Zone

A Workspace is an organizational mechanism provided by SOFAStack. It is used to group and isolate resources for different purposes or stages. A typical use case is to create a workspace for each stage of the development and O&M process. For example, you can have a development workspace in a single data center (a single zone) and a production workspace in two data centers (two zones).

A Workspace provides a resource boundary that is independent of network connectivity. On Alibaba Cloud, networks between regions are not connected by default. Most cloud products also use the region as a boundary for product instances. For example, an SLB instance cannot attach ECS instances across regions, and a VPC cannot span regions. The Workspace model was created to simplify resource relationships within its scope and abstract away the complexity of network connectivity.

In practice, a Workspace uses Resource Access Management (RAM) for access control isolation, and VPCs and security groups for network isolation. A Workspace can also achieve physical isolation using different Kubernetes clusters or implement filtered management using different resource labels within the same Kubernetes cluster.

For related operations, see Manage workspaces.

Application and Workspace

An application is a tenant-level concept. Within a tenant, one codebase corresponds to one application. An application can span multiple Workspaces and regions.

AppService and Workspace

During the application development lifecycle, developers often work with multiple environments. A Workspace can be considered a single environment, but an environment can also consist of multiple Workspaces.

An AppService is not limited to a single Workspace. This is because an AppService can be deployed in multiple Workspaces simultaneously. For example, a production environment might consist of multiple Workspaces.

However, the resources that an AppService uses must belong to a specific Workspace. A single resource cannot belong to two Workspaces simultaneously.

For related operations, see Create an AppService.

Workspace and Virtual Private Cloud (VPC)

Each Workspace corresponds to a single VPC. This design supports the core purpose of a Workspace, which is to define a resource boundary that is independent of network connectivity.

Multi-tenancy

Multi-tenancy

SOFAStack on the public cloud uses a multi-tenant architecture. Each tenant can create their own Workspaces and define operation permissions for their users.

SOFAStack is deeply integrated with the Alibaba Cloud account system. One tenant maps to one Alibaba Cloud account, and each user is a RAM user under that account.

• Alibaba Cloud account: The primary account used to log on to the Alibaba Cloud platform. It has root permissions and serves as an independent billing entity. This account is typically held by an enterprise and is responsible for all payments to Alibaba Cloud.

• RAM user: A virtual user created under an Alibaba Cloud account. You can create multiple RAM users, which usually correspond to individuals or systems within an enterprise.

For related operations, see Grant permissions to a RAM user and Authorize a RAM user across Alibaba Cloud accounts.

Extended domain models of the PaaS layer

To support more complex application scenarios, the Alibaba Finance Cloud PaaS layer also defines the following advanced models.

• WorkspaceGroup

• AppService Instance Group (AIG)

• Cell

WorkspaceGroup

A WorkspaceGroup is an extension of a Workspace across multiple regions. It is used to group and isolate resources across multiple regions. The networks of these regions can be interconnected using Express Connect circuits. For example, a production WorkspaceGroup (WorkspaceGroup: prod) might include two Workspaces: the Shanghai production workspace (Workspace: prod_shanghai) and the Hangzhou production workspace (Workspace: prod_hangzhou).

In the SOFAStack console, some products, such as the unitized application service LHC, active geo-redundancy products, and monitoring products, support operations at the WorkspaceGroup level.

For related operations, see Create a WorkspaceGroup.

AppService Instance Group (AIG)

An AppService Instance Group (AIG) is used to define a set of resources within an AppService. It represents a more granular deployment shard of an application.

In some business scenarios, an application must be divided into more granular units at the business level. For example, if different services depend on the same Application, you need a way to control the deployment instances of that application from the perspective of a single service, including controls for deployment isolation and traffic allocation. The AIG model was introduced to address this requirement.

AIG and WorkspaceGroup (WSG)

An AIG can span multiple WSGs. Based on Ant Group's experience, a WSG can be defined as a single environment.

An AppService can span multiple Workspaces, but not multiple WSGs. This is because an AppService typically cannot contain resources from two different environments. AppServices in two different environments usually have two different baseline configurations.

Cell

A Cell is the smallest deployment unit recognized by the deployment process. A Cell usually corresponds to a middleware configuration center.

Cells are the foundation for implementing active-active disaster recovery within the same city, blue-green deployments, and unitized architectures. Each Cell can be considered a logically independent configuration center.

A Unit is a model encapsulated by the LHC product and is not a core domain model of the PaaS layer. The LHC product uses the Cell model from the PaaS layer to define logical zones in a unitized architecture.

For related operations, see Manage deployment units.

AppService and Cell

• An AppService can span multiple Cells. This is suitable for active-active disaster recovery in two data centers and for blue-green deployment scenarios.

  

• An AppService can span multiple Cells and Workspaces. This is suitable for active geo-redundancy and unitized architecture scenarios.

  

• An application can have multiple AppServices that are created and placed in multiple Cells. This is suitable for multi-branch independent development and unitized architecture scenarios, assuming one unit contains only one cell.

  

• Multiple AppServices for the same application can be deployed in the same Cell. This is suitable for joint debugging scenarios that use sofaRouter or for regular application scenarios that do not depend on a configuration center.

  

Mapping between PaaS domain models and Kubernetes domain models

As PaaS has evolved, its relationship with Kubernetes has become closer. Although Kubernetes is an excellent technology platform, it is not PaaS. The PaaS layer domain models are essentially business semantics that serve PaaS products.

To allow the Kubernetes-based SOFAStack platform to support the complex scenarios and architectures described by the PaaS domain models, certain conventions and mappings must be established between the PaaS domain models and Kubernetes.

Cluster and Tenant

On the public cloud and Apsara Stack, a Tenant has different constraints on a Kubernetes Cluster:

• On the public cloud, a Cluster can belong to only one tenant, but a tenant can have multiple Clusters.

• On Apsara Stack, a Cluster is often shared by multiple tenants.

For related operations, see Create a cluster.

Cluster, Namespace, and Workspace

The relationship between a Cluster and a Workspace is many-to-many. A Cluster can be shared by multiple Workspaces, and a Workspace can have multiple Clusters.

• Public cloud: A Workspace can contain multiple Clusters. Because a Workspace corresponds to only one VPC, all Clusters must belong to that same VPC. Cluster management tasks, such as creation and initialization, are performed within the Workspace.

• Apsara Stack: Cluster management is not performed within the Workspace. Instead, Clusters are managed globally and then assigned to a Workspace.

A Namespace is an abstraction used to group resources and objects. You can create multiple Namespaces within the same cluster. The resources in different Namespaces are isolated from each other. This allows different groups to share the services of the same cluster without interfering with each other. A Namespace can be associated with only a single Workspace.

For related operations, see Create a cluster.