You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: principles.md
+6-6
Original file line number
Diff line number
Diff line change
@@ -1,4 +1,4 @@
1
-
# The 5 principles of Standard Containers
1
+
# <aname="the5PrinciplesOfStandardContainers" />The 5 principles of Standard Containers
2
2
3
3
Define a unit of software delivery called a Standard Container.
4
4
The goal of a Standard Container is to encapsulate a software component and all its dependencies in a format that is self-describing and portable, so that any compliant runtime can run it without extra dependencies, regardless of the underlying machine and the contents of the container.
@@ -14,22 +14,22 @@ Shipping containers are a fundamental unit of delivery, they can be lifted, stac
14
14
Irrespective of their contents, by standardizing the container itself it allowed for a consistent, more streamlined and efficient set of processes to be defined.
15
15
For software Standard Containers offer similar functionality by being the fundamental, standardized, unit of delivery for a software package.
16
16
17
-
## 1. Standard operations
17
+
## <aname="standardOperations" />1. Standard operations
18
18
19
19
Standard Containers define a set of STANDARD OPERATIONS.
20
20
They can be created, started, and stopped using standard container tools; copied and snapshotted using standard filesystem tools; and downloaded and uploaded using standard network tools.
21
21
22
-
## 2. Content-agnostic
22
+
## <aname="contentAgnostic" />2. Content-agnostic
23
23
24
24
Standard Containers are CONTENT-AGNOSTIC: all standard operations have the same effect regardless of the contents.
25
25
They are started in the same way whether they contain a postgres database, a php application with its dependencies and application server, or Java build artifacts.
Standard Containers are INFRASTRUCTURE-AGNOSTIC: they can be run in any OCI supported infrastructure.
30
30
For example, a standard container can be bundled on a laptop, uploaded to cloud storage, downloaded, run and snapshotted by a build server at a fiber hotel in Virginia, uploaded to 10 staging servers in a home-made private cloud cluster, then sent to 30 production instances across 3 public cloud regions.
31
31
32
-
## 4. Designed for automation
32
+
## <aname="designedForAutomation" />4. Designed for automation
33
33
34
34
Standard Containers are DESIGNED FOR AUTOMATION: because they offer the same standard operations regardless of content and infrastructure, Standard Containers, are extremely well-suited for automation.
35
35
In fact, you could say automation is their secret weapon.
@@ -39,7 +39,7 @@ Before Standard Containers, by the time a software component ran in production,
39
39
Builds failed, libraries conflicted, mirrors crashed, post-it notes were lost, logs were misplaced, cluster updates were half-broken.
40
40
The process was slow, inefficient and cost a fortune - and was entirely different depending on the language and infrastructure provider.
Standard Containers make INDUSTRIAL-GRADE DELIVERY of software a reality.
45
45
Leveraging all of the properties listed above, Standard Containers are enabling large and small enterprises to streamline and automate their software delivery pipelines.
0 commit comments