Added link to main page, for cloudnative sections.

pages/03-Cloud-Native/001-What-is-Cloud-Native.md

@@ -26,4 +26,6 @@ We'll get to explore how microservices ties in with Cloud-native in the labs.
 </details>
 
 
-[Back to first page](../../README.md##cloud-native)
+<br>
+
+[Back to first page](../../README.md##cloud-native)

pages/03-Cloud-Native/002-Containers-and-being-Cloud-Native.md

@@ -14,3 +14,8 @@ The third key thing is **containers**.
 To recall, containers are simply **processes** which wraps the dependencies and libraries so that it can be shipped as runnable applications across different platforms. 
 
 They are closely associated with cloud native applications as containers are a great way to deploy applications quickly and resiliently given their lightweight feature.
+
+
+<br>
+
+[Back to first page](../../README.md##cloud-native)

pages/03-Cloud-Native/003-Cloud-Native-Landscape.md

@@ -27,3 +27,8 @@ Over time, Kubernetes was developed to include more than just automation but als
 - Service Mesh
 - Logs and metrics
 - Tracing
+
+
+<br>
+
+[Back to first page](../../README.md##cloud-native)

pages/03-Cloud-Native/004-Business-and-Technical-Considerations.md

@@ -13,3 +13,9 @@ From a technical perspective, the adoption of cloud-native tooling represents:
 - **Automation** - release a service without human intervention
 - **Orchestration** - introduce a container orchestrator to manage  thousands of services with minimal effort
 - **Observability** - ability to independently troubleshoot and debug each component
+
+
+<br>
+
+[Back to first page](../../README.md##cloud-native)
+

pages/03-Cloud-Native/005-Design-Considerations.md

@@ -16,4 +16,9 @@ It is necessary to allocate time at the start to identifying the design factors
     Here we determine what is the context of implementing these functionalities.
     - Engineering resources - *Who can work on the project?*
     - Financial resources - *How much is the budget?*
-    - Timeframes - *How soon do we want the project to finish?*
+    - Timeframes - *How soon do we want the project to finish?*
+
+
+<br>
+
+[Back to first page](../../README.md##cloud-native)

pages/03-Cloud-Native/006-Monoliths-and-Microservices.md

@@ -51,3 +51,8 @@ In a microservice architecture, application tiers can be described as
 The main point of microservices is to break the software into smaller chunks, allowing developers to work on a piece of the code and release on their own cycle, which in turn speeds up development. 
 
 This kind of architecture also enables the software to scale independently.
+
+
+<br>
+
+[Back to first page](../../README.md##cloud-native)

pages/03-Cloud-Native/007-Tradeoffs.md

@@ -11,3 +11,8 @@ Depending on which model we choose, each one will have their own set of tradeoff
 **Flexibility** | Ability to adapt to new technologies and introduce new functionalities. | <ul><li>low rate</li><li>entire application stack might need restructuring to incorporate new functionalities</li></ul> | <ul><li>high rate</li><li>since changing an independent unit is straightforward</li></ul> |
 **Operational Cost** | Represents the cost of necessary resources to release a product. | <ul><li>low initial cost</li><li>one code base and one pipeline should be managed</li><li>cost increases exponentially when the application needs to operate at scale</li></ul> | <ul><li>high initial cost</li><li>multiple repositories and pipelines require management</li><li>to scale, the cost remains proportional to the consumed resources at that point in time</li></ul>
 **Reliability** | Reliability captures practices for an application to recover from failure and tools to monitor an application.| <ul><li>in a failure scenario, the entire stack needs to be recovered</li><li>the visibility into each functionality is low, since all the logs and metrics are aggregated together</li></ul> | <ul><li>in a failure scenario, only the failed unit needs to be recovered</li><li>there is high visibility into the logs and metrics for each unit</li></ul>
+
+
+<br>
+
+[Back to first page](../../README.md##cloud-native)

pages/03-Cloud-Native/008-Best-Practice-for-App-Deployments.md

@@ -54,4 +54,9 @@ Helpful for understanding the full journey of a request.
 ## Resource Consumption
 
 Refers to how much resources an application uses to perform its operations.
-- usually CPU, memory, network throughput, and number of concurrent requests.
+- usually CPU, memory, network throughput, and number of concurrent requests.
+
+
+<br>
+
+[Back to first page](../../README.md##cloud-native)

pages/03-Cloud-Native/009-Product-is-Released-Whats-Next.md

@@ -26,3 +26,8 @@ These are some of most common operations you'll encounter after a product goes l
 - **stale** operation - performed for services that are no longer providing any business value, and should be archived or deprecated. For example, services that were used to perform a one-off migration process.
 
 These operations are inevitable and you will perform these as your application grows. At the end of the day, the application exists to provide value to customers and to be easily managed by the technical team. 
+
+
+<br>
+
+[Back to first page](../../README.md##cloud-native)