Organize the file structure within vendor-neutral

vendor-neutral/API-Security-Pattern.md

@@ -4,7 +4,7 @@
 
 APIs are the interface to external and internal users through which valuable business information is shared. Protecting these valuable information access is crucial in enterprise software design. 
 
-![API Security Pattern](API-Security-Pattern.png)
+![API Security Pattern](images/API-Security-Pattern.png)
 
 APIs provides you with the ability to compete in the digital marketplaces where brick and mortar stors are no longer dominating. The entire consumer and business landscape is becoming more and more digital savvy and it is essential for any enterprise regardless of their domain, to blend into this digital transformation. Companies from manufacturing, healthcare, automobile to consumer electronics are some of the examples which were not relying on digital business in the past but rapidly moving through digital journeys. 
 

vendor-neutral/Anti-Corruption-Layer-Pattern.md

@@ -15,7 +15,7 @@ Even though these systems are built in isolation, they can't operate in isolatio
 
 When one system needs to talk to another system and if these 2 systems are not compatible, you can use an intermediate layer which is capable of translating first systems communication to the protocol which is used by the second system and vice versa, this intermediate system is called as an Anti Corruption Layer since that layer helps to avoid the data corruption which would have happened otherwise. This is not a new concept and the traditionally, Enterprise Service Bus (ESB) has been used as this intermediate layer. 
 
-![Anti-Corruption-Layer-Pattern](Anti-Corruption-Layer-Pattern.png)
+![Anti-Corruption-Layer-Pattern](images/Anti-Corruption-Layer-Pattern.png)
 
 As depicted in the above figure, putting an intermediate anti corruption layer component only will not solve the modern enterprise requirements. Instead, various client applications require to access the capabilities of these heterogenous systems. API Management layer can help in exposing these internal complex systems to external clients through a standard based, managed interface. Sometimes, this same API management layer can act as the anti corruption layer. 
 

vendor-neutral/Ballerina-sidecar-pattern-microservices.md

@@ -19,13 +19,13 @@ There are leading technologies that have become the front runners in the SM race
 
 You can find a detailed article on service mesh sidecar pattern in the below github repository. The architecture is shown in below figure for reference.
 
-![Istio Service Mesh Pattern](Istio-Service-Mesh-Pattern.png)
+![Istio Service Mesh Pattern](images/Istio-Service-Mesh-Pattern.png)
 
 #### Sidecar 2.0 and the OPA
 
 Security is not an afterthought anymore. Microservices security is still at the early stages and people are trying out different approaches to provide security (authentication, authorization) for microservices which are written in polyglot fashion. The very first approach people tried for microservices security was to have a central component that provides authentication and authorization for microservices. This approach works without any issue. But the problem is that, it is more or less against the MSA strategy. Then people tried to use self-contained JWT for microservices security so that microservice itself can verify the tokens and make security-related decisions. Though this approach works fine and going along nicely with MSA, it has certain limitations on what level of security it can provide. That is where this Open Policy Agent (OPA) comes in handy where it provides a mechanism to delegate security-related functionality to an external agent (sidecar) which is running along with the microservice. OPA provides the ability to define policies with a language called REGO and the user and service-related data can be stored separately. You can find a detailed article on OPA can be used to secure microservices from the below link. The architecture presented in that article is shown below for reference.
 
-![Microservices Security with OPA](Micoservices-Security-Pattern-Policy-Based-OPA.png)
+![Microservices Security with OPA](images/Micoservices-Security-Pattern-Policy-Based-OPA.png)
 
 ### Ballerina sidecar pattern
 With the above 2 approaches, it is evident that taking certain functionality out of the microservice and managing them separately proves the real power of the distributed nature of microservices. One fear people have with this sort of explosion of microservices into sidecars is the management overhead. With proper tools to manage and monitor microservices, it won’t be an issue.
@@ -40,7 +40,7 @@ Ballerina is a new programming language developed by a team at WSO2 with the foc
 
 Instead of bringing third-party libraries into our core microservice, we can implement these functionalities as a separate sidecar and expose them over an efficient protocol (HTTP/2, gRPC) would make life easier and more manageable for developers. If they need to make a change to their data transformation, they can do that without modifying the core microservice. All the microservice advantages will be there with this approach. Let’s take a look at how this would work at a high level.
 
-![Ballerina sidecar pattern](Ballerina-sidecar-pattern-for-microservices.png)
+![Ballerina sidecar pattern](images/Ballerina-sidecar-pattern-for-microservices.png)
 
 As you can see in the above figure, there will be a “ballerina agent” which will run as a sidecar along with the main microservice. It will provide the capabilities which were mentioned above to the main microservice. Ballerina agent can have its own control plane with ballerina CLI to make changes to the ballerina sidecar. 
 

vendor-neutral/Centralized-Identity-Access-Management-Pattern.md

@@ -13,7 +13,7 @@ When it comes to security within an enterprise software system, there are 3 main
 Let’s try to understand how these requirements are fulfilled in most of the existing enterprise applications with the help of the below figure 1.
 
 
-![Figure 1: Application security implementation in a traditional enterprise](Brownfield-enterprise-security.png)
+![Figure 1: Application security implementation in a traditional enterprise](images/Brownfield-enterprise-security.png)
 Figure 1: Application security implementation in a traditional enterprise
 
 The different types of applications used in an enterprise can be divided into 3 main categories.
@@ -31,7 +31,7 @@ The above mentioned applications are developed by different vendors and they hav
 
 Authentication and authorization capabilities are required by each and every application running in your enterprise. Instead of implementing these capabilities at each application, these capabilities can be delegated to a specialized component. There are many Identity and Access Management (IAM) solutions available in the market. Some of them are open source and some are proprietary. Some are cloud based while others are on-premise based. This IAM component will do the heavy lifting of authentication, authorization as well as user management while allowing applications to implement more modern types of security methodologies which will improve the overall user experience while providing improved protection to the applications. Let’s see how the above architecture can be improved with an IAM component.
 
-![Figure 2: Centralized security architecture for enterprise](Centralized-Identity-Access-Management.png)
+![Figure 2: Centralized security architecture for enterprise](images/Centralized-Identity-Access-Management.png)
 Figure 2: Centralized security architecture for enterprise
 
 The above figure 2 contains many changes to the figure 1. Let’s try to identify these changes and what those changes mean to the overall system architecture.

vendor-neutral/Decentralized-Enterpise-Architecture-Pattern.md

@@ -7,7 +7,7 @@ Container based deployments are becoming more and more common within enterprise
 
 ### Architecture
 
-![Decentralized-Enterprise-Architecture-Pattern](Decentralized-Enterprise-Architecture-Pattern.png)
+![Decentralized-Enterprise-Architecture-Pattern](images/Decentralized-Enterprise-Architecture-Pattern.png)
 
 Let's start deciphering the above architecture diagram from the left hand side where we can find the most important entities for an enterprise which is the end users or the consumers who uses this nicely architected enterprise software system. These users can come from different channels like mobile, web and partner systems. To provide business functionality to these different channels, we can use REST APIs so that it is easier to implement from the client side. 
 

vendor-neutral/Enterprise-CICD-Pattern.md

@@ -34,7 +34,7 @@ Designing a continous integration continous deployment process for an enterprise
 
 A properly implemented CICD process should capture any of the above development activities as a system change and execute the entire CICD pipeline in such a scenario. The below figure depicts a process which can be used to implement a CICD process within your enterprise.
 
-![Enterprise-CICD-Pattern](Enterprise-CICD-Pattern.png)
+![Enterprise-CICD-Pattern](images/Enterprise-CICD-Pattern.png)
 
 As depicted in the above diagram, the sequence of events occurs when there is a development activity happens is mentioned below.
 

vendor-neutral/Enterprise-Software-Stack.md

@@ -24,7 +24,7 @@ Everything starts with the bits and bytes running on a set of electronic circuit
 The figure below showcases how each of these components are layered up.
 
 
-![Enterprise Software Stack](Enterprise-Software-Layered-Architecture.png)
+![Enterprise Software Stack](images/Enterprise-Software-Layered-Architecture.png)
 
 Figure 1: Enterprise software architecture stack
 

vendor-neutral/Event-Driven-Architecture-Kafka-Pattern.md

@@ -5,7 +5,7 @@ Apache Kafka has evolved as the defacto standard for building reliable event bas
 
 ## Architecture
 Kafka architecture is a simple yet powerful architecture which blends well within most of the existing architectures. 
-![Event-Driven-Architecture-Kafka-Pattern](Event-Driven-Architecture-Kafka-Pattern.png)
+![Event-Driven-Architecture-Kafka-Pattern](images/Event-Driven-Architecture-Kafka-Pattern.png)
 
 Kafka can run on a cluster of nodes spanning across multiple machines, multiple data centers, mutiple regions. Kafka has the capability to expand across geographically distributed resources. Once Kafka cluster is set up, external applications and systems can interact with the cluster through 4 standard APIs. 
 

vendor-neutral/Hybrid-API-Management-Pattern.md

@@ -24,7 +24,7 @@ The functional capabilities mentioned above can be run independently if the API
 
 The APIM platforms which are implemented in a modularized nature can be deployed in a hybrid architecture as depicted in the below figure.
 
-![Hybrid-API-Management-Pattern](Hybrid-API-Management-Pattern.png)
+![Hybrid-API-Management-Pattern](images/Hybrid-API-Management-Pattern.png)
 
 Enterprises are more and more moving towards cloud based infrastructure and having a fully managed software solution is preferred over on-premise software due to the ease of management. But it is not possible to go with full cloud solutions which are offered as SaaS solutions due to various regulatory requirements. In such a scenario, enterprises can use this hybrid api management pattern. In this model, API management functional components are deployed in 2 different environments. 
 

vendor-neutral/Hybrid-Integration-Pattern.md

@@ -10,7 +10,7 @@ Depending on the infrastructure a given software system is installed, we can div
 
 The integration platform we choose should be able to connect with both types of systems which are mentioned above. Such an integration platform is called as an hybrid integration platform (HIP). 
 
-![Hybrid-Integration-Pattern](Hybrid-Integration-Pattern.png)
+![Hybrid-Integration-Pattern](images/Hybrid-Integration-Pattern.png)
 
 
 As depicted in the above figure, hybrid integration platform should be capable of supporting functional requirements like

vendor-neutral/Istio-Service-Mesh-Pattern.md

@@ -23,7 +23,7 @@ Istio is a service mesh technology which supports both data plane and control pl
 ## Architecture
 Service Mesh architecture consists of side car proxies which are running by the side of each microservice. These proxies intercept all the requests coming into a microservice as well as going out of the same. 
 
-![Istio Service Mesh Pattern](Istio-Service-Mesh-Pattern.png)
+![Istio Service Mesh Pattern](images/Istio-Service-Mesh-Pattern.png)
 
 The above figure explains a lot of details in one picture. Some of the concepts used here are directly related to kubernetes. But you can use the same architecture with other supported platforms as well.
 

vendor-neutral/Kubernetes-Deployment-Pattern.md

@@ -29,7 +29,7 @@ A deployment is a configuration which can create a given set of kubernetes artef
 #### Namespace
 Namespaces are used to categorize different components which are related within kubernetes. As an example, different teams can utilize the same kubernetes cluster and run their own services by using their own namespaces without interfering with other teams.
 
-![Kubernetes Deployment Pattern](Kubernetes-Deployment-Pattern.png)
+![Kubernetes Deployment Pattern](images/Kubernetes-Deployment-Pattern.png)
 
 As depicted in the above figure, 
 

vendor-neutral/Layered-Architecture-Pattern.md

@@ -19,7 +19,7 @@ Enterprise software systems are typically running down under and most of the end
 
 Instead of building a one large monolith which has all these capabilities, the solutions architects over the time has identified that building a system with a layered architecture provides more flexibility when it comes to adding more and more features based on the business requirements. It also allows each layers to be independently scale, update and have their own technology which is best suited for the task. Building a layered architecture requires the designers of this architecture to understand what each layer does and how these layers are interact with each other so that those layers are loosely coupled. 
 
-![Layered Architecture Pattern](Layered-architecture-pattern.png)
+![Layered Architecture Pattern](images/Layered-architecture-pattern.png)
 
 #### Data Access Layer
 As depicted in the above picture, core system which is providing the data which is stored in databases is built through the data access layer. This layer will make sure that data is accessible over a more systematic mechanism like SOAP or REST by converting the complexities of database connection handling and transactional behaviours. 

vendor-neutral/Micro-Architecture-Pattern.md

@@ -13,7 +13,7 @@ All these architectures can be categorized under the common umbrella of "microse
 
 ### Micro Architecture
 
-![Micro Architecture Pattern](Micro-Architecture-Pattern.png)
+![Micro Architecture Pattern](images/Micro-Architecture-Pattern.png)
 
 As depicted in the above figure, micro architecture is independent from any type of infrastructure or vendor or technology. It is an open architecture which can be implemented using the best suitable technology or vendor for specific enterprise. Let’s understand the micro-architecture a bit more in respect to the above figure.
 

vendor-neutral/Microservices-Security-Pattern-Policy-Based.md

@@ -16,7 +16,7 @@ Even though the above mentioned centralized security architecture works fine wit
 ## Architecture
 The better approach to build a microservices architecture is to use containers, pods and service mesh so that you get the total control over the architecture. OPA is a component which you can easily bind in to this architecture by running it as a sidecar container along with the microservice. The below architecture diagram depicts a possible approach to implement a fully distributed policy based security for your microservices architecture.
 
-![Microservices-Security-OPA](Micoservices-Security-Pattern-Policy-Based-OPA.png)
+![Microservices-Security-OPA](images/Micoservices-Security-Pattern-Policy-Based-OPA.png)
 
 As depicted in the above figure, microservices A and B are deployed as respective services (kubernetes) which internally runs on a set of auto scalable pods (kubernetes). Each pod containes the following components running as separate containers. 
 

vendor-neutral/Multi-Cloud-Enterprise-Deployment-Pattern.md

@@ -19,7 +19,7 @@ Instead of running all your business functionality in a single cloud or on-premi
 ## Architecture
 Maintaining a multi cloud deployment is not a trivial task. You need to architect the deployment such that it is maintainable. Otherwise you will lose the purpose of setting up the multi cloud stretegy in the first place. Given below is a high level solutions architecture on how you can deploy your applications within a multi cloud environment.
 
-![Multi-Cloud-Enterprise-Deployment-Pattern](Multi-Cloud-Enterprise-Deployment-Pattern.png)
+![Multi-Cloud-Enterprise-Deployment-Pattern](images/Multi-Cloud-Enterprise-Deployment-Pattern.png)
 
 As depicted in the above figure, it is best to have a master deployment which acts as the leader of the overall deployment. This master deployment can be hosted on-premise or in a cloud infrastructure. In this master deployment, you should have the components like