├── .github └── ISSUE_TEMPLATE │ ├── bug_report.md │ └── feature_request.md ├── .gitignore ├── CODE_OF_CONDUCT.md ├── CONTRIBUTING.md ├── LICENSE ├── README.md ├── _config.yml ├── industry-specific ├── Automotive-Industry-Information-Technology-Reference-Architecture.md ├── Digital-Health-Platform-Open-Source-Architecture.md ├── Effective-ground-transportation-architecture-pattern.md ├── Energy-Information-Technology-Reference-Architecture.md ├── Higher-Education-Information-Technology-Architecture.md ├── Hospitality-Platform-Reference-Architecture-WSO2.md ├── README.md ├── Telecommunication-reference-architecture-pattern.md ├── future-retail-a-business-and-technical-architecture.md └── images │ ├── Digital-Health-Platform-2-Hospital-ecosystem (1).png │ ├── Digital-Health-Platform-3-Solutions-Architecture.png │ ├── Digital-Health-Platform-4-OpenSource-deployment.png │ ├── Digital-Health-Platform-Information-Architecture (1).png │ ├── Digital-Healthcare-Platform-1-Stakeholders.png │ ├── Open-Hospitality-Platform-0.png │ ├── Open-Hospitality-Platform-1.png │ ├── Open-Hospitality-Platform-2-a.png │ ├── Open-Hospitality-Platform-2.png │ ├── automotive-industry-business-architecture.png │ ├── automotive-industry-solution-architecture.png │ ├── education-industry-existing-architecture.png │ ├── education-industry-transformation-phase-1.png │ ├── education-industry-transformation-phase-2.png │ ├── education-industry-transformation-phase-3.png │ ├── energy-industry-ra-conceptual-model.JPG │ ├── energy-industry-ra-ibm-safe-model.png │ ├── energy-industry-ra-smart-grid.png │ ├── energy-industry-ra-solution-architecture.png │ ├── ground-transportation-figure-1.jpeg │ ├── ground-transportation-reference-architecture.png │ ├── ground-transportation-reference-implementation-wso2.png │ ├── ground-transportation-stakeholders.png │ ├── ground-transportation-technical-architecture.png │ ├── retail-fig1.png │ ├── retail-fig2-accenture.png │ ├── retail-fig3-BA.png │ ├── retail-fig4-apparc.png │ ├── retail-fig5-ref_arc.png │ ├── retail-fig6-swarc.png │ ├── telecommunication-information-architecture.png │ ├── telecommunication-information-reference-architecture.png │ ├── telecommunication-information-wso2-reference.png │ ├── telecommunication-network.png │ ├── telecommunication-openapi-architecture.png │ └── telecommunication-stakeholders.png ├── technology-selection-guides ├── API-Management-Platform-selection-guide.md ├── Integration-Platform-selection-guide.md ├── README.md └── images │ ├── api-platform-selection-1.png │ ├── api-platform-selection-2.png │ ├── api-platform-selection-3.png │ ├── api-platform-selection-4.png │ ├── integration-platform-selection-0.png │ ├── integration-platform-selection-1.png │ ├── integration-platform-selection-2.png │ └── integration-platform-selection-3.png ├── vendor-neutral ├── API-Security-Pattern.md ├── API-led-Connectivity-Pattern.md ├── Anti-Corruption-Layer-Pattern.md ├── Ballerina-sidecar-pattern-microservices.md ├── Centralized-Identity-Access-Management-Pattern.md ├── Cloud-Migration-Strangler-Pattern.md ├── Decentralized-Enterpise-Architecture-Pattern.md ├── Enterprise-CICD-Pattern.md ├── Enterprise-Software-Stack.md ├── Event-Driven-Architecture-Kafka-Pattern.md ├── Event-Driven-Architecture-Pattern.md ├── GraphQL-Pattern.md ├── Hybrid-API-Management-Pattern.md ├── Hybrid-Integration-Pattern.md ├── Innovation-Driven-Enterprise-Platform-Architecture.md ├── Introduction-to-Change-Data-Capture.md ├── Istio-Service-Mesh-Pattern.md ├── Kubernetes-Deployment-Pattern.md ├── Layered-Architecture-Pattern.md ├── Micro-Architecture-Pattern.md ├── Microservices-Governance-And-API-Management.md ├── Microservices-Security-Pattern-Policy-Based.md ├── Microservices-with-NATS-messaging.md ├── Microservices-without-service-mesh-pattern.md ├── Multi-Cloud-Enterprise-Deployment-Pattern.md ├── OpenAPI-Based-Digital-Transformation-Pattern.md ├── README.md ├── SOA-governance-to-API-management-pattern.md └── images │ ├── API-Security-Pattern.png │ ├── API-led-Business-Transformation-1.png │ ├── API-led-Business-Transformation-2.png │ ├── Anti-Corruption-Layer-Pattern.png │ ├── Ballerina-sidecar-pattern-for-microservices.png │ ├── Brownfield-enterprise-security.png │ ├── Centralized-Identity-Access-Management.png │ ├── Decentralized-Enterprise-Architecture-Pattern.png │ ├── Enterprise-CICD-Pattern.png │ ├── Enterprise-Software-Layered-Architecture.png │ ├── Event-Driven-Architecture-Kafka-Pattern.png │ ├── Event-Driven-Architecture-Pattern.png │ ├── GraphQL-Pattern-1-dataservice.png │ ├── GraphQL-Pattern-2-integration-hub.png │ ├── GraphQL-Pattern-3-hybrid-integration.png │ ├── GraphQL-Pattern-4-API-protected.png │ ├── GraphQL-Pattern-5-Operation-protected.png │ ├── Hybrid-API-Management-Pattern.png │ ├── Hybrid-Integration-Pattern.png │ ├── Istio-Service-Mesh-Pattern.png │ ├── Kubernetes-Deployment-Pattern.png │ ├── Layered-architecture-pattern.png │ ├── Micoservices-Security-Pattern-Policy-Based-OPA.png │ ├── Micro-Architecture-Pattern.png │ ├── Migrating-architecture-with-strangler-pattern-0.png │ ├── Migrating-architecture-with-strangler-pattern-1.png │ ├── Migrating-architecture-with-strangler-pattern-2.png │ ├── Multi-Cloud-Enterprise-Deployment-Pattern.png │ ├── OpenAPI-DT-Pattern-img1.png │ ├── OpenAPI-DT-Pattern-img2.png │ ├── OpenAPI-DT-Pattern-img3.png │ ├── cdc-architecture.png │ ├── cdc-conceptual-view.png │ ├── cdc-debezium-architecture.png │ ├── cdc-intro.png │ ├── cdc-maxwell-event-format.png │ ├── four-pillars-drive-innovation-in-enterprise-platforms.png │ ├── microservices-governance-0.png │ ├── microservices-governance-1.png │ ├── microservices-governance-2.png │ ├── microservices-governance-3.png │ ├── microservices-governance-4.png │ ├── microservices-governance-5.png │ ├── microservices-governance-7.png │ ├── microservices-governance-8.png │ ├── microservices-governance-and-api-management.png │ ├── microservices-governance-ibm.jpeg │ ├── microservices-mesh.png │ ├── microservices-with-nats.png │ ├── microservices-wo-sm-1.png │ ├── microservices-wo-sm-2.png │ ├── nats-performance.png │ ├── nats-pub-sub.png │ ├── nats-queue-groups.png │ ├── nats-request-reply.png │ ├── nats-subject-based-messaging.png │ ├── soa-governance-0.png │ ├── soa-governance-1.png │ ├── soa-governance-2.png │ ├── soa-governance-3.png │ └── soa-governance-4.png └── vendor-specific ├── aws ├── AWS-Networking-In-a-Nutshell.md ├── README.md └── images │ ├── AWS-Networking-Services.png │ └── AWS-Networking-in-a-nutshell.png ├── azure ├── Azure-Networking-Services-in-a-nutshell.md ├── README.md └── images │ └── Azure-Networking-in-a-Nutshell.png ├── gcp └── README.md ├── mulesoft └── README.md ├── pivotal ├── Enterprise-Application-Workload.png ├── Pivotal-Cloud-Foundry-High-Level-Architecture.png ├── Pivotal-Cloud-Foundry-Pattern.md ├── README.md ├── pcf-commercialization.png └── pivotal-cloud-foundry-architecture-detailed.png ├── redhat └── README.md └── wso2 ├── README.md ├── images ├── API-Store-integrate-with-3rd-party-KM.png ├── Cloud-Application-Security-Pattern.png ├── Microgateway-Pattern1-Decentralized-Gateway.png ├── Microgateway-Pattern2-Locked-Down-Gateway.png ├── Microgateway-Pattern3-Seasonal-Gateway.png ├── Microgateway-Pattern4-Multi-Data-Center-Gateway.png ├── Microgateway-Pattern5-Service-Mesh-Sidecar-Gateway.png ├── Microgateway-Pattern6-Hybrid-API-Gateway.png ├── Modern-Brown-Field-Enterprise-WSO2.png ├── Security-Federation-Pattern.png ├── Sync-Async-Eventing-Hybrid-Integration-WSO2-EI7.png ├── Sync-Async-Hybrid-Integration-WSO2-EI7.png ├── Synchronous-Hybrid-Integration-WSO2-EI7.png ├── WSO2-APIM-Multi-Cloud-Deployment-Pattern.png ├── WSO2APIM-3rdParty-Authorization-Server-Integration.png ├── bring-your-own-api-architecture.png ├── building-and-api-strategy-using-an-enterprise-api-marketplace-figure-3.png ├── health │ ├── Figure_1-FHIT-API-Portal.png │ ├── Figure_2-Autogen-Proj-Download.png │ ├── Figure_3-Integration-Studio.png │ ├── Figure_4-Visual-DM.png │ ├── Figure_5-Pub-Portal.png │ ├── Figure_6-API-LM.png │ ├── Figure_7-DevPortal.png │ └── Figure_8-Consent-Mgt.png ├── modernize-legacy-platforms-with-wso2-0.png ├── modernize-legacy-platforms-with-wso2-1.png ├── modernize-legacy-platforms-with-wso2-2.png ├── modernize-legacy-platforms-with-wso2-3.png ├── modernize-legacy-platforms-with-wso2-4.png ├── real-time-event-based-information-system-architecture-wso2-broker-details.png ├── real-time-event-based-information-system-architecture-wso2-broker.png ├── real-time-event-based-information-system-architecture-wso2-details.png ├── real-time-event-based-information-system-architecture-wso2.png ├── real-time-event-based-information-system-architecture.png ├── reusable-api-platform-wso2-apim.png ├── wso2-apim-ei-deployment-aws.png ├── wso2-apim-ei-deployment-azure.png ├── wso2-apim-websocket-create-api.png └── wso2-apim-websocket-details.png └── patterns ├── API-manager-3rd-party-KM-integration.md ├── APIM-EI-Deployment-Reference-Architecture-AWS.md ├── APIM-EI-Deployment-Reference-Architecture-Azure.md ├── Cloud-Application-Security-Pattern.md ├── Event-Driven-Real-Time-Information-System-Kafka-WSO2.md ├── Legacy-Platform-Modernization-with-WSO2.md ├── Microgateway-Pattern1-Decentralized-Gateway.md ├── Microgateway-Pattern2-Locked-Down-Gateway.md ├── Microgateway-Pattern3-Seasonal-Gateway.md ├── Microgateway-Pattern4-Multi-Data-Center-Gateway.md ├── Microgateway-Pattern5-Service-Mesh-Sidecar-Gateway.md ├── Microgateway-Pattern6-Hybrid-API-Gateway.md ├── Modern-Brown-Field-Enterprise-WSO2.md ├── Open-Health-Savings.md ├── Reusable-API-Platform-WSO2-API-Manager-Pattern.md ├── Security-Federation-Pattern.md └── WSO2-EI7-Solution-patterns.md /.github/ISSUE_TEMPLATE/bug_report.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Bug report 3 | about: Create a report to help us improve 4 | title: '' 5 | labels: '' 6 | assignees: '' 7 | 8 | --- 9 | 10 | **Describe the bug** 11 | A clear and concise description of what the bug is. 12 | 13 | **To Reproduce** 14 | Steps to reproduce the behavior: 15 | 1. Go to '...' 16 | 2. Click on '....' 17 | 3. Scroll down to '....' 18 | 4. See error 19 | 20 | **Expected behavior** 21 | A clear and concise description of what you expected to happen. 22 | 23 | **Screenshots** 24 | If applicable, add screenshots to help explain your problem. 25 | 26 | **Desktop (please complete the following information):** 27 | - OS: [e.g. iOS] 28 | - Browser [e.g. chrome, safari] 29 | - Version [e.g. 22] 30 | 31 | **Smartphone (please complete the following information):** 32 | - Device: [e.g. iPhone6] 33 | - OS: [e.g. iOS8.1] 34 | - Browser [e.g. stock browser, safari] 35 | - Version [e.g. 22] 36 | 37 | **Additional context** 38 | Add any other context about the problem here. 39 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/feature_request.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Feature request 3 | about: Suggest an idea for this project 4 | title: '' 5 | labels: '' 6 | assignees: '' 7 | 8 | --- 9 | 10 | **Is your feature request related to a problem? Please describe.** 11 | A clear and concise description of what the problem is. Ex. I'm always frustrated when [...] 12 | 13 | **Describe the solution you'd like** 14 | A clear and concise description of what you want to happen. 15 | 16 | **Describe alternatives you've considered** 17 | A clear and concise description of any alternative solutions or features you've considered. 18 | 19 | **Additional context** 20 | Add any other context or screenshots about the feature request here. 21 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | 2 | # General 3 | .DS_Store 4 | .AppleDouble 5 | .LSOverride 6 | 7 | # Icon must end with two \r 8 | Icon 9 | 10 | # Thumbnails 11 | ._* 12 | 13 | # Files that might appear in the root of a volume 14 | .DocumentRevisions-V100 15 | .fseventsd 16 | .Spotlight-V100 17 | .TemporaryItems 18 | .Trashes 19 | .VolumeIcon.icns 20 | .com.apple.timemachine.donotpresent 21 | 22 | # Directories potentially created on remote AFP share 23 | .AppleDB 24 | .AppleDesktop 25 | Network Trash Folder 26 | Temporary Items 27 | .apdisk 28 | -------------------------------------------------------------------------------- /CODE_OF_CONDUCT.md: -------------------------------------------------------------------------------- 1 | # Contributor Covenant Code of Conduct 2 | 3 | ## Our Pledge 4 | 5 | In the interest of fostering an open and welcoming environment, we as 6 | contributors and maintainers pledge to making participation in our project and 7 | our community a harassment-free experience for everyone, regardless of age, body 8 | size, disability, ethnicity, sex characteristics, gender identity and expression, 9 | level of experience, education, socio-economic status, nationality, personal 10 | appearance, race, religion, or sexual identity and orientation. 11 | 12 | ## Our Standards 13 | 14 | Examples of behavior that contributes to creating a positive environment 15 | include: 16 | 17 | * Using welcoming and inclusive language 18 | * Being respectful of differing viewpoints and experiences 19 | * Gracefully accepting constructive criticism 20 | * Focusing on what is best for the community 21 | * Showing empathy towards other community members 22 | 23 | Examples of unacceptable behavior by participants include: 24 | 25 | * The use of sexualized language or imagery and unwelcome sexual attention or 26 | advances 27 | * Trolling, insulting/derogatory comments, and personal or political attacks 28 | * Public or private harassment 29 | * Publishing others' private information, such as a physical or electronic 30 | address, without explicit permission 31 | * Other conduct which could reasonably be considered inappropriate in a 32 | professional setting 33 | 34 | ## Our Responsibilities 35 | 36 | Project maintainers are responsible for clarifying the standards of acceptable 37 | behavior and are expected to take appropriate and fair corrective action in 38 | response to any instances of unacceptable behavior. 39 | 40 | Project maintainers have the right and responsibility to remove, edit, or 41 | reject comments, commits, code, wiki edits, issues, and other contributions 42 | that are not aligned to this Code of Conduct, or to ban temporarily or 43 | permanently any contributor for other behaviors that they deem inappropriate, 44 | threatening, offensive, or harmful. 45 | 46 | ## Scope 47 | 48 | This Code of Conduct applies both within project spaces and in public spaces 49 | when an individual is representing the project or its community. Examples of 50 | representing a project or community include using an official project e-mail 51 | address, posting via an official social media account, or acting as an appointed 52 | representative at an online or offline event. Representation of a project may be 53 | further defined and clarified by project maintainers. 54 | 55 | ## Enforcement 56 | 57 | Instances of abusive, harassing, or otherwise unacceptable behavior may be 58 | reported by contacting the project team at chanaka.leadership@gmail.com. All 59 | complaints will be reviewed and investigated and will result in a response that 60 | is deemed necessary and appropriate to the circumstances. The project team is 61 | obligated to maintain confidentiality with regard to the reporter of an incident. 62 | Further details of specific enforcement policies may be posted separately. 63 | 64 | Project maintainers who do not follow or enforce the Code of Conduct in good 65 | faith may face temporary or permanent repercussions as determined by other 66 | members of the project's leadership. 67 | 68 | ## Attribution 69 | 70 | This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, 71 | available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html 72 | 73 | [homepage]: https://www.contributor-covenant.org 74 | 75 | For answers to common questions about this code of conduct, see 76 | https://www.contributor-covenant.org/faq 77 | -------------------------------------------------------------------------------- /CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | ## What this repository is? 2 | 3 | This repository does not contain new architecture styles. Rather it contains common solutions architecture patterns found in enterprise software systems. If you have a solutions architecture pattern which you think as important for others and can share, you can contribute to this repository. 4 | 5 | ## Few ideas on contributions 6 | 7 | - It would be nice if you could draw a diagram which explains the architecture since that diagram can speaks for 1000 words you write in the description 8 | - Having a description would make it ever better 9 | - If you are looking for a certain solutions architecture pattern for your project, create an issue so that people who has the knowledge on that subject can send us a PR 10 | 11 | ## Contact us 12 | chanaka.leadership@gmail.com 13 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Solution Architecture Patterns 2 | This repository contains solution architecture patterns which can be reused to build enterprise software systems. Some of these patterns are well established in the industry and some of them are evolving patterns while there is another set which is at conceptual level. 3 | 4 | We have released a book to explain the topics discussed in this repository in a greater detail. You can find the link to the book below. 5 | **[Solution Architecture Patterns for Enterprise](https://a.co/d/8cZ5SHp)** 6 | 7 | 8 | ## Vendor neutral architecture patterns 9 | 10 | - API Security pattern 11 | [API Security Pattern](vendor-neutral/API-Security-Pattern.md) 12 | 13 | - API-led Connectivity pattern 14 | [API-led Connectivity pattern](vendor-neutral/API-led-Connectivity-Pattern.md) 15 | 16 | - Anti Corruption Layer pattern 17 | [Anti Corruption Layer Pattern](vendor-neutral/Anti-Corruption-Layer-Pattern.md) 18 | 19 | - Ballerina sidecar pattern 20 | [Ballerina sidecar pattern](vendor-neutral/Ballerina-sidecar-pattern-microservices.md) 21 | 22 | - Centralized Identity and Access Management Pattern 23 | [Centralized Identity and Access Management Pattern](vendor-neutral/Centralized-Identity-Access-Management-Pattern.md) 24 | 25 | - Change Data Capture Pattern [Change Data Capture Pattern](vendor-neutral/Introduction-to-Change-Data-Capture.md) 26 | 27 | - Cloud Migration with Strangler Pattern 28 | [Cloud Migration with Strangler Pattern](vendor-neutral/Cloud-Migration-Strangler-Pattern.md) 29 | 30 | - Decentralized Enterprise Architecture pattern 31 | [Decentralized Enterprise Architecture Pattern](vendor-neutral/Decentralized-Enterpise-Architecture-Pattern.md) 32 | 33 | - Enterprise CICD pattern 34 | [Enterprise CICD Pattern](vendor-neutral/Enterprise-CICD-Pattern.md) 35 | 36 | - Enterprise Software Stack 37 | [Enterprise Software Stack](vendor-neutral/Enterprise-Software-Stack.md) 38 | 39 | - Event Driven Architecture Kafka Pattern 40 | [Event Driven Architecture Kafka Pattern](vendor-neutral/Event-Driven-Architecture-Kafka-Pattern.md) 41 | 42 | - GraphQL enterprise architecture patterns 43 | [GraphQL Pattern](vendor-neutral/GraphQL-Pattern.md) 44 | 45 | - Hybrid API Management pattern 46 | [Hybrid API Management Pattern](vendor-neutral/Hybrid-API-Management-Pattern.md) 47 | 48 | - Hybrid Integration pattern 49 | [Hybrid Integration Pattern](vendor-neutral/Hybrid-Integration-Pattern.md) 50 | 51 | - Istio Service Mesh pattern 52 | [Istio Service Mesh Pattern](vendor-neutral/Istio-Service-Mesh-Pattern.md) 53 | 54 | - Kubernetes Deployment pattern 55 | [Kubernetes Deployment Pattern](vendor-neutral/Kubernetes-Deployment-Pattern.md) 56 | 57 | - Layered architecture pattern 58 | [Layered Architecture Pattern](vendor-neutral/Layered-Architecture-Pattern.md) 59 | 60 | - Micro architecture pattern 61 | [Micro Architecture Pattern](vendor-neutral/Micro-Architecture-Pattern.md) 62 | 63 | - Microservices with NATS messaging 64 | [Microservices with NATS messaging](vendor-neutral/Microservices-with-NATS-messaging.md) 65 | 66 | - Microservices without Service Mesh pattern 67 | [Microservices without Service Mesh](vendor-neutral/Microservices-without-service-mesh-pattern.md) 68 | 69 | - Microservices Security Pattern - Policy based 70 | [Microservices Security Pattern - Policy based](vendor-neutral/Microservices-Security-Pattern-Policy-Based.md) 71 | 72 | - Multi Cloud Enterprise Deployment pattern 73 | [Multi Cloud Enterprise Deployment Pattern](vendor-neutral/Multi-Cloud-Enterprise-Deployment-Pattern.md) 74 | 75 | - OpenAPI Based Digital Transformation pattern 76 | [OpenAPI Based Digital Transformation Pattern](vendor-neutral/OpenAPI-Based-Digital-Transformation-Pattern.md) 77 | 78 | - SOA Governance to API Management Pattern 79 | [SOA Governance to API Management Pattern](vendor-neutral/SOA-governance-to-API-management-pattern.md) 80 | 81 | - Microservices Governance and API Management Pattern 82 | [Microservices Governance and API Management Pattern](vendor-neutral/Microservices-Governance-And-API-Management.md) 83 | 84 | - Innovation Driven Enterprise Platform Architecture 85 | [Innovation Driven Enterprise Platform Architecture](vendor-neutral/Innovation-Driven-Enterprise-Platform-Architecture.md) 86 | 87 | ## Industry specific architecture patterns 88 | These patterns are specific to a business domain or an industry. Most of these patterns can be considered as reference archtiectures. 89 | 90 | - Telecommunication Reference Architecture 91 | [Telecommunication Reference Architecture](industry-specific/Telecommunication-reference-architecture-pattern.md) 92 | 93 | - Transportation Reference Architecture 94 | [Transportation Reference Architecture](industry-specific/Effective-ground-transportation-architecture-pattern.md) 95 | 96 | - Digital Health Platform Open Source Architecture 97 | [Digital Health Platform Open Source Architecture](industry-specific/Digital-Health-Platform-Open-Source-Architecture.md) 98 | 99 | - Hospitality Platform Reference Architecture 100 | [Hospitality Platform Reference Architecture](industry-specific/Hospitality-Platform-Reference-Architecture-WSO2.md) 101 | 102 | - Retail Platform Reference Architecture 103 | [Retail Platform Reference Architecture](industry-specific/future-retail-a-business-and-technical-architecture.md) 104 | 105 | - Higher Education Information Technology Architecture [Higher Education Information Technology Architecture](industry-specific/Higher-Education-Information-Technology-Architecture.md) 106 | 107 | - Energy industry Information Technology Reference Architecture [Energy industry Information Technology Reference Architecture](industry-specific/Energy-Information-Technology-Reference-Architecture.md) 108 | 109 | - Automotive industry Information Technology Reference Architecture [Automotive industry Information Technology Reference Architecture](industry-specific/Automotive-Industry-Information-Technology-Reference-Architecture.md) 110 | 111 | 112 | ## Vendor specific architecture patterns 113 | These patterns are specific to a vendor and some of the terminology used in these diagrams may not be common across other vendors. 114 | 115 | - Amazon Web Services (AWS) [Amazon Web Services (AWS)](vendor-specific/aws) 116 | 117 | - Microsoft Azure [Microsoft Azure](vendor-specific/azure) 118 | 119 | - Google Cloud Platform (GCP)[Google Cloud Platform (GCP)](vendor-specific/gcp) 120 | 121 | - Mulesoft [Mulesoft](vendor-specific/mulesoft) 122 | 123 | - Pivotal [Pivotal](vendor-specific/pivotal) 124 | 125 | - RedHat [RedHat](vendor-specific/redhat) 126 | 127 | - WSO2 [WSO2](vendor-specific/wso2) 128 | 129 | ## Technology selection guides 130 | - API Management platform selection guide [API Management platform selection guide](technology-selection-guides/API-Management-Platform-selection-guide.md) 131 | - Integration platform selection guide [Integration platform selection guide](technology-selection-guides/Integration-Platform-selection-guide.md) 132 | 133 | ## Related architecture resources 134 | - Technology reference architecture [Technology reference architecture](https://github.com/wso2/reference-architecture) 135 | - Design patterns for humans [Design patterns for humans](https://github.com/kamranahmedse/design-patterns-for-humans) 136 | - Awesome scalability [Awesome scalability](https://github.com/binhnguyennus/awesome-scalability) 137 | - Awesome design patterns [Awesome design patterns](https://github.com/DovAmir/awesome-design-patterns) 138 | - Awesome distributed systems [Awesome distributed systems](https://github.com/theanalyst/awesome-distributed-systems) 139 | - Technology Architecture Lessons[Technology Architecture Lessons](https://www.developertoarchitect.com/lessons/) 140 | 141 | # License details 142 | 143 | Shield: [![CC BY 4.0][cc-by-shield]][cc-by] 144 | 145 | This work is licensed under a 146 | [Creative Commons Attribution 4.0 International License][cc-by]. 147 | 148 | [![CC BY 4.0][cc-by-image]][cc-by] 149 | 150 | [cc-by]: http://creativecommons.org/licenses/by/4.0/ 151 | [cc-by-image]: https://i.creativecommons.org/l/by/4.0/88x31.png 152 | [cc-by-shield]: https://img.shields.io/badge/License-CC%20BY%204.0-lightgrey.svg 153 | -------------------------------------------------------------------------------- /_config.yml: -------------------------------------------------------------------------------- 1 | plugins: 2 | - jekyll-relative-links 3 | relative_links: 4 | enabled: true 5 | collections: true 6 | include: 7 | - CONTRIBUTING.md 8 | - README.md 9 | - LICENSE.md 10 | - COPYING.md 11 | - CODE_OF_CONDUCT.md 12 | - CONTRIBUTING.md 13 | - ISSUE_TEMPLATE.md 14 | - PULL_REQUEST_TEMPLATE.md 15 | 16 | theme: jekyll-theme-cayman -------------------------------------------------------------------------------- /industry-specific/README.md: -------------------------------------------------------------------------------- 1 | ## Industry specific solution architecture patterns 2 | 3 | - Telecommunication Reference Architecture 4 | [Telecommunication Reference Architecture](Telecommunication-reference-architecture-pattern.md) 5 | 6 | - Transportation Reference Architecture 7 | [Transportation Reference Architecture](Effective-ground-transportation-architecture-pattern.md) 8 | 9 | - Digital Health Platform Open Source Architecture 10 | [Digital Health Platform Open Source Architecture](Digital-Health-Platform-Open-Source-Architecture.md) 11 | 12 | - Hospitality Platform Reference Architecture 13 | [Hospitality Platform Reference Architecture](Hospitality-Platform-Reference-Architecture-WSO2.md) 14 | 15 | - Retail Platform Reference Architecture 16 | [Retail Platform Reference Architecture](future-retail-a-business-and-technical-architecture.md) 17 | 18 | - Higher Education Information Technology Architecture [Higher Education Information Technology Architecture](Higher-Education-Information-Technology-Architecture.md) 19 | 20 | - Energy industry Information Technology Reference Architecture [Energy industry Information Technology Reference Architecture](Energy-Information-Technology-Reference-Architecture.md) 21 | 22 | - Automotive industry Information Technology Reference Architecture [Automotive industry Information Technology Reference Architecture](Automotive-Industry-Information-Technology-Reference-Architecture.md) 23 | -------------------------------------------------------------------------------- /industry-specific/images/Digital-Health-Platform-2-Hospital-ecosystem (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/industry-specific/images/Digital-Health-Platform-2-Hospital-ecosystem (1).png -------------------------------------------------------------------------------- /industry-specific/images/Digital-Health-Platform-3-Solutions-Architecture.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/industry-specific/images/Digital-Health-Platform-3-Solutions-Architecture.png -------------------------------------------------------------------------------- /industry-specific/images/Digital-Health-Platform-4-OpenSource-deployment.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/industry-specific/images/Digital-Health-Platform-4-OpenSource-deployment.png -------------------------------------------------------------------------------- /industry-specific/images/Digital-Health-Platform-Information-Architecture (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/industry-specific/images/Digital-Health-Platform-Information-Architecture (1).png -------------------------------------------------------------------------------- /industry-specific/images/Digital-Healthcare-Platform-1-Stakeholders.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/industry-specific/images/Digital-Healthcare-Platform-1-Stakeholders.png -------------------------------------------------------------------------------- /industry-specific/images/Open-Hospitality-Platform-0.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/industry-specific/images/Open-Hospitality-Platform-0.png -------------------------------------------------------------------------------- /industry-specific/images/Open-Hospitality-Platform-1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/industry-specific/images/Open-Hospitality-Platform-1.png -------------------------------------------------------------------------------- /industry-specific/images/Open-Hospitality-Platform-2-a.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/industry-specific/images/Open-Hospitality-Platform-2-a.png -------------------------------------------------------------------------------- /industry-specific/images/Open-Hospitality-Platform-2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/industry-specific/images/Open-Hospitality-Platform-2.png -------------------------------------------------------------------------------- /industry-specific/images/automotive-industry-business-architecture.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/industry-specific/images/automotive-industry-business-architecture.png -------------------------------------------------------------------------------- /industry-specific/images/automotive-industry-solution-architecture.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/industry-specific/images/automotive-industry-solution-architecture.png -------------------------------------------------------------------------------- /industry-specific/images/education-industry-existing-architecture.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/industry-specific/images/education-industry-existing-architecture.png -------------------------------------------------------------------------------- /industry-specific/images/education-industry-transformation-phase-1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/industry-specific/images/education-industry-transformation-phase-1.png -------------------------------------------------------------------------------- /industry-specific/images/education-industry-transformation-phase-2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/industry-specific/images/education-industry-transformation-phase-2.png -------------------------------------------------------------------------------- /industry-specific/images/education-industry-transformation-phase-3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/industry-specific/images/education-industry-transformation-phase-3.png -------------------------------------------------------------------------------- /industry-specific/images/energy-industry-ra-conceptual-model.JPG: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/industry-specific/images/energy-industry-ra-conceptual-model.JPG -------------------------------------------------------------------------------- /industry-specific/images/energy-industry-ra-ibm-safe-model.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/industry-specific/images/energy-industry-ra-ibm-safe-model.png -------------------------------------------------------------------------------- /industry-specific/images/energy-industry-ra-smart-grid.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/industry-specific/images/energy-industry-ra-smart-grid.png -------------------------------------------------------------------------------- /industry-specific/images/energy-industry-ra-solution-architecture.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/industry-specific/images/energy-industry-ra-solution-architecture.png -------------------------------------------------------------------------------- /industry-specific/images/ground-transportation-figure-1.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/industry-specific/images/ground-transportation-figure-1.jpeg -------------------------------------------------------------------------------- /industry-specific/images/ground-transportation-reference-architecture.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/industry-specific/images/ground-transportation-reference-architecture.png -------------------------------------------------------------------------------- /industry-specific/images/ground-transportation-reference-implementation-wso2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/industry-specific/images/ground-transportation-reference-implementation-wso2.png -------------------------------------------------------------------------------- /industry-specific/images/ground-transportation-stakeholders.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/industry-specific/images/ground-transportation-stakeholders.png -------------------------------------------------------------------------------- /industry-specific/images/ground-transportation-technical-architecture.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/industry-specific/images/ground-transportation-technical-architecture.png -------------------------------------------------------------------------------- /industry-specific/images/retail-fig1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/industry-specific/images/retail-fig1.png -------------------------------------------------------------------------------- /industry-specific/images/retail-fig2-accenture.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/industry-specific/images/retail-fig2-accenture.png -------------------------------------------------------------------------------- /industry-specific/images/retail-fig3-BA.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/industry-specific/images/retail-fig3-BA.png -------------------------------------------------------------------------------- /industry-specific/images/retail-fig4-apparc.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/industry-specific/images/retail-fig4-apparc.png -------------------------------------------------------------------------------- /industry-specific/images/retail-fig5-ref_arc.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/industry-specific/images/retail-fig5-ref_arc.png -------------------------------------------------------------------------------- /industry-specific/images/retail-fig6-swarc.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/industry-specific/images/retail-fig6-swarc.png -------------------------------------------------------------------------------- /industry-specific/images/telecommunication-information-architecture.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/industry-specific/images/telecommunication-information-architecture.png -------------------------------------------------------------------------------- /industry-specific/images/telecommunication-information-reference-architecture.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/industry-specific/images/telecommunication-information-reference-architecture.png -------------------------------------------------------------------------------- /industry-specific/images/telecommunication-information-wso2-reference.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/industry-specific/images/telecommunication-information-wso2-reference.png -------------------------------------------------------------------------------- /industry-specific/images/telecommunication-network.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/industry-specific/images/telecommunication-network.png -------------------------------------------------------------------------------- /industry-specific/images/telecommunication-openapi-architecture.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/industry-specific/images/telecommunication-openapi-architecture.png -------------------------------------------------------------------------------- /industry-specific/images/telecommunication-stakeholders.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/industry-specific/images/telecommunication-stakeholders.png -------------------------------------------------------------------------------- /technology-selection-guides/README.md: -------------------------------------------------------------------------------- 1 | # Technology selection guides 2 | 3 | - [API Management platform selection guide](API-Management-Platform-selection-guide.md) 4 | - [Integration platform selection guide](Integration-Platform-selection-guide.md) 5 | 6 | -------------------------------------------------------------------------------- /technology-selection-guides/images/api-platform-selection-1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/technology-selection-guides/images/api-platform-selection-1.png -------------------------------------------------------------------------------- /technology-selection-guides/images/api-platform-selection-2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/technology-selection-guides/images/api-platform-selection-2.png -------------------------------------------------------------------------------- /technology-selection-guides/images/api-platform-selection-3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/technology-selection-guides/images/api-platform-selection-3.png -------------------------------------------------------------------------------- /technology-selection-guides/images/api-platform-selection-4.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/technology-selection-guides/images/api-platform-selection-4.png -------------------------------------------------------------------------------- /technology-selection-guides/images/integration-platform-selection-0.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/technology-selection-guides/images/integration-platform-selection-0.png -------------------------------------------------------------------------------- /technology-selection-guides/images/integration-platform-selection-1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/technology-selection-guides/images/integration-platform-selection-1.png -------------------------------------------------------------------------------- /technology-selection-guides/images/integration-platform-selection-2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/technology-selection-guides/images/integration-platform-selection-2.png -------------------------------------------------------------------------------- /technology-selection-guides/images/integration-platform-selection-3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/technology-selection-guides/images/integration-platform-selection-3.png -------------------------------------------------------------------------------- /vendor-neutral/API-Security-Pattern.md: -------------------------------------------------------------------------------- 1 | ## API Security Pattern 2 | 3 | ### Introduction 4 | 5 | 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. 6 | 7 | ![API Security Pattern](images/API-Security-Pattern.png) 8 | 9 | APIs provides you with the ability to compete in the digital marketplaces where brick and mortar stores 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. 10 | 11 | The market has become so large that a product you make in some rural village in SriLanka can be sold to an individual who is living in New York through the online digital e-commerce website like ebay or alibaba. Rather than going into a retail or wholesale shop, people would like to order items from their fingertips by using a mobile phone or a tablet. Enterprises has been doing well without these mobile apps and websites for a longest of time in the past. But that time is over. 12 | 13 | Now enterprises are reqiured to offer their business services through different channels to their internal and external consumers. Those different consumers will use different mediums to access your business information. Having a set of well defined, well documented, browsable set of APIs would allow these different users to consume these business information with all sorts of different mediums. Some of the mediums are 14 | 15 | - Mobile application 16 | - Web application (server based) 17 | - Web sites (Single Page Application based) 18 | 19 | ### Protecting your APIs 20 | 21 | Allowing users to access your business information helps you to expand your business and compete with the other vendors. But due to the competition and the nature of the internet, you cannot expose your valuable business information without any security and control. If you don't control your APIs, there are hackers who will jeopardize your business even before you think about it by various means. 22 | 23 | API Security is an evolving concept which has been there for less than a decade. When it comes to securing your APIs, there are 2 main factors. 24 | 25 | - Authentication - Identifying and validating the user identity (who you are) 26 | - Authorization - Recognizing the level of access a user has to the business information (what you can do) 27 | 28 | User authentication is the basic requirement of providing access to any system. That method has been there for a longest of time since the beginning of computers. In the past you could have keep your user names and password in some vault and use them to authenticate into the systems you want to access. With the growth of different business systems and the other web applications you access day to day, sometimes keeping all these usernames and passwords has become a difficult task. Most people uses same credentials for their bank accounts, social logins, computer logins as well as business applications. So providing this information to one system can be dangerous if some hackers access this information (Facebook recently found out that they have stored user credentials in plain-text in their databases). 29 | 30 | Due to various reasons, people wanted a mechanism to reuse their existing identities without compromising their credentials so that you can use different applications while having a single username password pair stored in one system which you trust. In a business or enterprise scenario, you can have your enterprise account where your credentials are stored securely in enterprise user store (LDAP, AD). 31 | 32 | ### API Security mechanisms 33 | 34 | #### OAuth2 35 | OAuth2 has become the defacto standard in securing APIs through access delegation mechanism. With OAuth2, you can give permissions for an applications to access a certain set of resources on behalf of you to provide a valuable service to you without giving your credentials. With this model, you authenticate against your secured identity provider. The application (web, mobile) will get an access token on behalf of you and access the information which you are allowed through the token. 36 | 37 | #### OIDC 38 | Sometimes these applications wanted to identify the user information (without password) and the OAuth2 framework didn't have a standard mechanism to do this. Because of this limitation, engineers came up with the Open ID Connect (OIDC) framework through that applications can request for basic user information once the user had given permissions to access a certain resource (with user consent). 39 | 40 | #### Basic Authentication 41 | On top of all these modern security frameworks, there are some enterprises who still uses username and password based authentication (basic authentication) for API security. 42 | 43 | #### Token exchange with existing security mechanisms 44 | Sometimes as an enterprise solutions architect, you need to introduce new concepts like API management without modifying the existing applications and the user experience. If the end user applications are out of your control, you might not have the luxury of completely introducing a new security mechanism like OAuth2 with these applications. In such cases, you need to build your api management layer so that it can interoperate with the existing security mechanisms like SAML2, Kerberos, NTLM and build a token exchange mechanism around the applications. Users might not see the difference in security implementation since you can either have a token proxy at the enterprise level or develop some code at the client side applications to perform the token exchange. 45 | 46 | ### API Gateway and the Identity Provider 47 | API Gateway (sometimes called as API Manager) is the runtime component which receives all the requests from different users through applications. It is the duty of gateway to validate the user requests before calling the actual endpoints which provides the business information. API Gateway uses a special component to validate the user identities and the access control levels named as Identity Provider. It can be a fully fledged Identity and Access Management product or a component built as part of the same API Management product (e.g. Key Manager). This Identity Provider component takes care of all the security related tasks like 48 | 49 | - User management 50 | - Key and token management (OAuth2 and OIDC) 51 | - Entitlement management (XACML) 52 | - Authentication 53 | - Authorization 54 | 55 | Sometimes, the same IdP is used for managing authentication and authorization for existing back end applications as well. If a user wants to access an API through an application, user will be redirected to the authentication endpoint of this IdP (or to another IdP if there is federation) and the user credentials are provided here. These user credentials are securely stored within this IdP. If the enterprise already has an IdP, it makes sense to use that to provide these token validation and token generation functionalities. To do that, the particular IdP should have the retrospective API implemented on that server. 56 | 57 | ### Connecting to backend endpoints 58 | Sometimes the authentication and authorization at the API Gateway is not sufficient and the back end services also expects some information about the user to validate the data access at that level. In such cases, most of the time, API gateway should pass the basic authentication information coming from the client side or a JWT generated out of the access token. 59 | 60 | -------------------------------------------------------------------------------- /vendor-neutral/API-led-Connectivity-Pattern.md: -------------------------------------------------------------------------------- 1 | ## Introduction 2 | 3 | Businesses need to grow with the market to make it relevant to the consumers in the long run. Building a successful, long-running business needs a lot of planning and adopting to changes happening around it. Digital transformation is something that every business must adopt if they want to be in the game. That does not necessarily mean that you need to hire a consulting company who are specialized in digital transformation and spend millions of dollars to go there. Instead, you can always start with the fundamental requirements of an expanding business and slowly migrate towards a full digital transformation. 4 | 5 | The fundamental requirement of the digital transformation is the integration of your existing set of systems, applications, and data. This article discusses how you can use the concept of “API-led connectivity or API-led integration” to kick-start your digital transformation journey with open source technology using WSO2 product stack. 6 | 7 | ## Architecture 8 | “Every business is running on software” is not a false statement. It is the 80% case and we can consider that as the practical norm in the enterprise. Running business operations using software applications is not something to make your enterprise special. But if you are exposing your business products and services through digital mediums, that is indeed a specialty depending on your vertical. Industries like retail, banking, education are already adopting the technology for internal and external operations. But there are certain industries that are still not utilizing the power of the digital age and the value of structural information exchange patterns to boost their businesses. 9 | 10 | Application Programming Interface or an API defines an interface that can be used by internal and external consumers to get services from your business. It can be as simple as buying a product through a web site, sending a purchase order to supply raw material or even updating the EOD profit and loss statement to the head office branch. APIs allow you to build interactions amongst your customers, partners, employees and your entire business. 11 | 12 | ### Business Architecture 13 | 14 | Let’s dig a bit deep and understand the business architecture of a typical enterprise with an API-driven approach. 15 | 16 | ![API-led-connectivity-1](images/API-led-Business-Transformation-1.png) 17 | 18 | Figure 1: API-led connectivity, business architecture 19 | 20 | Disclaimer: The original architecture diagram of the above figure can be found in the below link. 21 | [1] https://blogs.mulesoft.com/dev/api-dev/what-is-api-led-connectivity/ 22 | 23 | In a typical enterprise, there are certain types of users interact with systems, applications, and data. Depending on their role within the enterprise ecosystem, they require different sets of services and information access. To fulfill these requirements of different consumers, we can categorize the enterprise system into 3 main layers of responsibility. 24 | 25 | - Experience APIs - At the highest interaction point, users (internal and external) expect access to fine-grained, purpose-built, cutting-edge information with high value and easy usage. This is where innovation happens. As an example, a user who wants to buy a bicycle through his mobile phone wants to know every detail of the bicycle through the phone itself (except the real bicycle ride). The data which is exposed to this layer needs to improve the user experience or else it will be invalid. 26 | - Process APIs - Providing quality experience APIs require the interaction of multiple systems and data sources and the proper design of data structures. This is where the process API layer comes in handy. This layer acts as the orchestration layer for multiple systems and data sources while fine-tuning the end result for the above layer (Experience API layer). Providing API based access to these capabilities allows users to create value and bring agility to business operations. 27 | - System APIs - There should always be a component that does the heavy-lifting on behalf of the entire system. That is what this system APIs layer does. It makes interactions with core data sources and caches where valuable business data resides in for longer periods and provide guarantees of data. These core systems can also expose their functionalities as APIs with proper controls in place so that it is much easier to interact with. 28 | 29 | 30 | Note: There will always be systems and data types that need to be processed in an asynchronous manner where you need to put a messaging system (e.g. Kafka, NATS) into the mix. This article does not specifically mention that aspect since this article focuses on APIs. You can always bring in a messaging system and asynchronous communication to this architecture. 31 | 32 | With the above architecture in mind, let’s try to build a solution architecture for this business architecture. 33 | 34 | ### Solution Architecture 35 | Having a layered business architecture allows us to define a solution architecture which is also a layered architecture. But this is not a necessity and someone can come up with a fully distributed solution architecture even with the above-mentioned business architecture if needed. But for the sake of simplicity, let’s take a layered approach with well defined functional components for each layer. 36 | 37 | ![API-led-connectivity-2](images/API-led-Business-Transformation-2.png) 38 | 39 | Figure 2: API-led integration, solution architecture 40 | 41 | As depicted in the above figure, we can map the functionalities of each layer to certain functional capabilities within enterprise architecture. 42 | 43 | - Experience APIs layer can be implemented with an API management platform. This may require a different set of functionalities depending on your enterprise and selecting an API management vendor needs to be done after evaluating the requirements. The fundamental capabilities like security, monitoring, rate-limiting, throttling, caching and better performance are supported by majority of vendors. 44 | - One fundamental difference in this API-led connectivity or API-led integration is that you don’t need an API management component at each and every layer though it discusses APIs at each layer. Process APIs layer can be easily implemented with an integration technology platform that is capable of doing protocol translations, message transformations, service orchestration and support for major messaging formats and wire-level protocols. These integrated services can be exposed as managed or un-managed APIs to the upper experience layer. 45 | - System APIs layer can sometimes be directly passed through if the core data is coming from those systems through a defined API. If not, there should be a core business logic layer that converts the business-specific, raw data to meaningful data through an intermediate layer. Users can either utilize an existing integration framework or a standard web-services, microservices technology stack to implement this layer. 46 | - One major advantage of this proposed API-led integration approach is that every functional capability is available in the means of APIs. Having a centralized developer portal that has details of all the APIs (experience, system, and process) would increase the overall operational efficiency in magnitudes since users do not need to make individual manual requests get certain things implemented on a lower layer. There are API management vendors who can provide this sort of a developer portal as part of their core offering or through a plugin or add-on. 47 | 48 | ## Final thoughts 49 | Though people going after hyped words like microservices, containers, serverless, the fundamental architectures for building digital businesses still remains the same. API-led connectivity or API-led integration is such a fundamental concept that can live nicely in both existing monolithic enterprise as well as modern cloud-native, microservices-based enterprise. Any large digital transformation project can be kicked-off with this fundamental architecture pattern and can grow to much bigger projects. Having the fundamental architecture right at the start is crucial in any successful project whether it is large or small. 50 | -------------------------------------------------------------------------------- /vendor-neutral/Anti-Corruption-Layer-Pattern.md: -------------------------------------------------------------------------------- 1 | ## Anti Corruption Layer Pattern 2 | 3 | ### Introduction 4 | 5 | Enterprise software systems are built with heterogenous systems which uses best of breed technologies to solve the respective problem at hand. Here are some examples 6 | 7 | - ERP systems uses proprietary protocols which are efficient in storing and managing enterprise resources (e.g. SAP) 8 | - Data warehousing tools uses relational or no-sql type databases 9 | - Web services use SOAP+XML or REST+JSON over HTTP 10 | - Asynchronous message processing systems may use message queueing protocols like JMS, AMQP, STOMP 11 | 12 | Even though these systems are built in isolation, they can't operate in isolation within enterprise. They need to talk to other systems to provide value to the end customers. 13 | 14 | ### Architecture 15 | 16 | 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. 17 | 18 | ![Anti-Corruption-Layer-Pattern](images/Anti-Corruption-Layer-Pattern.png) 19 | 20 | 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. 21 | 22 | 23 | ### When to use 24 | 25 | Unless otherwise you have all your systems communicated over a single protocol like HTTP, having an anti corruption layer is required to integrate heterogenous systems within an enterprise. By using this pattern, you can avoid building point to point spaghetti type architectures in the long run. 26 | 27 | ### Advantages 28 | 29 | Here are some of the advantages of using this pattern. 30 | 31 | - No need to customize systems when talking to another system. The protocol translation happens at intermediate layer 32 | - Error handling can be done at the intermediate layer 33 | - Functionalities can be exposed to external world through a standard interface 34 | - Systems can optimize their implementations without dropping their efficiency on compatibility 35 | - Services are easier to discover 36 | 37 | ### Future 38 | 39 | With more and more people moving into micro type architectures, some architects think that this anti corruption layer is no longer required and the communication to these heterogenous systems can be done through a some type of a distributed proxy (sidecar) which runs along with the microservice. Some argues that service mesh is the distributed version of the traditional ESB or the anti corruption layer. But doing the heavy lifting of protocol translations, message translations along with supporting many different types of protocols needs to be implemented in these service meshes if they are to become the future anti corruption layer. 40 | -------------------------------------------------------------------------------- /vendor-neutral/Ballerina-sidecar-pattern-microservices.md: -------------------------------------------------------------------------------- 1 | ## Ballerina sidecar pattern for microservices 2 | 3 | ### Evolution of sidecar pattern 4 | The microservices architecture pattern is designed to be distributed in nature. But recently, we have observed that this distribution of responsibility has gone beyond the microservices itself. 5 | 6 | #### Sidecar 1.0 and the Service Mesh 7 | The first sidecar pattern which became mainstream with microservices was the “Service Mesh” sidecar where certain functionalities related to network communication have been delegated into a separate sidecar. Some of the functionalities which were delegated are 8 | - Error handling 9 | - Load balancing 10 | - Timeout/Retry 11 | - Circuit breaker 12 | - Service discovery 13 | - Traffic routing/ Rate limiting 14 | 15 | There are leading technologies that have become the front runners in the SM race. Some of them are 16 | - Envoy/ Istio 17 | - Nginx 18 | - Linkerd 19 | 20 | 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. 21 | 22 | ![Istio Service Mesh Pattern](images/Istio-Service-Mesh-Pattern.png) 23 | 24 | #### Sidecar 2.0 and the OPA 25 | 26 | 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. 27 | 28 | ![Microservices Security with OPA](images/Micoservices-Security-Pattern-Policy-Based-OPA.png) 29 | 30 | ### Ballerina sidecar pattern 31 | 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. 32 | 33 | Ballerina is a new programming language developed by a team at WSO2 with the focus of making application integration more powerful than ever before. I won’t say that it will make it easier. Rather I would say Ballerina is trying to give more power to the typical integration developer who used to work with restricted, high-level languages. Having said that, if we come back to the world of microservices, there are certain functionalities that we implement in microservices (business logic) that can be taken outside and do with a common library or framework. That is why people are using certain frameworks like Spring, Gson, Netty to do certain operations within microservices. If you do a thorough analysis of your microservices code, you will find that there are certain code segments that we write in almost all the microservices. That is where this concept of Ballerina sidecar plays a major role. Here are some of the requirements which we are using libraries/frameworks to implement. 34 | 35 | - Handling of message types like JSON, XML, CSV, etc 36 | - Transforming messages across formats 37 | - Connecting with databases (CRUD operations) 38 | - Integrating with other systems (SaaS, COTS) 39 | - Doing protocol translations 40 | 41 | 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. 42 | 43 | ![Ballerina sidecar pattern](images/Ballerina-sidecar-pattern-for-microservices.png) 44 | 45 | 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. 46 | 47 | ### Conclusion 48 | As a final conclusion, it is evident that microservices architecture is expanding beyond its initial architecture and things are becoming more and more distributed and delegated with their own control planes. At the end of the day, operations people will need a mechanism to consolidate all these activities and connect them when bad things happen to the system. There is another set of technologies built for managing higher-level groupings of microservices so that you don’t need to monitor the entire mesh with 1000s of services. Cellery is such an attempt to build a management layer for these sorts of complex architectures. I am finishing my article with a link to Cellery. 49 | 50 | [Cellery](https://wso2-cellery.github.io) 51 | 52 | -------------------------------------------------------------------------------- /vendor-neutral/Cloud-Migration-Strangler-Pattern.md: -------------------------------------------------------------------------------- 1 | ## Introduction 2 | 3 | One of the most common requests coming from enterprise leaders to enterprise architects these days is “move to cloud”. There is a common notion about cloud that it is 4 | - Cheap (pay per usage) 5 | - Easier to maintain 6 | - Highly available 7 | 8 | and sometimes more safer than your on-premise system. All those points are valid and hold true to a certain extent. The intention of this post is not to challenge the decision of “move to cloud”, rather to help enterprise architects to make the move with a proper architecture guidance. 9 | Every time you make a change to the enterprise system, it can affect the entire business operation within your organization. Because of this, I have seen some enterprise systems kept as it is for ages without making any change. With the adoption of “cloud” and cloud-native technologies, none of those systems can live in isolation and in hiding. Those systems must make significant improvements if those systems needs to survive within the enterprise. 10 | 11 | ### Before migration 12 | Let’s consider a typical medium sized organization having a SOA based enterprise system with a set of integrated components. In most cases, you would find an architecture similar to the below figure in such an enterprise. 13 | 14 | ![enterprise-architecture-before-migration](images/Migrating-architecture-with-strangler-pattern-0.png) 15 | Figure 1: Enterprise Architecture — Before migration 16 | 17 | As depicted in the above figure, there are different types of systems which are used in the enterprise for daily operations and an ESB has been used to integrate certain systems which cannot communicate with each other natively. There are certain in-house developed systems as well as legacy and COTS systems along with data sources. All the systems are exposed through a load balancer, proxy and/or a firewall to external and internal consumers. Everything works perfectly fine and business operations running smoothly with this architecture. Then why do you need to change this architecture? 18 | 19 | The new CIO or CTO looks at the architecture and explains the challenges of this architecture as below. 20 | - How do you scale this architecture from thousands to millions of consumers if we are growing globally 21 | - What happens if one of the components goes down and what happens if an entire data center goes down? 22 | - How easy to deploy a new application with this architecture? 23 | - How often this system is being updated and when was the last time you made an update/upgrade? 24 | 25 | If you haven’t put a lot of thinking around these pointers, there is a high chance that you will stuck in front of your C-member without proper answers. 26 | 27 | Now you are convinced that you need to make a move and start working on the aspects which are mentioned above. How can you achieve those capabilities without impacting the business operations is the real challenge. That is where we can use the concept of “Strangler Pattern” or “Strangler Facade” to our rescue. 28 | 29 | ### Start migration 30 | The idea of the “Strangler Pattern” is to introduce a layer which will hide the actual transition which is going underneath from the users. To achieve this, we can utilize an integration platform or a product to act as the glue between existing components and the newly developed components while exposing both those capabilities selectively to the users. 31 | 32 | ![enterprise-architecture-during-migration](images/Migrating-architecture-with-strangler-pattern-1.png) 33 | Figure 2: Enterprise Architecture — During migration 34 | 35 | As depicted in the above figure, we are going to introduce an additional layer on top of the existing services. This layer is called the “Strangler Facade” which is capable of exposing similar functionality as it is now (through proxy) or with additional capabilities (e.g. monitoring, security) and improved user experience (developer portal). These additional capabilities are optional and you should not worry much at the beginning. In addition to exposing the existing set of systems through this layer, it will also selectively open up the services which are developed in the new deployment which is on the cloud. You can start with things like in-house tools which were built sometime ago and convert them into a set of microservices. While doing this development, you can selectively expose these services through the API management functionality of the strangler facade. In addition to the API management capability, strangler facade has the capability to integrate across systems if required. 36 | 37 | The deployment of this “Strangler Facade” component needs to be done in the cloud since the eventual goal of this effort is to move to the cloud. But if you are thinking of moving out to a on-premise deployment with container technologies, you can deploy the strangler facade on the same deployment. 38 | 39 | With the time, more and more of your enterprise systems will be moved to the cloud either running on cloud VMs, microservices or as SaaS services. During this time, strangler facade will act as a controlling layer which will offer existing services as well as new services to the consumers. The other advantage of this approach is that, you don’t need to wait till the end of the migration to reap the real benefits of the new architecture. 40 | 41 | ### Post migration 42 | If you continue the migration with a proper plan, you should be able to migrate most of your systems to “cloud” without impacting the business operations while adding more and more services to your consumers. There can be situations where some of the systems might stay in the on-premise deployment. Even those systems can be integrated into the new architecture through the “integration” capability of the strangler facade. 43 | 44 | ![enterprise-architecture-migrated](images/Migrating-architecture-with-strangler-pattern-2.png) 45 | Figure 3: Enterprise Architecture — migrated 46 | 47 | Once the migration is done, you can achieve the requirements which were initially put in front of you by your CIO/CTO. As depicted in the above figure, fully migrated enterprise system can be exposed through the strangler facade. If you really need, you can even live without the strangler facade by utilizing similar functional components provided by the respective cloud service providers. But this is something you should do after considering all the facts. The danger of making such a move to remove the strangler facade is that you will be locked down to that particular cloud provider for all your operations. Instead, it is recommended to keep the strangler facade as an independent component so that if you decide to move to a different cloud vendor or to move back to on-premise container deployment, you can easily do that with the same. 48 | 49 | ## Final thoughts 50 | The requirement of “move to cloud” is becoming more and more prominent in the enterprise and there are people rolling out cloud migration projects without understanding the value of cloud as well as the disruptions that can bring to your business. Hence, if you are doing a cloud migration project, you should consider all the nitty gritty details of where you are, where you want to be and how you are planning to go there. The “strangler pattern” or “strangler facade” introduced in this article helps you to take a measured approach make that move without much interruptions. I have used WSO2 API Manager and WSO2 Enterprise Integrator (EI) as the products which offers the required functionality at the strangler facade. You can replace them with any technology of your choice as long as it provides the required functionality. 51 | -------------------------------------------------------------------------------- /vendor-neutral/Decentralized-Enterpise-Architecture-Pattern.md: -------------------------------------------------------------------------------- 1 | ## Decentralized Enterprise Architecture Pattern 2 | 3 | ### Introduction 4 | Enterprise software has been used to run on mainframes or server racks with multiple CPU units and heaps of memory. The amount of energy needed to run these machines as well as the high maintenance costs has become a concern for the CIOs and CTOs. Then they decided to go with a virtualization platform where it allows the enterprise software to be run on much lesser resources. After sometime, these virtual machines also looked premature and wasting a lot of resources which can be used for other purposes. That is where the container runtimes become useful. With the rise of docker, people started thinking about running applications with the same level of isolation as virtual machines without sacrificing the compute resources to run an entire operating system on a VM. 5 | 6 | Container based deployments are becoming more and more common within enterprise software ecosystem and there are many cloud service providers offer managed container services. This solutions architecture pattern explains how an entire enterprise software system can be built using a container based deployment model. Some of the concepts mentioned in this document may use terminology from some specific technologies. But that does not mean that this pattern can be applied in a vendor neutral manner. 7 | 8 | ### Architecture 9 | 10 | ![Decentralized-Enterprise-Architecture-Pattern](images/Decentralized-Enterprise-Architecture-Pattern.png) 11 | 12 | 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. 13 | 14 | 15 | #### No API Manager 16 | The well-known approach to expose a set of REST APIs is to use a fully blown API Management platform and start creating APIs in an API gateway. But in this architecture pattern, we are proposing somewhat different style of architecture without using any monolithic API Management platform. Instead, we can use one of the following components in place of ingress controller block 17 | 18 | - Ingress Controller (Kubernetes) 19 | - Load balancer 20 | - Reverse Proxy 21 | 22 | The most common questions which arises with this design choice is that where do we apply the standard QOS functionalities to the services. 23 | 24 | #### Everything is a service (in most cases a micro one) 25 | Instead of putting a layer which is capable of providing centralized QOS capabilities, we are using a decentralized component called a sidecar proxy (or micro gateway or edge gateway) to provide the functionalities like 26 | 27 | - Authentication 28 | - Authorization 29 | - Throttling 30 | - Monitoring 31 | 32 | In container world, you can package your application code along with any dependencies into a container image using a container descriptor file (e.g. Dockerfile) and it became a container in the runtime which runs your application. Let's consider every application which you develop as a Service (in MSA) or a Function (in Serverless). All these services needs some form of QOS capabilities which are mentioned above. Instead of implementing these capabilities at the service level or using a centralized API gateway, we can use a component called "Sidecar Proxy" which can provide the same functionality. Regardless of the technology you used to implement your service (.Net, Java, Go, Node, etc.), these QOS functionalities will be provided through this sidecar proxy. If your applications requires a database to store some persistent data, you may need a supportive or dependent service or function. So every service can consist of 33 | 34 | - Main Service or Function 35 | - Sidecar Proxy 36 | - Supportive Service or Function 37 | 38 | All the above components can be run in separate containers or within the same container if there is no container orchestration capability available. In a platform like kubernetes, these 3 components can be run within the same "Pod" as depicted in the figure. 39 | 40 | #### Scaling services 41 | Once we have the service deployed in a Pod, we need to look at the next level functionality like 42 | 43 | - Availability 44 | - Performance 45 | - Scalability 46 | 47 | This is where the container orchestration systems comes into rescue. By using a container orchestration system like kubernetes, pods can be scaled to achieve the above mentioned capabilities. The scaling the "Pods" will make it harder to the ingress controller to route traffic since it has to modify the endpoints when the containers come and go. That is where the concept like "Service" helps out. 48 | 49 | Grouping multiple pods into a "Service" make it easier to the consumers. Instead of calling multiple endpoints, any external party can call the service URL to make a call to any of the "Pods". Service layer will do the required load balancing across the pods based on a given algorithm. 50 | 51 | These services can be mapped into an externally accessible IP address with the usage of a ingress controller. It allows external users like web, mobile and partner systems to consumer the services or functions which are deployed in containers within Pods and exposed through Services. 52 | 53 | #### Controlling the services 54 | Since we decided to get rid of an API Management platform at the beginning, we should have some layer of functionality which can control the configurations of each and every sidecar proxy as and when necessary and capture valuable analytics information. A control plane is the place where this configuration of various QOS capabilities are handled. The deployment model we are proposing here is a service mesh and the role of a control plane is to control and configure the mesh. 55 | 56 | #### Monitoring and Analytics 57 | In a large enterprise implementation, this architecture may consists of 100s or 1000s of services which are interacting with each other as well as consumed by external consumers. Having a proper monitoring and analytics capability is crucial when we want to 58 | 59 | - Troubleshoot issues in services 60 | - Analyze the usage of services 61 | - Plan the business operations 62 | 63 | Monitoring and analytics can be implemented as an independent component. The standard tracing technologies like "Opentracing" can be used to publish analytics data so that services developed in polyglot manner can be monitored through a centralized analytics component which is independent of any technology used for service implementations. 64 | 65 | ### Conclusion 66 | This solutions architecture pattern is quite new and challenge some of the well established concept like API Management platforms while offering the freedom to the developers to use any technology they like when implementing the business logic. All the supportive functionalities are provided through other components. There are new set of technology vendors who are developing entire platforms which abstract out all the functionalities except service development and sell the entire platform using this type of architecture pattern underneath. 67 | -------------------------------------------------------------------------------- /vendor-neutral/Enterprise-CICD-Pattern.md: -------------------------------------------------------------------------------- 1 | ## Enterprise Continous Integration Continous Deployment (CICD) Pattern 2 | 3 | ### Introduction 4 | Enterprise deployments used to span across several teams and took more time than it was expected. The mismatch of timelines, goals, resources and skills made it really hard to do a release within the enterprise within a desired time/date. It would have been fine when there was a little competition in the market. But that time has come to an end and the competition has become ever so increasing that some competitors do deployments and releases several times within a day. These modern enterprises have followed up the "Continous Integration(CI)/ Continous Deployment (CD)" pattern when implementing enterprise software. 5 | 6 | Within an enterprise software system, there are many types of software running. The below list contains a few types which are used within enterprise. 7 | - On premise software developed in-house 8 | - On premise software running on top of a server runtime (e.g. tomcat, ESB, etc.) 9 | - Commercial Off The Shelf (COTS) software developed by a 3rd party vendor 10 | - Cloud based SaaS solutions 11 | - Hybrid applications which runs part of their solution on cloud and the rest on premise 12 | 13 | The above list contains a fraction of different types of software running in the enterprise. As enterprise architects or engineers, you should identify which components of which software needs to be maintained and managed by your team. Most of the time, cloud based solutions are maintained and managed by the cloud vendor and COTS systems also has less maintenance overhead. But the on premise systems requires more attention from you since those systems are maintained and managed by the teams within the enterprise. 14 | 15 | ### Advantages of CI/CD within enterprise 16 | By implementing a proper CI/CD process within your enterprise, you can achieve 17 | - Flexible and Reliable product/service releases 18 | - Less impact with human errors 19 | - Short time to market 20 | - Be on the edge of the technology 21 | - Instant recovery of system errors/failures 22 | 23 | ### Solutions architecture for a CICD process 24 | Designing a continous integration continous deployment process for an enterprise requires an understanding of existing software systems within the enterprise. In any type of system which was described above, there are 2 types of development activities take place. 25 | 26 | 1. Development of use cases with business logic using one of the below methods 27 | - write code using a programming language 28 | - write code using a DSL (Domain Specific Language) 29 | - Configure product using a UI and generate configurations and metadata 30 | 31 | 2. Configure the server runtimes by either of the below methods 32 | - modifying the server configuration files 33 | - modifying the server libraries for update/upgrade 34 | 35 | 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. 36 | 37 | ![Enterprise-CICD-Pattern](images/Enterprise-CICD-Pattern.png) 38 | 39 | As depicted in the above diagram, the sequence of events occurs when there is a development activity happens is mentioned below. 40 | 41 | 1. The developers use an IDE or a code/configuration editor to make the change to the source code or a configuration file. It is advisable to use a configuration change to apply any change in the binary (e.g. patch, update or upgrade). Users can keep a configuration file with binary timestamp. When there is a new binary, modifying this timestamp will trigger the process. 42 | 2. The change in the source repository triggers a process in the CI server and it builds the developed artefacts. These artefacts are deployed into a artefact repository like nexus. 43 | 3. CI server will trigger another process to run the configuration management tool and create a runtime with environment specific parameters and artefacts blended into the binariesalong with the configurations. This runtime is then packaged into a docker image. 44 | - 3b). This docker image is deployed into one of the environments (dev, uat, staging, etc.) 45 | 4. CI server will deploy the test scripts to the server which is running the test client and trigger a test run. 46 | 5. Test client will execute the tests against the environment which has the latest runtime artefacts deployed in step 3b. 47 | 6. Once the testing is passed, CI server will trigger the config management tool and build the docker image with relevant environment specific configurations and artefacts for the following environment. 48 | - 6b). Deploy the docker image to the next environment 49 | 50 | The above mentioned process can be extended and implemented to support various kinds of software development within the enterprise. Based on the type of software, you may need to modify some components in this architecture. 51 | -------------------------------------------------------------------------------- /vendor-neutral/Event-Driven-Architecture-Kafka-Pattern.md: -------------------------------------------------------------------------------- 1 | # Event driven architecture with Kafka 2 | 3 | ## Introduction 4 | Apache Kafka has evolved as the defacto standard for building reliable event based systems with ultra high volumes. The unique, yet simple architecture has made Kafka an easy to use component which integrate well with existing enterprise architectures. At a very high level, it is a messaging platform which decouples the message producers from the message consumers while providing the reliability of message delivery to consumers at scale. Kafka has message producers which send messages (events) to kafka which kafka stores in a entity called a topic which will deliver the messages to one or more consumers in a reliable manner. There can be different types of producers and consumers depending on the use case. 5 | 6 | ## Architecture 7 | Kafka architecture is a simple yet powerful architecture which blends well within most of the existing architectures. 8 | ![Event-Driven-Architecture-Kafka-Pattern](images/Event-Driven-Architecture-Kafka-Pattern.png) 9 | 10 | 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. 11 | 12 | - Publisher API - This is used by event sources which generates events to send those events in large magnitudes to the kafka cluster. Kafka cluster stores these events in topics which are partitioned so that these topics can scale beyond a single server. These partitions are replicated across multiple nodes in case if one node goes down, the data is not going to be lost. These events are stored for a configurable duration regardless of whether they are consumed or not. During the time of publishing the events, publishers can specify the parition in which the event is going to be stored in a given topic. 13 | 14 | - Consumer API - The events stored in the topics are delivered to consumers who are subscribed to these topics. Unlike in standard pub-sub based topics, the consumer has total control over reading the messages from the topics. Consumer can control the offset value which tells the position of the message within a given partition so that consumers can read messages from any location within a given topic and a parition. Additionally, kafka comes with the concept of a consumer group through which, the consumers can balance load across multiple competing consumers similar to a queue based subscription. There can be multiple consumer groups subscribed to a given topic and each consumer group will get a one copy of the message at a given time. A given consumer within a consumer group is bounded to a given parition within a topic. Hence there cannot be more consumers within a group than the number of paritions of a topic. 15 | 16 | - Connector API - Sometimes kafka needs to be integrated with existing applications and systems. As an example, if we want to read a set of log files through kafka to process the data within those files using a stream processor, kafka provides the connector API to implement reusable components called connectors. The same connector can be used for any file based integration with kafka. 17 | 18 | - Streaming API - The events stored in kafka sometimes needs to be processed in real-time for various purposes like transformation, correlation, aggregation, etc. These sort of functionalities can be applied through a stream processor which acts on a continous stream of records. Kafka streaming API exposes a topic as a stream of events so that any other stream processor engine can consume that and do processing. 19 | 20 | ## Advantages 21 | Kafka has aggregated several advantages of existing messaging systems into a one single solution through it's unique design. Here are some of the advantages of Kafka 22 | 23 | - Ability to build cloud scale message processing platforms with fault tolerance 24 | - Message persistence and durability with a configurable retention period with control at the consumer end allows consumers the freedom to process messages at their will 25 | - Order of the messages are guaranteed within a partition which is critical in some use cases 26 | - Replication allows messages to be stored reliably so that failure of n-1 nodes within a n node cluster with replication count of n does not affect the message delivery to the consumers 27 | - Scalability of cluster allows to deploy the system across multiple data centers for highest levels of availability and better performance 28 | - Streams API allows the events to be processed in real-time with stream processing engines 29 | 30 | ## Use cases 31 | - Build reliable messaging platforms which delivers messages across systems at cloud scale 32 | - Build real time event processing systems with machine learning, AI based processing 33 | - Build large scale data processing systems like log monitoring, ETL based systems 34 | - Build systems with event sourcing where each activity is considered as an event which is attached to an event log 35 | -------------------------------------------------------------------------------- /vendor-neutral/Event-Driven-Architecture-Pattern.md: -------------------------------------------------------------------------------- 1 | # Event-Driven Architecture Pattern 2 | 3 | ## Introduction 4 | Enterprise systems are built on 2 fundamental messaging models. Which are 5 | - Synchronous messaging (request-response) 6 | - Asynchronous messaging (pub-sub, callback, batch) 7 | 8 | Out of these 2 models, synchronous messaging style is the most common pattern and within enterprises. But that doesn't reduce the importance of the asynchronous messaging architectures. In layman's terms, asynchronous messaging means that the consumer and the producer are decoupled and the producer would not get an immediate response to his message. 9 | 10 | Event-Driven architecture is one such asynchronous messging pattern where a set of actors called publishers generate a set of events and a set of subscribers or consumers consume these events independently and process those events asynchronously. We call this pattern as pub-sub model. 11 | 12 | ## Architecture 13 | -------------------------------------------------------------------------------- /vendor-neutral/GraphQL-Pattern.md: -------------------------------------------------------------------------------- 1 | # GraphQL based solution architecture patterns 2 | 3 | ## Introduction 4 | GraphQL is becoming popular in the tech industry as a replacement for REST. It really carries out significant advantages over existing mechanisms for the client-server type of communications. 5 | In simple terms, GraphQL allows the client to choose which information it wants rather than receiving all the data which is available for the API. This is similar to a database query where we request only the required information. That is why it is called as GraphQL. We can do this easily with databases and data services runtime. But if you think about implementing the same capability for a REST API, you have to create so many different resources and the client has to call each and every one of these resources and handle the orchestration logic at the client-side. Otherwise, the API server has to do the heavy-lifting of orchestration. But this is not scalable with the changing demands from customers and the business. You can find a simple example and an explanation of why GraphQL is considered as the better REST by reading the content in the below link. 6 | 7 | https://www.howtographql.com/basics/1-graphql-is-the-better-rest 8 | 9 | The intention of this post is to discuss possible solution architecture patterns that can be used to implement systems with GraphQL. 10 | 11 | ## Solution Architecture Patterns 12 | 13 | ### Pattern 1 — GraphQL Server exposing database 14 | This is the fundamental use case of the GraphQL. That is to expose a database in a much more controlled manner with additional capabilities like caching. A similar kind of functionality can be achieved with the OData specification. But GraphQL has really excelled beyond the OData by giving users to do basic CRUD operations as well as allowing the consumers to subscribe to data changes. It has clearly separated out the read operations (Queries) from the write operation (Mutations) and introduced a new operation type for data change notifications through Subscriptions. 15 | 16 | ![GraphQL with database](images/GraphQL-Pattern-1-dataservice.png) 17 | Pattern 1 — GraphQL server exposing a database 18 | 19 | As depicted in the above figure, GraphQL provides server libraries for multiple programming languages so that developers can build servers based on GraphQL specification. You can find more details on available language support for the server-side from here. Similarly, it provides client libraries to implement GraphQL clients. More details can be found here. GraphQL server exposes a simple HTTP/REST interface so that users can use any existing tools and clients which they have already built. 20 | 21 | ### Pattern 2 — GraphQL as a layer of integration 22 | The real power of the GraphQL specification comes from the ability to provide access to various data sources from the clients in one go. Instead of sending multiple requests (and hence wasting the bandwidth due to headers), GraphQL client can send a single request and get all the data it requires regardless of the actual backend data source. This allows the GraphQL server to act as an integration hub while exposing the services through GraphQL. 23 | 24 | ![GraphQL as integration hub](images/GraphQL-Pattern-2-integration-hub.png) 25 | Pattern 2 — GraphQL server as an integration hub 26 | As shown in the above figure, GQL server can connect to multiple backend systems within the enterprise including legacy systems, microservices, and existing 3rd party cloud APIs as data sources and provide a unified GraphQL interface to the clients. 27 | 28 | ### Pattern 3 — GraphQL hybrid integration 29 | In most of the real-world scenarios, you find there are various systems that need to be connected including databases, legacy apps, microservices, cloud APIs, etc. Therefore, building a GraphQL server that connects to a database as well as other systems can be a more frequent requirement. 30 | 31 | ![GraphQL as hybrid integration](images/GraphQL-Pattern-3-hybrid-integration.png) 32 | Pattern 3 — GraphQL hybrid integration 33 | In this pattern, GraphQL server has its own connected database and it will also connect to external systems. The clients get a unified API that they can consume efficiently without sending multiple requests to get desired data. 34 | The above 3 patterns are the standard GraphQL patterns recommended by the GraphQL community. But these patterns don’t fulfill the requirements of a modern enterprise architecture. The interfaces that expose these services need to be managed through a management layer. That is where the API gateways come into the picture. 35 | 36 | ### Pattern 4 — GraphQL server with one managed API 37 | Exposing the GraphQL based interfaces without any security can be a big issue in most of the enterprise deployments. That is the reason why we need to apply proper protection to these APIs using an API gateway. GraphQL provides a single endpoint to access data and execute various actions on top of that data. Therefore, the simplest approach to protect and manage this interface is by applying the management functionalities over this single endpoint. 38 | 39 | ![GraphQL with API per endpoint](images/GraphQL-Pattern-4-API-protected.png) 40 | Pattern 4 — GraphQL server with one managed API 41 | In this architecture, API gateway provides the security, throttling and monitoring capabilities to the single endpoint which is exposed from the GQL server. If you have multiple GraphQL endpoints available, these endpoints can be protected as separate APIs. Also, with this approach, multiple resources can be implemented for the same API with different throttling and security policies. But this needs to be done as a custom implementation and a lot of manual work needs to be done. 42 | 43 | ### Pattern 5 — GraphQL server with native API management 44 | One of the drawbacks of the above pattern 4 was that GraphQL native concepts (Queries, Mutations, Subscriptions) cannot be managed as separate entities. That is the exact requirement covered with this pattern. Here, once the GraphQL endpoint is provided to the API gateway, it will generate the GraphQL specific endpoints (operations) based on the definition of the GQL file and allow the users to apply throttling, security, and monitoring at these operations level. 45 | 46 | ![GraphQL with native API management](images/GraphQL-Pattern-5-Operation-protected.png) 47 | Pattern 5 — GraphQL server with native API management 48 | In this pattern, both Queries and Mutations can be implemented with native API management capabilities like security, throttling, caching, monitoring, etc. But the subscription feature of the GQL server cannot be implemented with that functionality since it works in an asynchronous, event-based mechanism. 49 | 50 | ## Implementation approach 51 | GraphQL servers and clients can be implemented in many different programming languages and there are libraries that are purpose-built for certain technology stacks available in the community. For adding the API management capabilities, users can use existing API management tools like WSO2 API Manager which supports both the above-mentioned pattern 4 as well as pattern 5. 52 | 53 | ## Future 54 | I have discussed some of the possible solution architecture patterns with the GraphQL specification. These are not the only patterns and there can be more and more patterns evolved with the time. Additionally, the above patterns didn’t cover the container-based, cloud-native architecture patterns since that is too much of a scope for a single article. But the concepts mentioned in this article can be reused when building such architectures as well. This article is more or less a foundation article on building real-world systems with GraphQL specification. 55 | -------------------------------------------------------------------------------- /vendor-neutral/Hybrid-API-Management-Pattern.md: -------------------------------------------------------------------------------- 1 | ## Hybrid API Management Pattern 2 | 3 | ### Introduction 4 | API Management has become a cornerstone in any digital transformation project happening within the enterprises. APIs provide a mechanism to build a secured, well-defined, discoverable interface to external consumers who are coming through various channels. API Management platforms provide a set of functionalities which are required by your business services. 5 | 6 | - Security (Authn and Authz) 7 | - Monitoring & Analytics 8 | - Throttling & Rate limiting 9 | - Discoverability 10 | - Error handling 11 | 12 | There are many API Management vendors (both open source and proprietary) who offers these capabilities through their products. 13 | 14 | ### Deployment choices 15 | These API Management platforms can be deployed in various different modes. Here are the 3 most common ways of deploying an API Management platform. 16 | 17 | 1. On premise 18 | 2. On Cloud (Public SaaS or Managed/Private Cloud) 19 | 3. Hybrid 20 | 21 | Though both on premise and on cloud deployments have their own advantages, they also have some disadvantages as well. By using a hybrid deployment model, we can achieve the advantages of both approaches while minimizing the disadvantages. 22 | 23 | The functional capabilities mentioned above can be run independently if the API Management vendor has designed the solution in such a manner. These functional components can run within different runtimes and different environments while communicating with each other to provide the end to end API management functionality. 24 | 25 | The APIM platforms which are implemented in a modularized nature can be deployed in a hybrid architecture as depicted in the below figure. 26 | 27 | ![Hybrid-API-Management-Pattern](images/Hybrid-API-Management-Pattern.png) 28 | 29 | 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. 30 | 31 | 1. API Gateway is deployed in on-premise infrastructure 32 | 2. API Management, Analaytics, Security components are deployed in cloud infrastructure 33 | 34 | In a hybrid deployment model, all the API traffic (requests) will be going through the on premise gateway runtime. In the meantime, the rest of the API management capabilities like security, analytics, lifecycle management, development, discovery will be running on the cloud. 35 | 36 | ### How it works 37 | Once we deploy the API Gateway within the on premise infrastructure and the rest of the components within the cloud, these components should communicate with each other to provide the end to end API Management capabilities. As an example, when a new API is created from the API development component, that API needs to be available in the gateway runtime which is running on premise. Additionally, the token validation, throttling, analytics capabilities needs to interact with the gateway runtime even though they are running in the cloud. 38 | 39 | This communication needs to be implemented in such a way that it won't disturb the runtime traffic, does not need any special connectivity from cloud to on premise gateways. To fulfill these requirements, API gateway component needs to connect to the cloud based components in an asynchronous manner with a periodic "pull" model for API artefacts and "push" model for analytics information. In both scenarios, it is the gateway component connecting to publicy accessible cloud URLs which does not need any special connectivity from cloud to on premise data center. 40 | 41 | ### Advantages of hybrid model 42 | This deployment model provides certain advantages over the other 2 deployment choices which are on-premise and on-cloud (SaaS or PaaS). Here are few advantages. 43 | 44 | - Keeping API Gateway runtime closer to the actual backend improves the overall performance of the API responses 45 | - Routing the API traffic which carries sensitive data through on-premise gateway improves the data security 46 | - Running API Gateway on-premise allows the system to be designed in a manner which compatible with regulations like HIPAA, PCI-DSS, GDPR 47 | - Keeping the rest of the API Management components in the cloud reduces the management overhead of those components 48 | 49 | ### Possibility to run multi-cloud 50 | This hybrid api management pattern can be extended to support a multi-cloud deployment topology where API Gateway can be run on one cloud provider and the rest of the components can be run on another cloud provider depending on the infrastructure your backend services are running 51 | -------------------------------------------------------------------------------- /vendor-neutral/Hybrid-Integration-Pattern.md: -------------------------------------------------------------------------------- 1 | ## Hybrid Integration Pattern 2 | 3 | ### Introduction 4 | Integration is one of the key capabilities required within any enterprise software system. With the growth of a business, its enterprise software system also grows accordingly. This growth can happen by adding more functionality to existing systems, introducing new on premise systems or more recently, bringing in cloud (SaaS) solutions into enterprise (e.g. salesforce, servicenow, peoplehr). The more systems you use for business operations, more complex your enterprise system becomes. Instead of connecting each system with other systems in a point to point manner which ends up in spaghetti pattern, using an integration layer would make the connections and the management of overall system integration more efficient. 5 | 6 | Depending on the infrastructure a given software system is installed, we can divide the enterprise software components into 2 main categories. 7 | 8 | - On premise systems which are running within enterprise perimeter 9 | - Cloud services which are hosted by 3rd party organizations in public cloud 10 | 11 | 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). 12 | 13 | ![Hybrid-Integration-Pattern](images/Hybrid-Integration-Pattern.png) 14 | 15 | 16 | As depicted in the above figure, hybrid integration platform should be capable of supporting functional requirements like 17 | - Data mapping/transformation 18 | - Protocol translations 19 | - Service orchestrations 20 | - Connecting to cloud services 21 | - Connecting to proprietary/legacy systems 22 | - Routing 23 | - Enterprise Integration Patterns 24 | 25 | On top of these functional requirements, another key aspect of selecting a proper HIP is the flexibility of development. This choice needs to be made based on the type of developers available within your organization. There can be different types of developers available within your enterprise like 26 | 27 | - Integration specialists - Domain experts who understands various EIP patterns, DSLs 28 | - Citizen Integrators - Not much experts but can implement use cases with a high level config language like XML or UIs 29 | - Software Developers - Willing to do the development with programming language 30 | -------------------------------------------------------------------------------- /vendor-neutral/Istio-Service-Mesh-Pattern.md: -------------------------------------------------------------------------------- 1 | # Istio Service Mesh Pattern 2 | 3 | ## Introduction 4 | Microservices Architecture (MSA) has given enterprise architects many challenges while offering outweighing number of advantages. It is easy to start with and with the number of services increases and the functionality is getting more and more granular, managing the services and their interactions become complex. Microservices communicated in 3 different ways 5 | 6 | - Ingress traffic (requests coming from external clients) 7 | - Intra service traffic (requests coming from another microservice) 8 | - Egress traffic (requests going out to an external service) 9 | 10 | The above mentioned different types of communication can happen either synchronously or asynchronously over different protocols. Some of them are 11 | - HTTP 1.1/2 12 | - Websocket 13 | - gRPC 14 | - TCP 15 | 16 | Managing these different forms of communications within a complex microservices architecture has become a major problem which needs to be solved when adopting a microservices strategy. The solution for this complex problem is the "Service Mesh" which is a "Network of microservices which are communicated with each other, with external systems over standard protocols". Service Meshes contains 2 layers where each layer performs a selected set of functionality. 17 | 18 | 1) Data plane - is responsible for communication across microservices as well as ingress and egress traffic 19 | 2) Control plane - provides control over networking of microservices and their interactions 20 | 21 | Istio is a service mesh technology which supports both data plane and control plane functionality with a platform independent manner. It can run with infrastructures like kubernetes, nomad and consul. 22 | 23 | ## Architecture 24 | 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. 25 | 26 | ![Istio Service Mesh Pattern](images/Istio-Service-Mesh-Pattern.png) 27 | 28 | 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. 29 | 30 | At the top of the picture you can find 2 microservices which are deployed in containers within kubernetes platform as pods. These pods contains another component alongside the microservice which is the envoy proxy which acts as the data plane within the Istio service mesh. This pod is then exposed as a kubernetes service. There are 2 kubernetes services depicted in the above picture. 31 | 1) helloworld service - expose via 9095 port 32 | 2) test service - expose via 9095 port 33 | 34 | In addition to the data plane, there are 4 main control plane components depicted in the above picture. Those are 35 | 1) Mixer - Which collects attributes from envoy proxies and enforce policy checks and collect telemetry information. If you need to extend the functionality of the mixer, you can write a mixer adapter which can process this metadata and do additional policy enforcements and analytics 36 | 2) Pilot - It provides functionalities like service discovery, configuration of error handling and routing 37 | 3) Citadel - This provides the service to service security (mTLS) as well as end user authentication (JWT) capabilities 38 | 4) Galley - This is a tool which validated the istio configurations and inject them to proxies and distribute within the service mesh 39 | 40 | ## How it works in runtime 41 | Once the Istio SM is up and running with the above mentioned components, let's see how the communication between different components happen. There are mainly 3 scenarios. 42 | 43 | ### A message going from testservice to helloworld service 44 | Let's consider a scenario where testservice needs to communicate to helloworld service. Given that both services are exposed as kubernetes services, they can talk to each other using service name as host name. The endpoint URL which testservice calls within it would be 45 | 46 | - http://helloworldservice:9095/ 47 | 48 | When the request is made from testservice, it will first go through the envoy proxy within its pod and then connect to envoy proxy within the helloworld service and then it will be forwarded to the helloworld service. When the two envoy proxies are communicated with each other over the network, proxy on the testservice pod will push some attributes to the mixer for runtime policy checks. If those policy checks are successful only, the request will be sent to the envoy proxy on the helloworld service side. 49 | 50 | ### A message coming from external client to helloworld service (ingress traffic) 51 | The other scenario is the most common case where an external application which resides outside the service mesh wanted to communicate with a microservice. This type of traffic is called as "ingress". In kubernetes, it uses an ingress controller to accept all the ingress traffic towards a kubernetes cluster. Similarly, in istio, it has extended the ingress controller functionality to its own concepts called a "gateway" and a "virtual service". When istio is started, it starts up a set of pods called "ingress-gateway" which can accept traffic coming from external clients. These ingress-gateway pods can be configured using a "gateway" configuration which specifies the protocol and the port which is exposed to external clients. Then this gateway needs to be configured to route the traffic to respective services within the service mesh using a "virtual service" where you can define context paths and the destination URLs for routing ingress traffic. 52 | 53 | If an external client wants to connect to helloworld service, it can send the request to following URL 54 | 55 | - http://:80/helloworld 56 | 57 | This request will be accepted by the envoy proxy within the ingress-gateway pod and then forwarded into the helloworld kubernetes service. Within the helloworld service pod, it will first received by the envoy proxy and then forwarded to microservice. 58 | 59 | ### A message going out from a microservice to an external service (egress traffic) 60 | If a microservice within the service mesh wanted to send a message to a service which lives outside the service mesh, then it can choose 2 options. 61 | 1) Use an egress gateway and send the request through that 62 | In this scenario, request will be intercepted by an envoy proxy runnnig within the egress gateway. It is similar to the way we have configured the ingress gateway with gateway and virtual service. 63 | 2) Call the backend URL directly from the microservice 64 | In this, requests will be directly going from microservice via the envoy proxy within the same pod to external URLs. 65 | -------------------------------------------------------------------------------- /vendor-neutral/Kubernetes-Deployment-Pattern.md: -------------------------------------------------------------------------------- 1 | # Kubernetes Deployment Pattern 2 | 3 | ## Introduction 4 | Container based deployments are becoming more and more popular within enterprise software architectures due to the many advantages it bring to the table. There are many articles which explains the advantages of containers vs virtual machines or physical machines. Running your application within a container does not solve all your problems. To reap the full benefits of a container based deployment, containers needs to be properly managed. Container orchestration platforms does just that. Kubernetes has become the defacto standard in container orchestration. It provides capabilities like 5 | 6 | - Run work loads (applications) in containers 7 | - Automated rollouts and rollbacks 8 | - Service discovery and load balancing 9 | - Self-healing and automatic scaling 10 | - Storage Orchestration 11 | 12 | In simple terms, kubernetes has provided an operating system to run your work loads (applications) within a data center by hiding the underlying complexity of the data center. Similar to running an application on your laptop or desktop, kubernetes provides a higher level interfaces to run your applications on containers. 13 | 14 | ## Architecture 15 | In kubernetes, there are few concepts which we need to understand before diving deep into the solutions architecture. 16 | 17 | #### Pod 18 | Pod is the smallest unit of execution in kubernetes. It can run one or more containers and has its own ip address. 19 | 20 | #### Service 21 | A service is a kubernetes component which can wrap one or more similar pods and expose a given functionality (service) to outside world. A service can expose more than one pod and load balance traffic between them. Service has its own IP address and port when accessing from external client. 22 | 23 | #### Ingress Controller 24 | This provides an interface to external clients to access the services which are running within the kubernetes cluster. Typically, major load balaning vendors have implementations of this ingress controller. 25 | 26 | #### Deployment 27 | A deployment is a configuration which can create a given set of kubernetes artefacts like pods, services, replica sets, etc. 28 | 29 | #### Namespace 30 | 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. 31 | 32 | ![Kubernetes Deployment Pattern](images/Kubernetes-Deployment-Pattern.png) 33 | 34 | As depicted in the above figure, 35 | 36 | - Individual work loads or applications can run within a pod as one or more containers. 37 | - Pod can contain the (micro)service, a support service (e.g. database), side car proxy (e.g. envoy) and other containers based on the requirement. 38 | - A single pod cannot cannot offer services to a scaling client requirements and grouping multiple pods into a service is the correct approach to take when deploying in kubernetes. 39 | - These services can expose the functionality of pods to external client through an ingress controller. 40 | - When designing these services, categorizing them based on the functionality into namespaces is recommended. 41 | - Once these namespaces are defined, the cluster wide resource allocations can be easily done. As an example, if a given set of services require more resources than the other services, you can enforce resource allocations at namespace level. 42 | 43 | ## Under the hood 44 | Kubernetes runs on top of an infrastructure layer. This can be any of the physical, virtual or cloud based resources. To set up a kubernetes cluster on a given infrastructure, you have to setup the relevant kubernetes components. 45 | 46 | #### Overlay network 47 | Kubernetes has various components which acts like their own hosts with their own ip addresses, port ranges, and access with localhost interfaces. All these activities are controller by the overlay network implemented in kubernetes platform. It allows services within kubernetes to contact other services using their own ClusterIPs while routing external traffic from external IP addresses. 48 | 49 | #### Kubernetes master 50 | These are the nodes which controls the state of the kubernetes cluster. It collects information from kubernetes workers and push commands to these workers to maintain the state. 51 | 52 | #### Kubernetes worker 53 | These are the nodes which runs the actual work loads in a container platform as pods, services. These workers get commands from manager to run the work loads. 54 | 55 | #### etcd 56 | Kubernetes uses etcd as the key value store to keep the metadata about the state of the kubernetes cluster. 57 | 58 | #### Image repository 59 | Kubernetes runs containers using an image repository. This repository contains the container images which contains the work load. 60 | 61 | #### Storage 62 | Containers are ephemeral in nature and they will come and go without keeping any state. But all the applications cannot survive without the state. To keep state across container restarts, kubernetes offers storage services. 63 | 64 | Even though not directly related to core kubernetes functionalities, monitoring and logging plays a key role when managing a kubernetes environment. It provides visibility into the kubernetes cluster and it's operations. Having proper monitoring is a key when monitoring the application level details for debugging issues. 65 | 66 | -------------------------------------------------------------------------------- /vendor-neutral/Layered-Architecture-Pattern.md: -------------------------------------------------------------------------------- 1 | ## Layered Architecture Pattern 2 | 3 | ### Introduction 4 | Enterprise software systems needs to build assuming that every functional requirement can be varied over the time. Scope creeps and requirement changes are pretty common in enterprise software systems. The business leaders always wants to put the best piece of functionality in front of their customers no matter what is going on down under. 5 | 6 | Software systems are not started in a manner that they are well thought out at the beginning. The reason was that, those systems had limited capabilities and many other challenges like hardware capabilities, sofrware capabilities, cost. It is understandable that these systems are not in the same way that enterprise architects or business leaders wants it to be. It is the challenge ahead of a solutions architect to build a modular system which can be used for next 10 years without much hassle. 7 | 8 | ### Requirement identification 9 | 10 | Enterprise software systems are typically running down under and most of the end users like employees, partners and customers think that as a luxury in their hands and expect it to run 24x7x365. Users do not care the actual information coming in and how they are coming in. But the system designers have to think about a lot of factors when designing these systems. Here are some of the basic requirements which needs to be addressed with an enterprise software system. 11 | 12 | - Availability 13 | - Performance 14 | - Security 15 | - Monitoring 16 | - Quality of information 17 | 18 | ### Layered architecture 19 | 20 | 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. 21 | 22 | ![Layered Architecture Pattern](images/Layered-architecture-pattern.png) 23 | 24 | #### Data Access Layer 25 | 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. 26 | 27 | #### Integration Layer 28 | Your enterprise systems are built throughout a longer period of time and there can be many different systems which has been playing key parts in your enterprise system. These disparate systems needs to be interconnected in a manner that those systems does not need to be modified to understand the connecting systems. That is the task of an integration layer which interconnects systems which are communicating over different protocols, messaging formats. 29 | 30 | #### API Management Layer 31 | Exposing your business data through various consumer channels like mobile, web and other means is critical in providing an unmatching customer experience. API Management layer controls all the channels which exposes data to external and internal users and apply measures like security, throttling and monitoring so that every business transaction means something to the end user as well as the business. 32 | 33 | #### Web services Layer 34 | If your organization is somewhat ahead of time thinking and going with the bleeding edge technology, you could have ended up having some amount of your business data in cloud services, micro services or some type of HTTP services layer. This layer can be connected into either Integration Layer or API Management Layer which will eventually connect with the end users. 35 | 36 | #### Security 37 | Data security is not an afterthought anymore. Valuable business data and transactions needs to be properly secured and authentication and authorization of data access will be crucial in enterprise system design. 38 | 39 | #### Monitoring and Analytics 40 | At the end of the day, your business leaders need to grow your business each day and as system designers you should enable necessary capabilities through your design. Monitoring and analysis of business transactions is crucial in identifying the business and user trends within your platform as well as across the business domain. 41 | 42 | -------------------------------------------------------------------------------- /vendor-neutral/Micro-Architecture-Pattern.md: -------------------------------------------------------------------------------- 1 | ## Micro Architecture Pattern 2 | 3 | ### Introduction 4 | Microservices Architecture (MSA) is becoming the SOA of the modern era. Like the way SOA improved the enterprise software architecture with new patterns and architectures around that, Microservices Architecture (MSA) has tripped off several new architectural styles and new concepts around how people build enterprise software. Some of them are 5 | 6 | - Service Mesh  — Technique to communicate amongst microservices 7 | - Serverless  — Running your code as functions on cloud 8 | - Micro Integration  — Run your integrations as microservices 9 | - Micro Gateway  — Run your api gateways in a microservices compatible manner 10 | 11 | 12 | All these architectures can be categorized under the common umbrella of "microservices" and if we can identify an architecture style which supports all these different micro-micro architectures, that can be called as micro architecture. 13 | 14 | ### Micro Architecture 15 | 16 | ![Micro Architecture Pattern](images/Micro-Architecture-Pattern.png) 17 | 18 | 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. 19 | 20 | We have 3 groups of micro services in the figure with 3 different colors. The microservices started with MS are real back end business logic implementations. MS-X and MS-Y depicts 2 groups of micro services (e.g. lending and deposits microservices groups in a banking system). Each hexagon depicts a load-balanced, high available microservice (e.g. kubernetes service). The hexagons marked with MI are integration microservices which are integrating existing micro services (MS type) and provide a complex and advanced functionality. 21 | 22 | The arrows connecting microservices with each other depicts the service mesh functionality and internally, it uses a side car proxy (or not depending on the selected technology stack). This component provides functionalities like timeout, retry, circuit breaker, service discovery, load balancing at the transport layer(L3/L4). Then the configuration of the service mesh is done through the control plane of the service mesh. 23 | 24 | Then we have the 3 diamonds which demonstrate the API micro gateway functionality where these gateways offers functionalities like security, caching, throttling, rate limiting and analytics capabilities to the upstream micro services layer. In this diagram, we have used 3 different micro gateways for 3 groups of microservices. This can be extended in such a manner that each MS or MI can have their own micro gateway. 25 | 26 | Micro API Gateway is a special component in this architecture since it has some cross cutting features which are already available in other components. If we take the functionality of service mesh, it has some capabilities like load balancing, service discovery, circuit breaker which are already available in the micro gateway. It is important understand that these functionalities are available for internal, inter-micro service communication while micro gateway uses these functionalities to expose services externally. Which means that we cannot dismiss the necessaity of api gateway within a service mesh type architecture. 27 | 28 | The other cross-cutting component which overlaps with the micro api gateway is the micro integration layer where some capabilities like service orchestration, transformation and composition can be done at that layer. Here also we need to clearly understand that the micro integration layer offers these capabilities for internal services and at the developer level. But the types of capabilities available at the micro gateway are more towards external user interaction layer and sometimes users can directly use these features like API composition to build their own APIs. 29 | 30 | On the other hand, using Micro API Gateway as a replacement for service mesh or micro integration layer is not recommended even though it can serve the purpose for some of the cases. That approach will introduce lot more complexities when your system grows in the future. 31 | 32 | The next advancement or the service which can offer through this micro-architecture is the serverless (or Function as a Service — FaaS) capability to developers. Any technology vendor can combine the infrastructure layer with the micro gateway and micro integration capabilities which are hosted on their data centers to offer the serverless service to their customers so that customer can write their implementations in whatever the preferred programming language and run them as microservices under the hood within their infrastructure. In a serverless world, MS type implementations will be done by the users and all the other components will be deployed, hosted and maintained by the cloud provider. 33 | 34 | Finally, the applications can consume the relevant APIs by contacting relevant micro gateways. Based on the application type and the API requirements, same application can use all the micro gateways as well. 35 | 36 | As the last piece of this article, I’ll share some of the existing technologies which can utilize to realize this micro-architecture. 37 | 38 | #### Microservices 39 | 40 | - Java (SpringBoot, DropWizard) 41 | - Javascript (NodeJs) 42 | - Go 43 | 44 | #### Micro Integrations 45 | 46 | - Ballerina 47 | - Java (Spring Boot) 48 | 49 | #### Service Mesh 50 | 51 | - LinkerD 52 | - Istio/envoy 53 | - Nginx 54 | 55 | #### API Micro Gateway 56 | 57 | - WSO2 APIM 58 | - Apigee 59 | - Kong 60 | 61 | #### Infrastructure 62 | 63 | - IaaS (GCP, AWS, Azure) 64 | - VM (VMWare) 65 | - Physical (Bare metal) 66 | 67 | #### Containerization 68 | 69 | - Docker 70 | - Rocket 71 | 72 | #### Orchestration 73 | 74 | - Kubernetes 75 | - Docker Swarm 76 | - Mesos DC/OS 77 | -------------------------------------------------------------------------------- /vendor-neutral/Microservices-Security-Pattern-Policy-Based.md: -------------------------------------------------------------------------------- 1 | # Microservices Security Pattern - Implementing a policy based security for microservices with OPA 2 | 3 | ## Introduction 4 | Implementing security for a microservices architecture can be done with 2 approaches. 5 | 6 | 1) Centralized security layer - A common security service (STS) running as a microservice which can be consumed by other microservices. This security service can take care of all the security related requirements by having it's own user store and security policies. 7 | 8 | 2) Distributed security layer - Instead of having the security service external to the microservice (Pod), each microservice can run a security service which is dedicated to the MS itself. With this approach, MS can have more finer grained access policies which are customized according to the service. 9 | 10 | Some people might argue that having a centralized security layer would kill the purpose of whole microservices architecture. But in reality, it is not entirely true. You can run this centralized security component as a microservice with all the characteristics of a microservice like auto scaling, containerized, highly available, componentized manner. Most of the current security implementations within microservices deployments today follow this approach. 11 | 12 | Even though the above mentioned centralized security architecture works fine with MSA, we shouldn't stop looking for a better alternative which is distributed in nature. Instead of delegating the security aspect to a separate service, microservice can run the security service as a sidecar within the same pod so that each and every microservice has it's own security component. This is what exactly Open Policy Agent (OPA) is trying to promote with it's decoupled policy agent approach. You can read more about OPA by referring to the below link. 13 | 14 | [OPA Site](https://www.openpolicyagent.org/) 15 | 16 | ## Architecture 17 | 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. 18 | 19 | ![Microservices-Security-OPA](images/Micoservices-Security-Pattern-Policy-Based-OPA.png) 20 | 21 | 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. 22 | 23 | - Microservice - The actual business logic implementation of the service 24 | - Sidecar proxy (envoy) - This is the supportive proxy which takes care of inter-service communication and related matters 25 | - Open Policy Agent - This is running as a separate container which acts as the security service for the microservice. It uses a data store and a policy store to store the user details as well as policies respectively. These components can run within the pod itself or within the OPA container itself. 26 | 27 | ## How it works? 28 | Let's assume an external user wants to access microservice A. User will present his token (Oauth2, JWT, etc.) to the LB/IC/MGW layer and it will validate the user against the security controls which are applied at the global level. Then it will pass the user information (possibly through a JWT) to the microservice through the sidecar proxy. Once the microservice recieves this information, it needs to validate this information against the policies which are related to it. It will call the OPA service to validate the user information along with the accessed service/resource details. Then OPA will respond back with a JSON response mentioning the validity of the request. Once this validation is successful, microservice will execute the remaining business logic and provide the deisred output to the user. 29 | 30 | ### How to manage policies and data 31 | One of the key advantages of this approach is that each and every microservice can have it's own set of policies and data which is local to that microservice. If needed, this data and policies can be shared across multiple OPA agents. If a user needs to modify a security policy related to a microservice, he does not need to modify global components like LB/MGW/IC. Instead, it can use the REST APIs which available in the OPA to manage and control the policies and data. 32 | 33 | ### Using OPA as a library with go microservices 34 | In addition to running as a separate container alongside the microservice, OPA can be used as a library if you are implementing microservice in go programming language. This approach will slightly modify the above architecture by moving the OPA agent within the microservice container itself as a runtime component. 35 | 36 | ## Future 37 | With the increasing adoption of MSA, a simple, distributed security architecture is evloving. OPA is one such implementation where is uses the distributed, policy based security approach for microservices which blends nicely with existing tools like kubernetes and istio. Going forward, this sort of implementations can become the norm and the de-facto standard for microservices security. This is just the beginning! 38 | 39 | 40 | 41 | -------------------------------------------------------------------------------- /vendor-neutral/Microservices-without-service-mesh-pattern.md: -------------------------------------------------------------------------------- 1 | ## Introduction 2 | Microservices are becoming a commodity in the enterprise world. The reason being the agility and the modularity it brings to the software development and delivery process. It is not that difficult to getting started with the microservices since there are enough tools and frameworks available to bootstrap the microservices-based application development. But there is a point that most teams who adopt microservices find it challenging to deal with. That is when the number of microservices goes beyond a certain limit (let’s say 25 in some cases), people start realizing the real challenges that microservices architecture brings to the table. Some major challenges most teams face at this point are 3 | 4 | - Inter-service communication (east-west traffic) 5 | - Observability 6 | - Failure handling 7 | 8 | The popular solution to deal with these challenges is the Service Mesh. A service mesh is a technology that is used to help microservices communicate with each other in a centrally manageable manner without adding complexity to the microservices logic. It is capable of handling functions such as 9 | 10 | - Routing 11 | - Error handling 12 | - Service Discovery 13 | - Observability 14 | - Load balancing 15 | - Access Control (Security) 16 | 17 | ## What is a Service Mesh? 18 | The figure below depicts the general architecture of a service mesh. 19 | 20 | ![Service Mesh Architecture](./images/microservices-wo-sm-1.png) 21 | 22 | Figure: Service Mesh Architecture 23 | 24 | The data plane takes care of the communication of messages from one service to another service while the control plane takes care of the supporting functionalities such as routing, access control, and service discovery. 25 | 26 | It really looks like a promising solution to face the challenges of microservices architecture when the number of microservices goes beyond a certain limit. There is Istio Service Mesh which is backed by industry giants such as Google, IBM, Microsoft, and most people think that if those big guys are using it why shouldn’t we? 27 | 28 | This was the trend for the last couple of years and the general consensus that we find in the industry is that there are more teams struggling to manage microservices with Service Meshes than who succeeded with it. Even Istio is making a lot of changes to its architecture and rethinking the ways to improve the service mesh technology. 29 | 30 | ## Microservices with first principles 31 | Let’s take a step back and think about one of the first principles of the microservices architecture which is the idea of “Smart endpoints and dumb pipes”. Most people seem to forget this idea when designing microservices platforms. The practical meaning of this idea is that microservices can use an entity such as a message broker (dumb pipe) when communicating with each other (inter-service communication). If we expand this idea into the practical world, we can get rid of the Service Mesh and build a microservices architecture that is capable of handling the challenges we mentioned at the beginning. 32 | 33 | Inter-Service communication can be implemented in an asynchronous manner using an event-based publish-subscribe model or a request-reply model. There are message brokers such as NATS that support both these models of communication. 34 | 35 | Error handling is much easier since communication happens between the microservice and the message broker. We can use acknowledgments and various message guarantee levels such as exactly once, at least once and at-most-once to make sure that messages are properly delivered to the recipients. With the features such as persistent message storage, applications can replay lost messages without ever contacting the sender. 36 | 37 | Observability can be implemented with the usage of UUIDs attached to the messages and using a centralized observability platform such as ELK stack or Prometheus, Grafana, and Loki stack. 38 | 39 | ## Microservices with NATS 40 | The below figure depicts the architecture of using NATS as the inter-service communication mechanism to build a microservices-based platform. 41 | 42 | ![Microservices with NATS](./images/microservices-wo-sm-2.png) 43 | 44 | Figure: Microservices Inter-Service Communication with NATS 45 | 46 | The preceding figure introduces the NATS message broker in place of the service mesh for inter-service communication. It allows services to communicate with each other without worrying about the other services. The communication happens in a fully decoupled manner and services can process messages and respond to them according to their own interests. The NATS server is capable of providing the capabilities such as 47 | 48 | - Security 49 | - Error handling (via message guarantees and acks) 50 | - Routing (via subject-based message communication) 51 | - Scalability (via clustering) 52 | - Performance (best-in-class performance) 53 | - Observability (via logging and Prometheus agents) 54 | - Load balancing (via queue-based messaging) 55 | 56 | In fact, NATS provides the same set of capabilities (even more) as the service mesh without adding much complexity to the overall solution. It eases out the dependencies of services with each other and allows them to operate in a truly independent manner. 57 | 58 | If you need to learn more on this topic and understand how to design and implement microservices-based enterprise platforms, you can read this book on the subject from the following links. It provides practical examples of how to design and implement a microservices-based platform with NATS. 59 | [Designing Microservices Platforms with NATS](https://www.packtpub.com/product/designing-microservices-platforms-with-nats/9781801072212) 60 | -------------------------------------------------------------------------------- /vendor-neutral/Multi-Cloud-Enterprise-Deployment-Pattern.md: -------------------------------------------------------------------------------- 1 | # Multi Cloud Enterprise Deployment Pattern 2 | 3 | ## Introduction 4 | Enterprises are expanding their IT operations to match with the consumer demand and to become the leader in their respective industries. Cloud has provided a reliable platform to these enterprises to run their business operations without much hassle. Few years ago, Amazon Web Services or AWS was the only choice people had when they want to deploy their applications in a cloud environment. But the market has been changed and there are many other vendors who offers cloud infrastructure at a competitive price. This allowed the enterprises to choose the best cloud environment for a given task rather than locking into a single vendor. 5 | 6 | ### Advantages 7 | Instead of running all your business functionality in a single cloud or on-premise platform, running on multiple clouds give enterprises many advantages. Here are few advantages. 8 | 9 | - Provides much better service availability - Given that your applications are running across mutiple cloud environments, your services can run without much interruption even if an entire cloud system goes down. 10 | 11 | - Get enterprises free from vendor lock-in - Cloud vendors always try to get as much applications into their own cloud and that will lock you into a single vendor so that you cannot get away from them even you need to do it. With the multi-cloud approach, you don't need to lock into any vendor and move away from them at any time. 12 | 13 | - Can negotiate for better deals - Once you are in multi cloud, you have more power to demand for discounts since every vendor wants to increase their share of your account. 14 | 15 | - Can use best technology for the applications - Different cloud vendors are strong in different areas. When you have a multi cloud strategy, you can select the best technology for your task which is provided by the resective cloud vendor. 16 | 17 | - Can provide better performance to consumers - Your applications can run on multiple clouds and expose the functionality through cloud gateways which are closed to the consumers in relevant cloud deployments based on locations. 18 | 19 | ## Architecture 20 | 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. 21 | 22 | ![Multi-Cloud-Enterprise-Deployment-Pattern](images/Multi-Cloud-Enterprise-Deployment-Pattern.png) 23 | 24 | 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 25 | 26 | - Management components which are used to add/modify artefacts to runtimes 27 | - Analytics and monitoring components which are capable of monitoring across multiple clouds 28 | - Master datasources which acts as master in a master/slave or master/master (multi-master) deployment 29 | - Runtime components which serves the traffic from consumers 30 | 31 | In addition to this master deployment, there can be multiple of worker deployments which contains 32 | 33 | - Runtime components which served the traffic from customers 34 | - Master/Slave data sources which contains runtime and metadata which are required by the applications 35 | 36 | The above architecture explains at a high level which type of components can run on which parts of the deployment. Let's understand this better with a reference architecture where WSO2 API Manager is deployed in a multi cloud deployment architecture. 37 | 38 | ![WSO2 API Manager Multi Cloud Deployment](vendor-specific/wso2/WSO2-APIM-Multi-Cloud-Deployment-Pattern.png) 39 | 40 | As depicted in the above figure, management components of the WSO2 API Manager are deployed in the master deployment. This can be a deployment on an on-premise DC, private cloud or a public (shared) cloud. The components in the master deployment are 41 | 42 | - API Publisher 43 | - API Store 44 | - API Analytics 45 | - API Key Manager 46 | - API Gateway 47 | 48 | Additionally, you can have worker deployments across different cloud environments which contains the APIM Gateway component. 49 | 50 | ## Usage Patterns 51 | Multi cloud deployment architecture can be used for different use cases. Here are some of the usage patterns. 52 | 53 | - Run production on master and pre-production on worker deployments 54 | - Run production on both master and worker deployments for load balancing, high availability and better performance 55 | - Run bursts in worker clouds while running main production load in master cloud 56 | - Run DR site on worker cloud while running production in master 57 | - Run workloads across clouds based on the load and the cheapest pricing option (cloud arbitrage) 58 | 59 | ## Challenges 60 | While there are many advantages in the multi cloud strategy, there are challenges which needs to be properly managed. Here are some disadvantages 61 | 62 | - Managing deployment across multiple clouds require expertise on respective clouds which is costly than using a single infrastructure 63 | - Performance will get impacted when the worker deployments needs to contact with master deployment 64 | - Increased security risk with a widen attack surface 65 | 66 | 67 | ## Conclusion 68 | Multi-cloud strategy is something every enterprise is looking into because of the advantages it brings around the availability, pricing and freedom from vendor-locking. In the same time, it is not coming without it's own challenges. With the multi cloud strategies becoming more main stream, these challenges will be addressed through proper solutions. 69 | -------------------------------------------------------------------------------- /vendor-neutral/README.md: -------------------------------------------------------------------------------- 1 | ## Vendor neutral architecture patterns 2 | This directory contains the architecture patterns are generic and vendor independent. In some cases, we had to use certain vendors to elaborate the idea better. 3 | 4 | - API Security pattern 5 | [API Security Pattern](API-Security-Pattern.md) 6 | 7 | - API-led Connectivity pattern 8 | [API-led Connectivity pattern](API-led-Connectivity-Pattern.md) 9 | 10 | - Anti Corruption Layer pattern 11 | [Anti Corruption Layer Pattern](Anti-Corruption-Layer-Pattern.md) 12 | 13 | - Ballerina sidecar pattern 14 | [Ballerina sidecar pattern](Ballerina-sidecar-pattern-microservices.md) 15 | 16 | - Centralized Identity and Access Management Pattern 17 | [Centralized Identity and Access Management Pattern](Centralized-Identity-Access-Management-Pattern.md) 18 | 19 | - Change Data Capture Pattern [Change Data Capture Pattern](Introduction-to-Change-Data-Capture.md) 20 | 21 | - Cloud Migration with Strangler Pattern 22 | [Cloud Migration with Strangler Pattern](Cloud-Migration-Strangler-Pattern.md) 23 | 24 | - Decentralized Enterprise Architecture pattern 25 | [Decentralized Enterprise Architecture Pattern](Decentralized-Enterpise-Architecture-Pattern.md) 26 | 27 | - Enterprise CICD pattern 28 | [Enterprise CICD Pattern](Enterprise-CICD-Pattern.md) 29 | 30 | - Enterprise Software Stack 31 | [Enterprise Software Stack](Enterprise-Software-Stack.md) 32 | 33 | - Event Driven Architecture Kafka Pattern 34 | [Event Driven Architecture Kafka Pattern](Event-Driven-Architecture-Kafka-Pattern.md) 35 | 36 | - GraphQL enterprise architecture patterns 37 | [GraphQL Pattern](GraphQL-Pattern.md) 38 | 39 | - Hybrid API Management pattern 40 | [Hybrid API Management Pattern](Hybrid-API-Management-Pattern.md) 41 | 42 | - Hybrid Integration pattern 43 | [Hybrid Integration Pattern](Hybrid-Integration-Pattern.md) 44 | 45 | - Istio Service Mesh pattern 46 | [Istio Service Mesh Pattern](Istio-Service-Mesh-Pattern.md) 47 | 48 | - Kubernetes Deployment pattern 49 | [Kubernetes Deployment Pattern](Kubernetes-Deployment-Pattern.md) 50 | 51 | - Layered architecture pattern 52 | [Layered Architecture Pattern](Layered-Architecture-Pattern.md) 53 | 54 | - Micro architecture pattern 55 | [Micro Architecture Pattern](Micro-Architecture-Pattern.md) 56 | 57 | - Microservices with NATS messaging 58 | [Microservices with NATS messaging](Microservices-with-NATS-messaging.md) 59 | 60 | - Microservices without Service Mesh 61 | [Microservices without Service Mesh](Microservices-without-service-mesh-pattern.md) 62 | 63 | - Microservices Security Pattern - Policy based 64 | [Microservices Security Pattern - Policy based](Microservices-Security-Pattern-Policy-Based.md) 65 | 66 | - Multi Cloud Enterprise Deployment pattern 67 | [Multi Cloud Enterprise Deployment Pattern](Multi-Cloud-Enterprise-Deployment-Pattern.md) 68 | 69 | - OpenAPI Based Digital Transformation pattern 70 | [OpenAPI Based Digital Transformation Pattern](OpenAPI-Based-Digital-Transformation-Pattern.md) 71 | 72 | - SOA Governance to API Management Pattern 73 | [SOA Governance to API Management Pattern](SOA-governance-to-API-management-pattern.md) 74 | 75 | - Microservices Governance and API Management Pattern 76 | [Microservices Governance and API Management Pattern](Microservices-Governance-And-API-Management.md) 77 | 78 | - Innovation Driven Enterprise Platform Architecture 79 | [Innovation Driven Enterprise Platform Architecture](Innovation-Driven-Enterprise-Platform-Architecture.md) 80 | -------------------------------------------------------------------------------- /vendor-neutral/images/API-Security-Pattern.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-neutral/images/API-Security-Pattern.png -------------------------------------------------------------------------------- /vendor-neutral/images/API-led-Business-Transformation-1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-neutral/images/API-led-Business-Transformation-1.png -------------------------------------------------------------------------------- /vendor-neutral/images/API-led-Business-Transformation-2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-neutral/images/API-led-Business-Transformation-2.png -------------------------------------------------------------------------------- /vendor-neutral/images/Anti-Corruption-Layer-Pattern.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-neutral/images/Anti-Corruption-Layer-Pattern.png -------------------------------------------------------------------------------- /vendor-neutral/images/Ballerina-sidecar-pattern-for-microservices.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-neutral/images/Ballerina-sidecar-pattern-for-microservices.png -------------------------------------------------------------------------------- /vendor-neutral/images/Brownfield-enterprise-security.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-neutral/images/Brownfield-enterprise-security.png -------------------------------------------------------------------------------- /vendor-neutral/images/Centralized-Identity-Access-Management.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-neutral/images/Centralized-Identity-Access-Management.png -------------------------------------------------------------------------------- /vendor-neutral/images/Decentralized-Enterprise-Architecture-Pattern.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-neutral/images/Decentralized-Enterprise-Architecture-Pattern.png -------------------------------------------------------------------------------- /vendor-neutral/images/Enterprise-CICD-Pattern.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-neutral/images/Enterprise-CICD-Pattern.png -------------------------------------------------------------------------------- /vendor-neutral/images/Enterprise-Software-Layered-Architecture.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-neutral/images/Enterprise-Software-Layered-Architecture.png -------------------------------------------------------------------------------- /vendor-neutral/images/Event-Driven-Architecture-Kafka-Pattern.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-neutral/images/Event-Driven-Architecture-Kafka-Pattern.png -------------------------------------------------------------------------------- /vendor-neutral/images/Event-Driven-Architecture-Pattern.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-neutral/images/Event-Driven-Architecture-Pattern.png -------------------------------------------------------------------------------- /vendor-neutral/images/GraphQL-Pattern-1-dataservice.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-neutral/images/GraphQL-Pattern-1-dataservice.png -------------------------------------------------------------------------------- /vendor-neutral/images/GraphQL-Pattern-2-integration-hub.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-neutral/images/GraphQL-Pattern-2-integration-hub.png -------------------------------------------------------------------------------- /vendor-neutral/images/GraphQL-Pattern-3-hybrid-integration.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-neutral/images/GraphQL-Pattern-3-hybrid-integration.png -------------------------------------------------------------------------------- /vendor-neutral/images/GraphQL-Pattern-4-API-protected.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-neutral/images/GraphQL-Pattern-4-API-protected.png -------------------------------------------------------------------------------- /vendor-neutral/images/GraphQL-Pattern-5-Operation-protected.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-neutral/images/GraphQL-Pattern-5-Operation-protected.png -------------------------------------------------------------------------------- /vendor-neutral/images/Hybrid-API-Management-Pattern.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-neutral/images/Hybrid-API-Management-Pattern.png -------------------------------------------------------------------------------- /vendor-neutral/images/Hybrid-Integration-Pattern.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-neutral/images/Hybrid-Integration-Pattern.png -------------------------------------------------------------------------------- /vendor-neutral/images/Istio-Service-Mesh-Pattern.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-neutral/images/Istio-Service-Mesh-Pattern.png -------------------------------------------------------------------------------- /vendor-neutral/images/Kubernetes-Deployment-Pattern.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-neutral/images/Kubernetes-Deployment-Pattern.png -------------------------------------------------------------------------------- /vendor-neutral/images/Layered-architecture-pattern.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-neutral/images/Layered-architecture-pattern.png -------------------------------------------------------------------------------- /vendor-neutral/images/Micoservices-Security-Pattern-Policy-Based-OPA.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-neutral/images/Micoservices-Security-Pattern-Policy-Based-OPA.png -------------------------------------------------------------------------------- /vendor-neutral/images/Micro-Architecture-Pattern.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-neutral/images/Micro-Architecture-Pattern.png -------------------------------------------------------------------------------- /vendor-neutral/images/Migrating-architecture-with-strangler-pattern-0.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-neutral/images/Migrating-architecture-with-strangler-pattern-0.png -------------------------------------------------------------------------------- /vendor-neutral/images/Migrating-architecture-with-strangler-pattern-1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-neutral/images/Migrating-architecture-with-strangler-pattern-1.png -------------------------------------------------------------------------------- /vendor-neutral/images/Migrating-architecture-with-strangler-pattern-2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-neutral/images/Migrating-architecture-with-strangler-pattern-2.png -------------------------------------------------------------------------------- /vendor-neutral/images/Multi-Cloud-Enterprise-Deployment-Pattern.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-neutral/images/Multi-Cloud-Enterprise-Deployment-Pattern.png -------------------------------------------------------------------------------- /vendor-neutral/images/OpenAPI-DT-Pattern-img1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-neutral/images/OpenAPI-DT-Pattern-img1.png -------------------------------------------------------------------------------- /vendor-neutral/images/OpenAPI-DT-Pattern-img2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-neutral/images/OpenAPI-DT-Pattern-img2.png -------------------------------------------------------------------------------- /vendor-neutral/images/OpenAPI-DT-Pattern-img3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-neutral/images/OpenAPI-DT-Pattern-img3.png -------------------------------------------------------------------------------- /vendor-neutral/images/cdc-architecture.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-neutral/images/cdc-architecture.png -------------------------------------------------------------------------------- /vendor-neutral/images/cdc-conceptual-view.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-neutral/images/cdc-conceptual-view.png -------------------------------------------------------------------------------- /vendor-neutral/images/cdc-debezium-architecture.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-neutral/images/cdc-debezium-architecture.png -------------------------------------------------------------------------------- /vendor-neutral/images/cdc-intro.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-neutral/images/cdc-intro.png -------------------------------------------------------------------------------- /vendor-neutral/images/cdc-maxwell-event-format.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-neutral/images/cdc-maxwell-event-format.png -------------------------------------------------------------------------------- /vendor-neutral/images/four-pillars-drive-innovation-in-enterprise-platforms.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-neutral/images/four-pillars-drive-innovation-in-enterprise-platforms.png -------------------------------------------------------------------------------- /vendor-neutral/images/microservices-governance-0.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-neutral/images/microservices-governance-0.png -------------------------------------------------------------------------------- /vendor-neutral/images/microservices-governance-1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-neutral/images/microservices-governance-1.png -------------------------------------------------------------------------------- /vendor-neutral/images/microservices-governance-2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-neutral/images/microservices-governance-2.png -------------------------------------------------------------------------------- /vendor-neutral/images/microservices-governance-3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-neutral/images/microservices-governance-3.png -------------------------------------------------------------------------------- /vendor-neutral/images/microservices-governance-4.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-neutral/images/microservices-governance-4.png -------------------------------------------------------------------------------- /vendor-neutral/images/microservices-governance-5.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-neutral/images/microservices-governance-5.png -------------------------------------------------------------------------------- /vendor-neutral/images/microservices-governance-7.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-neutral/images/microservices-governance-7.png -------------------------------------------------------------------------------- /vendor-neutral/images/microservices-governance-8.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-neutral/images/microservices-governance-8.png -------------------------------------------------------------------------------- /vendor-neutral/images/microservices-governance-and-api-management.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-neutral/images/microservices-governance-and-api-management.png -------------------------------------------------------------------------------- /vendor-neutral/images/microservices-governance-ibm.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-neutral/images/microservices-governance-ibm.jpeg -------------------------------------------------------------------------------- /vendor-neutral/images/microservices-mesh.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-neutral/images/microservices-mesh.png -------------------------------------------------------------------------------- /vendor-neutral/images/microservices-with-nats.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-neutral/images/microservices-with-nats.png -------------------------------------------------------------------------------- /vendor-neutral/images/microservices-wo-sm-1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-neutral/images/microservices-wo-sm-1.png -------------------------------------------------------------------------------- /vendor-neutral/images/microservices-wo-sm-2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-neutral/images/microservices-wo-sm-2.png -------------------------------------------------------------------------------- /vendor-neutral/images/nats-performance.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-neutral/images/nats-performance.png -------------------------------------------------------------------------------- /vendor-neutral/images/nats-pub-sub.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-neutral/images/nats-pub-sub.png -------------------------------------------------------------------------------- /vendor-neutral/images/nats-queue-groups.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-neutral/images/nats-queue-groups.png -------------------------------------------------------------------------------- /vendor-neutral/images/nats-request-reply.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-neutral/images/nats-request-reply.png -------------------------------------------------------------------------------- /vendor-neutral/images/nats-subject-based-messaging.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-neutral/images/nats-subject-based-messaging.png -------------------------------------------------------------------------------- /vendor-neutral/images/soa-governance-0.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-neutral/images/soa-governance-0.png -------------------------------------------------------------------------------- /vendor-neutral/images/soa-governance-1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-neutral/images/soa-governance-1.png -------------------------------------------------------------------------------- /vendor-neutral/images/soa-governance-2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-neutral/images/soa-governance-2.png -------------------------------------------------------------------------------- /vendor-neutral/images/soa-governance-3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-neutral/images/soa-governance-3.png -------------------------------------------------------------------------------- /vendor-neutral/images/soa-governance-4.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-neutral/images/soa-governance-4.png -------------------------------------------------------------------------------- /vendor-specific/aws/README.md: -------------------------------------------------------------------------------- 1 | ### Solutions Architecture Patterns specific to AWS platform 2 | 3 | - [AWS Solutions Architecture Site](https://aws.amazon.com/architecture) 4 | - [AWS Networking in a Nutshell](AWS-Networking-In-a-Nutshell.md) 5 | 6 | 7 | 8 | -------------------------------------------------------------------------------- /vendor-specific/aws/images/AWS-Networking-Services.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-specific/aws/images/AWS-Networking-Services.png -------------------------------------------------------------------------------- /vendor-specific/aws/images/AWS-Networking-in-a-nutshell.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-specific/aws/images/AWS-Networking-in-a-nutshell.png -------------------------------------------------------------------------------- /vendor-specific/azure/Azure-Networking-Services-in-a-nutshell.md: -------------------------------------------------------------------------------- 1 | ## Introduction 2 | Microsoft Azure is one of the up and coming cloud service providers that can be used to host your applications in the cloud. It has various cloud services which can be categorized as 3 | - IaaS — Infrastructure as a Service (Azure VMs, AKS) 4 | - PaaS — Platform as a Service (Azure logic apps, Azure Service Bus, Xamarin) 5 | - SaaS — Software as a Service (Office365, Dynamics365, Outlook) 6 | - FaaS — Function as a Service (Azure Functions) 7 | Regardless of what type of service you are going to utilize in the Azure cloud, you need to understand the networking model of the Azure to better utilize these services. This article discusses the various networking services available in Azure in a nutshell. 8 | 9 | ## Azure networking services 10 | The users of the Azure cloud can utilize various network services available in azure to deliver the best experience to the consumers of their respective business applications and services. These network services can be divided into 4 main categories. 11 | 12 | - Application delivery services — These are the services on the edge of the network which delivers the consumable services to end-users of the organizations who are using the Azure cloud to serve their customers 13 | - Application protection services — Application security is one of the utmost critical aspects of the cloud. These services protect the applications and services from all kinds of threats coming from malicious users 14 | - Connectivity services — Even though we consider cloud as a single entity, it consists of multiple disparate systems and applications which need to be interconnected. These connectivity services allow the cloud to build internal connectivity as well as external connectivity to and from the cloud infrastructure. 15 | - Network monitoring — In a distributed network, anything can fail. It is quite critical to monitor various points of the cloud infrastructure to debug the issues that can happen more often than not. Network monitoring services allow cloud users to monitor various services and take necessary actions on failures. 16 | 17 | Depending on the place within the data path in which these services are applied, I have come up with the below figure which puts all these services into a single diagram as a nutshell representation of Azure cloud networking services. 18 | 19 | ![Azure networking in a nutshell](images/Azure-Networking-in-a-Nutshell.png) 20 | 21 | Figure: Azure networking services in a nutshell 22 | 23 | As depicted in the above figure, azure networking services cover the full spectrum of connectivity between services spanning from service delivery, application security, intra/inter networking to the monitoring of the services. These services can be further detailed into the following services. 24 | 25 | ### Application Delivery Services 26 | User experience is critical when using cloud services since these resources are hosted all over the internet. These services make sure that applications are delivered to consumers with better performance without any jitter. 27 | 28 | - Content Delivery Network (CDN) — Delivers high-bandwidth content to users. CDNs store cached content on edge servers in point-of-presence (POP) locations that are close to end users, to minimize latency 29 | - Azure Front Door — Enables you to define, manage, and monitor the global routing for your web traffic by optimizing for best performance and instant global failover for high availability 30 | - Traffic Manager — Distributes traffic based on DNS to services across global Azure regions, while providing high availability and responsiveness 31 | - Load Balancer — Provides regional load-balancing by routing traffic across availability zones and into your VNets. Provides internal load-balancing by routing traffic across and between your resources to build your regional application 32 | - Application Gateway — Azure Application Gateway is a web traffic load balancer that enables you to manage traffic to your web applications 33 | 34 | ### Application Protection Services 35 | These services provide the necessary infrastructure for securing the applications and services hosted in the cloud. 36 | 37 | - DDoS protection — High availability for your applications with protection from excess IP traffic charges 38 | Web Application Firewall (WAF) — Azure WAF with Application Gateway provides regional protection to entities in public and private address space. Azure WAF with Front Door provides protection at the network edge to public endpoints. 39 | - Azure Firewall — Azure Firewall is a managed, cloud-based network security service that protects your Azure Virtual Network resources. It’s a fully stateful firewall as a service with built-in high availability and unrestricted cloud scalability 40 | - Network Security Groups (NSG) — Full granular distributed end node control at VM/subnet for all network traffic flows 41 | - Virtual network service endpoints — Enables you to limit network access to some Azure service resources to a virtual network subnet 42 | 43 | ### Connectivity services 44 | These are the services that are used to build the connectivity between components within the cloud as well as outside the cloud. 45 | 46 | - Virtual network — Enables Azure resources to securely communicate with each other, the internet, and on-premises networks. 47 | - Express Route — Extends your on-premises networks into the Microsoft cloud over a private connection facilitated by a connectivity provider 48 | - VPN Gateway — Sends encrypted traffic between an Azure virtual network and an on-premises location over the public Internet. 49 | - Virtual WAN — Optimizes and automates branch connectivity to, and through, Azure. Azure regions serve as hubs that you can choose to connect your branches to. 50 | - Azure DNS — Hosts DNS domains that provide name resolution by using Microsoft Azure infrastructure. 51 | - Azure Bastion — Configure secure and seamless RDP/SSH connectivity to your virtual machines directly in the Azure portal over SSL. When you connect via Azure Bastion, your virtual machines do not need a public IP address 52 | 53 | ### Network Monitoring 54 | In the cloud, failure is inevitable and you should take necessary steps to monitor the failures and recover immediately. These services allow cloud users to monitor their applications and services. 55 | 56 | - Network Watcher — Helps monitor and troubleshoot connectivity issues, helps diagnose VPN, NSG, and routing issues, capture packets on your VM, automates triggering diagnostics tools using Azure Functions and Logic Apps 57 | - ExpressRoute Monitor — Provides real-time monitoring of network performance, availability, and utilization helps with auto-discovery of network topology, provides faster fault isolation, detects transient network issues, helps analyze historical network performance characteristics, supports multi-subscription 58 | - Azure Monitor — Helps you understand how your applications are performing and proactively identifies issues affecting them and the resources they depend on 59 | - Virtual Network TAP — Provides continuous streaming of virtual machine network traffic to packet collector, enables network and application performance management solutions and security analytics tools 60 | 61 | #### References : 62 | https://docs.microsoft.com/en-us/azure/networking/networking-overview 63 | -------------------------------------------------------------------------------- /vendor-specific/azure/README.md: -------------------------------------------------------------------------------- 1 | ### Solutions Archtecture Patterns specific to Microsoft Azure platform 2 | 3 | - [Azure solutions architecture site](https://azure.microsoft.com/en-us/solutions/architecture/) 4 | - [Cloud design patterns](https://docs.microsoft.com/en-us/azure/architecture/patterns/) 5 | - [Azure networking in a nutshell](Azure-Networking-Services-in-a-nutshell.md) 6 | 7 | -------------------------------------------------------------------------------- /vendor-specific/azure/images/Azure-Networking-in-a-Nutshell.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-specific/azure/images/Azure-Networking-in-a-Nutshell.png -------------------------------------------------------------------------------- /vendor-specific/gcp/README.md: -------------------------------------------------------------------------------- 1 | ### Solutions Architecture Patterns specific to Google Cloud Platform 2 | 3 | [GCP Solutions architecture web site](https://cloud.google.com/solutions/) 4 | 5 | -------------------------------------------------------------------------------- /vendor-specific/mulesoft/README.md: -------------------------------------------------------------------------------- 1 | ### Solutions Architecture Patterns specific to Mulesoft platform 2 | 3 | - [Mulesoft Deployment Options](https://docs.mulesoft.com/runtime-manager/deployment-strategies) 4 | -------------------------------------------------------------------------------- /vendor-specific/pivotal/Enterprise-Application-Workload.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-specific/pivotal/Enterprise-Application-Workload.png -------------------------------------------------------------------------------- /vendor-specific/pivotal/Pivotal-Cloud-Foundry-High-Level-Architecture.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-specific/pivotal/Pivotal-Cloud-Foundry-High-Level-Architecture.png -------------------------------------------------------------------------------- /vendor-specific/pivotal/Pivotal-Cloud-Foundry-Pattern.md: -------------------------------------------------------------------------------- 1 | ## Pivotal Cloud Foundry Introduction 2 | 3 | ### Introduction 4 | 5 | Enterprises are moving towards a more smooth running IT operations where the maintenance and the management of IT resources are in auto-pilot mode. Mega cloud providers like Amazon, Google, Microsfot and IBM are taking the advantages of this mindset of enterprise architects at a higher cost. These mega clouds has strategies where customers will lock-in to a certain set of technologies and runtimes which will hinder the agility of the overall solutions architecture of your enterprise. Here are some of the drawbacks or challenges with adopting a mega cloud 6 | 7 | - Vendor locking 8 | - Lack of visibility and control 9 | - Hidden prices and strategies to increase your cost with the time 10 | - Sometimes unpredictable performance 11 | - Harder to debug 12 | 13 | Because of these challenges, people started to step back and looking for a better alternative to deliver your digital experiences to the customers in a more agile, user friendly manner. One of the popular alternatives to some of the above mentioned challenges is the multi-cloud approach where, using multiple cloud service providers to get the best of all clouds. This approach will address some of the concerns mentioned above. But it will become more and more complex when it comes to maintain. Few drawbacks of multi-cloud approach are 14 | 15 | - Lack of knowledgeable resources who understands all clouds 16 | - Latencies can be increased when communicating across clouds 17 | - Differeneces in user management, resource management can increase the complexity of the overall maintenance 18 | 19 | Does that mean cloud is not something we should adhere to? This is where the concept of a private cloud comes into the picture. Most of the time, private cloud is identified as a platform as a service (PaaS) which is running for you. It need not to be a dedicated deployment for you. This is an additional functional layer which sits on top of IaaS layer and control the overall operations within an IT team. 20 | 21 | Cloud Foundry is an open source initiave which defines a “Platform as a Service” stack which is independent of any cloud provider. Pivotal has utilized this open source framework and built their own layer of capabilities to the open source version as Pivotal Cloud Foundry (PCF). 22 | 23 | ### Architecture 24 | 25 | The day-to-day IT operations belongs to 3 types of workloads. Those are 26 | - Applications 27 | - Runtimes 28 | - Infrastructure 29 | 30 | Applications contains the business logic of a give service and the runtime defines the technology stack which is used to develop that application. Based on the application domain, a developer can select the best runtime (polyglot programming). Once the application and the runtime is fixed into an artefact as a VM, container image or binary, these needs to be run on top of a computing infrastrutre which is abstracted away by an operating system. 31 | 32 | ![Enterprise Application Workload](Enterprise-Application-Workload.png) 33 | 34 | Figure 1: Enterprise application workload seggregation 35 | 36 | 37 | As depicted in the above figure, understanding an enterprise application in the above mentioned 3 aspects allows us to define the processes to manage and maintain each and every aspect independently. That is exactly what Pivotal Cloud Foundry has done with their architecture. They have built a platform with frameworks which can help developers to utilize and automate their development at each layer so that application development becomes a one end-to-end process with well defined set of connected operations. As an example, developer can develop their application with a seletec technology and push that to the PCF platform and from that point onwards, PCF will take care of the rest of the testing, deployment and monitoring of the application. 38 | 39 | ![Pivotal Cloud Foundry High level architecture](Pivotal-Cloud-Foundry-High-Level-Architecture.png) 40 | Figure 2: Pivotal Cloud Foundry High level architecture 41 | 42 | At a very high level (33,000 feet), PCF contains the following 3 main components. 43 | 44 | - Application framework - This is where application developers can utilize the available frameworks within the PCF platform to develop their applications. It provides various different frameworks and application runtimes for polyglot types of application development 45 | - Platform runtime - This is the component which provides supportive capabilities to run your application in a distributed environment. Capabilities like routing, data services, monitoring, logging and infrastructure automation are provided at this layer 46 | - Infrastructure automation - This is the component responsible for actual provisioning of computing resources by utilizing the underlying infrastrucutre on top which PCF is running or connected to. 47 | 48 | 49 | Let’s take a bit deeper look into the Pivotal Cloud Foundry. 50 | 51 | ![Pivotal Cloud Foundry - detailed look](pivotal-cloud-foundry-architecture-detailed.png) 52 | Figure 3: Pivotal Cloud Foundry - detailed look (Source: https://www.slideshare.net/Pivotal/t3-pivotal-cloud-foundry-a-technical-overview) 53 | 54 | As depicted in the above figure 3, the PCF platform can be divided into 3 main functional components. 55 | 56 | - Cloud native application framework - The application framework contains the cloud native application runtimes to implement all sorts of enterprise grade applications. The application developer does not need to worry about bundling these runtimes into their applications since those frameworks are provided from the framework itself. Application developers can use different styles like 12 factor apps, microservices, REST services as well as different programming languages like Javascript, Java, Ruby, C# .Net, etc. 57 | 58 | - Cloud native platform runtime - Once these applications are put into work, they cannot live in isolation. These applications needs to be discovered, scaled, monitored, connect with other services, etc. All these supportive services are provided through the platform runtime. There are a set of services which will be utilized by the applications as well as platform runtime. 59 | 60 | - Cloud native infrastructure automation - Running applications has been isolated from the application developers in the past. But with the automated CI/CD pipelines, infrastructure as code concepts, application developer cannot throw his application over the boundary to the devops engineer to run it for you. Rather, application developers are responsible end-to-end from developement to production. With the pivotal’s platform, developers can achieve 61 | -- zero downtime deployments 62 | -- failover and recovery 63 | -- platform upgrades 64 | -- security patching 65 | seamlessly. 66 | 67 | ### Why Pivotal Cloud Foundry? 68 | Cloud Foundry(CF) is an open source project which is trying to build a vendor neutral, cloud native Platform as a Service (PaaS) framework and it has already achieved the goal to some extent. So what is special about Pivotal version of the Cloud Foundry? 69 | 70 | Pivotal has been able to add a value chain on top of the standard CF framework with leading open source software technologies. Some of them are developed and contributed by Pivotal and others are independent vendors. The below figure highlights the difference between the standard CF and PCF. 71 | 72 | ![PCF vs CF](pcf-commercialization.png) 73 | Figure 4: PCF vs CF (source: https://docs.pivotal.io/pivotalcf/2-6/concepts/overview.html) 74 | 75 | As depicted in the above figure 4, Pivotal has added many additional components which becomes really handy when implementing enterprise level software. The services offerred through pivotal as well as through the partner network allows application developers to make their software enterprise grade with caching, monitoring, security. Additionally, pivotal also provides documentation, training, consultancy, certification to the users who are willing to utlize the PCF platform. 76 | 77 | At the end of the day, what pivotal is trying to build is an efficient software delivery pipeline which can be deployed on-premise or cloud which increased the agility, quality and the experience of the developers as well as consumers. There was an analogy somewhere in the internet which compared kubernetes with PCF. 78 | 79 | “If K8S is google, PCF is apple ”. 80 | -------------------------------------------------------------------------------- /vendor-specific/pivotal/README.md: -------------------------------------------------------------------------------- 1 | ### Solutions Architecture Patterns specific to Pivotal technology stack 2 | 3 | 1. [Introduction to Pivotal Cloud Foundry from the outset](Pivotal-Cloud-Foundry-Pattern.md) 4 | -------------------------------------------------------------------------------- /vendor-specific/pivotal/pcf-commercialization.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-specific/pivotal/pcf-commercialization.png -------------------------------------------------------------------------------- /vendor-specific/pivotal/pivotal-cloud-foundry-architecture-detailed.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-specific/pivotal/pivotal-cloud-foundry-architecture-detailed.png -------------------------------------------------------------------------------- /vendor-specific/redhat/README.md: -------------------------------------------------------------------------------- 1 | ### Solutions Architecture Patterns specific to RedHat technology stack 2 | 3 | - [RedHat Architecture Guidelines](https://www.redhat.com/architect/) 4 | -------------------------------------------------------------------------------- /vendor-specific/wso2/README.md: -------------------------------------------------------------------------------- 1 | ## Solutions Architecture Patterns specific to WSO2 technology stack 2 | 3 | This directory contains solution architecture patterns which are built using WSO2 technology stack. To implement the patterns described in this section, users needs to use WSO2 software components (open source or licensed) 4 | 5 | ### Identity and Access Management (WSO2 Identity Server) 6 | 7 | - [Cloud Application Security Pattern](patterns/Cloud-Application-Security-Pattern.md) 8 | - [Security Federation Pattern](patterns/Security-Federation-Pattern.md) 9 | 10 | ### API Management (WSO2 API Manager) 11 | 12 | #### API Manager Extensions 13 | - [API Manager 3rd party key manager integration pattern](patterns/API-manager-3rd-party-KM-integration.md) 14 | 15 | #### API Microgateway deployment patterns 16 | - [Decentralized API Gateway pattern](patterns/Microgateway-Pattern1-Decentralized-Gateway.md) 17 | - [Locked-Down/Offline API Gateway pattern](patterns/Microgateway-Pattern2-Locked-Down-Gateway.md) 18 | - [Seasonal API Gateway pattern](patterns/Microgateway-Pattern3-Seasonal-Gateway.md) 19 | - [Multi data center API Gateway pattern](patterns/Microgateway-Pattern4-Multi-Data-Center-Gateway.md) 20 | - [Service Mesh sidecar API Gateway pattern](patterns/Microgateway-Pattern5-Service-Mesh-Sidecar-Gateway.md) 21 | - [Hybrid API Gateway pattern](patterns/Microgateway-Pattern6-Hybrid-API-Gateway.md) 22 | 23 | ### Application Integration (WSO2 Enterprise Integrator) 24 | - [WSO2 EI7 Solution Patterns](patterns/WSO2-EI7-Solution-patterns.md) 25 | 26 | ### Platform solutions 27 | - [Modern Brown-Field Enterprise With WSO2](patterns/Modern-Brown-Field-Enterprise-WSO2.md) 28 | - [Legacy platform modernization with WSO2](patterns/Legacy-Platform-Modernization-with-WSO2.md) 29 | - [Reusable API Platform with WSO2 API Manager](patterns/Reusable-API-Platform-WSO2-API-Manager-Pattern.md) 30 | - [Event-driven Real-time Information System with Kafka and WSO2](patterns/Event-Driven-Real-Time-Information-System-Kafka-WSO2.md) 31 | 32 | ### Cloud deployment patterns 33 | - [WSO2 APIM and EI deployment reference architecture for AWS](patterns/APIM-EI-Deployment-Reference-Architecture-AWS.md) 34 | - [WSO2 APIM and EI deployment reference architecture for Azure](patterns/APIM-EI-Deployment-Reference-Architecture-Azure.md) 35 | 36 | ### Industry Specific Solution Patterns 37 | - [Open Health Savings Solution](patterns/Open-Health-Savings.md) 38 | 39 | 40 | 41 | 42 | 43 | -------------------------------------------------------------------------------- /vendor-specific/wso2/images/API-Store-integrate-with-3rd-party-KM.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-specific/wso2/images/API-Store-integrate-with-3rd-party-KM.png -------------------------------------------------------------------------------- /vendor-specific/wso2/images/Cloud-Application-Security-Pattern.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-specific/wso2/images/Cloud-Application-Security-Pattern.png -------------------------------------------------------------------------------- /vendor-specific/wso2/images/Microgateway-Pattern1-Decentralized-Gateway.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-specific/wso2/images/Microgateway-Pattern1-Decentralized-Gateway.png -------------------------------------------------------------------------------- /vendor-specific/wso2/images/Microgateway-Pattern2-Locked-Down-Gateway.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-specific/wso2/images/Microgateway-Pattern2-Locked-Down-Gateway.png -------------------------------------------------------------------------------- /vendor-specific/wso2/images/Microgateway-Pattern3-Seasonal-Gateway.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-specific/wso2/images/Microgateway-Pattern3-Seasonal-Gateway.png -------------------------------------------------------------------------------- /vendor-specific/wso2/images/Microgateway-Pattern4-Multi-Data-Center-Gateway.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-specific/wso2/images/Microgateway-Pattern4-Multi-Data-Center-Gateway.png -------------------------------------------------------------------------------- /vendor-specific/wso2/images/Microgateway-Pattern5-Service-Mesh-Sidecar-Gateway.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-specific/wso2/images/Microgateway-Pattern5-Service-Mesh-Sidecar-Gateway.png -------------------------------------------------------------------------------- /vendor-specific/wso2/images/Microgateway-Pattern6-Hybrid-API-Gateway.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-specific/wso2/images/Microgateway-Pattern6-Hybrid-API-Gateway.png -------------------------------------------------------------------------------- /vendor-specific/wso2/images/Modern-Brown-Field-Enterprise-WSO2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-specific/wso2/images/Modern-Brown-Field-Enterprise-WSO2.png -------------------------------------------------------------------------------- /vendor-specific/wso2/images/Security-Federation-Pattern.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-specific/wso2/images/Security-Federation-Pattern.png -------------------------------------------------------------------------------- /vendor-specific/wso2/images/Sync-Async-Eventing-Hybrid-Integration-WSO2-EI7.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-specific/wso2/images/Sync-Async-Eventing-Hybrid-Integration-WSO2-EI7.png -------------------------------------------------------------------------------- /vendor-specific/wso2/images/Sync-Async-Hybrid-Integration-WSO2-EI7.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-specific/wso2/images/Sync-Async-Hybrid-Integration-WSO2-EI7.png -------------------------------------------------------------------------------- /vendor-specific/wso2/images/Synchronous-Hybrid-Integration-WSO2-EI7.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-specific/wso2/images/Synchronous-Hybrid-Integration-WSO2-EI7.png -------------------------------------------------------------------------------- /vendor-specific/wso2/images/WSO2-APIM-Multi-Cloud-Deployment-Pattern.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-specific/wso2/images/WSO2-APIM-Multi-Cloud-Deployment-Pattern.png -------------------------------------------------------------------------------- /vendor-specific/wso2/images/WSO2APIM-3rdParty-Authorization-Server-Integration.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-specific/wso2/images/WSO2APIM-3rdParty-Authorization-Server-Integration.png -------------------------------------------------------------------------------- /vendor-specific/wso2/images/bring-your-own-api-architecture.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-specific/wso2/images/bring-your-own-api-architecture.png -------------------------------------------------------------------------------- /vendor-specific/wso2/images/building-and-api-strategy-using-an-enterprise-api-marketplace-figure-3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-specific/wso2/images/building-and-api-strategy-using-an-enterprise-api-marketplace-figure-3.png -------------------------------------------------------------------------------- /vendor-specific/wso2/images/health/Figure_1-FHIT-API-Portal.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-specific/wso2/images/health/Figure_1-FHIT-API-Portal.png -------------------------------------------------------------------------------- /vendor-specific/wso2/images/health/Figure_2-Autogen-Proj-Download.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-specific/wso2/images/health/Figure_2-Autogen-Proj-Download.png -------------------------------------------------------------------------------- /vendor-specific/wso2/images/health/Figure_3-Integration-Studio.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-specific/wso2/images/health/Figure_3-Integration-Studio.png -------------------------------------------------------------------------------- /vendor-specific/wso2/images/health/Figure_4-Visual-DM.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-specific/wso2/images/health/Figure_4-Visual-DM.png -------------------------------------------------------------------------------- /vendor-specific/wso2/images/health/Figure_5-Pub-Portal.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-specific/wso2/images/health/Figure_5-Pub-Portal.png -------------------------------------------------------------------------------- /vendor-specific/wso2/images/health/Figure_6-API-LM.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-specific/wso2/images/health/Figure_6-API-LM.png -------------------------------------------------------------------------------- /vendor-specific/wso2/images/health/Figure_7-DevPortal.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-specific/wso2/images/health/Figure_7-DevPortal.png -------------------------------------------------------------------------------- /vendor-specific/wso2/images/health/Figure_8-Consent-Mgt.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-specific/wso2/images/health/Figure_8-Consent-Mgt.png -------------------------------------------------------------------------------- /vendor-specific/wso2/images/modernize-legacy-platforms-with-wso2-0.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-specific/wso2/images/modernize-legacy-platforms-with-wso2-0.png -------------------------------------------------------------------------------- /vendor-specific/wso2/images/modernize-legacy-platforms-with-wso2-1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-specific/wso2/images/modernize-legacy-platforms-with-wso2-1.png -------------------------------------------------------------------------------- /vendor-specific/wso2/images/modernize-legacy-platforms-with-wso2-2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-specific/wso2/images/modernize-legacy-platforms-with-wso2-2.png -------------------------------------------------------------------------------- /vendor-specific/wso2/images/modernize-legacy-platforms-with-wso2-3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-specific/wso2/images/modernize-legacy-platforms-with-wso2-3.png -------------------------------------------------------------------------------- /vendor-specific/wso2/images/modernize-legacy-platforms-with-wso2-4.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-specific/wso2/images/modernize-legacy-platforms-with-wso2-4.png -------------------------------------------------------------------------------- /vendor-specific/wso2/images/real-time-event-based-information-system-architecture-wso2-broker-details.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-specific/wso2/images/real-time-event-based-information-system-architecture-wso2-broker-details.png -------------------------------------------------------------------------------- /vendor-specific/wso2/images/real-time-event-based-information-system-architecture-wso2-broker.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-specific/wso2/images/real-time-event-based-information-system-architecture-wso2-broker.png -------------------------------------------------------------------------------- /vendor-specific/wso2/images/real-time-event-based-information-system-architecture-wso2-details.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-specific/wso2/images/real-time-event-based-information-system-architecture-wso2-details.png -------------------------------------------------------------------------------- /vendor-specific/wso2/images/real-time-event-based-information-system-architecture-wso2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-specific/wso2/images/real-time-event-based-information-system-architecture-wso2.png -------------------------------------------------------------------------------- /vendor-specific/wso2/images/real-time-event-based-information-system-architecture.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-specific/wso2/images/real-time-event-based-information-system-architecture.png -------------------------------------------------------------------------------- /vendor-specific/wso2/images/reusable-api-platform-wso2-apim.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-specific/wso2/images/reusable-api-platform-wso2-apim.png -------------------------------------------------------------------------------- /vendor-specific/wso2/images/wso2-apim-ei-deployment-aws.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-specific/wso2/images/wso2-apim-ei-deployment-aws.png -------------------------------------------------------------------------------- /vendor-specific/wso2/images/wso2-apim-ei-deployment-azure.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-specific/wso2/images/wso2-apim-ei-deployment-azure.png -------------------------------------------------------------------------------- /vendor-specific/wso2/images/wso2-apim-websocket-create-api.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-specific/wso2/images/wso2-apim-websocket-create-api.png -------------------------------------------------------------------------------- /vendor-specific/wso2/images/wso2-apim-websocket-details.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chanakaudaya/solution-architecture-patterns/6ea8caee3007b2507abcac4c5b879a633ed2615f/vendor-specific/wso2/images/wso2-apim-websocket-details.png -------------------------------------------------------------------------------- /vendor-specific/wso2/patterns/API-manager-3rd-party-KM-integration.md: -------------------------------------------------------------------------------- 1 | ## Introduction 2 | WSO2 API Manager comes with a built-in key management server that is used for OAuth2 based security within the product. Sometimes, customers like to use their existing Identity Provider (IdP) as the OAuth2 key management server. There can be several reasons for this type of requirement. Some of them are 3 | 4 | - Having a central control over user identities and tokens rather than splitting that into application-specific components 5 | - High-level compliance requirements like certain hashing algorithms, encryption methods used for storing the tokens and keys 6 | - Feature level mismatches of the default key manager 7 | 8 | If the requirement is just to share the same user base with the API platform, going with an approach like identity federation is recommended over implementing a 3rd party key manager. 9 | 10 | ## Architecture 11 | WSO2 API Manager comes with a componentized architecture where each component can be deployed separately if required. Even within a single runtime, these components run with clear separation by communicating over well defined APIs. This API driven product design allows the product to be extended by using these interfaces. Using an external IdP as the key management component of the WSO2 API Manager is possible with this design. Let’s take a look at how this can be achieved. 12 | 13 | ![WSO2 APIM 3rd party KM](../images/WSO2APIM-3rdParty-Authorization-Server-Integration.png) 14 | Figure 1: WSO2 API Manager 3rd party key manager integration 15 | 16 | The above figure depicts the standard integration of an external Identity Provider as the 3rd party key manager for WSO2 API Manager. There are 4 main components of API Manager is depicted here along with the users of those profiles. 17 | Let’s try to understand the integration in detail. There are certain functionalities provided by the key manager within the WSO2 API Manager. 18 | 19 | - API Publisher will register API resources at the key manager (which acts as the authorization server) so that these resources can be protected with OAuth2 20 | - API Store will register clients (apps) within the key manager and provide clientID/clientSecret pair which can be used to generate access tokens for API consumption 21 | - Client applications will register themselves with the key manager as well as generate access tokens for API consumption 22 | - API Gateway will communicate with key manager to introspect the tokens for validity as well as to validate the API subscriptions 23 | 24 | A detailed explanation of the requests and the responses of the above interactions can be found in[2]. Implementing a custom key manager component requires to override these core functionalities with this custom implementation. 25 | In addition to the aforementioned functionalities, the key manager component also provides support for subscription validation, JWT generation, token caching, etc. 26 | 27 | ## How does it work? 28 | WSO2 API Manager provides 2 main extension points to implement the functionalities required by the key manager. Those interfaces are 29 | 30 | - Key Manager interface — This interface is used to implement the resource registration, dynamic client registration, token generation/revocation related functionalities 31 | - Key Validation handler — This interface is used to implement the token introspection capabilities at the key manager with advanced capabilities like scope validation, subscription validation, and consumer token generation 32 | 33 | In a typical workflow of API management, here is how this custom implementation works and how it connects with other components like user store, database and the rest of the API management components. 34 | 35 | 1) API developers will log into the API publisher and create APIs. This process will invoke the key manager component and register the resources at the resource server (key manager) side. Custom implementation will route this request to the external IdP and register the resources at the IdP side. 36 | 37 | 2) Once the API is published to the store, API consumers (application developers) log into the API store and create applications to subscribe to these APIs. This application creation will trigger the dynamic client registration endpoint of the key manager component and it will delegate the functionality to the external IdP through the custom extension. The application IDs and secrets are stored at the external IdP side. In addition to that, functionalities like the update, delete applications are also supported by this implementation. 38 | 39 | 3) Once the application is registered, the user needs to subscribe to APIs using this application. This subscription information will be stored in the API management database which is shared between store, publisher and key manager components. Once subscribed, users can generate access tokens using a supported grant type. At this point, the client will call the /token endpoint of the key manager which will eventually route this request to the external IdP using the custom implementation. This external IdP will generate the access token and store them at IdP side. 40 | 41 | 4) The client application will use this token to consume the resources by calling the resource server which is the gateway component in this case. 42 | 43 | 5) API gateway will call the introspection endpoint (/tokeninfo) of the key manager to validate the token and the subscription details. Custom implementation will call the introspection endpoint of the external IdP for token validation and get the status of the token with any additional details like scope, userId, clientId, and validity. 44 | 45 | 5a) At the same time, the key manager default implementation will validate the subscription details by checking on the API management database which is connected to the key manager. Additional customization can be done with the extension of the KeyValidationHanlder interface as mentioned previously. 46 | 47 | Note: In the above figure, it has connected the same user store (LDAP/AD/JDBC) to both WSO2 API Manager and the IdP. This will make the integration flowless since additional user-level information can be extracted for the users with this approach. If we don’t use the same user store, we can’t support scope validation and backend JWT with user claims. But this is optional and based on the grant type and the backend implementation, you can decide on whether to share the user store or not. 48 | A sequence diagram view of the above mentioned workflow (starting from login into API Store) is depicted in the below figure. 49 | 50 | ![APIM 3rd party KM integration workflow](../images/API-Store-integrate-with-3rd-party-KM.png) 51 | Figure 2: Sequence diagram view of component interaction 52 | 53 | ## Reference implementation 54 | You can find a reference implementation of a custom key manager with SurfOauth as an external IdP in the below medium post. You can follow the instructions mentioned there to test the functionality. 55 | 56 | https://medium.com/@nuwandiwickramasinghe/using-wso2-api-manager-store-with-third-party-key-manager-50e2428ba76f 57 | 58 | The GitHub repository mentioned in the above article had a small bug in the implementation and it is fixed in the following repository (a PR has also been sent to the original repository). If you are building the sample code, make sure you use the below repository. The rest of the steps mentioned in the above article are working fine. 59 | 60 | https://github.com/chanakaudaya/surf-oauth-demo 61 | 62 | You can also find another implementation of 3rd party key manager for Okta in the GitHub repository mentioned below. 63 | 64 | https://github.com/wso2-extensions/apim-keymanager-okta 65 | 66 | ### References: 67 | [1] https://medium.com/@nuwandiwickramasinghe/using-wso2-api-manager-store-with-third-party-key-manager-50e2428ba76f 68 | 69 | [2] http://blog.facilelogin.com/2014/10/revamping-wso2-api-manager-key.html 70 | 71 | [3] https://wso2.com/library/article/2019/09/architecture-for-third-party-authorization-server-integration/ 72 | 73 | [4] https://github.com/wso2-extensions/apim-keymanager-okta 74 | 75 | [5] https://github.com/chanakaudaya/surf-oauth-demo 76 | -------------------------------------------------------------------------------- /vendor-specific/wso2/patterns/Cloud-Application-Security-Pattern.md: -------------------------------------------------------------------------------- 1 | # Cloud Application Security Pattern 2 | 3 | ## Introduction 4 | Enterprises are more and more out sourcing their internal IT applications to cloud based solutions due to the fact that maintainence cost of these on premise solutions are much more higher than the cloud counterparts in most cases. There are many cloud software service providers who is dominating the respective technology area. 5 | 6 | With the introduction of more and more cloud based applications, user management within the enterprise will become challenging. Here are some of the challenges 7 | 8 | - Different cloud applications have different mechanisms to authenticate users 9 | - Remembering different username/password pairs for different applications will be cumbersome to the users 10 | - Different applications will need different levels of security (2FA, SSO) 11 | - Keeping user profiles within each application will be hard to maintain 12 | 13 | ## Architecture 14 | Using a centralized Identity Provider (IdP) is the solution to address the above challenges and come up with a user-friendly, scalable experience to identity admins as well as users. 15 | 16 | ![Cloud-Application-Security-Pattern](../images/Cloud-Application-Security-Pattern.png) 17 | 18 | As depicted in the above figure, cloud applications are configured within the WSO2 Identity Server (or any IdP) as service providers. Based on the authentication mechanism supported by the relevant application (e.g. SAML2, OIDC, WS-Federation), WSO2 IS can be configured. In the meantime, WSO2 IS needs to be configured as an Identity Provider within the relevant cloud application side. Once these settings are done, when a user tries to log into the respective cloud application, it will be redirected to the WSO2 IS authentication endpoint. Now users can provide the credentials which are stored within the enterprise user store (AD, LDAP, JDBC) which is connected with the WSO2 IS. 19 | 20 | ## Advantages 21 | 22 | With the above mentioned architecture, enterprises will be able to reap the following benefits. 23 | 24 | - Enterprise users can be centrally managed regardless of whether they sit within the enterprise or outside the enterprise 25 | - Applications can have their own authentication protocols and connect with the WSO2 IS for authentication 26 | - Different applications can be enabled with Single-Sign-On so that users don't need to log into multiple applications 27 | 28 | ## Additional reading 29 | 30 | [WSO2 Identity Server Documentation](https://docs.wso2.com/display/IS570/Logging+in+to+Salesforce+using+the+Identity+Server) 31 | -------------------------------------------------------------------------------- /vendor-specific/wso2/patterns/Microgateway-Pattern1-Decentralized-Gateway.md: -------------------------------------------------------------------------------- 1 | ## Decentralized API gateway pattern 2 | 3 | ### Introduction 4 | With the adoption of microservices style of architecture within the enterprise, decentralized api gateway pattern fits in nicely. Instead of having a centralized api gateway layer, each microservice can be fronted with an api gateway. WSO2 API microgateway can be deployed as a service (in kubernetes) which will provide the authentication, throttling, analytics, rate limiting capabilities to each microservice. 5 | 6 | ### Architecture 7 | 8 | ![Decentralized API Gateway](../images/Microgateway-Pattern1-Decentralized-Gateway.png) 9 | Figure 1: Decentralized API Gateway pattern 10 | 11 | As depicted in the above figure 1, In this deployment mode, api consumers can either use oauth2 tokens or jwt tokens. In the case of oauth2 tokens, microgateway will communicate with the key manager component. If there is a requirement to implement shared throttling across apis, microgateway will communicate with the external traffic manager. Analytics data will be published to the analytics runtime. In this deployment pattern, api publisher and store are deployed separately and will be exposed to api and application developers. These components will not have any interaction with microgateway components during the runtime. 12 | -------------------------------------------------------------------------------- /vendor-specific/wso2/patterns/Microgateway-Pattern2-Locked-Down-Gateway.md: -------------------------------------------------------------------------------- 1 | ## Locked-down API gateway pattern 2 | 3 | ### Introduction 4 | Sometimes applications needs to be deployed in environment where there are no connection to the public internet or any other parts of the system. As an example, If you are deploying a system which is deployed in deep water under the sea, the system will be deployed in total isolation in a locked-down mode. 5 | 6 | ### Architecture 7 | 8 | ![Locked-down API gateway pattern](../images/Microgateway-Pattern2-Locked-Down-Gateway.png) 9 | Figure 1: Locked-down API Gateway pattern 10 | 11 | As depicted in the above figure 1, WSO2 API Microgateway has the ability to run in this type of environment with it’s built in security (JWT based), rate limiting (local) and offline-analytics capabilities. The applications and microservices will get the same set of capabilities from the API Microgateway, though there is no connection at all with the rest of the components of the API Manager. The Analytics data will be collected into files and will be uploaded to the analytics runtime when there is a connection established with that component. 12 | 13 | With this deployment pattern, API development can be entirely automated and done through the API Microgateway toolkit. The APIs can be defined in Open API Specification (OAS) format with the WSO2 specific extensions in a json file and it can generate the microgateway. This entire process can be automated and implemented through a CI/CD pipeline. 14 | -------------------------------------------------------------------------------- /vendor-specific/wso2/patterns/Microgateway-Pattern3-Seasonal-Gateway.md: -------------------------------------------------------------------------------- 1 | ## Seasonal API Gateway pattern 2 | 3 | ### Introduction 4 | If you have already deployed WSO2 API Manager (all-in-one) in a centralized manner and you are happy with the setup, deploying that in a fully distributed manner would be an overkill. But the drawback of that approach is that, if your traffic fluctuates based on the seasons, scaling all the components would add additional complexity and will take more time than expected. 5 | 6 | ### Architecture 7 | 8 | ![Seasonal API Gateway pattern](../images/Microgateway-Pattern3-Seasonal-Gateway.png) 9 | Figure 1: Seasonal API Gateway pattern 10 | 11 | With the API Microgatway, you can quickly set up a seasonal gateway with a selected set of APIs and scale them up and down as necessary without impacting the existing deployment. 12 | -------------------------------------------------------------------------------- /vendor-specific/wso2/patterns/Microgateway-Pattern4-Multi-Data-Center-Gateway.md: -------------------------------------------------------------------------------- 1 | ## Multi data center API gateway pattern 2 | 3 | ### Introduction 4 | Large enterprises which has global operations requires their applications to be as much closer to the user as possible. That will give their users a better experience when they search for a product or making a purchase order. Having multiple data centers across different geographical regions is a common approach taken by these multi national corporations. These data centers can be their own or on public cloud platforms like Amazon, Google or Microsoft. One of the key challenges of deploying an API Management platform across data centers is to share data across data centers. WSO2 API Microgateway solve this complexity with it’s unique immutable design and the ability to run without any other dependency. 5 | 6 | ### Architecture 7 | 8 | ![Multi data center API gateway pattern](../images/Microgateway-Pattern4-Multi-Data-Center-Gateway.png) 9 | Figure 1: Multi data center API gateway pattern 10 | 11 | As depicted in the above figure 4, the only component which shares data across data centers during the runtime is the analytics component which can connect to the other data centers in an offline manner. With the API microgateway, multi data center deployment has become much simpler and easier to implement and maintain. The above mentioned data centers can span across multiple cloud IaaS providers (Amazon, Google, Microsoft) as well. 12 | -------------------------------------------------------------------------------- /vendor-specific/wso2/patterns/Microgateway-Pattern5-Service-Mesh-Sidecar-Gateway.md: -------------------------------------------------------------------------------- 1 | ## Service Mesh sidecar API gateway pattern 2 | 3 | ### Introduction 4 | If your enterprise is deeply integrated with microservices and wanted a fully fledged microservices implementation, service mesh is a pattern which you cannot ignore. Service mesh defines a network to communicate between microservices with a similar level of protection on top of them as external communications. Some might think this as an overkill but there are enough practical examples where people has implemented microservices with service meshes for better security, visibility and management of the overall microservices implementation. WSO2 API Microgateway can be used as a sidecar proxy in a service mesh kind of microservices architecture. It provides capabilities like authentication, rate limiting, circuit breaker, timeouts as well as monitoring. 5 | 6 | ### Architecture 7 | ![Service Mesh sidecar API gateway pattern](../images/Microgateway-Pattern5-Service-Mesh-Sidecar-Gateway.png) 8 | Figure 1: Service Mesh sidecar API gateway pattern 9 | 10 | In this deployment pattern, each microservice has an API Microgateway running alongside it in the same localhost. In kubernetes, both microservice and the API microgateway runs in the same pod (can be in different containers). All the communications across microservices will go through API microgateway for ingress and egress traffic. WSO2 API Manager analytics component can be used to analyze the interactions happening through the sidecar gateway. 11 | -------------------------------------------------------------------------------- /vendor-specific/wso2/patterns/Microgateway-Pattern6-Hybrid-API-Gateway.md: -------------------------------------------------------------------------------- 1 | ## Hybrid API gateway pattern 2 | 3 | ### Introduction 4 | In all the deployment patterns mentioned above, the management aspect of the deployment needs to be handled by the enterprise. It gives them the utmost flexibility and control over the platform. But sometimes, organizations with limited IT staff and skill set wants to outsource some of the management and hosting capabilties of the platform while keeping the important components. This is what exactly the hybrid API gateway pattern provides. 5 | 6 | ### Architecture 7 | ![Hybrid API Gateway pattern](../images/Microgateway-Pattern6-Hybrid-API-Gateway.png) 8 | Figure 1: Hybrid API gateway pattern 9 | 10 | In this deployment pattern, the critical runtime component of the API platform which is the gateway will be running under the control of the enterprise. It can be run on a private data center, public IaaS cloud or both. In the meantime, the management components of API publisher, Developer Portal, Analytics and Key manager will be hosted and maintained by WSO2 within their public API Cloud. 11 | -------------------------------------------------------------------------------- /vendor-specific/wso2/patterns/Security-Federation-Pattern.md: -------------------------------------------------------------------------------- 1 | # Security Federation Pattern 2 | 3 | ## Introduction 4 | Application security has been an area which has improved a lot with the time. Starting from the basic authentication, access control list(ACL), role based authentication, attribute based authentication, OAuth2, OIDC to JWT, it has evolved over the last decade or so. Enterprise applications typically has a long lifetime which spand across decades. If your enterprise has been there for few decades, there is a chance that you have variuos types of applications with different authentication mechanisms. In most cases, applications had their own user stores which were backed by a database and authenticated with username/password pair. 5 | 6 | This is not a scalable and maintainable solution due to the fact that users have to remember multiple username/password pairs and applications have their own user profiles and adding/removing/modifying these profiles is a tedious task. As a solution, solution architects can propose 2 approaches. 7 | 8 | 1) Delegate the authentication to an Identity Provider and let it handle the security 9 | 2) Federate the authentication to a 3rd party IdPs inclusing social logins 10 | 11 | Out of the above 2 options, we are discussing the second option in this pattern. 12 | 13 | ## Architecture 14 | A typical enterprise software system consists of different types of applications like web, mobile and cloud based. Providing security to all these heterogenous systems requires a well designed Identity solution which is capable of understanding the protocols which are implemented by these systems. To enable federated authentication to these applications, this identity solution should understand the protocols supported by the outbound side as well. Here is the solutions architecture diagram of federated security pattern. 15 | 16 | ![Security Federation Pattern](../images/Security-Federation-Pattern.png) 17 | 18 | As depicted in the above figure, the applications on the far left corner are configured to identify WSO2 Identity Server as the Identity Provider (IdP). Then WSO2 IS is configured to consider these applications as service providers so that when a user tries to access any of these applications, user will be redirected towards WSO2 IS for authentication purpose. At the WSO2 IS side, 3rd party IdPs are configured as Federated Identity Providers (IdP). If this 3rd party system is a legacy application or an application which is not supported OOTB or through the connector store, users can write a custom outbound authenticator. 19 | 20 | ## When to use 21 | If you have heterogenous systems with user identities distributed across multiple Identity Providers or you need to enable social logins, you can consider this pattern rather than doing the authentication within the central IdP. 22 | 23 | ## Advantages 24 | 25 | - Users get easy access to multiple systems without remembering multiple passwords 26 | - No need to keep copies of user information within the central identity system 27 | - User management can be offloaded to external IdPs 28 | 29 | 30 | --------------------------------------------------------------------------------