rename and some changes to other screenshot (#1401)

* rename and some changes to other screenshot

* Update docs/development_suite/api-console/api-design/custom_microservice_get_started.md

Co-authored-by: Giovanna Monti <[email protected]>

* Update docs/development_suite/api-console/api-design/services.md

Co-authored-by: Giovanna Monti <[email protected]>

* Apply suggestions from code review

Co-authored-by: Giovanna Monti <[email protected]>

* improved docs

* Update docs/development_suite/deploy/overview.md

Co-authored-by: Giovanna Monti <[email protected]>

* fix

* Apply suggestions from code review

---------

Co-authored-by: Giovanna Monti <[email protected]>

docs/development_suite/api-console/api-design/api_key.md

@@ -19,7 +19,7 @@ In order to create a new API Key, open the dedicated section in the *Design area
 * **Active**: check the flag to activate the API Key, uncheck to deactivate.
 * **Description**: optional description of the API Key.
 
-![API Key creation](img/how_to_create_API_Keys.gif)
+![API Key creation](img/api-keys/overview.png)
 
 ## How to use an API Key
 

docs/development_suite/api-console/api-design/custom_microservice_get_started.md

@@ -29,7 +29,7 @@ In the Console, follow these steps:
 Now you have a customization interface and you can optionally customize some configuration if you want.
 
 :::note
-By default are enabled the standard kubernetes configurations, that provide the default configurations yml, but you can use your custom files by enable *Advanced configuration*
+By default the standard Kubernetes configurations are enabled, providing the default yaml configurations, but you can use your custom files by enabling *Raw manifest configuration mode*
 :::
 
 In the *Environment variable configuration section* you can customize the environment variables.

docs/development_suite/api-console/api-design/microservice-container-ports.md

@@ -23,8 +23,3 @@ The **Port name** is the identifier of the port, which can be used to refer to t
 The **Port** field contains the abstracted Kubernetes Service port; this is the port that must be used by other pods to access the Service. The default port value is 80.  
 The **Target Port** represents the port that the Kubernetes container accepts traffic on. Our default is 3000.  
 The **Protocol** field defines the network protocol used for the Service. The default is TCP but UDP is also supported.
-
-:::caution
-Remember that the port used to contact the probes is always (and only) the one indicated in the environment variable "HTTP_PORT". For more information on the [probes](/development_suite/api-console/api-design/microservice-runtime-resources.md#liveness--readiness-probes), click here.   
-For more information on environment variables, [click here](/development_suite/api-console/api-design/services.md#environment-variable-configuration).
-:::

docs/development_suite/api-console/api-design/proxy.md

@@ -14,12 +14,17 @@ Moreover being able to expose proxies on the same project domain, you'll be able
 ## Create a Proxy
 
 You can create a proxy selecting one of the available proxy inside the marketplace, or you can create a custom proxy by yourself.
-There are two types of proxy: External and Cross Project.
+There are two types of proxy: [**External**](#external-proxy) and [**Cross Project**](#cross-projects-proxy).
 
-An External Proxy allows you to contact endpoints outside your cluster.
-A Cross Projects proxy allows you to call a microservice in another namespace of the cluster.
+:::caution
+When you call an [external proxy](#external-proxy) any cookie/client-key are removed to avoid security issues. Instead, when you call a [cross projects proxy](#cross-projects-proxy) you will keep them.
+:::
 
-### Type External 
+### External Proxy
+
+:::info
+An External Proxy allows you to contact endpoints outside your cluster.
+:::
 
 In order to create a new external proxy, open the `Proxies` section in the *Design area*, select `Create new proxy` and choose `External` as `Type`. Then enter the following information:
 
@@ -43,9 +48,13 @@ For example, this feature is useful to call an external API passing an authoriza
 If the proxy host is unreachable you can see error logs in the API Gateway service pod.
 :::
 
-![external proxy creation](img/how_to_create_external_proxy.gif)
+![external proxy creation](img/proxies/external-proxy.png)
+
+### Cross-Projects Proxy
 
-### Type Cross Projects
+:::tip
+A Cross Projects proxy allows you to call a microservice in another namespace of the cluster.
+:::
 
 In order to create a new external proxy, open the `Proxies` in the *Design area*, select `Create new proxy` and choose `Cross Projects` as `Type`. Then enter the following information:
 
@@ -54,21 +63,15 @@ In order to create a new external proxy, open the `Proxies` in the *Design area*
 * **Port** (*required*): the port of the microservice
 * **Description**: optional description of the proxy
 
-![cross proxy creation](img/how_to_create_cross_proxy.gif)
-
-:::caution
-When you call an [external proxy](#create-a-new-external-proxy) any cookie/client-key are removed to avoid security issues. Instead, when you call a [cross projects proxy](#create-a-new-cross-projects-proxy) you will keep them.
-:::
+![cross proxy creation](img/proxies/cross-project-proxy.png)
 
 ## Expose a Proxy
 
 Before using a proxy you have to expose it by an [endpoint](/development_suite/api-console/api-design/endpoints.md#what-is-an-endpoint).
 
 The `Type` of the endpoint must be `External Proxy/Cross Projects proxy`. In the `Microservice` field select the name of the proxy you want to expose. The proxy endpoint will be exposed on [API gateway](/runtime_suite/api-gateway/10_overview.md).
 
-![Expose proxy](img/how_to_expose_proxy.gif)
-
-## How to call a Proxy
+### How to call a Proxy
 
 You can call a proxy endpoint making an HTTP request:
 
@@ -84,4 +87,3 @@ curl --request GET
 The proxy endpoints are exposed on the [API gateway](/runtime_suite/api-gateway/10_overview.md) so you can call them from your microservices making an HTTP request to the API Gateway: `http://api-gateway:8080/your-endpoint`.
 
 You can also use the [Mia-Platform Service Libraries](/libraries/mia-service-libraries.md) that help you to get a proxy towards the API Gateway.
-

docs/development_suite/api-console/api-design/services.md

@@ -105,16 +105,10 @@ For a step-by-step guide on creating a microservice using a Docker image, refer
 
 ## Manage Microservices
 
-For each microservice, Console allows to:
-
-* **Delete** the microservice: with the 'Delete' button present at the bottom of each microservice detail, you can delete it.
-
-:::warning
-Deleting a microservice, you are also deleting each associated endpoint.
-:::
+Microservices, and workloads in general, are the most important entity in your Project architecture as they hold the core business
+logics. In the Console you can manage all the configuration that you may need in your Project lifecycle: from configuration variables, files, exposed ports and many others.
 
 * **View Repository**: this button, present only in microservices created from Examples and Templates, allows you to go directly to your git repository from the Console.
-
 * **Clone**: this button, present only in microservices created from Examples and Templates, enables to clone code repository directly from Console. The code repository can be copied with both ssh and https.
 
 The detail of each microservice is divided in the following sections:
@@ -451,42 +445,38 @@ Finally, you should create a new environment variable passing the following data
 
 Once saved all these changes, you should see the volume correctly mounted in the generated deployment file.
 
-### Advanced Configuration
-
-In this section, you can write your advanced configurations by filling the files:
-
-* *File Deployment*: defines how the pod in Kubernetes is built (container, probes, ports).
+## Raw Manifest configuration
 
-* *File Service*: defines how to contact your deployment.
+If, for any reason, the Console lacks some functionality that you may need, you can switch to the Raw Manifest configuration mode and write your own kubernetes manifest files:
 
+* *Deployment file*: defines how the pod in Kubernetes is built (container, probes, ports).
+* *Service file*: defines how to contact your deployment.
 * *Configmaps*: configuration files that are mounted on the containers.
 
-:::info
-You have to use Advanced Configuration if you want to write deployment files with more than one container.
-:::
-
- By switching from standard to advanced configuration (and vice versa), Console allows you to customize your Kubernetes files:
-
-* **To switch from standard to advanced configuration**, you have to flag the option 'I want to write custom k8s files for this microservice'. Enabling advanced configuration, you can customize your kubernetes files.
+### Enabling raw manifest configuration mode
 
-    ![service-to-advanced](img/service-to-advanced.png)
+You can enable the **Raw Manifest mode** in the Advanced tab of your Microservice configuration page
 
-    The advanced section allows you to configure service.yml and deployment.yml (*File Service* and *File Deployment*). You can also add configmaps by filling the *File path to create* and the *File name to create*.  By pushing the delete button, you can completely remove your advanced configurations.
+![service-to-advanced](img/services/service-to-advanced.png)
 
 :::warning
-By switching from standard to advanced configuration, you will lose every standard configuration set before.
+By switching from standard to raw manifest configuration mode, you will lose every standard configuration set before.
 :::
 
-* **To switch from advanced to standard configuration**, you have to de-flag the option 'I want to write custom k8s files for this microservice'. Coming back to standard configuration, you will no longer be able to customize your K8s files.
+### Enable standard managed mode
 
-    ![service-to-standard](img/service-to-standard.png)
+in the Advanced tab, you can also **switch back** from raw manifest mode to the standard Console-managed configuration.
 
-    If you configure your advanced service, deployment and configmaps files, when you come back to standard configuration, you can see your custom configuration files already filled with the environment variables. In other words, you can come back to standard configuration without loosing your advanced settings like your docker image, your variables and your configmaps.
+![service-to-standard](img/services/service-to-standard.png)
 
-:::info
-We suggest you to convert in a standard mode all your microservices in order to achieve a better governance of your microservices.
+:::tip
+You can convert to standard configuration without losing your advanced settings like your docker image, variables, ConfigMaps and other configurations.
 :::
 
+## Deleting a service
+
+To delete a microservice head to the Advanced tab and use the **Delete** button.
+
 :::warning
-By switching from advanced to standard configuration, you are loosing all the containers, except for the first one that you have inserted. The docker image, all the environment variables and all the configmaps are preserved. Other advanced configurations will be lost.
+By deleting a microservice, you are also deleting each associated depency (e.g. endpoints, decorators, etc.)
 :::

docs/development_suite/deploy/overview.md

@@ -104,7 +104,7 @@ It is important to **save** the configuration at least one time after the featur
 :::
 
 :::info
-In order to avoid unnecessary deployments, services created using an **advanced configuration** should be manually modified by **removing all the old interpolated annotations**.
+In order to avoid unnecessary deployments, services created using a **raw manifest configuration** should be manually modified by **removing all the old interpolated annotations**.
 :::
 
 When deploying for the first time using this feature, some services might not be able to collect all the necessary information to show the effective deployment strategy adopted. However, service that do not show actual differences on the cluster will not be deployed.

docs/development_suite/governance/design-overview.md

@@ -16,6 +16,7 @@ In the Design Overview you can aggregate Resources from all Projects across the
 ### Homepage
 
 The Homepage tab contains the list of resource views. They can be of two types:
+
 * *Default Views* - A predefined set of read-only views configured at Company level. All Company users can access these views, modifications (edit/delete) are not allowed, default filters and thresholds are configured into the Design Overview backend service;
 * *Public Views* - A set of user-defined editable views configured at Company level. All Company users can access these views, modifications (edit/delete) are allowed only for Project Administrator and/or Company Owner roles.
 
@@ -79,6 +80,7 @@ An example is in the following picture.
 The Microservices Overview provides the user with a graphical cross-project overview of all the Microservices.
 
 The Microservices Overview collects data on the project configuration and creates a table presenting information on all the Microservices, where each row shows:
+
 * *Name*: Name of the Microservice.
 * *Project*: Project of the Microservice.
 * *Type*: Type of the Microservice.
@@ -89,7 +91,7 @@ The Microservices Overview collects data on the project configuration and create
 * *Memory Request*: Memory Request of the Microservice.
 * *Memory Limit*: Memory Limit of the Microservice.
 * *Log Parser*: Log Parser implementation of the Microservice.
-* *Advanced Configuration*: Advanced Configuration flag of the Microservice.
+* *Advanced Configuration*: Whether the Microservice is using raw manifest configuration.
 
 An example is in the following picture.