add rephrasing, comments for containerization

Author: Xronophobe

chapter_09_docker.asciidoc

@@ -153,16 +153,37 @@ Because containerization is a kind of even-more-virtual virtualization.
 Conceptually, "regular" virtualization works at the hardware level,
 it gives you multiple virtual machines (VMs)
 that pretend to be physical computers, on a single real machine.
-So you can run multiple operating systems inside separate VMs
+So you can run multiple operating systems using separate VMs
 on the same physical box.
-
-Containers work at the operating system level.
-It gives you multiple virtual operating systems that
+// CSANAD:  to me, the wording sounded like it meant the multiple OS-s
+//          ran inside (each) VM. Maybe "using separate VMs" is a little
+// more clear.
+
+Containers work at the operating system level: packing the source code and its
+dependencies together, often with the entire environment required to run the
+application, while using the host system's kernel. This is what we call
+containers.
+// CSANAD:  I felt like some explanation like this on the term "container"
+//          was missing. Probably a simple hand-drawn image visualizing the
+// differences between virtualization and containerization could be also
+// helpful.
+
+They can give you multiple virtual operating systems that
 all run on a single real OS.
-So you can run multiple programs inside separate virtual operating systems,
+So you can run programs inside separate virtual environments,
 using a single real host operating system and kernel.
-
-The upshot of this is that containers are much "cheaper".
+// CSANAD:  rephrased it a little, since containers aren't necessarily
+//          separate operating systems. Sometimes they are just a few
+// processes running in isolation. This, in my opinion aligns better
+// with the way Docker worded it.
+For further clarification, have a look at
+https://www.docker.com/resources/what-container/[Docker's Resources on
+containers]
+
+The upshot of this is that containers are much "cheaper" in terms of
+system resources.
+// CSANAD:  probably nobody would believe you were talking about
+//          money, but I think it's more specific this way.
 You can start one up in milliseconds,
 and you can run hundreds on the same machine.
 
@@ -191,14 +212,22 @@ and most of the rest of the deployment process is taken care of by someone else.
 
 How will containerizing our software help with the danger areas?
 
-* Containers are like a little virtual server,
+* Containers can be like little virtual servers and this is how
+  we will use them,
   so they will force us to address many of the problems
   like dependency management and configuration.
 
 * We can use the containers to package up as much
   of the functionality of our application as possible,
   which in turn will minimise the amount of configuration
   we need to do to our actual servers.
+// CSANAD:  I'm not sure about this point. Can you be a bit more
+//          specific or maybe give a few examples?
+// I feel like the first point is about having the dependencies along
+// with the source code and setting open ports, users set up for running
+// the program, DB-related settings, etc. This one is a little vague,
+// I'm not sure what functionalities would save additional configuration
+// of the servers.
 
 * We can test our containers work by running our functional tests
   against them.