希望大家尽快认识到，云计算时代的CRUD跟传统开发模式的区别。
历史回顾(二维)
2014年的时候，我们公司还有自己的服务器，后来由于一次断电没处理好，没UPS，数据库在里面，然后就哭了。
后来逐渐转向云计算平台(Infrastructure-as-a-service)。
当时我负责一个用户中心的ASP.NET后端。
里面有一个叫做下载数据包的功能。下载数据包，需要缓存图片，然后复制到一个临时的目录，再生成一个压缩包，供客户下载。我做的改进是多线程下载图片，并提高了压缩的速率，最后定期自动删除缓存的图片。
也就是说，这是一个二维命题。
人月成本+WEB服务器
云计算时代（三维）
云计算时代，我们可能会把图片的存储放到OSS这类的对象存储服务（Software-as-a-service）。所以问题升级到三维。
人月成本+WEB服务器+OSS
财务视角（四维）
财务不懂技术，技术部的员工也不是他招来的，TA只关心云服务的费用。所以问题升级到四维。
人月成本+WEB服务器+OSS+云服务费用
老板角度（超一维）
公司的一切都是老板的资产。
从老板角度，他并不管你用什么语言实现多么简单抑或复杂的功能，他只关心最小的人月成本，最少的服务器支出，最少的云服务费用。所有的维度合起来就是
成本
简单的说，P均衡为0。也就说，最少的预算，带来最大的价值。
员工视角——云计算时代的CRUD
那么再度回到员工视角。在开发下载数据包这个功能的时候，我们就有了新的认知。
方案一：WEB服务器上下行。
这种方案只适用于用户基数少–>上下行带宽小的场景。
方案二：WEB服务器+OSS+CDN。
C:创建的文件要尽可能小。并且要足够“密集”。也就是说，两张一模一样的图片存放在同一个OSS bucket里面，是相当浪费资源的行为。这里面包含存储的费用，API调用的费用等。
R:文件位置要有规律，这样才易于查找，复用。这里面可能包含CDN的费用，OSS公网流出费用等。
U:更新的频率要尽可能小。如果同一个文件反复更新，说明一开始设计的思路有问题。OSS文件自动刷新，会导致所有CDN节点需要重新重新回源，从而产生一定的费用。
D:数据都是有生命的。无意义的数据需要尽快删除。占着茅坑不拉屎，这是弟弟行为。
结论
希望做技术的各位，尽快认识到一点，“技术为业务价值服务”。
也就是说，不管你的技术有多好，多么前瞻，在限定期限内不能盈利，不能创造公认价值，那么它就是一种无用的屠龙技。
I hope everyone realizes as soon as possible the difference between CRUD in the cloud computing era and traditional development models.
Historical Review (Two-Dimensional)
In 2014, our company still had its own servers. Later, due to a power outage that wasn’t handled well, no UPS, and the database was inside, we cried.
Later, we gradually moved to cloud computing platforms (Infrastructure-as-a-service).
At that time, I was responsible for an ASP.NET backend for a user center.
There was a function called download data package. Downloading data packages requires caching images, then copying them to a temporary directory, and generating a compressed package for customers to download. My improvement was multi-threaded image downloading and increased compression speed, finally automatically deleting cached images periodically.
That is to say, this is a two-dimensional proposition.
Human-month cost + WEB server
Cloud Computing Era (Three-Dimensional)
In the cloud computing era, we might put image storage in OSS-type object storage services (Software-as-a-service). So the problem upgrades to three dimensions.
Human-month cost + WEB server + OSS
Financial Perspective (Four-Dimensional)
Finance doesn’t understand technology, and technical department employees weren’t hired by them. They only care about cloud service costs. So the problem upgrades to four dimensions.
Human-month cost + WEB server + OSS + Cloud service costs
Boss Perspective (Super One-Dimensional)
Everything in the company is the boss’s assets.
From the boss’s perspective, they don’t care what language you use to implement simple or complex functions. They only care about minimum human-month costs, minimum server expenses, and minimum cloud service costs. All dimensions combined are:
Cost
Simply put, P equilibrium is 0. That is to say, minimum budget brings maximum value.
Employee Perspective—CRUD in the Cloud Computing Era
So back to the employee perspective. When developing the download data package function, we had new insights.
Option 1: WEB server upload/download.
This solution only applies to scenarios with small user base –> small upload/download bandwidth.
Option 2: WEB server + OSS + CDN.
C: Created files should be as small as possible. And sufficiently “dense”. That is to say, storing two identical images in the same OSS bucket is quite wasteful. This includes storage costs, API call costs, etc.
R: File locations should be regular, making them easy to find and reuse. This may include CDN costs, OSS public network egress costs, etc.
U: Update frequency should be as small as possible. If the same file is repeatedly updated, it means there’s a problem with the initial design thinking. OSS file auto-refresh will cause all CDN nodes to need to re-source, thus generating certain costs.
D: Data all have life. Meaningless data needs to be deleted as soon as possible. Occupying the toilet without shitting is little brother behavior.
Conclusion
I hope those doing technology realize as soon as possible that “technology serves business value”.
That is to say, no matter how good your technology is, how forward-looking, if it can’t profit within a limited time, can’t create recognized value, then it’s a useless dragon-slaying skill.
皆さんができるだけ早く、クラウドコンピューティング時代のCRUDと従来の開発モデルの違いを認識することを願っています。
歴史的レビュー（2次元）
2014年、私たちの会社にはまだ独自のサーバーがありました。その後、停電がうまく処理されず、UPSがなく、データベースが中にあったため、泣きました。
その後、徐々にクラウドコンピューティングプラットフォーム（Infrastructure-as-a-service）に移行しました。
当時、私はユーザーセンターのASP.NETバックエンドを担当していました。
データパッケージをダウンロードするという機能がありました。データパッケージをダウンロードするには、画像をキャッシュし、一時ディレクトリにコピーしてから、圧縮パッケージを生成して顧客がダウンロードできるようにします。私が行った改善は、マルチスレッドで画像をダウンロードし、圧縮速度を向上させ、最後に定期的にキャッシュされた画像を自動削除することでした。
つまり、これは2次元の命題です。
人月コスト+WEBサーバー
クラウドコンピューティング時代（3次元）
クラウドコンピューティング時代、画像のストレージをOSSのようなオブジェクトストレージサービス（Software-as-a-service）に置く可能性があります。そのため、問題は3次元にアップグレードされます。
人月コスト+WEBサーバー+OSS
財務の視点（4次元）
財務は技術を理解せず、技術部門の従業員も彼らが採用したものではありません。彼らはクラウドサービスのコストだけを気にしています。そのため、問題は4次元にアップグレードされます。
人月コスト+WEBサーバー+OSS+クラウドサービスコスト
ボスの視点（超1次元）
会社のすべてはボスの資産です。
ボスの視点から、彼らはどの言語を使用してどれだけ簡単または複雑な機能を実装するかは気にしません。彼らは最小の人月コスト、最小のサーバー支出、最小のクラウドサービスコストだけを気にします。すべての次元を合わせると：
コスト
簡単に言えば、P均衡は0です。つまり、最小の予算が最大の価値をもたらします。
従業員の視点—クラウドコンピューティング時代のCRUD
では、従業員の視点に戻りましょう。データパッケージをダウンロードする機能を開発する際、新しい認識がありました。
オプション1：WEBサーバーのアップロード/ダウンロード。
このソリューションは、ユーザーベースが少ない–>アップロード/ダウンロード帯域幅が小さいシナリオにのみ適用されます。
オプション2：WEBサーバー+OSS+CDN。
C：作成されたファイルはできるだけ小さくする必要があります。そして十分に「密集」している必要があります。つまり、2つの同一の画像を同じOSSバケットに保存することは、かなりリソースを浪費する行為です。これには、ストレージコスト、API呼び出しコストなどが含まれます。
R：ファイルの場所は規則的である必要があり、そうすることで検索と再利用が容易になります。これには、CDNコスト、OSSパブリックネットワーク流出コストなどが含まれる可能性があります。
U：更新頻度はできるだけ小さくする必要があります。同じファイルが繰り返し更新される場合、最初の設計の考え方に問題があることを示しています。OSSファイルの自動更新により、すべてのCDNノードが再ソースする必要があり、特定のコストが発生します。
D：データにはすべて生命があります。意味のないデータはできるだけ早く削除する必要があります。トイレを占領して用を足さないのは、弟の行動です。
結論
技術に携わる皆さんが、できるだけ早く「技術はビジネス価値に奉仕する」ことを認識することを願っています。
つまり、技術がどれだけ優れていても、どれだけ先見性があっても、限定期間内に利益を上げられず、認められた価値を創造できない場合、それは無用な屠龍技です。
Я надеюсь, что все как можно скорее осознают разницу между CRUD в эру облачных вычислений и традиционными моделями разработки.
Исторический обзор (двухмерный)
В 2014 году у нашей компании ещё были свои серверы. Позже из-за отключения электроэнергии, которое не было обработано должным образом, не было UPS, база данных была внутри, и мы плакали.
Позже мы постепенно перешли на платформы облачных вычислений (Infrastructure-as-a-service).
В то время я отвечал за ASP.NET-бэкенд пользовательского центра.
Там была функция под названием загрузка пакета данных. Загрузка пакета данных требует кэширования изображений, затем копирования их во временный каталог, а затем создания сжатого пакета для загрузки клиентами. Моё улучшение заключалось в многопоточном скачивании изображений и повышении скорости сжатия, наконец, периодическом автоматическом удалении кэшированных изображений.
То есть, это двухмерное предложение.
Стоимость человеко-месяца + WEB-сервер
Эра облачных вычислений (трёхмерная)
В эру облачных вычислений мы можем поместить хранение изображений в службы хранения объектов типа OSS (Software-as-a-service). Поэтому проблема обновляется до трёх измерений.
Стоимость человеко-месяца + WEB-сервер + OSS
Финансовая перспектива (четырёхмерная)
Финансы не понимают технологию, и сотрудники технического отдела не были наняты ими. Они заботятся только о стоимости облачных услуг. Поэтому проблема обновляется до четырёх измерений.
Стоимость человеко-месяца + WEB-сервер + OSS + Стоимость облачных услуг
Перспектива босса (сверх одномерная)
Всё в компании — это активы босса.
С точки зрения босса, им всё равно, какой язык вы используете для реализации простых или сложных функций. Они заботятся только о минимальной стоимости человеко-месяца, минимальных расходах на серверы и минимальной стоимости облачных услуг. Все измерения вместе:
Стоимость
Проще говоря, P-равновесие равно 0. То есть минимальный бюджет приносит максимальную ценность.
Перспектива сотрудника—CRUD в эру облачных вычислений
Итак, вернёмся к перспективе сотрудника. При разработке функции загрузки пакета данных у нас появились новые инсайты.
Вариант 1: Загрузка/выгрузка WEB-сервера.
Это решение применимо только к сценариям с небольшой пользовательской базой –> малая пропускная способность загрузки/выгрузки.
Вариант 2: WEB-сервер + OSS + CDN.
C: Созданные файлы должны быть как можно меньше. И достаточно “плотными”. То есть, хранение двух одинаковых изображений в одном OSS-бакете — довольно расточительное поведение. Это включает стоимость хранения, стоимость вызовов API и т.д.
R: Расположение файлов должно быть регулярным, чтобы их было легко найти и переиспользовать. Это может включать стоимость CDN, стоимость публичного исходящего трафика OSS и т.д.
U: Частота обновления должна быть как можно меньше. Если один и тот же файл обновляется повторно, это означает проблему с первоначальным дизайнерским мышлением. Автообновление файлов OSS приведёт к тому, что всем CDN-узлам потребуется повторный источник, что создаст определённые затраты.
D: Все данные имеют жизнь. Бессмысленные данные нужно удалять как можно скорее. Занимать туалет, не какая — это поведение младшего брата.
Заключение
Я надеюсь, что те, кто занимается технологией, как можно скорее осознают, что “технология служит бизнес-ценности”.
То есть, независимо от того, насколько хороша ваша технология, насколько дальновидна, если она не может приносить прибыль в ограниченное время, не может создавать признанную ценность, то это бесполезный навык убийства драконов.
💬 讨论 / Discussion
对这篇文章有想法？欢迎在 GitHub 上发起讨论。
Have thoughts on this post? Start a discussion on GitHub.