n8nを2年間使ってきた経験から言うと、同じようなソリューションがたくさんある中で、これは本当に良い製品だと思う。安定してるし、すぐに使える統合がめちゃくちゃ多い。モジュールシステムとして設計されてるから、自分で作るのも簡単。コミュニティ中心で、コミュニティのワークフローや統合モジュールがGitHubにたくさん公開されてる。あ、オープン（コア）ソースだしね。特定のエンタープライズ機能がオープンになってないのは残念だけど、ほとんどの強力な機能はオープンで、自分でホストしたり、改造したりできる。結局、アプリを形成するPythonの部分ができるのは間違いない。スケールするかって？もちろん。複雑なフローは維持可能か？コーダーとしては、スニペットで作られたビジュアル要素より、コードのリポジトリを維持する方が好きだけど、重要なのは生産性。シンプルなフローなら、コミュニティの知恵でほとんど解決できるから、インターフェースに慣れれば数時間、いや数分で価値のあるソリューションが手に入る。もう一つのポイントは、パイロットフローをアプリとしてデプロイして、実データでテストして、パイロットテストが終わったらボタン一つで本番に持っていけること。コードプロジェクトだと、しっかりしたCI/CDパイプラインが必要になるからね。私にとっての限界や欠点は、論理的で計算負荷の高いソリューションはn8nプラットフォームで動かすのには向いてないってこと。n8nをスケールするのは、単一機能のアプリケーションコンポーネントをスケールするほど直感的じゃない。例えば、CPU負荷の高いノードとメモリ負荷の高いノードがあったら、全体のインスタンスをスケールするのが非常に非効率的になる。メモリ集約型アプリケーションのメモリをスケールするのと、計算集約型コンポーネントの計算をスケールするのは、はるかに最適だよ。もしリソースコストがフローの価値に対して重要でなければ、自己ホストのn8nをスケールすればいいし、あなたのアナロジーに従えば「パイソンの巣」を維持するだけで済む。注意：n8nは残念ながらカスタムコードノードにPythonかJavaScriptしかサポートしてないけど、ポリグロットランタイムを作ってくれたらもっと良かったのにね。でも、他のフロープラットフォームがユーザーにできることよりはずっといいよ。