インストール：基礎化学から量子力学まで
バックグラウンドプロセスでベースデータベースとアプリケーションをセットアップすることは、かなり明確なプロセスでした。 私はGithubでreadmeを公開しています。1時間後、せいぜい2、3時間ですべてが機能し、新しいプロジェクトを開始します。 少なくとも最初の環境では、コードの追加と実行は最初の日に行われます。 しかし、マイクロサービスに挑戦した場合、最初の起動時間は天国に飛び立ちます。 はい。現在、組織化されたDockerとK8マシンのクラスターがありますが、初心者のプログラマーにとっては、これはすべてはるかに複雑です。 多くのジュニアにとって、これは本当に不必要な複雑さである負担です。
システムを理解するのは簡単ではありません。
ちょっと後輩に立ち寄ろう。 モノリシックアプリケーションでは、エラーが発生した場合、それを簡単に追跡し、デバッグに直接進むことができました。 これで、別のサービスを処理するメッセージバス上の何かをキューに入れる別のサービスと通信するサービスができました。エラーが発生します。 最終的にサービスAがバージョン11で実行され、サービスEがすでにバージョン12を待機していることを確認するために、これらのすべての部分をまとめる必要があります。これは、標準の統合ジャーナルとは大きく異なります。プロセスを実行するには、対話型のターミナル/デバッガーを使用する必要がありますステップバイステップ。 本質的にデバッグと理解がより難しくなりました。
デバッグできない場合は、テストするでしょう
継続的インテグレーションと継続的開発は現在一般的になりつつあります。 新しいリリースごとに表示される新しいアプリケーションのほとんどは、テストを自動的に作成および実行するため、登録前にテストに合格してレビューする必要があります。 これらは放棄できない優れたプロセスであり、多くの企業にとって大きな変化となっています。 しかし、今、実際にサービスをテストするには、アプリケーションの完全な動作バージョンを上げる必要があります。 150のサービスのK8クラスターを持つ新しいエンジニアを覚えていますか？ それでは、CIシステムにこれらすべてのシステムを起動して、すべてが実際に機能することを確認する方法を教えます。 おそらくあまりにも手間がかかるので、各部分を個別にテストするだけです。仕様が十分であり、APIがクリーンであり、サービスの障害が隔離され、他のユーザーに影響を与えないことを確信しています。
すべての妥協には正当な理由があります。 そう？
マイクロサービスにアップグレードする理由はたくさんあります。 柔軟性を高め、コマンドをスケーリングし、パフォーマンスを向上させ、安定性を高めるために、これを行うことがわかりました。 しかし、実際には、モノリスを開発するためのツールと実践に数十年を投資し、開発を続けています。 私はさまざまな技術の専門家と仕事をしています。 スケーリングについては、単一のPostgresデータベースノードの制限に直面しているため、通常話します。 講演のほとんどは、 データベースのスケーリングに関するものです。
しかし、私は常に彼らの建築について学ぶことに興味があります。 マイクロサービスへの移行のどの段階にあるのか。 モノリシックなアプリケーションに満足していると言うエンジニアが増えているのを見るのは興味深いです。 多くのマイクロサービスにはメリットがあり、そのメリットは移行パスのくぼみを上回ります。 しかし、個人的には、私のモノリシックなアプリケーション、ビーチの場所を教えてください-そして私は完全に幸せです。