ishenwei/nexus
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Update nexus: fix conflicts and sync local changes

Browse Source
This commit is contained in:
Shen Wei
2026-04-26 12:06:50 +08:00
parent 191797c01b
commit f09834b5a5
2443 changed files with 254323 additions and 255154 deletions
Download Patch File Download Diff File Expand all files Collapse all files

112
wiki/concepts/Vendor-Lock-In.md
View File

@@ -1,56 +1,56 @@
---
title: Vendor Lock-In
tags: [Cloud, Risk, Strategy]
---
# Vendor Lock-In
**Vendor Lock-In** refers to the situation where a customer becomes dependent on a single cloud provider for products and services, making it difficult and costly to switch to another provider.
## Overview
Vendor lock-in is one of the primary concerns when adopting cloud services. Organizations invest in provider-specific tools, APIs, and infrastructure that may not be portable to other platforms.
## Why It Happens
1. **Proprietary APIs** — Provider-specific interfaces that require code changes to migrate
2. **Custom Data Formats** — Formats that only work with that provider's services
3. **Discounting Incentives** — Long-term contracts with committed spending
4. **Skill Development** — Teams trained on specific provider's tools
5. **Integration Dependencies** — Deep coupling with provider's ecosystem
## Multi-Cloud as Mitigation
[[Multi-Cloud-Strategy]] directly addresses vendor lock-in by:
- Distributing workloads across multiple providers
- Using cloud-agnostic tools (Kubernetes, Terraform)
- Standardizing on open APIs and formats
- Negotiating favorable contracts with competition
## Signs of Lock-In Risk
- Difficulty estimating migration costs to another provider
- Most applications tightly coupled to single provider's services
- Team has limited skills across multiple cloud platforms
- Long-term committed spending with one provider
- Provider-specific data formats in use
## Mitigation Strategies
1. **Adopt Cloud-Agnostic Tools** — Use Kubernetes, Terraform, open-source solutions
2. **Design for Portability** — Abstract provider-specific code into interfaces
3. **Multi-Cloud Architecture** — Distribute critical workloads across providers
4. **Standardize Data Formats** — Use open, portable formats where possible
5. **Develop Cross-Cloud Skills** — Train teams on multiple platforms
## Related Concepts
- [[Multi-Cloud-Strategy]] — Primary mitigation strategy
- [[Cloud-Maturity-Model]] — Level 4-5 organizations effectively avoid lock-in
- [[Cloud-Native]] — Portable architectures reduce lock-in
- [[FinOps]] — Helps evaluate cost of lock-in vs. flexibility
## Sources
- [[sources/how-can-a-multi-cloud-strategy-transform-your-business-roi.md]]
---
title: Vendor Lock-In
tags: [Cloud, Risk, Strategy]
---
# Vendor Lock-In
**Vendor Lock-In** refers to the situation where a customer becomes dependent on a single cloud provider for products and services, making it difficult and costly to switch to another provider.
## Overview
Vendor lock-in is one of the primary concerns when adopting cloud services. Organizations invest in provider-specific tools, APIs, and infrastructure that may not be portable to other platforms.
## Why It Happens
1. **Proprietary APIs** — Provider-specific interfaces that require code changes to migrate
2. **Custom Data Formats** — Formats that only work with that provider's services
3. **Discounting Incentives** — Long-term contracts with committed spending
4. **Skill Development** — Teams trained on specific provider's tools
5. **Integration Dependencies** — Deep coupling with provider's ecosystem
## Multi-Cloud as Mitigation
[[Multi-Cloud-Strategy]] directly addresses vendor lock-in by:
- Distributing workloads across multiple providers
- Using cloud-agnostic tools (Kubernetes, Terraform)
- Standardizing on open APIs and formats
- Negotiating favorable contracts with competition
## Signs of Lock-In Risk
- Difficulty estimating migration costs to another provider
- Most applications tightly coupled to single provider's services
- Team has limited skills across multiple cloud platforms
- Long-term committed spending with one provider
- Provider-specific data formats in use
## Mitigation Strategies
1. **Adopt Cloud-Agnostic Tools** — Use Kubernetes, Terraform, open-source solutions
2. **Design for Portability** — Abstract provider-specific code into interfaces
3. **Multi-Cloud Architecture** — Distribute critical workloads across providers
4. **Standardize Data Formats** — Use open, portable formats where possible
5. **Develop Cross-Cloud Skills** — Train teams on multiple platforms
## Related Concepts
- [[Multi-Cloud-Strategy]] — Primary mitigation strategy
- [[Cloud-Maturity-Model]] — Level 4-5 organizations effectively avoid lock-in
- [[Cloud-Native]] — Portable architectures reduce lock-in
- [[FinOps]] — Helps evaluate cost of lock-in vs. flexibility
## Sources
- [[sources/how-can-a-multi-cloud-strategy-transform-your-business-roi.md]]