From 182fe95571393d39e0ad212c1e46acfacd7db8db Mon Sep 17 00:00:00 2001
From: zakaria-c <23211915+zakaria-c@users.noreply.github.com>
Date: Thu, 10 Sep 2020 13:32:13 +0200
Subject: [PATCH] Fix typo in containerize-monolithic-applications.md (#20535)

Fixed a small typo:
Original: .. choke points that requiring scaling,
New: ... choke points that require scaling,
---
 .../containerize-monolithic-applications.md                     | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/architecture/microservices/architect-microservice-container-applications/containerize-monolithic-applications.md b/docs/architecture/microservices/architect-microservice-container-applications/containerize-monolithic-applications.md
index 5716613d72b92..ba22eaefbd1d8 100644
--- a/docs/architecture/microservices/architect-microservice-container-applications/containerize-monolithic-applications.md
+++ b/docs/architecture/microservices/architect-microservice-container-applications/containerize-monolithic-applications.md
@@ -15,7 +15,7 @@ To manage this model, you deploy a single container to represent the application
 
 You can include multiple components, libraries, or internal layers in each container, as illustrated in Figure 4-1. A monolithic containerized application has most of its functionality within a single container, with internal layers or libraries, and scales out by cloning the container on multiple servers/VMs. However, this monolithic pattern might conflict with the container principle "a container does one thing, and does it in one process", but might be ok for some cases.
 
-The downside of this approach becomes evident if the application grows, requiring it to scale. If the entire application can scale, it isn't really a problem. However, in most cases, just a few parts of the application are the choke points that requiring scaling, while other components are used less.
+The downside of this approach becomes evident if the application grows, requiring it to scale. If the entire application can scale, it isn't really a problem. However, in most cases, just a few parts of the application are the choke points that require scaling, while other components are used less.
 
 For example, in a typical e-commerce application, you likely need to scale the product information subsystem, because many more customers browse products than purchase them. More customers use their basket than use the payment pipeline. Fewer customers add comments or view their purchase history. And you might have only a handful of employees that need to manage the content and marketing campaigns. If you scale the monolithic design, all the code for these different tasks is deployed multiple times and scaled at the same grade.