更新记录

2021/6/17 – 对于“云供应商锁定”和“云原生数据库”进行补充说明
2021/6/16 – 对于“开源软件”进行补充说明
2021/6/14 – 对于“行业标准”进行补充解释

首先

IT企业 = 提供供应商锁定的公司
平台型企业 = 提供供应商锁定的公司

很遗憾，但是有很多人持有这个观点。软件本身可能没有像期望的那样正常运行，更甚者，可能在那个不那么老化的时代，只有这个选择。

在IT行业中，人们一直说它是“狗年”，但在云计算盛行的今天，供应商的盈利重点已经发生了很大变化。供应商封锁竞争对手的策略是“围困战略”，供应商清楚这种策略的负面影响更为重要。

解釋

我从维基百科上找到了关于供应商锁定的定义。

维基百科 – 供应商锁定

特定供应商的产品和技术的依赖可能成为一个问题。

为什么这个会成为一个”问题”呢？
我来列举一些可能成为讨论焦点的事项。

受到影响的事物 de

我想主要的是以下内容。

• プログラムのCode。アプリケーションそのものと言えますね。

 

• Data … 構造化データと言いましょうか。

 

ファイル … 半構造化データ。非構造化データとも言えますね。つまり Data の一種

确切地说，是指代码和数据。

对商业的影响

以下是我在一些项目中考虑的主要事项。

アプリの移行が困難になる

例えば、Windows アプリから、iOS アプリへの移植
例えば、Oracle から、SQL Server への移植
これを鑑みると 既存の Code の変更の必要性が少ない場合 が対象となりますね。

Data の閲覧が困難になる

例えば、Excel のファイルを、Google Sheet で正確に再現できない
例えば、BigQuery のデータを、Azure Synapse Analytics に移行が出来ない
これを鑑みると 既存のデータを移動させる必要性が高い場合 が対象となりますね。

为什么需要进行转型呢？

• アプリケーションの場合

長期にわたってフローが変わらない

在商业上，对于不需要更改的应用程序，供应商方面的版本更新是很困难的。虽然会出现封存的选择，但我们希望能够通过实现API等方式，确保与最基本的新应用程序进行协作的状态。

• Data の場合

Big Data を実現できる環境の登場により、Data のライフサイクルが長くなった。特に RAW Data。
Data が企業の意思決定や、B2C・B2B・B2E などでの自動化のための様々なエンジン (機械学習のモデル作成など) を開発するための源泉であると再認識された。

特别是数据比应用程序（也就是代码）的生命周期往往更长。拿智能手机应用程序的代码来说，能用几年呢？我认为数据通常能使用超过10年，这是因为我们可以详细地观察到它随时间的变化。

那么:

• 構造化データよりも、非構造化データ。特にファイル

 

ファイルのフォーマット (CSV、Paquetなど)

怎样拿着 是很重要的。

顺便说一下，NLP（自然语言处理）系列的机器学习技术在这里变得非常重要。因为它有可能从非结构化数据，如电子邮件和文件中，提取出结构化数据。而这一切正是从Microsoft 365的Viva开始的。结果就是可以进行推荐等工作。

典型的的供应商锁定

我们之前已经提到过，但现在让我总结一下。

• 過度に求めたパフォーマンス

Hardware 機能の直接呼出し
OS のAPIの直接呼出し
RDBMS でのストアドプロシージャ
RDBMS でのベンダーが売りにしている関数・機能の実装

単独の Platform への過信

全てを Cloud に置く
全てを 最速と言われているファイルフォーマットに統一する

自社にエンジニアを抱える。あるいはそこが触れる組織との有償契約の準備

Open Source の場合は、Contribute 出来る道を作る
全てを丸投げする。ベンダーの言う事を鵜呑みにする。
カネでしか解決できない

大家都知道时间是有限的，对吧？

与开源的关系

如果是开源的话，就不会有厂商依赖的问题。

这个故事经常出现。
真的吗？

比如说.NET。
现在，它是.NET基金会的项目，Microsoft也是其中的成员之一。
隐私政策和行为准则由dotnetfoundation.org管理，而不是由Microsoft来管理。
.NET – 开源的。

举例来说，TensorFlow。
虽然同属于开源，但tensorflow.org的使用条款需要在Google.com上查阅。

ONNX最初是由Facebook和Microsoft开发的。现在由Linx Foundation进行管理。根据相关网站的使用条款等，可以做出一定的判断。

只要我们能够了解目前谁在掌管，就无关是好是坏。

我认为开源项目并不仅仅依靠社区的善意而存在。赞助商也是必需的，并且需要一种机制来评估和奖励那些为项目做出贡献的工程师。是否赞助商偏袒某方面是重要的吗?

在这里，还有一个问题浮现出来。那就是开源项目将来会怎么样？会继续由特定的供应商管理吗？还是会捐赠给像Linux Foundation这样的供应商之外的组织？这需要有眼光，需要对行业动态保持敏感，这是很重要的。

关于开源产品，需要采用完全不同的处理方式，与商业产品完全不同。我在另一篇博客中写到过。对于云时代的产品和服务选择，应有不同的考虑方法。

• 消費するだけの立場しか取れない場合

その製品へのロックインが始まる可能性があります。
将来、似た役割の別の製品に引っ越しできる準備を常に考慮した方がいいです。例えばRDBMSなら、別のRDBMSにデータを持っていけるのか? RDBMSの場合は、スキーマつまりテーブルが無いとデータの格納が出来ません。テーブルのスキーマの互換性も重要です

Contribute つまり、一緒に開発する力がある場合

License に注意を払って、Community と一緒にその製品を普及させる。それが結果として多くのエンジニアとユーザーを巻き込み、長く使えるようになります

换句话说，取决于是否具备技术能力会产生很大的差异。
从根本上讲，因为我们希望自己能够掌握控制权，所以我们希望公司内部拥有这种技术能力。

因为价格便宜，所以选择开源。
这只是关于产品价格的讨论。如果考虑到总拥有成本和投资回报率，很快就能明白是否是一个合理的说法了?

新一代供应商锁定，称为“云供应商锁定”。

由于xxx系统在AWS上运行，所以预计与其进行协作的这个系统也将在AWS上运行。

最近这类故事越来越多了，不仅仅局限于AWS。Azure和GCP也是一样的。
我认为这就是厂商锁定的一个变种，云厂商锁定。

問題 – 疑問

这种情况发生的原因主要有以下几个。

• クラウドからのデータのダウンロードに費用が発生する

 

アーキテクチャ上、連携システムはネットワークの観点から近い方が良い

此外,
– 有一些技术仅存在于该云平台中，尤其是与SDK相关的技术。需要考虑将应用程序对SDK的依赖最小化的考虑。可以应用类似于驱动程序的方法。从这个角度来看，SQL Server – SQL Database可以通过仅使用连接字符串来实现可移植性，这非常令人惊叹。

考察存放位置是重要的。将大量数据存放在云端。这将引发供应商锁定的可能性，不同于技术层面。作为一名工程师，了解仅仅进行文件复制可能会产生数千万元成本的事情是很重要的。

对于那个云平台，我们是否真的能信赖它呢？为了防止陷入无法挽回的局面，我认为调查作为企业的那个云服务提供商在隐私、合规等方面非常重要。

并不意味着在云上不放置数据。考虑到风险，需要注意适当地使用。此外，也希望通过CI/CD（如GitHub）部署代码。这样可以提高代码的可移植性，并且最重要的是，在发生故障时可以立即在另一个地区或云中启动服务。

在推进思考时，极端观点非常重要，但在实施时，往往存在各种折衷办法。因此，我们需要充分理解与纯粹的供应商对话会引发的危险。否则我们可能会与云供应商同归于尽。

松散的联系

即使成为云端，松散耦合的观点仍然始终帮助我们。避免供应商锁定是困难的，所以要尽量减少。松散耦合仍然是有相互依赖的，也就是说它们仍然存在某种依赖关系。

我尝试写了一份粗略的垂直方向解耦列表，列出了一个应用可能依赖的内容。

• もはや OSのAPIを直接呼び出すような最適化をするコードは存在はしますが、数としては少ない。

 

通信は HTTP/HTTPS 系で確定。

如果画出这样的图，我认为可以得出这样的结论。

• アプリケーションは、Java 11 上で動くようにしている。別のOSで動かす場合は、テストは必要だけど、最小限に留まるかと。

 

RDBMSを使っていますが、データは全件 Export 出来ます。ベンダー独自のデータ型を使っていないのであれば、別の RDBMS に移行したい場合は、テストは必要だけど、最小限に留まるかと。

PaaS = 经常不会受到供应商绑定。

在Azure中，有一种被广泛使用的PaaS称为Web App。可以说它是用于托管Web服务器的环境。

概述 Azure Web App

由于PaaS会引发供应商锁定问题。

果真如此吗？

• Web App で動かすコードは、ピュアな .NET/Java/PHP/Python の Web アプリケーション

 

• Web App は、Web Server 以下のレイヤーのホスティング。Web Serverの設定もある程度変更できる

Windows 版 なら、web.config
Linux 版 なら、httpd.conf

https://docs.microsoft.com/ja-jp/aspnet/core/host-and-deploy/linux-apache?view=aspnetcore-5.0

Container 版なら、docker config
しかも、そもそもそれらを吸収する UI や CLI などもある。全ての差分吸収は勿論、難しいですけど。

UI
CLI

CI/CD に至っては、GitHub など複数のサービスが使える

总之，管理系统中仍然存在供应商锁定的问题。但是，我认为应用程序迁移是相对容易的。

从这个角度来看，有趣的是Azure Cosmos DB。为什么呢？

Cosmos DB 独自の API は SQL のみ。それも ANSI SQL に相当近い。それ以外の NoSQL (Cassandra, MongoDB, Gremlin) は、ほぼ100%互換。Key-Value は単純なオペレーションのみなので割愛。以下、明確な違いではないですが?

ANSI SQL との SELECT文の違い
ANSI SQL との 関数の違い

インフラだけは、設定のみ。頑張れ Cloud と委任できる。

换句话说，代码的可移植性很高，数据可以随时以标准方式提取。就连部署在本地环境也可以携带。如果你能想象基础设施即服务(IaaS)，就可以理解这一点。

我认为这就是我心目中的云原生。或许也可以称为“云生态”?

我想避免供应商锁定。完全避免是不可能的。那么，有没有一个折中的方案？行业标准是一个选择。

在商业、日常生活和学校中使用的操作系统实际上分为三种：Windows / iOS / Android。这些操作系统都是由”供应商”开发的。

在中文中，电脑的CPU基本上由Intel/AMD/ARM等公司开发，它们是主流的“供应商”。

我认为要否定供应商锁定，需要具备能够在公司自行开发和维护所有技术的能力。实际上，我认为这是非常困难的。换句话说，要避免一定程度的供应商锁定是困难的。
因此，重要的问题是是否有选择余地呢？

重要的是該技術是否標準化。例如，SQL。在ANSI/ISO等標準中，已經定義了SQL語句。

无论是商业还是开源，很多关系数据库管理系统（RBMS）或者像Spark SQL这样的系统都宣称遵循ANSI SQL标准。在迁移后是否也遵循相同的标准，这是可以立即查询的，我想?

ANSI SQL的例子

我认为这是最重要的评估要点。
为什么网络技术会如此广泛和长久地被使用？这可以归因于W3C的存在。目前，HTTP/3的讨论正在进行中。这是Google通过QUIC协议进行了独立实现，其效果得到了广泛认可（Chrome浏览器的普及率很高，对吧），目前在IETF等方面继续讨论采用的可能性。W3C也在讨论之中，对吗？

换言之，大家需要具备对该领域的标准技术及其是否被未来的标准化团体采纳的洞察力。

实际上，除了供应商锁定外，在迁移过程中还存在问题 – 无法进行版本升级。

实际上，在迁移过程中还会遇到其他问题，其中之一就是无法进行版本升级。

使用开源产品时经常发生的情况。 这是缺乏向下兼容性的问题。
相对于上一个版本，升级是相对受支持的，但是如果跳过两个版本，会变得非常困难。

商用产品由于其明确的支持生命周期，跳跃多个版本对其影响被最小化。对于商用产品而言，比版本更重要的是时间，例如10年。

总结

我认为能够可见的是尽量减少限制的选择。一旦进入限制的状态，就会涉及到兼容性问题。拖延的时间越长，就会有越多的事情需要放弃。

同样，在软件中，将代码和数据分开并考虑其生命周期是很重要的。我们应该避免创建一个巨大的独立数据库。我们应该将应用程序直接使用的读写数据库和用于Big Data的数据库分开。因为数据的生命周期是不同的。

在软件界，符合行业标准有多重要？即使是开源软件也是如此。

而且，我希望将敏捷的思维方式应用于所有的项目中。这样可以保持项目始终有些进展。
如果每个人都能参与其中，我们还可以使代码更易读，考虑到依赖关系，也就是松耦合。为了减少对其他公司的依赖，我们需要在自己的公司拥有能力来做决策，并与工程师一起工作，共同朝着相同的商业目标迈进，而不是与合作伙伴合作。

只要动起来就好。
但仅有这点要求，对于想要创造出对世界有用的系统的工程师来说，可能还有很长的路要走吧。

附赠

iOS的生态系统令人惊奇，让人不禁思考它如何能够持续存在。原生应用使用的是Objective C的编程语言。
而相比之下，Web则截然不同。

用户数量庞大，真是件了不起的事情啊?