Permalink
Browse files

[Principles] Add anchor tags for headings

Signed-off-by: Rob Dolin <robdolin@microsoft.com>
  • Loading branch information...
1 parent 9ce258d commit cbcf1a99ef6d9fd330323a2ab6be02880613eb0d @RobDolinMS RobDolinMS committed on GitHub Dec 1, 2016
Showing with 6 additions and 6 deletions.
  1. +6 −6 principles.md
View
@@ -1,4 +1,4 @@
-# The 5 principles of Standard Containers
+# <a name="the5PrinciplesOfStandardContainers" />The 5 principles of Standard Containers
Define a unit of software delivery called a Standard Container.
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
Irrespective of their contents, by standardizing the container itself it allowed for a consistent, more streamlined and efficient set of processes to be defined.
For software Standard Containers offer similar functionality by being the fundamental, standardized, unit of delivery for a software package.
-## 1. Standard operations
+## <a name="standardOperations" />1. Standard operations
Standard Containers define a set of STANDARD OPERATIONS.
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.
-## 2. Content-agnostic
+## <a name="contentAgnostic" />2. Content-agnostic
Standard Containers are CONTENT-AGNOSTIC: all standard operations have the same effect regardless of the contents.
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.
-## 3. Infrastructure-agnostic
+## <a name="infrastructureAgnostic" />3. Infrastructure-agnostic
Standard Containers are INFRASTRUCTURE-AGNOSTIC: they can be run in any OCI supported infrastructure.
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.
-## 4. Designed for automation
+## <a name="designedForAutomation" />4. Designed for automation
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.
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,
Builds failed, libraries conflicted, mirrors crashed, post-it notes were lost, logs were misplaced, cluster updates were half-broken.
The process was slow, inefficient and cost a fortune - and was entirely different depending on the language and infrastructure provider.
-## 5. Industrial-grade delivery
+## <a name="industrialGradeDelivery" />5. Industrial-grade delivery
Standard Containers make INDUSTRIAL-GRADE DELIVERY of software a reality.
Leveraging all of the properties listed above, Standard Containers are enabling large and small enterprises to streamline and automate their software delivery pipelines.

0 comments on commit cbcf1a9

Please sign in to comment.