2 |
3 | {% unless page.url contains '/strategy-risk-reduction' %}
{% endunless %}
4 | {% unless page.url contains '/organization-culture' %}
{% endunless %}
5 | {% unless page.url contains '/development-design' %}
{% endunless %}
6 | {% unless page.url contains '/infrastructure-cloud' %}
{% endunless %}
7 | {% unless page.url contains '/operations' %}
{% endunless %}
8 |
{{ page.title }}
9 | {{ page.description }}
10 |
11 |
22 | {% capture cta-section %}{% include_relative cta-section.md %}{% endcapture %}
23 | {{ cta-section | markdownify }}
24 |
25 | {% include footer.html %}
26 | {% include scripts.html %}
27 | {% include analytics.html %}
28 |
29 |
30 |
--------------------------------------------------------------------------------
/README.md:
--------------------------------------------------------------------------------
1 | # Cloud Native Transformation Patterns
2 | This site contains patterns for making your organisation Cloud Native. The official URL of the site is [https://cnpatterns.org](https://cnpatterns.org)
3 |
4 | # What are Cloud Native Patterns?
5 | When it comes to Cloud Native, most of us are junior. The technology is so new, and our understanding of the architecture is constantly evolving. Sharing our rapidly growing knowledge is essential. Creating Cloud Native-specific patterns is a way to name the things we are learning as developers, engineers, and technology managers so we can talk to each other more effectively. As we learn and continue, the patterns will evolve and improve alongside our understanding.
6 |
7 | # Contributing
8 | This is far from an exhaustive list of patterns, and we welcome contributions from all industry practicioners who would like
9 | to share their expertise with the community in the form of patterns.
10 | Reach out to us [here](https://cnpatterns.org/contact-us) for help with writing your own patterns.
11 |
12 | # License
13 | See [LICENSE](LICENSE).
14 |
--------------------------------------------------------------------------------
/_sass/components/_footer.scss:
--------------------------------------------------------------------------------
1 | .footer-strip {
2 | background-color: #000;
3 | background-image: url("#{$baseurl}/assets/images/pattern_background.png");
4 | background-size: cover;
5 | color: #fff;
6 | font-weight: 700;
7 | font-size: 15px;
8 | }
9 |
10 | .footer-menu {
11 | align-items: center;
12 | display: block;
13 | flex-direction: row;
14 | justify-content: space-between;
15 | margin-left: auto;
16 | margin-right: auto;
17 | max-width: 940px;
18 |
19 | ul {
20 | list-style: none;
21 | margin: 0;
22 | padding: 0;
23 | text-align: center;
24 |
25 | li {
26 | display: inline-block;
27 | padding: 20px;
28 |
29 | a {
30 | color: #ffffff;
31 | text-decoration: none;
32 | }
33 | }
34 | }
35 | }
36 |
37 | .footer-title {
38 | align-items: center;
39 | display: block;
40 | flex-direction: row;
41 | justify-content: space-between;
42 | margin-left: auto;
43 | margin-right: auto;
44 | max-width: 940px;
45 | text-align: right;
46 |
47 | img {
48 | width: 130px;
49 | }
50 | }
51 |
--------------------------------------------------------------------------------
/cta-section.md:
--------------------------------------------------------------------------------
1 | ---
2 | ---
3 |
4 |
12 | {% if page.url contains '/strategy-risk-reduction' %}
Return{% endif %}
13 | {% if page.url contains '/organization-culture' %}
Return{% endif %}
14 | {% if page.url contains '/development-design' %}
Return{% endif %}
15 | {% if page.url contains '/infrastructure-cloud' %}
Return{% endif %}
16 | {% if page.url contains '/operations' %}
Return{% endif %}
17 |
Pattern: {{ page.title }}
18 | {{ page.description }}
19 | {{ content }}
20 |
14 |
15 | {:.col-sm .d-flex .flex-column}
16 | [Strategy & Risk Reduction]({{ site.baseurl }}/strategy-risk-reduction)[{:height="410px" width="300px"}]({{ site.baseurl }}/strategy-risk-reduction)
17 |
18 | {:.col-sm .d-flex .flex-column}
19 | [Organization & Culture]({{ site.baseurl }}/organization-culture)[{:height="410px" width="300px"}]({{ site.baseurl }}/organization-culture)
20 |
21 | {:.col-sm .d-flex .flex-column}
22 | [Development & Design]({{ site.baseurl }}/development-design)[{:height="410px" width="300px"}]({{ site.baseurl }}/development-design)
23 |
24 | {:.col-sm .d-flex .flex-column}
25 | [Infrastructure & Cloud]({{ site.baseurl }}/infrastructure-cloud)[{:height="410px" width="300px"}]({{ site.baseurl }}/infrastructure-cloud)
26 |
27 | {:.col-sm .d-flex .flex-column}
28 | [Operations]({{ site.baseurl }}/operations)[{:height="410px" width="300px"}]({{ site.baseurl }}/operations)
29 |
30 |
--------------------------------------------------------------------------------
/_strategy-risk-reduction/value-hierarchy.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Value Hierarchy
3 | description: When an organization’s values are clearly stated and prioritized, as well as fully internalized across the company, people have the basis for making day-to-day decisions without needing to seek consent or permission/approval
4 | layout: pattern
5 | ---
6 |
7 | 
8 |
9 | The company’s cloud native transformation has just begun, and there is a lot of uncertainty. People are still learning about the tech, and the organizational structureis evolving. Teams are becoming independent, and there are many moving pieces.
10 |
11 | ## In This Context
12 |
13 | Without a clear understanding of the company values and the priorities, people have no easy way to connect their daily work to the company strategy. In such a situation, different teams may make conflicting decisions or waste a lot of effort on low-priority tasks.
14 |
15 | - Gaining consensus from all stakeholders is time-consuming.
16 | - In traditional organizations managers make all the decisions.
17 | - The market is changing frequently, with new competitors appearing unexpectedly.
18 | - Cloud native technology is constantly and rapidly evolving.
19 |
20 | ## Therefore
21 |
22 | Create an ordered list of clearly stated values to simplify decision making and guide behavior in an uncertain environment.
23 |
24 | - Identify the company’s values: what is important to us?
25 | - Formulate these simply and clearly.
26 | - Rank these values in order of importance.
27 | - Incorporate this value hierarchy into the company’s culture and identity by broadcasting it across the organization.
28 |
29 | ## Consequently
30 |
31 | Teams and individuals in an organization are able to make decisions with confidence.
32 |
33 | {:.plusminus}
34 | - {:.plus} Organizational principles and priorities are clear and commonly understood by all.
35 | - {:.plus} People can easily make informed choices that reflect both the company’s values and best interest.
36 | - {:.plus} In a constantly changing environment, there is a stable and constant point of orientation.
37 | - {:.minus} Too-frequent changes to the value hierarchy can cause confusion and chaos.
38 |
--------------------------------------------------------------------------------
/_infrastructure-cloud/containerized-apps.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Containerized Apps
3 | description: When an application is packaged in a container with all its necessary dependencies, it does not rely on the underlying runtime environment and so can run agnostically on any platform
4 | layout: pattern
5 | ---
6 |
7 | 
8 |
9 | The team is building a distribution app that can scale up and down. Separate teams are meanwhile building microservices, and they need to take them quickly through a variety of dev and test environments all the way to production. There are a variety of different runtime environments, such as personal laptops, during development and different private and public clouds for testing, integration, and production.
10 |
11 | ## In This Context
12 |
13 | Speed of delivery can be slow if an app depends on uniformity among different environments. Maintaining consistency of different tools and their versions on many machines across many on-premises and/or public clouds is difficult, time consuming,and risky.
14 |
15 | - All stable environments tend to drift eventually.
16 | - It’s impossible to manage thousands of machines manually.
17 | - Differences in environment are difficult to find and to fix.
18 |
19 | ## Therefore
20 |
21 | Package up an application’s code and everything it needs to run (all its dependencies,runtime, system tools, libraries, and settings) as a consistent unit so the application can be distributed to start up quickly and run reliably in any computing environment.This minimizes dependency on the runtime environment. Build once, run everywhere,and distribute quickly and easily.
22 |
23 | - Use industry standards like Docker.
24 | - Ensure proper versioning and simple and quick distribution.
25 | - All dependencies included.
26 | - All environments use the same basic tooling.
27 | - Ensure that containers can run on local or any other environment.
28 |
29 | ## Consequently
30 |
31 | Every part of the app is packaged in a container and can be easily started anywhere.
32 |
33 | {:.plusminus}
34 | - {:.plus} Container tools like Docker improve efficiency.
35 | - {:.minus} Large numbers of separate containers increase system complexity.
36 | - {:.minus} Managing container images requires extra effort.
37 |
--------------------------------------------------------------------------------
/_strategy-risk-reduction/vision-first.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Vision First
3 | description: Defining a high-level transformation path as the very first step helps set the right course through an uncertain environment
4 | layout: pattern
5 | ---
6 |
7 | 
8 |
9 | The company has established a Business Case for going cloud native, achieved Executive Commitment, and is ready to move forward with a transformation initiative.
10 |
11 | ## In This Context
12 |
13 | The company needs to define a clear and achievable vision that can be translated into specific executable steps.
14 |
15 | - Without an overall consistent vision, different teams will make independent and,frequently, conflicting architectural decisions.
16 | - The combination of limited experience and lack of extra time and flexibility for research leads to pursuing cloud native implementation using “well-known ways.”
17 | - In many companies, enterprise architects are responsible for creating a detailed architecture. Many enterprise architects lack sufficient theoretical or practical experience in the cloud native approach.
18 | - Agile methodologies, widely adopted in the contemporary business world, create pressure to produce results early and onboard teams to new systems very quickly.
19 |
20 | ## Therefore
21 |
22 | Define and visualize the organizational structure and architecture of the whole system upfront.
23 |
24 | - This can be either requested from external sources or uncovered by a series of small research and prototyping projects ranging from a few hours to a few days each.
25 | - Keep the vision high-level to allow freedom of choice during implementation(not dictating specific tools or approaches) yet also specific enough to provide clear goals and desired outcomes.
26 | - Revisit the vision regularly to evaluate status and adjust the plan if necessary.
27 | - Executive Commitment paired with leadership by the Transformation Champion are essential for successful vision creation—this indicates the path for the teams to follow.
28 |
29 | ## Consequently
30 |
31 | All teams have a clear guiding principle for the implementation phase.
32 |
33 | {:.plusminus}
34 | - {:.plus} The teams can start producing the lower-level architecture and translate it to the backlog of tasks.
35 |
--------------------------------------------------------------------------------
/_operations/network-isolation.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Network Isolation
3 | description: Leverage a tool to provide more granular control over connections to workloads.
4 | layout: pattern
5 | ---
6 |
7 | 
8 |
9 | An organisation is utilising a container platform which runs multiple different systems, environments, shared by multiple teams or even customers.
10 |
11 | ## In This Context
12 |
13 | Multiple applications, teams, environments (e.g. dev/staging) and even clients (multi tenant) are sharing the platform. While these separate services should not normally access each other across certain boundaries (e.g. Namespaces),
14 | by default there is nothing blocking traffic (either malicious or by error) from crossing these boundaries.
15 | Separate applications running on one platform can be susceptible to attacks from others.
16 |
17 | ## Therefore
18 |
19 | By leveraging a feature such as NetworkPolicies in Kubernetes, we can block all unwanted traffic between services.
20 |
21 | #### Actions
22 | - Determine all expected traffic between your services. (A service mesh or tracing tool can generate this dynamically).
23 | - Define rules to block all (other) traffic between services.
24 | - Apply the created rules and monitor your applications for any problems created.
25 | - (Optional) add logging for all blocked traffic
26 | - For any unforeseen traffic, determine if it is a) intended or b) undesired 
14 |
15 |