changes based on review comments, removed tpls

doc/blueprints/source/best-practices/index.rst

@@ -2,8 +2,8 @@
 Best Practices
 ==============
 
-Welcome Open Telekom Cloud Architecture Center Best Practices.
+Welcome to the Open Telekom Cloud Architecture Center Best Practices.
-Here we provides crucial guidelines for optimizing cloud-based solutions with emphasis to architectural principles that
+Here we provide crucial guidelines for optimizing cloud-based solutions with emphasis to architectural principles that
 enhance reliability, scalability, and security. Explore our recommended strategies for resource management, such as
 efficient utilization of compute and storage resources. Gain insights into designing for high availability and fault tolerance
 to ensure robust system performance. This section serves as a valuable resource for architects and developers

doc/blueprints/source/best-practices/network/index.rst

@@ -5,7 +5,7 @@ Network Best Practices outline key strategies for optimizing network configurati
 resilient and high-performance network architectures, including considerations for security and scalability.
 Learn about best practices for leveraging Virtual Private Clouds (VPCs), network segmentation, and load balancing to
 enhance overall network efficiency. This section serves as a valuable resource for architects and network administrators,
-providing insights into building robust and secure network infrastructures within the Open Telekom Cloud environment,
+providing insights for a robust network strategy within the Open Telekom Cloud environment,
 ensuring reliable and seamless connectivity for applications and services.
 
 

doc/blueprints/source/best-practices/security/cce_vault.rst

@@ -2,14 +2,17 @@
 Secrets management with CCE and Hashicorp Vault
 ===============================================
 
+Overview
+========
+
 Most modern IT setups are composed of several subsystems like databases, object
 stores, master controller, node access, and more. To access one component from
 another, some form of credentials are required. Configuring and storing these
 secrets directly in the components is considered as an anti-pattern, since a
-vulnerability of one component may iteratively affect the security of the whole
+vulnerability of one component may iteratively and transitively affect the security of the whole
 setup.
 
-With centralized secret management it becomes unnecessary to keep secrets used
+With centralized secret management in place, it's not necessary to keep secrets used
 by various applications spread across DevOps environments. This helps to close
 some security attack vectors (like `secret sprawl
 <https://www.hashicorp.com/resources/what-is-secret-sprawl-why-is-it-harmful>`_,
@@ -18,6 +21,9 @@ usually introduces a problem of the so-called `Secret Zero
 <https://www.hashicorp.com/resources/secret-zero-mitigating-the-risk-of-secret-introduction-with-vault>`_
 as a key to the key storage.
 
+Solution Description
+====================
+
 Vault is an open-source software, provided and maintained by Hashicorp, that
 addresses this very problem. It is considered one of the reference solutions
 for it. This article demonstrates how to utilize infrastructure authorization
@@ -25,12 +31,7 @@ with Hashicorp Vault in an CCE-powered setup. As an example workload, we deploy
 a Zookeeper cluster with enabled TLS protection. Certificates for Zookeeper are
 stored in Vault, and they oblige required practices like rotations or audits.
 Zookeeper can easily be replaced by any other component that requires access to
-internal credentials.
+internal credentials. TLS secrets are kept in the Vault. They are being read by Vault Agent component
-
-Overview
-========
-
-TLS secrets are kept in the Vault. They are being read by Vault Agent component
 running as a sidecar in Zookeeper service pod and writes certificates onto the
 file system. Zookeeper services reads certificates populated by Agent. Vault
 Agent is configured to use password-less access to Vault. Further in the
@@ -110,7 +111,7 @@ mitigates this risk.
 Populating secrets in Vault
 ===========================
 
-Within Vault there are two possibilities to access TLS certificates:
+Vault offer two options to access TLS certificates:
 
 * Store certificate data in the `KeyValue store
   <https://www.vaultproject.io/docs/secrets/kv/kv-v2>`_

doc/blueprints/source/best-practices/security/index.rst

@@ -6,7 +6,8 @@ implementing robust identity and access management, encryption protocols, and ne
 secure data at rest and in transit, as well as strategies for monitoring and responding to
 security incidents. This section is a crucial resource for architects and cybersecurity professionals, providing
 insights into designing and maintaining resilient security postures within the Open Telekom Cloud, ensuring the
-confidentiality, integrity, and availability of sensitive information.
+confidentiality, integrity, high availability, scalability, robustness and resilience of sensitive information and
+critical infrastructure.
 
 .. toctree::
    :maxdepth: 1

doc/blueprints/source/index.rst

@@ -2,7 +2,12 @@
 Blueprints
 ==========
 
-<PLACEHOLDER>
+Users sometimes identify use cases that can be solved in a standardized way to
+save research time and effort. Architecture Center Blueprints offer a collection of series of best practices,
+curated by the Open Telekom Cloud engineering and architecture teams. While
+they are not covered directly by the `Service description
+<https://open-telekom-cloud.com/service-description>`_, they are tested and
+validated recommendations from our experts.
 
 .. toctree::
    :maxdepth: 1

doc/blueprints/source/use-cases/index.rst

@@ -1,7 +1,7 @@
 Use Cases
 =========
 
-Welcome Open Telekom Cloud Architecture Center Use Cases. Here you can find tailored solutions and
+Welcome to Open Telekom Cloud Architecture Center Use Cases. Here you can find tailored solutions and
 practical implementations for a range of scenarios. Explore real-world examples demonstrating the versatility and optimal
 application and infrastructure design using our cloud services. This section serves as a comprehensive
 resource for architects, offering insights into how to adapt and optimize cloud solutions for specific business needs.

doc/source/_templates/article_internal.tpl

@@ -1,85 +0,0 @@
-. meta::
-   :description: add a SEO description here
-   :keywords: add SEO keywords here, and list additionally all OTC services used
-
-==================
-Article (Internal)
-==================
-
-.. Introduction
-
-Introduction
-============
-
-| > *There are no further requirements for an article except to include the following sections at the **end**, and to follow all general Open Telekom Architecture Center content requirements.*
-| > *An Open Telekom Cloud Architecture Center article template, for **external** creators, requires the following sections at the end of the article:*
-
-.. topic:: TL;DR
-
-    | >> Make a brief summary of what is the article about
-
-.. Main Article
-
-.. Components
-
-| > *No header required here*
-| > *(Expected to list all the Open Telekom Cloud components used, but it could be optional if it just an architectural paradigm.*
-
-.. Sections 1..n
-
-| > *You can name the Section titles as it seems fit to the workflow of the article.*
-
-Section 1
-=========
-
-Section 2
-=========
-
-Section n
-=========
-
-
-.. Next steps & Related Resources
-
-Next Steps
-==========
-
-| > *(Expected, but it could be optional if you don't want the article stops here and doesn't connect with other resources)*
-| > *Add site-relative links to Architecture Center related articles but NOT to external or third-party resources*
-| > *If there are additional resources like Cloud Topology Designer solution or Github repos, list them first with the aforementioned order*
-
-.. seealso::
-
-   `Link1 <https://www.t-systems.com>`_
-
-   `Link2 <https://www.t-systems.com>`_
-
-Resources
-=========
-
-.. Resources
-
-| > *If there are additional deployable resources like Cloud Topology Designer solution or Github repos, list them first with the aformentioned order*
-
-.. seealso::
-
-   `Link1 <https://www.t-systems.com>`_
-
-   `Link2 <https://www.t-systems.com>`_
-
-
-.. References
-
-References
-==========
-
-| > *Add site-relative links to Architecture Center articles*
-| > *Add links to external or third-party resources*
-
-.. seealso::
-
-   `Link1 <https://www.t-systems.com>`_
-
-   `Link2 <https://www.t-systems.com>`_
-
-| > **REMOVE ALL THE LINES THAT START WITH "| >"**

doc/source/index.rst

@@ -1,11 +1,12 @@
 Architecture Center
 ===================
 
-Lorem ipsum dolor sit amet, consectetur adipiscing elit.
+Welcome to the Open Telekom Cloud Architecture Center.
-Sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.
+
-Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris.
+Unlock the full potential of Open Telekom Cloud with our comprehensive collection of resources, best practices,
-Duis aute irure dolor in reprehenderit in voluptate velit esse cillum.
+and expert guidance material. Whether you're new to the cloud landscape or an experienced professional,
-Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt.
+our Architecture Center is designed to empower you in building robust, reliable, scalable, innovative and cost-efficient
+architectures on Open Telekom Cloud.
 
 .. directive_wrapper::
    :class: container-sbv