学んだことがそのまま稼げるのです！NodeJS実践シリーズ：個人開発者はクラウドサービスをどう選ぶべきか

この記事には少なくとも千ドルの価値があります。これは私が控えめに見積もった無駄なお金だからです（苦笑の絵文字は自分で考えてください）

この記事には、クラウドサービスを選択するためのいくつかの提案が散りばめられており、もちろん、いくつかの「綿密なヒント」も提供されます。しかしその前に、もっと重要なことについて考える必要があります。それは、なぜクラウドサービスを購入するのかということです。

製品を作るのか、それとも技術を作るのか？

この質問は、次の購入戦略を決定するだけでなく、コーディングを開始するための前提条件でもあります。

テクノロジーを出発点として私が達成したい目標は、「コードを正しく書きたい（まずコードを学び）、コードを上手に書きたい（その後、コードに習熟する）」です。コードはすべての仕事の出発点です。コーディングプロセスの難しさは多ければ多いほど良いです。遭遇するビジネスシナリオが複雑であればあるほど、より良い結果が得られます。また、業界のベストプラクティスに精通しているほど、より良い結果が得られます。利益はコードの量に直接比例します。実際に投資した。

プロダクト側から見ると、コードが良いから製品が良いというわけではなく、アイデアの実現可能性を検証することが最優先です。ユーザーが料金を支払う前の、人、日数、マシン、コードなどはすべて沈黙のコストであり、個人の開発者にとっては自腹を切る損失なので、早く製品を作ることが実は最優先事項なのです。皆さんも多かれ少なかれ、テクノロジーと製品の間にあるこの種の矛盾を経験したことがあると思います。高品質なコードは時間の投資と切り離せませんが、時間は製品の「競争」の最大の敵です。そのような選択は決して難しいことではありませんインターネットのスタートアップ企業で働いたことがあるなら、会社は前者を犠牲にすることを躊躇しません。製品とテクノロジは相反するものではありません。製品開発中に意図的に特定のテクノロジに習熟することはできますが、製品とコードの作成者としては、コストと利益を慎重に計算する必要があります。

タイトルが示すように、この記事の視点は個人 (独立した) 開発者の視点です。このグループの人々にとって、彼らは独自のコーディングの才能を持っていますが、完璧なコードを書くことよりも、製品を適切に実行することの方がはるかに重要です。言い換えれば、この記事では、「クラウド」によって提供される主なオブジェクトは製品です。

製品第一の前提を受け入れたら、あらゆる種類のコードへの執着を「克服」する努力を開始し、製品開発におけるさまざまな不完全性を受け入れることを学ぶ必要があります。2 年前に site2share を書き直す機会が与えられたら、次のようにコーディング実装を大幅に削減するでしょう。

データストレージには ORM の代わりにネイティブ SQL ステートメントを使用する

テストを書かないでください

CI/CD を実行する代わりに、ローカルコンパイル、手動圧縮、手動アップロードとデプロイメントを選択します。

私があらゆる種類の明らかなアンチパターンを推奨する理由がまだ理解できない場合は、そのまま読み進めてください。

どのようなサービスを購入するか

尋ねるべき正しい質問は、進歩的なものでなければなりません。

製品のどの機能にサービスサポートが必要ですか?

これらのサービスを自分で作成できますか?

見分ける方法、またはサードパーティから購入する必要がありますか?

MVP (実用最小限の製品) から始める

この質問に答えるには、プロダクト思考を使用する必要があります。あなたの Web サイトにログイン機能が必要な場合、待ってください。あなたの Web サイトには本当にログイン機能が必要ですか?

限られた人的および財政的リソースを考慮すると、コーディングする前に、Web サイトのどの機能を実装する必要がある (必須) か、どの機能が不要である (あれば便利) かを明確に理解する必要があるというのが私の提案です。なぜ事前にワクチン接種を行うかというと、ほとんどの製品は寿命を迎えるまでに人の目に触れる機会が極めて限られており、不確実性への投資は無駄になる可能性が高いからです。次の 2 つの例を見てみましょう。

ProductHunt は、業界でよく知られたインターネット製品リリースプラットフォームです。ここで毎日 10 製品がリリースされると控えめに見積もると、過去 1 年間で少なくとも 3,650 の新製品が世界中で発売されたことになります。過去 2022 年あなたの記憶に残っている新しいアプリはありますか?

site2share の例に戻ると、Google Analytics の統計によると、過去 1 年間に少なくとも 3,000 人の新規ユーザーが私の Web サイトにアクセスしましたが、実際に OAuth ログインに Google メールを使用したユーザーは 47 人だけでした。今年はちょうど Google から Google Authentication SDK のアップグレードを促された年だったため、その後のメンテナンスコスト (たとえば、ハードウェアで Azure Redis を購入すると月額 15 ドルかかる) を考慮して、ログイン機能を完全にオフラインにすることにしました。

ログイン機能に戻りますが、それが完全な機能の一部であることが確認された場合は、それをサポートするインフラストラクチャを購入する前に、購入することが唯一の方法であるかどうかも検討する必要があります。

ログインの目的がパーソナライズされたデータを保存することである場合、excalidraw のローカルキャッシュ (localStorage など) と同様のソリューションを使用できますか?

バックエンドでパーソナライズされたデータを保存する必要がある場合、アカウントシステムを最初から構築するのではなく、OAuth を統合するなど、ログイン機能の軽量実装を使用できますか?

確実に OAuth を使用する場合は、Auth0 を直接選択する方が良いでしょうか?

Auth0 の無料バージョンは、最大 7,000 人の登録ユーザーの無制限のログインをサポートします。ユーザーが 7,000 人になったらどうすればよいか尋ねるかもしれません。わかりません、まだそこまで進んでいないからです。しかし、その頃には、よく考えられたユーザーシステムが議題に上るようになっており、資金や人材の問題はもう問題ではなくなっているでしょう。でもその前に、生き延びましょう。

隠れたコストを測定する

お金が問題なのではなく、お金がないことが問題なので、この記事を書いています。しかし、人々はお金とは別に、時間への投資を無視することがよくあります。長期的には、作成コストはコードコストの大部分を占めませんが、メンテナンスコストは大部分を占めます。

たとえば、今クローラーを構築する必要があり、プロキシプールを使用する必要がある場合、自分で構築するべきですか、それともプロキシプールを購入するべきですか?

この proxy_pool など、市場にはすでに多くのプロキシプールオープンソースプロジェクトが存在します。プロキシプールの原理は非常に単純で、本質的には、インターネット上のパブリックプロキシライブラリをクロールし、それらをまとめて保存する集約サービスです。この問題に戻りますが、私は独自のプロキシサービスを構築するよりも、既存のプロキシサービスを購入する傾向があります。このオープンソースプロジェクトのデプロイメントを例として挙げると、自己構築では次のような問題が発生します。

Python と Docker をもう一度学ぶ必要があります。これは学習コストです

私の Web サービスは App Service にデプロイされています。proxy_pool を独立したサービスとしてデプロイする場合は、追加の仮想マシンを購入する必要があります。

サービスのセキュリティ、テスト、メンテナンス、監視のコスト

IP を再度効果的にフィルタリングするには、追加の開発作業が必要です。これは、パブリック IP ライブラリの品質が通常低く、指定された Web サイトのクロールや Web サービスの共同デバッグのニーズを満たすことができないためです。

給料を時給換算して、将来的に上記の仕事に長期間投資する時間をかけると、そのお金を直接適切な代行サービスを購入するのに使ったほうが費用対効果が高いかもしれません。エージェントプールは現在非常に成熟した業界であるため、業界には多数の成熟したプレーヤーがいます。最大のブライトデータを例に挙げると、より詳細な方法でプロキシ IP を提供するだけでなく、コードを作成し、クローリングサービス API を直接提供し、ブラウザでのデバッグをサポートすることもできます。

ブライトデータには参入障壁があるかもしれませんが、この業界では自分に合った「代替案」が必ず見つかります。競争により、誰もが同じようなサービスを提供しています。例えば、私にとっては、Geonode の代理店サービスの方が自分に合っているのかもしれません。

私が言いたいのは、お金をかけないからといって必ずしも無料になるわけではなく、隠れたコストも考慮する必要があるということを忘れないでください。そうは言っても、手動で構築することで多くのことを学ぶことができ、それは授業料と考えることができます。しかし、ここでの私の立場は依然として製品に基づいており、迅速に行動するか、迅速に失敗するかにかかわらず、迅速であることは非常に重要です。

どの構成サービスを購入すればよいですか?

クラウドサービスの購入を決定したら、次に問題となるのは、どのような構成のクラウドサービスを購入するかです。私はクラウドサービスをマネージドと非マネージドという非公式な分類にしています。簡単に言うと、アンマネージド型は基本的なニーズを超える付加価値を提供しません。たとえば、サーバーが必要な場合、提供できるのは 1 台 (仮想マシン) サーバーだけです。DigitalOcean の Droplets や Alibaba の ECS はこれに当てはまります。さまざまなタイプがあり、その製品タイプの下に CPU 最適化タイプ、メモリ最適化タイプなどのサブカテゴリが存在します。一部の製品では、購入時にプリインストールされたシステムまたはランタイム環境を選択できますが、本質的には依然としてサーバーであり、将来何に使用するかは気にしません。

一方、マネージド型は、プログラムの基本的なニーズを満たすだけでなく、より多くの追加サービスも提供します。たとえば、デジタルオーシャンのアプリプラットフォームのホームページに表示されるキャッチコピーは「フルマネージドインフラストラクチャ」であり、直接デプロイメントも含まれます。 GitHub から. 、アプリケーション監視、ログ分析、その他の機能. 現在使用している Azure App Service を例に挙げると、インターフェイス上で次の機能を使用できます。

しかし問題は、アプリケーションがこれほど多くの機能をサポートできるかということです。そうです、あなたのアプリケーションがそれをサポートできるかどうかを尋ねているのです。

私が購入したのは、メモリ容量が1.75Gの最小構成パッケージBasic B1です。しかし、アプリサービスによって提供される監視統計によると、アプリケーションが年間を通じて使用するメモリ (メモリワーキングセット) に必要なメモリは 140 MB のみです。ハードウェアインフラストラクチャがあれば、機能が長期間にわたって正常に動作することが保証されるのは当然のことです。そのため、モニタリングでインフラストラクチャアラートは必要ありません (アラートの実行にも追加料金がかかります)。また、ハードウェアをアップグレードするためにメニューバーに [スケールアップ] ボタンを設ける必要もありません。アプリケーションレベルの監視に関しては、サードパーティの無料サービス UptimeRobot を使用できます。

デプロイメントスロットを例に挙げると、マルチ環境デプロイメントメカニズムが提供されます。最初にステージング環境を作成し、そこに起動されるコードをデプロイし、テストが正しくなった後、ステージング環境プログラムを本番環境に切り替えることができます。ワンクリックで。しかし、中小企業を経営する個人開発者にとって、複数の分離環境（分離データベース環境など）を用意するのは実際には贅沢ですし、人気のないアプリケーションにはダウンタイムを導入し、試用や試用のためにオンライン環境を直接使用することも許容されます。エラー— デプロイメントスロットも厳密には必要ありません。

どのようなクラウドサービス構成を購入すればよいかというと、拡張が容易で十分である、というのが私の答えです。Digital Ocean 上の月額 4 ドルの仮想マシンでメモリが 512 MB のみでアプリケーションを実行できる場合は、それを購入するだけです。少なくともプロジェクトの初期段階では、マネージドサービスによってもたらされる利点はそれほど明白ではありませんが、いつか既存のインフラストラクチャがトラフィックをサポートできなくなったとしても、確実に拡張することは難しいことではありません。

無料の選び方

私たちが思っているよりも多くの「無料」クラウドサービスがあります - この記述が正確ではないため引用符が付けられています。ほとんどのサービスは一定の制限内でのみ無料ですが、ほとんどの場合、個々の開発者の行動は「羊毛をつかむ」ことです。無料のオンライン割り当てに達します。

Alibaba Cloud Effect、Azure DevOps、GitHub Actions の 3 つの無料の DevOps ツールを例として、無料の CI/CD ツールを優先順位の高い順に選択する必要があると考えていることを説明します。

親しみやすさ：この記事のテーマは「速い」です。日常業務ですでに使い慣れているツールがある場合は、それが第一の選択肢です

エコシステムを選択する: すべてのクラウドサービスが同じプロバイダーから提供されることが最善です。アプリケーションが Azure にデプロイされている場合は、Azure DevOps を使用することが最良の選択です。当然のことながら、ワンクリックでパイプラインをクラウドサービスに接続できる組み込みメカニズムなど、より優れたサポートが提供されます。

付加価値: Github Actions は最も純粋に CI/CD に重点を置いています。ただし、他の 2 つは、単なるパイプラインではなく DevOps の価値を提唱しているため、チームコラボレーションとプロジェクト管理機能も同時に提供します。Yunxiao は、DingTalk などの Alibaba エコシステムと統合することもできます。Azure App Service を使用する過程で、既定で提供されるログ収集ツール Application Insights が非常に使いやすく、ログツールに関するほとんどすべての空想を満たしてくれることがわかりました。これは、複数のプログラミング言語をサポートし、フロントエンドとフロントエンドの両方をサポートします。エンドおよび分散トレース、アクティブコレクション、および (一部) 無料

開発経験: サードパーティとの統合がどれほど簡単か、問題のトラブルシューティングが容易かどうかなど。1 つ言及しておきたいのは、Yunxiao の UI は素晴らしく、無料のマニュアルコンサルティングサービスも提供しますが、IaC (Infra Structure as Code) はサポートしていません。私にとっては IaC の方が重要です。

コア機能: CI/CD パイプラインは業界標準であり、誰もがそれを完全に理解しています。ここでは心配する必要はありません。違いはそれほど大きくありません。

業界の状況: この基準条件はこれら 3 つに固有のものではなく、この分野では大きな違いはありません。ただし、静的リソースホスティングなどの他のクラウドサービスについては、私の経験では、Netlify の方が Azure Static Web Apps よりも優れたエクスペリエンスを提供し、より多くのプロフェッショナルなサービスを提供します。たとえば、多くの人が Netlify を使用してシングルページアプリケーションをホストしており、フォーム機能も提供していると考えることができます。Web ページにフォームを統合し、指定されたアドレスにフォームを送信すると、フォームが自動的に収集されます。もちろん、無料のサードパーティサービス FormKeep も利用できます。