Vendor lock-in
Vendor lock-in is dependence on a provider, product, or technology that makes switching to an alternative difficult, costly, or impractical.
Kafka for Architects
Vendor lock-in is a condition in which proprietary dependencies, integrations, or switching costs make migration away from a provider difficult or impractical.
- How it is used
- Guides enterprise decisions between managed cloud Kafka and on-premises deployment.
- How deep it goes
- Explains proprietary dependencies, configuration limits, egress costs, and portability mitigations without detailing migration procedures.
- Examples
- Uses Confluent Cloud, Amazon MSK, Aiven, proprietary integrations, egress fees, and dual Kafka clusters as examples.
- What you can do after
- Evaluate provider portability, document exit costs, and preserve migration options with standard serializers and APIs.
First-Party Data Activation
Dependence on a technology or vendor that makes replacing, migrating from, or interoperating with it difficult or costly.
- How it is used
- Evaluates first-party data solutions by their portability, offboarding difficulty, and effect on marketing-stack agility.
- How deep it goes
- Explains business-logic portability and compares solution categories, but stops short of implementation procedures or contractual analysis.
- Examples
- Uses audience criteria, personalization fields, experiment configurations, and audience membership lists as portability examples.
- What you can do after
- Evaluate vendors by asking how business logic and data can be offboarded and whether downstream systems can change independently.
Read how First-Party Data Activation explains vendor lock-in →
Architecting an Apache Iceberg Lakehouse
Tool lock-in is dependence on a particular software tool or vendor that makes changing tools difficult or costly.
- How it is used
- Guides lakehouse architecture and tool selection by exposing migration, interoperability, cost, and operational tradeoffs.
- How deep it goes
- Explains proprietary formats and modular alternatives, then evaluates operating tradeoffs; stops short of migration procedures.
- Examples
- Uses proprietary warehouses, Iceberg lakehouse layers, standard APIs, managed catalogs, and self-managed catalogs as comparison points.
- What you can do after
- Evaluate architecture and tool choices for interoperability, operational burden, cost growth, and dependence on a vendor ecosystem.
Read how Architecting an Apache Iceberg Lakehouse explains vendor lock-in →
Think Like a CTO
Vendor lock-in is a condition in which dependence on a provider makes it difficult or impractical to move software or services to another provider.
- How it is used
- Guides technology decisions toward preserving future options and avoiding dependence that removes practical corrective action.
- How deep it goes
- Defines lock-in, explains its cost trade-offs, and applies a portability test; it stops short of prescribing a migration plan.
- Examples
- Uses obsolete Flash administration software, Java portability, and Salesforce customization to expose dependence and escape options.
- What you can do after
- Evaluate technology choices by testing portability, licensing exposure, downtime consequences, and the cost of preserving alternatives.
Related concepts
- abstractionaddressed by · Abstraction is a simplified representation that exposes relevant properties or behavior while omitting lower-level details unnecessary for a given purpose.
- open standardaddressed by · An open standard is a publicly available technical specification developed through an open process and implementable by independent parties.
These guides are generated from the text of Manning books by Manning's knowledge graph and link to the sections they draw on. The full books are available on liveBook and at manning.com.