whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Fix markdown errors of unordered list in blog posts.

Browse Source
This commit is contained in:
TAKAHASHI Shuuji
2020-07-25 01:49:14 +09:00
parent 227920a15b
commit b0d3fb3144
15 changed files with 161 additions and 319 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/blog/_posts/2015-06-00-The-Distributed-System-Toolkit-Patterns.md
+4 -8
View File
@@ -12,14 +12,10 @@ In many ways the switch from VMs to containers is like the switch from monolithi
The benefits of thinking in terms of modular containers are enormous, in particular, modular containers provide the following:
-
Speed application development, since containers can be re-used between teams and even larger communities
-
Codify expert knowledge, since everyone collaborates on a single containerized implementation that reflects best-practices rather than a myriad of different home-grown containers with roughly the same functionality
-
Enable agile teams, since the container boundary is a natural boundary and contract for team responsibilities
-
Provide separation of concerns and focus on specific functionality that reduces spaghetti dependencies and un-testable components
- Speed application development, since containers can be re-used between teams and even larger communities
- Codify expert knowledge, since everyone collaborates on a single containerized implementation that reflects best-practices rather than a myriad of different home-grown containers with roughly the same functionality
- Enable agile teams, since the container boundary is a natural boundary and contract for team responsibilities
- Provide separation of concerns and focus on specific functionality that reduces spaghetti dependencies and un-testable components
Building an application from modular containers means thinking about symbiotic groups of containers that cooperate to provide a service, not one container per service.  In Kubernetes, the embodiment of this modular container service is a Pod.  A Pod is a group of containers that share resources like file systems, kernel namespaces and an IP address.  The Pod is the atomic unit of scheduling in a Kubernetes cluster, precisely because the symbiotic nature of the containers in the Pod require that they be co-scheduled onto the same machine, and the only way to reliably achieve this is by making container groups atomic scheduling units.