[skip ci] Architecture details / FAQ

Author: Chris Wiechmann

README.md

@@ -69,7 +69,7 @@ The overall architecture this project provides looks like this:
 With that architecture it is possible to collect data from API-Gateways running all over the world into a centralized Elasticsearch instance to have it available with the best possible performance indendent from the network performance.  
 It also helps, when running the Axway API-Gateway in Docker-Orchestration-Environment where containers are started and stopped as it avoids to loose data, when an API-Gateway container is stopped.  
 
-Click [here](https://github.com/Axway-API-Management-Plus/apigateway-openlogging-elk/tree/develop/imgs/architecture-examples) to find more detailed architecture examples. *Currently classic deployment only - Will be extended based on requirements*
+Click [here](https://github.com/Axway-API-Management-Plus/apigateway-openlogging-elk/tree/develop/architecture) to find more detailed architecture examples and explanations.  
 
 ### How it works - Overview 
 

architecture/README.md

@@ -1,3 +1,8 @@
+# Architecture overview
+
+The solution was designed to scale with growing requirements. Therefore, each component (Logstash, API-Builder4Elastic, etc.) can be scaled in isolation. For example, if more Logstash capacity is needed, but no additional API-Builder4Elastic, Logstash can be scaled individually. This is the main reason why the solution is deployed based on Docker containers.
+Another reason is to make setup and update as easy as possible. In the medium term, this should also be possible based on HELM charts for Kubernetes & OpenShift.
+
 # Architecture examples
 
 On this page, which is currently under construction, we will present various architecture deployment options in detail. 
@@ -9,3 +14,22 @@ For each architecture example there will be corresponding detailed information.
 | Name       | Description               |  
 | :---          | :---                 | 
 | [AWS EC2 HA-Setup 1 Region / 2 Zones](aws-ec2-ha-one-region-2-zones)|Example deployment architecture based on classic AWS-EC2 instances for a high availability solution in an AWS region with 2 availability zones.|
+| [Classic-Setup with native Filebeat](classic-simple-filebeat-native)|Very simple example of a classically deployed API gateway (3 nodes).|
+
+# Architecture FAQ
+
+## Can we support the solution in non-docker mode? 
+
+No, the solution is designed to run based on Docker containers. It is also planned that the solution can be deployed on Kubernetes/OpenShift using HELM charts. A non-Docker mode would be the opposite direction.
+
+## Can we get rid of API Builder and instead leverage policies in API Gateway/Manager for API detail lookup and other requirements?
+
+No, a large part of the logic of the solution is in the API Builder application. Implementing this in policies might be possible, but managing & updating the individual customer installations would be very time-consuming and error-prone. So the customer has to reference the appropriate API builder image and you know by version exactly what code base the customer is running.
+
+## Can we minimize the number of dependencies? Elastic Search, Logstash, Kibana and FileBeat agents are mandatory. Can API Builder and MemCache be made optional?
+
+No, API-Builder is a substantial part of the solution. It’s exposing the fully tested Traffic-Monitor API, manages Elasticsearch, provides Lookup-APIs. Everything fully automated tested.
+
+## Is it possible to use another caching solution than Memcached?
+
+No, that is not possible. Logstash uses a filter to communicate with Memcached and is integrated into the Logstash pipelines. Only the interaction of the pipelines & Memcached has been tested and is thus supported.