Split docs and add links

Author: Kate Osborn

CONTRIBUTING.md

@@ -91,7 +91,8 @@ Before beginning development, familiarize yourself with the following documents:
   outlining guidelines and best practices to ensure smooth and efficient pull request processes.
 - [Go Style Guide](/docs/developer/go-style-guide.md): A coding style guide for Go. Contains best practices and
   conventions to follow when writing Go code for the project. 
-- [Architecture and Design Principles](/docs/architecture.md): An overview of the project's architecture and design principles.
+- [Architecture](/docs/architecture.md): An high-level overview of the project's architecture.
+- [Design Principles](/docs/developer/design-principles.md): An overview of the project's design principles.
 
 ## Contributor License Agreement
 

README.md

@@ -9,6 +9,8 @@ For a list of supported Gateway API resources and features, see the [Gateway API
 > Warning: This project is actively in development (beta feature state) and should not be deployed in a production environment.
 > All APIs, SDKs, designs, and packages are subject to change.
 
+Learn about our [design principles](/docs/developer/design-principles.md) and [architecture](/docs/architecture.md). 
+
 ## Getting Started
 
 1. [Quick Start on a kind cluster](docs/running-on-kind.md).

docs/architecture.md

@@ -1,4 +1,4 @@
-# Architecture and Design Principles
+# Architecture
 
 This document provides an overview of the architecture and design principles of the NGINX Kubernetes Gateway. The target
 audience includes the following groups:
@@ -133,56 +133,3 @@ configuration and shutdowns workers with the old configuration.
 [conf-file]: https://github.com/nginxinc/nginx-kubernetes-gateway/blob/main/deploy/manifests/nginx-conf.yaml
 
 [share]: https://kubernetes.io/docs/tasks/configure-pod-container/share-process-namespace/
-
-## Design Principles
-
-The aim of NGINX Kubernetes Gateway is to become a fundamental infrastructure component within a Kubernetes cluster,
-serving as both an ingress and egress point for traffic directed towards the services (applications) running either
-within or outside the cluster. Leveraging NGINX as a data plane technology, it harnesses the well-established reputation
-of NGINX as an open-source project widely recognized for its role as a web server, proxy, load balancer, and content
-cache. NGINX is renowned for its stability, high performance, security, and rich feature set, positioning it as a
-critical infrastructure tool. Notably, once properly configured and operational, NGINX requires minimal attention,
-making it reliable and "boring" software.
-
-Likewise, the goal for the NGINX Kubernetes Gateway is to embody the same qualities as NGINX and be regarded as "boring"
-software. The principles outlined below serve as a guide for engineering the NGINX Kubernetes Gateway with the intention
-of achieving this goal.
-
-### Security
-
-We are security first. We prioritize security from the outset, thoroughly evaluating each design and feature with a
-focus on security. We proactively identify and safeguard assets at the early stages of our processes, ensuring their
-protection throughout the development lifecycle. We adhere to best practices for secure design, including proper
-authentication, authorization, and encryption mechanisms.
-
-### Availability
-
-As a critical infrastructure component, we must be highly available. We design and review features with redundancy and
-fault tolerance in mind. We regularly test the NGINX Kubernetes Gateway's availability by simulating failure scenarios
-and conducting load testing. We work to identify potential weaknesses and bottlenecks, and address them to ensure high
-availability under various conditions.
-
-### Performance
-
-We must be highly performant and lightweight. We fine-tune the NGINX configuration to maximize performance without
-requiring custom configuration. We strive to minimize our memory and CPU footprint, enabling efficient resource
-allocation and reducing unnecessary processing overhead. We use profiling tools on our code to identify bottlenecks and
-improve performance.
-
-### Resilience
-
-We design with resilience in mind. This includes gracefully handling failures, such as pod restarts or network
-interruptions, as well as leveraging Kubernetes features like health checks, readiness probes, and container restart
-policies.
-
-### Observability
-
-We provide comprehensive logging, metrics, and tracing capabilities to gain insights into our behavior and
-performance. We prioritize Kubernetes-native observability tools like Prometheus, Grafana, and distributed
-tracing systems to help users monitor the health of NGINX Kubernetes Gateway and to assist in diagnosing issues.
-
-### Ease of Use
-
-NGINX Kubernetes Gateway must be easy and intuitive to use. This means that it should be easy to install, easy to
-configure, and easy to monitor. Its defaults should be sane and should lead to "out-of-box" success. The documentation
-should be clear and provide meaningful examples that customer's can use to inform their deployments and configurations. 

docs/developer/design-principles.md

@@ -0,0 +1,52 @@
+# Design Principles
+
+The aim of NGINX Kubernetes Gateway is to become a fundamental infrastructure component within a Kubernetes cluster,
+serving as both an ingress and egress point for traffic directed towards the services (applications) running either
+within or outside the cluster. Leveraging NGINX as a data plane technology, it harnesses the well-established reputation
+of NGINX as an open-source project widely recognized for its role as a web server, proxy, load balancer, and content
+cache. NGINX is renowned for its stability, high performance, security, and rich feature set, positioning it as a
+critical infrastructure tool. Notably, once properly configured and operational, NGINX requires minimal attention,
+making it reliable and "boring" software.
+
+Likewise, the goal for the NGINX Kubernetes Gateway is to embody the same qualities as NGINX and be regarded as "boring"
+software. The principles outlined below serve as a guide for engineering the NGINX Kubernetes Gateway with the intention
+of achieving this goal.
+
+## Security
+
+We are security first. We prioritize security from the outset, thoroughly evaluating each design and feature with a
+focus on security. We proactively identify and safeguard assets at the early stages of our processes, ensuring their
+protection throughout the development lifecycle. We adhere to best practices for secure design, including proper
+authentication, authorization, and encryption mechanisms.
+
+## Availability
+
+As a critical infrastructure component, we must be highly available. We design and review features with redundancy and
+fault tolerance in mind. We regularly test the NGINX Kubernetes Gateway's availability by simulating failure scenarios
+and conducting load testing. We work to identify potential weaknesses and bottlenecks, and address them to ensure high
+availability under various conditions.
+
+## Performance
+
+We must be highly performant and lightweight. We fine-tune the NGINX configuration to maximize performance without
+requiring custom configuration. We strive to minimize our memory and CPU footprint, enabling efficient resource
+allocation and reducing unnecessary processing overhead. We use profiling tools on our code to identify bottlenecks and
+improve performance.
+
+## Resilience
+
+We design with resilience in mind. This includes gracefully handling failures, such as pod restarts or network
+interruptions, as well as leveraging Kubernetes features like health checks, readiness probes, and container restart
+policies.
+
+## Observability
+
+We provide comprehensive logging, metrics, and tracing capabilities to gain insights into our behavior and
+performance. We prioritize Kubernetes-native observability tools like Prometheus, Grafana, and distributed
+tracing systems to help users monitor the health of NGINX Kubernetes Gateway and to assist in diagnosing issues.
+
+## Ease of Use
+
+NGINX Kubernetes Gateway must be easy and intuitive to use. This means that it should be easy to install, easy to
+configure, and easy to monitor. Its defaults should be sane and should lead to "out-of-box" success. The documentation
+should be clear and provide meaningful examples that customer's can use to inform their deployments and configurations.