feat: implemented Public Network and VPC descriptions

Wouter0100 · Wouter0100 · commit db2e972e817b · 2025-05-09T11:54:28.000Z
diff --git a/.devcontainer/devcontainer.json b/.devcontainer/devcontainer.json
@@ -0,0 +1,34 @@
+// For format details, see https://aka.ms/devcontainer.json. For config options, see the
+// README at: https://github.com/devcontainers/templates/tree/main/src/python
+{
+	"name": "Python 3",
+	// Or use a Dockerfile or Docker Compose file. More info: https://containers.dev/guide/dockerfile
+	"image": "mcr.microsoft.com/devcontainers/python:1-3.12-bullseye",
+	"features": {
+		"ghcr.io/devcontainers-extra/features/mkdocs:2": {
+			"version": "latest",
+			"plugins": "mkdocs-gen-files mkdocs-material mkdocs-monorepo-plugin"
+		},
+		"ghcr.io/devcontainers-extra/features/pipx-package:1": {
+			"package": "black",
+			"version": "latest",
+			"injections": "pylint pytest",
+			"interpreter": "python3"
+		}
+	}
+
+	// Features to add to the dev container. More info: https://containers.dev/features.
+	// "features": {},
+
+	// Use 'forwardPorts' to make a list of ports inside the container available locally.
+	// "forwardPorts": [],
+
+	// Use 'postCreateCommand' to run commands after the container is created.
+	// "postCreateCommand": "pip3 install --user -r requirements.txt",
+
+	// Configure tool-specific properties.
+	// "customizations": {},
+
+	// Uncomment to connect as root instead. More info: https://aka.ms/dev-containers-non-root.
+	// "remoteUser": "root"
+}
diff --git a/docs/index.md b/docs/index.md
@@ -1 +1,11 @@
-# CBWS
+# CBWS Docs
+
+Welcome to the documentation for CBWS, your trusted sovereign European cloud provider headquartered in Eindhoven, The Netherlands. We're delighted you're here to explore the power and flexibility of our cloud-native services.
+
+At CBWS, we are committed to providing a secure, reliable, and high-performance platform built on European values and infrastructure. Our initial suite of services – including scalable Instances, our intuitive Kubernetes Engine, versatile Object Storage, and persistent Block Storage – is designed to empower your innovation and growth.
+
+**Please be aware that our documentation is actively under development and represents a work in progress. While we strive to provide accurate information, you may encounter areas where details are still being finalized or expanded. We appreciate your understanding as we continue to build out these resources.**
+
+This documentation serves as your central resource for understanding and utilizing the CBWS platform. Whether you're looking for technical specifications, step-by-step guides, or best practices for deployment and management, you'll find valuable information here.
+
+**Thank you for choosing CBWS.** We're confident that even in its current state, our documentation will provide you with the knowledge and tools necessary to begin building and scaling your applications successfully on our European cloud. We are continuously working to enhance these resources and appreciate your patience. Let's get started!
diff --git a/mkdocs.yml b/mkdocs.yml
@@ -1,4 +1,4 @@
-site_name: Default
+site_name: CBWS
 theme:
   name: material
   features:
@@ -9,7 +9,8 @@ nav:
   - Services:
     - Identity & Access Management: '!include ./iam/mkdocs.yml'
     - Projects: '!include ./projects/mkdocs.yml'
-    - Virtual Private Networks: '!include ./vpn/mkdocs.yml'
+    - Virtual Private Clouds: '!include ./vpc/mkdocs.yml'
+    - Public Network: '!include ./network/mkdocs.yml'
 
 markdown_extensions:
   - admonition
diff --git a/network/docs/description.md b/network/docs/description.md
@@ -0,0 +1,53 @@
+# Public Networking Service Description
+
+The Public Networking service provides your servers with robust and reliable public internet connectivity. CBWS manages the underlying network infrastructure, including transit provider relationships, Internet Exchange (IX) peering, and core routing, to ensure optimal performance and availability.
+
+This service can be used independently or in conjunction with our [Virtual Private Cloud (VPC) service](/vpc/description) to provide comprehensive connectivity solutions for your hosted infrastructure.
+
+## Service Overview
+
+This service equips your servers with access to the public internet, enabling them to send and receive traffic globally. We focus on providing high-quality bandwidth with diverse routing paths.
+
+## Key Features
+
+* **Managed Public Connectivity:** CBWS handles all aspects of upstream internet connectivity, including BGP routing, peering agreements, and capacity management.
+* **Resilient Infrastructure:** Our network is designed for high availability with redundant core components and multiple upstream providers.
+* **Scalable Bandwidth Options:** Choose from various billing models and uplink capacities to match your specific needs.
+* **Full Capacity Utilization:** CBWS ensures you can utilize the full provisioned capacity of your public network uplink.
+
+## Service Level Agreement (SLA)
+
+* **Per-AZ Availability:** We include a **99.9% uptime Service Level Agreement (SLA)** by default for network connectivity per Availability Zone.
+* **Region (Cross-AZ) SLA:** Currently we do not offer a general SLA that covers services across multiple Availability Zones. SLAs are specific to the Availability Zone where the service is delivered.
+
+## Billing Models for Public Bandwidth
+
+We offer the following billing models for your public internet traffic:
+
+* **Mbit/s (95th Percentile):** This model is based on your sustained bandwidth usage. We measure your inbound and outbound traffic separately. At the end of the billing period, the top 5% of these measurements are discarded, and you are billed based on the next highest value (the 95th percentile). This model is ideal for bursty traffic patterns.
+* **Flat Rate:** A fixed monthly fee for a committed bandwidth capacity. This provides predictable costs for consistent high-bandwidth usage.
+* **TB Bandwidth Usage (Traffic Packs):** Pay based on the total amount of data transferred (in Terabytes) over the public network. Bandwidth packs are purchased beforehand, and overusage is calculated if the allowance is exceeded. This model is suitable for applications with predictable data transfer volumes.
+
+## Uplink capacity
+
+The uplink capacity differs depending on whether the service is for virtual or physical servers.
+
+### Virtual servers
+
+The maximum uplink capacity for a virtual server is as advertised with the selected virtual server flavor. This capacity **is not** shared between public internet traffic and any [Virtual Private Cloud (VPC) service](/vpc/description) traffic.
+
+### Physical servers
+
+_Relevant for bare metal & colocation._
+
+The following dedicated physical uplink capacities are available for connecting your physical servers to our network infrastructure:
+
+* **1 Gbit/s:** Available at nl-ein-1
+* **10 Gbit/s:** Available at nl-ein-1
+* **25 Gbit/s:** Available at nl-ein-2
+
+The choice of uplink type will typically depend on the server or colocation package selected. For physical servers, Link Aggregation Control Protocol (LACP) is always deployed, bundling them into a single logical channel for increased throughput and redundancy. This total aggregated capacity **is** shared between public internet traffic and any [Virtual Private Cloud (VPC) service](/vpc/description) traffic.
+
+## Combining with Virtual Private Cloud (VPC)
+
+While this service provides public internet access, our [Virtual Private Cloud (VPC) service](/vpc/description) can be used simultaneously to create an isolated, high-speed network for communication *between* your servers. This allows public-facing services to run alongside secure, high-performance backend communication, with internal VPC traffic not incurring public bandwidth charges.
diff --git a/network/docs/getting-started.md b/network/docs/getting-started.md
@@ -0,0 +1 @@
+Something about Public Network
diff --git a/network/docs/sla.md b/network/docs/sla.md
@@ -0,0 +1,49 @@
+# Public Networking SLA
+
+This document outlines the Service Level Agreement (SLA) specific to the CBWS Public Networking service. This SLA is effective from the delivery date of the Public Networking service and remains in effect as long as the service is supplied by CBWS to the customer.
+
+## Availability Target
+
+* CBWS commits to providing the Public Networking service with **99.9% uptime** per Availability Zone (AZ).
+* This availability is measured by CBWS on a calendar month basis.
+
+## Downtime Measurement
+
+* CBWS measures service availability by continuously monitoring connectivity from multiple points within its own network to a diverse set of representative publicly available endpoints. This monitoring occurs every minute. The monitored endpoints include those hosted by major hyperscalers, as well as those on various smaller networks and key eyeball (consumer ISP) networks.
+* Downtime is registered if there is a loss of general internet connectivity via the Public Networking service, as verified by these monitoring systems, due to a failure solely within CBWS's network infrastructure. Downtime begins when CBWS confirms such a service interruption (or is reasonably made aware of one by a customer) and ends when general connectivity is restored.
+
+## SLA Claim Process
+
+* **Customer Responsibility:** Customers are responsible for monitoring their own services and identifying potential downtime that may qualify for an SLA claim. CBWS does not proactively issue SLA credits or report on general SLA adherence for individual customer services.
+* **Initiating a Claim:** To make an SLA claim related to service availability, the customer must open a support ticket with CBWS through the official support channels (e.g., by emailing support@cbws.nl).
+* **Claim Deadline:** The support ticket detailing the experienced downtime must be submitted **within 30 calendar days** following the end of the month in which the qualifying downtime occurred. Claims submitted after this period will not be eligible for remedies under this SLA.
+* **Verification:** All SLA claims will be verified against CBWS's monitoring data and service logs.
+
+## Remedies for Non-Achievement
+
+In the event the 99.9% availability target for the Public Networking service is not met in a given calendar month, customers may be entitled to the following remedies:
+
+1.  **Reason for Outage (RFO):** CBWS may provide the customer with a Reason for Outage (RFO) including a plan for improvement to address the cause of the service unavailability.
+2.  **Service Credits (Compensation):**
+    * **Eligibility:** If the Public Networking service in a specific Availability Zone is unavailable for at least four (4) continuous hours during a calendar month due to failures within CBWS's responsibility, the customer is eligible to request service credits.
+    * **Credit Amount:** Eligible compensation is 10% of the monthly fees paid for the specifically affected Public Networking service in the impacted AZ for that month. The maximum compensation for any single event or series of related events in a calendar month is capped at €1,000.00.
+    * **Application of Credits:** Approved service credits will be applied on the customer's next monthly invoice, deducting from the total amount payable for the services.
+    * Service credits are the sole and exclusive monetary remedy for any failure by CBWS to meet the availability target.
+
+## Exclusions
+
+This SLA for the Public Networking service does not apply to any unavailability, suspension, or termination of service performance:
+
+* That results from a suspension described in the CBWS Terms of Service.
+* Caused by factors outside of CBWS's reasonable control, including any force majeure event, or Internet access and related problems beyond the demarcation point of the CBWS network.
+* That results from any actions or inactions of the customer or any third party acting on the customer's behalf.
+* That results from the customer's equipment, software, or other technology, and/or third-party equipment, software, or other technology not within CBWS's direct control.
+* That results from any scheduled maintenance communicated in advance by CBWS.
+* That results from customer-initiated security measures, traffic filtering, or abuse mitigation actions.
+
+### Customer Support
+Customer support can be requested via email at support@cbws.nl. Opening times are Monday to Friday, 09:00 - 17:00 (CET/CEST). Support requests are responded to within 24 hours of receipt during these times; this reaction time is an effort obligation.
+
+## Concluding Terms
+
+These terms define the Service Level Agreement specifically for the CBWS Public Networking service. The general CBWS Terms of Service also apply to the use of all CBWS services and govern aspects not explicitly covered in this SLA.
diff --git a/network/mkdocs.yml b/network/mkdocs.yml
@@ -0,0 +1,14 @@
+site_name: network
+theme:
+  name: material
+
+nav:
+  - Service Description: "description.md"
+  - Service Level Agreement: "sla.md"
+  #- Guides:
+  #    - Getting started: "getting-started.md"
+#  - Reference:
+#      - Permissions/roles: "reference/permissions.md"
+#      - Golang: "golang.md"
+#      - PHP: "php.md"
+#      - Protobuf: "reference/protobuf.md"
diff --git a/projects/mkdocs.yml b/projects/mkdocs.yml
@@ -8,6 +8,6 @@ nav:
       - Managing projects: "managing-projects.md"
   - Reference:
       - Permissions/roles: "reference/permissions.md"
-      - Golang: "golang.md"
-      - PHP: "php.md"
+      #- Golang: "golang.md"
+      #- PHP: "php.md"
       - Protobuf: "reference/protobuf.md"
diff --git a/vpc/docs/description.md b/vpc/docs/description.md
@@ -0,0 +1,40 @@
+# VPC Service Description
+The Virtual Private Cloud (VPC) service offers a secure, isolated network environment for dedicated inter-server communication within the CBWS Cloud infrastructure. This service complements our Public Networking services, which furnish public internet connectivity.
+
+This service can be used independently or in conjunction with our [Public Network service](/network/description) to provide comprehensive connectivity solutions for your hosted infrastructure.
+
+# Service overview
+While our Public Networking service facilitates your servers' connection to the public internet, the Virtual Private Cloud (VPC) service enables designated servers to communicate directly and securely over an isolated private network infrastructure. Each VPC can be configured to include one or more Private Networks. A Private Network is specific to a single Availability Zone. The VPC provides routing capabilities to enable communication between these distinct Private Networks across different Availability Zones within the same region, offering enhanced flexibility and resilience.
+
+Traffic within your Private Networks, and traffic routed between them by the VPC, is segregated from public networks and other tenants. Furthermore, this private traffic is not subject to the bandwidth limitations or metered billing associated with the Public Networking service.
+
+The service is supported on virtual servers, as well as bare metal, colocation and racks in the following Availability Zones:
+
+- **Region nl-ein**
+    - nl-ein-1
+    - nl-ein-2
+
+# Key technical features
+
+1. **Isolated Network Segment**: Each Private Network within a VPC constitutes a distinct Layer 2 broadcast domain (VLAN) specific to an Availability Zone. This architecture ensures robust traffic segregation.
+2. **Low Latency**: Direct server-to-server connectivity within a Private Network minimizes network hops and processing overhead. Communication routed by the VPC between Private Networks in different Availability Zones also benefits from optimized, low-latency paths.
+3. **Unmetered Internal Traffic**: Data transfer between servers within the same Private Network (i.e., within the same Availability Zone) is unmetered. Furthermore, data transfer routed by the VPC between different Private Networks (i.e., across Availability Zones within the same region) also does not contribute to public bandwidth quotas (as defined by the Public Networking service) and incurs no additional data transfer costs.
+4. **Regional Redundancy and Resilience**: By enabling the creation of Private Networks in multiple Availability Zones within the same region, and providing :routing between them, the VPC service facilitates the design and deployment of highly available and fault-tolerant application architectures. This allows services to withstand the failure of an individual Availability Zone.
+
+# Implementation details
+
+Upon provisioning, servers designated for a Virtual Private Cloud are configured with access to their specified Private Network(s) within the VPC.
+
+- **Availability Zone connectivity**: Within a single Availability Zone, the VPC service provides Layer 2 connectivity for each Private Network. This allows for a flat network segment across your servers in that AZ as part of that Private Network.
+
+- **Region connectivity**: CBWS provides an interconnected private high capacity backbone between its Availability Zones within the same region. This backbone, _in conjunction with the VPC's routing capabilities_, facilitates communication between Private Networks located in different Availability Zones, based on Layer 3 routing between these subnets (the Private Networks).
+
+## Virtual servers
+
+For virtual servers, a dedicated virtual network interface is provisioned and assigned to the server, granting access to the designated Private Network. The maximum bandwidth available to this interface corresponds to the advertised capacity of the selected flavor.
+
+## Physical servers
+
+_Relevant for bare metal & colocation._
+
+By default, for physical servers, we deploy combined uplinks for the Public Networking service and the Virtual Private Cloud. This consolidated approach allows the total uplink capacity to be shared dynamically between public internet traffic and private VPC traffic, optimizing bandwidth utilization.
diff --git a/vpc/docs/getting-started.md b/vpc/docs/getting-started.md
diff --git a/vpc/docs/sla.md b/vpc/docs/sla.md
diff --git a/vpc/mkdocs.yml b/vpc/mkdocs.yml
