Skip to content

Commit cbcf1a9

Browse files
authored
[Principles] Add anchor tags for headings
Signed-off-by: Rob Dolin <[email protected]>
1 parent 9ce258d commit cbcf1a9

File tree

1 file changed

+6
-6
lines changed

1 file changed

+6
-6
lines changed

principles.md

+6-6
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,4 @@
1-
# The 5 principles of Standard Containers
1+
# <a name="the5PrinciplesOfStandardContainers" />The 5 principles of Standard Containers
22

33
Define a unit of software delivery called a Standard Container.
44
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
1414
Irrespective of their contents, by standardizing the container itself it allowed for a consistent, more streamlined and efficient set of processes to be defined.
1515
For software Standard Containers offer similar functionality by being the fundamental, standardized, unit of delivery for a software package.
1616

17-
## 1. Standard operations
17+
## <a name="standardOperations" />1. Standard operations
1818

1919
Standard Containers define a set of STANDARD OPERATIONS.
2020
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.
2121

22-
## 2. Content-agnostic
22+
## <a name="contentAgnostic" />2. Content-agnostic
2323

2424
Standard Containers are CONTENT-AGNOSTIC: all standard operations have the same effect regardless of the contents.
2525
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.
2626

27-
## 3. Infrastructure-agnostic
27+
## <a name="infrastructureAgnostic" />3. Infrastructure-agnostic
2828

2929
Standard Containers are INFRASTRUCTURE-AGNOSTIC: they can be run in any OCI supported infrastructure.
3030
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.
3131

32-
## 4. Designed for automation
32+
## <a name="designedForAutomation" />4. Designed for automation
3333

3434
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.
3535
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,
3939
Builds failed, libraries conflicted, mirrors crashed, post-it notes were lost, logs were misplaced, cluster updates were half-broken.
4040
The process was slow, inefficient and cost a fortune - and was entirely different depending on the language and infrastructure provider.
4141

42-
## 5. Industrial-grade delivery
42+
## <a name="industrialGradeDelivery" />5. Industrial-grade delivery
4343

4444
Standard Containers make INDUSTRIAL-GRADE DELIVERY of software a reality.
4545
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

Comments
 (0)