fix some wording

nikkhn · eevans · commit be4cdbc5db37 · 2021-09-23T13:04:22.000-05:00
diff --git a/STATUS.md b/STATUS.md
@@ -5,20 +5,19 @@ The idea behind service-scaffold-node is to separate the existing service-templa
 
 ## To Do:
 ### Remove service-runner
-service-runner is an npm package created at the Wikimedia Foundation enabling Node.js services to scale up, by spinning up multiple workers, in an otherwise single-threaded environment, to handle the load. It also handles logging, monitoring, and rate-limiting. 
+service-runner is an npm package created at the Wikimedia Foundation enabling Node.js services to scale up, by spinning up multiple workers, in an otherwise single-threaded environment. It also handles logging, monitoring, and rate-limiting. 
 
-After an informal discussion with service-ops, it was determined that service-runner is no longer necessary now that services at WMF will be running in Kubernetes. Kubernetes can now handle scaling up services in reponse to higher loads. The logging and monitoring it current handles will be put into servicelib-node, and the API Gateway is capable of handling the rate limiting.
+After an informal discussion with service-ops, it was determined that service-runner is no longer necessary now that services at WMF will be running in Kubernetes. Kubernetes can now handle scaling up services in reponse to higher loads. The logging and monitoring it currently handles will be put into servicelib-node, and the API Gateway is capable of handling the rate limiting.
+
+#### Pros
+- Removing a complex, difficult to maintain library. The less code, the better. 
+- Removing code that is tightly coupled and dependent largely on service-template-node structure
 
 #### Cons
 - service-runner can spin up new workers faster than Kubernetes can spin up another instance to support higher loads. 
 - With more pods come more resource utilization per-pod (e.g. more sidecars, more memory usage, etc. ) We would now be looking at a 1:1 k8s pod to worker ratio, as opposed to N:1 workers to pod ratio.
 
-#### Pros
-- Removing a complex, difficult to maintain library. The less code, the better. 
-- Tightly coupled with and dependent largely on service-template-node structure
-
 ### Ideas to explore:
 - Use an off-the-shelf worker coordinator
 - Create an instance of Envoy to route requests to and from multiple containers
 
-### Middleware
