マイクロサービスが必要なときとそうでないときについて話すことを提案します。 ネタバレ：プロジェクトによって異なります。
私たちソフトウェア開発者には、かなり興味深い職業があります。 NetflixがXYZに言ったので、私たちは1日中安全にコーディングしてから、何かに関する記事を読むことができます。
ちょうどそのように、一人または会社の意見のために、たとえすべてが完全に機能していても、長年やってきたことをすべて疑い始めます。
あなたはGoogleではありません（Googleでない限り）
HackerNewsやその他のニュースサイトを読むと、Google、Netflix、Amazon、Facebookからの技術的なメッセージをよく目にし、何百または何千ものサービスを開始することについて話します。 彼らは物事を独自の方法で行うことの利点について話します。 これは過去数年間の傾向です。
しかし、それに直面しましょう。 10年以上の歴史を持つ大規模なプロジェクトに取り組んでいる開発者が1000人いることはまずありません。
Googleがこれを行うからといって、それを行う必要があるわけではありません。
私たちは全く異なる銀河で働いています。 Googleはおそらく遭遇することのない問題に直面していますが、同時にGoogleにはできないこともできます。
ほとんどのソフトウェアプロジェクトはどのように始まりますか？
多くのプロジェクトは、すべての作業を行う1人の人物から始まります。 100万の例がありますが、Shopifyを見てみましょう。 当初、サービスはTobias Lyutkeをエンコードしていました（Ruby on Railsに基づいていましたが、それでもちなみに "rails"で動作します）。
コードの最初の行を書く前に、トビアスはmicroし、マイクロサービスの理想的なアーキテクチャを丹念に考えていたと思いますか？
地獄 Shopifyの最初のバージョンを開発するとき、私は出席していませんでした。Shopifyはもともとはスノーボードのオンラインストアでしたが、Tobiasが私（典型的な開発者）のようであれば、プロセスは次のようになりました：
- オリジナル製品を作成しながら、新しいテクノロジーを学びます。
- かなり標準的ではない（厄介な）が、完全に機能するコードを記述します。
- すべてが一緒に機能し、興奮する様子をご覧ください。
- 「火で焼く」などのリファクタリングを行い、問題が発生したときにコードを改善します。
- 新機能を追加して実稼働環境で起動する場合は、このサイクルを繰り返します。
これは非常に単純なサイクルのように思えるかもしれませんが、その深さを理解するのに約20年のプログラミングを要しました。
理論的には、コードの最初の行を書く前に最適な設定を熟考し、プログラマーとして良くなることはありません。 実際の問題が発生し始めるとすぐに、書くことのほとんどすべてをより良いコードに置き換えるという絶対的かつ明示的な意図を持って多くのコードを書くことによって、あなたは良くなります。
置き換えた元のコードは、時間や労力の無駄ではありません。 時間が経つにつれて、それはあなたのレベルを改善するのに大いに役立ちます。 これは秘密の成分です。
コードの抽象化について話す
開発者として、 「DRY：繰り返さないでください」というフレーズを耳にしました。全体として、この仕事を二度としないことは合理的なアドバイスです。 しかし、しばしばやりがいがあります。
完全に理解せずに何かを抽象化し、漏れやすい抽象化と呼ばれるものを作成しようとする場合、繰り返す価値があります。
いくつかのコードのリファクタリングと重複の削除について考える前に、私は通常3回作業を行います。 多くの場合、4回目または5回目以降にのみ対策を講じます。
変数に正確に変換するものが明確になり、このコードが最初に記述された場所から削除する前に、さまざまな状況でコードを複製する方法を何度も確認する必要があります。
組み込みコードから外部ライブラリまでの抽象化のレベル：
- インラインコードを記述します。
- いくつかの異なる場所でコードを複製します。
- 関数などで重複コードを抽出する
- これらの抽象化をしばらく使用します。
- このコードが他のコードとどのように相互作用するかをご覧ください。
- 一般的な機能を内部ライブラリに抽出します。
- 長い間、内部ライブラリを使用してください。
- すべてのピースがどのように組み合わされるかを本当に理解してください。
- 理にかなっている場合は、外部ライブラリ（オープンソースなど）を作成します。
ポイントは、優れたライブラリまたはフレームワークを「発明」することはできないということです。 今日使用している非常に成功したツールのほとんどは、実際のプロジェクトからのものです。 そこで、私たちのお気に入りのツールは、内部使用の実際のケースから抽出されます。
Railsは素晴らしい例です。 DHH（Railsの著者）は、いつか目を覚まさず、次のように言いました。 モデル/、コントローラ/およびビュー/！ディレクトリを作成します。」
いや 彼はBasecamp（実際の製品）を開発し、特定のテンプレートが登場しました。これらのテンプレートは一般化され、RailsのBasecampから抽出されました。 このプロセスは現在も進行中です。私の意見では、これがRailsがこれまでどおり成功している唯一の理由です。
これは、魅力的なコードを書くことができるプログラミング言語と組み合わせた、非常によく実行される（理論的に開発されたものではない）抽象化の理想的な嵐です。 これは、「Rails、only in XYZ」のようなほとんどすべてのフレームワークが機能しない理由も説明しています。 抽象化チェーンの主要なコンポーネントをスキップし、単純にRailsを複製できると考えています。
抽象化からマイクロサービスまで
私にとって、マイクロサービスは抽象化の別のレベルにすぎません。 すべてのライブラリがマイクロサービス用に設計されているわけではないため、これは必ずしも上記リストのステップ10ではありませんが、概念レベルではそのように見えます。
少なくとも1行のコードを記述する前に、完全な外部オープンソースライブラリをすぐに作成しようとしないように、マイクロサービスは開始する場所ではありません。 現時点では、何を開発しているのかさえわかりません。
マイクロサービスベースのアーキテクチャは、実際の問題に遭遇したときにプロジェクトが時間の経過とともに変化するものです。
おそらく、これらの問題に遭遇することは決してないでしょうし、それらの多くは異なる方法で解決できます。 BasecampとShopifyをご覧ください。 どちらもモノリシックアプリケーションとして機能します。
Googleの規模では機能しませんが、だれもが小さいとは思わないでしょう。
Shopifyは、モノリスで月額1700万ドルを稼ぎます
2018年半ばの時点で、Shopifyは60万以上のオンラインストアがプラットフォームで運営されていることを公表しました。
Shopifyは月額$ 29の最も安い料金のSaaSアプリケーションであり、多くの企業が月額$ 79の料金を選択していると感じています。 いずれにせよ、600,000人の顧客が29ドルで最も安いプランを使用したとしても、これは彼らのビジネスのSaaSラインからのみ1か月あたり1740万ドルの収入です。
Basecampアプリは、もう1つの優れたモノリシックアプリです。 Basecampの興味深い点は、従業員が約50人しかいないことと、メイン製品のソフトウェア開発者がその一部にすぎないことです。
マイクロサービスのうさぎの穴を降りることなく、とても遠くまで行けると言いたいです。 そのようなマイクロサービスを作成しないでください。
マイクロサービスはいつ使用する必要がありますか？
それはすべてあなたの決断次第です。 これは、「モノリスに対するマイクロサービス」をグーグル化しないものの1つにすぎません。 マイクロサービスが本当に必要な場合は、すでに知っています。
しかし、アプリケーションの個々の部分で作業するのに最適な開発者がたくさんいるという状況があります。 製品のさまざまなコンポーネントを単独で作業している多数のチームの存在は、マイクロサービスに使用する合理的な理由の1つです。
時間の経過とともにゆっくりと成長する小さなチームがある場合は、1つまたは2つのマイクロサービスから開始できることに注意してください。 このような状況では、採石場から始めて、モノリスを一度に100個のマイクロサービスに分割しないでください。
ゲームはろうそくに値しますか？
また、マイクロサービスへの移行には独自の問題が伴います。 ある問題を別の問題に変更するので、ゲームがあなたのプロジェクトにとって特に価値があるかどうかの長所と短所を比較検討する必要があります。
主な問題の1つは監視です。 突然、さまざまなテクノロジースタックで記述でき、複数のマシンで実行できるサービスの束が得られます。そして、それらを詳細に追跡する方法が必要です。
理想的には、すべてのマイクロサービスで単一の監視サービスを使用したいので、これは難しい作業です。
おそらく、独自のツールを開発したくないでしょう。なぜなら、これ自体が本格的な作業になる可能性があるからです。 それがLightStepのような企業の成功の理由です。 これは、私が遭遇した最も興味深い監視サービスの1つです。
彼らの製品は大規模なアプリケーションに焦点を当てていますが（理由は理解できます）、小規模なプロジェクトでも機能します。 Cloud Field Day 4で発表されたので、最近聞いたことがあります。
いずれにせよ、監視は多くの困難の1つに過ぎませんが、最も苦痛な問題の1つであるため、言及することにしました。
最終的な考え
基本的に、この記事を書いた理由は2つあります。
まず 、2週間前にCloud Field Day 4を訪れ、関連トピックに関するグループポッドキャストに誤って参加しました。 数か月でリリースされるはずですが、ここではいくつかの点について詳しく説明します。
第二に 、オンラインコースの著者として、アプリケーションの作成方法について多くの質問を受けます。
多くの開発者は「フリーズ」し、コードの最初の行を記述する前であっても、アプリケーションを独立したサービスに分割しようとします。 当初から、アプリケーションコンポーネントに複数のデータベースを使用しようとしています。
この瞬間は、彼らが前進するのを妨げます。そして、開発の同僚として、私は優柔不断で立ち往生するのがどれほど難しいか知っています（私はそれを持っていました！）
ところで、私は現在、かなり大きなSaaSアプリケーション（カスタムコースをホストするためのプラットフォーム）に取り組んでいます。 現在、私は単独でプロジェクトに取り組んでおり、最初の日にエディタを開いてコードの記述を開始したことを確認できます。
マイクロサービスを実装することが理にかなっているまで、プロジェクトを完全にモノリシックなアプリケーションとして保存しますが、私の本能はそのような瞬間は決して来ないことを教えてくれます。
これについてどう思いますか？ コメントで教えてください。