(DOCSP-15621): Remove recommendations that mongos should be deployed … (#1381) (#1418)

* (DOCSP-15621): Remove recommendations that mongos should be deployed on separate hardware

* revert config servers content

* updates per review feedback

Author: jeff-allen-mongo

source/core/sharded-cluster-components.txt

@@ -66,22 +66,11 @@ Number of ``mongos`` and Distribution
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Deploying multiple :binary:`~bin.mongos` routers supports high
-availability and scalability. A common pattern is to place a
-:binary:`~bin.mongos` on each application server. Deploying one
-:binary:`~bin.mongos` router on each application server reduces network
-latency between the application and the router.
-
-Alternatively, you can place a :binary:`~bin.mongos` router on dedicated
-hosts. Large deployments benefit from this approach because it decouples
-the number of client application servers from the number of
-:binary:`~bin.mongos` instances. This gives greater control over the number
-of connections the :binary:`~bin.mongod` instances serve.
-
-Installing :binary:`~bin.mongos` instances on their own hosts allows these
-instances to use greater amounts of memory. Memory would not be shared
-with a :binary:`~bin.mongod` instance. It is possible to use primary shards
-to host :binary:`~bin.mongos` routers but be aware that memory contention may
-become an issue on large deployments.
+availability and scalability. For shard-level high availability, a
+common pattern is to place :binary:`~bin.mongos` instances on the same
+hardware that :binary:`~bin.mongod` instances are already running on.
+Another option is to embed :binary:`~bin.mongos` routers with
+application tier infrastructure.
 
 There is no limit to the number of :binary:`~bin.mongos` routers you can
 have in a deployment. However, as :binary:`~bin.mongos` routers