You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For information on the available metrics, see the [User metrics options](./concept-metrics.md#user-metrics-options) section of [MetricsforAzureSpringApps](./concept-metrics.md).
Copy file name to clipboardExpand all lines: articles/spring-apps/how-to-enterprise-deploy-app-at-scale.md
+11-11Lines changed: 11 additions & 11 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,18 +1,18 @@
1
1
---
2
-
title: A Guide to Deploying Over 500 and Up To 1000 Application Instances Using Azure Spring Apps Enterprise
2
+
title: Scale out to deploy over 500 and up to 1000 application instances using Azure Spring Apps Enterprise
3
3
description: Learn how to deploy applications at scale in the Enterprise plan for Azure Spring Apps and learn about the restrictions.
4
4
author: karlerickson
5
5
ms.author: xiading
6
6
ms.service: spring-apps
7
7
ms.topic: how-to
8
-
ms.date: 06/26/2023
8
+
ms.date: 07/05/2023
9
9
---
10
10
11
-
# Scaling Out: A Guide to Deploying Over 500 and Up To 1000 Application Instances Using Azure Spring Apps Enterprise
11
+
# Scale out to deploy over 500 and up to 1000 application instances using Azure Spring Apps Enterprise
12
12
13
13
This article applies to ❌ Basic/Standard ✔️ Enterprise
14
14
15
-
This article guides you on deploying up to 1000 application instances in Azure Spring Apps Enterprise. The feature supporting deployment of more than 500 instances is currently in Preview. It outlines the limitations during the Preview stage. The Enterprise plan, crafted for handling substantial production workloads, supports a maximum of 1000 application instances per service. However, it is advisable to stick to a maximum of 500 instances in your production environment.
15
+
This article guides you on deploying up to 1000 application instances in Azure Spring Apps Enterprise. The feature supporting deployment of more than 500 instances is currently in Preview. This article outlines the limitations during the Preview stage. The Enterprise plan, crafted for handling substantial production workloads, supports a maximum of 1000 application instances per service. However, we recommend using a maximum of 500 instances in your production environment.
16
16
17
17
## Definition
18
18
@@ -22,29 +22,29 @@ The Azure Spring Apps Enterprise plan supports up to 1000 application instances
22
22
23
23
When you deploy Azure Spring Apps in an Azure virtual network, you need to configure the proper subnet ranges for your apps and services. The subnet ranges determine how many IP addresses are available for your apps and services to use. If the subnet ranges are too small, you might run out of IP addresses and encounter errors or failures.
24
24
25
-
To avoid this problem, you should preserve subnet ranges that be large enough to support the number of application instances. For subnets, Azure reserves five IP addresses, and Azure Spring Apps requires at least three IP addresses. We recommend that you preserve at least the `/24` subnet ranges for the apps subnet.
25
+
To avoid this problem, you should reserve subnet ranges that are large enough to support the number of application instances. For subnets, Azure reserves five IP addresses, and Azure Spring Apps requires at least three IP addresses. We recommend that you reserve at least the `/24` subnet ranges for the apps subnet.
26
26
27
-
For more detail about how deploy an Azure Spring Apps instance in your virtual network, follow the instructions in[Deploy Azure Spring Apps in a virtual network](how-to-deploy-in-azure-virtual-network.md).
27
+
For more information about how deploy an Azure Spring Apps instance in your virtual network, see[Deploy Azure Spring Apps in a virtual network](how-to-deploy-in-azure-virtual-network.md).
28
28
29
29
## Restrictions
30
30
31
31
Support for 1000 app instances is currently in the preview stage. The following sections describe the restrictions that you should understand when you try this feature.
32
32
33
33
### VMware Tanzu® Build Service™
34
34
35
-
VMware Tanzu Build Service automates container creation, management, and governance at enterprise scale. Tanzu Build Service uses the buildpacks project to turn application source code into container images.
35
+
VMware Tanzu Build Service automates container creation, management, and governance at enterprise scale. Tanzu Build Service uses the buildpacks project to turn application source code into container images.
36
36
37
37
The builder is a Tanzu Build Service resource, which contains a set of buildpacks and a stack used in the process of building source code. The build number using the same builder should be less than 200. Otherwise, it's hard to reconcile all builds when the builder updates.
38
38
39
39
The builds are generated when you deploy apps. We recommend that you create multiple customized builders to deploy apps when you have more than 200 apps or deployments.
40
40
41
41
### Application Configuration Service for Tanzu
42
42
43
-
Application Configuration Service for Tanzu is a central place to manage external properties for applications across all environments. This service is offered in two versions: Gen1 and Gen2. The Gen1 version mainly serves existing customers for backward compatibility purpose. Gen2 uses flux as the back end to communicate with Git repositories. Gen2 provides better performance compared with Gen1.
43
+
Application Configuration Service for Tanzu is a central place to manage external properties for applications across all environments. This service is offered in two versions: Gen1 and Gen2. The Gen1 version mainly serves existing customers for backward compatibility purpose. Gen2 uses flux as the back end to communicate with Git repositories. Gen2 provides better performance compared to Gen1.
44
44
45
45
The following table shows the benchmark for refresh times under different numbers of patterns. Be sure to carefully control the configuration pattern number based on these values to avoid unacceptable refresh performance.
46
46
47
-
| Application Configuration Service Generation| Duration to refresh under 100 patterns | Duration to refresh under 250 patterns | Duration to refresh under 500 patterns |
47
+
| Application Configuration Service generation| Duration to refresh under 100 patterns | Duration to refresh under 250 patterns | Duration to refresh under 500 patterns |
@@ -53,9 +53,9 @@ The following table shows the benchmark for refresh times under different number
53
53
54
54
Spring Cloud Gateway for VMware Tanzu handles the cross-cutting concerns for API development teams, such as single sign-on (SSO), access control, rate-limiting, resiliency, security, and more. You can accelerate API delivery using modern cloud native patterns using your choice of programming language for API development. Spring Cloud Gateway is a critical component for a microservices architecture.
55
55
56
-
The performance of the gateway is closely related to the number of routes. In general, we recommend that you don't exceed 500 routes. When the gateway can't handle some requests with reasonably low latency or without errors, it can stress a gateway instance's performance.
56
+
The performance of the gateway is closely related to the number of routes. In general, we recommend that you don't exceed 500 routes. When the gateway can't handle some requests with reasonably low latency or without errors, it can stress a gateway instance's performance.
57
57
58
-
Spring Cloud Gateway is able to handle a high volume of traffic. To support the traffic, you should consider increasing the memory requested for API gateway instances so that each pod can handle more requests per second. You can also refer to [Set up Autoscale settings for VMware Spring Cloud Gateway](how-to-configure-enterprise-spring-cloud-gateway.md#set-up-autoscale-settings-for-vmware-spring-cloud-gateway-in-azure-cli)to configure auto scale rules for the gateway to perform its best when demand changes.
58
+
Spring Cloud Gateway is able to handle a high volume of traffic. To support the traffic, you should consider increasing the memory requested for API gateway instances so that each pod can handle more requests per second. To configure autoscale rules for the gateway to perform best when demand changes, see the [Set up autoscale settings for VMware Spring Cloud Gateway](how-to-configure-enterprise-spring-cloud-gateway.md#set-up-autoscale-settings-for-vmware-spring-cloud-gateway-in-azure-cli)section in [Configure VMware Spring Cloud Gateway](how-to-configure-enterprise-spring-cloud-gateway.md).
59
59
60
60
Spring Cloud Gateway supports rolling restarts to ensure zero downtime and disruption. However, the current version of the gateway has a limitation that when it's rolling restarted, it may take longer to synchronize a large number of routes. This situation can cause incomplete route updates during the process. We're actively working on fixing this limitation and will provide an update through our documentation.
0 commit comments