ヒーローズ・オブ・コード」は、開発者、プログラマー、ハッカー、ギーク、オープンソースの反逆者たちが、いかにしてテクノロジーの未来に革命を起こしたかという真実の叙事詩です。
コードヒーローズとは？
この記事はCode Heroesポッドキャストシリーズの第2シーズン：サーバーを使わないオーディオスクリプトです。
はじめに：その本当の意味とは？ウェブを構築する基本的なアーキテクチャは変わりません。しかし、サーバーを少人数で運営・保守するようになった後、開発者にとって何が変わるのでしょうか？
サーバーレス・プログラミングは開発者のためのものであるべきです。また、合理化されたツールキットとはいえ、グローバルなシナリオに焦点を当て続けるべきです。
::
現在、もちろんアメリカ全土で、そして世界中で、インターネットは人々の生活を大きく変えています。
::
時は1998年。 グーグルが最初の従業員を採用したばかりの頃、アル・ゴア副大統領が報道陣のインタビューに答えました。
::
この技術はまだ発展途上です。大統領と私がホワイトハウスに入ったとき、ウェブサイトは50しかありませんでした。それが今では、私の誕生日にバーチャルな花束が届きました。
::
わかりました。すでに眉がひそんでいるのを感じます。なぜ私が20年前のインターネットの歴史をお見せしたいのでしょうか？それは、インターネットの基礎は今も変わらないということを思い出してほしいからです。
::
もちろん、今では50以上のサイトがあることは知っています。でも、まだバーチャルな花を贈っています。開発者の視点に立てば、驚くべき進歩をすべて取り除いたとしても、得られるのは、すべての始まりと同じ「モデル」なのです。分散型ネットワークを提供するクライアント・サーバー・モデル。
::
最近、開発者の間では、アル・ゴアが語ったクライアント・サーバー・モデルが非推奨になるというような話がよく聞かれます。そして、気をつけないと、インフラを抽象化しすぎて、まだそこで仕事をしているサーバーがあることを忘れてしまう可能性があります。
::
しかし、サーバーレスとは本当にサーバーを使わないことなのでしょうか？本当にそうなのでしょうか？それとも、開発者とサーバーの関係は変わりつつあるのでしょうか？このエピソードでは、この"
::
::
ワイヤレス・ネットワークには、場所によってはケーブルがあることをご存知ですか？
::
アンドレア・パスウォーターは......そう...... "サーバーレス "と呼ばれる会社で働いています。彼らはサーバーレス・アプリケーションを開発するための人気のあるオープンソース・フレームワークを開発し、アンドレアは組織がインフラを抽象化する方法に飢えていることに気づいています。
::
この用語は主に、サーバーレス・アプリケーションに取り組む開発者であれば、サーバーのことを考える必要がないという事実を伝えるためのものだと思います。コードを書いて、クラウド・プロバイダーにデプロイするだけで、その管理を心配する必要はありません。それがサーバーレスの本当の意味です。
::
アンドレアにとって、サーバーレスの魅力は明らかです。
::
サーバーレス方式でアプリケーションを開発すれば、デプロイやメンテナンスといった日々の作業を考える必要はありません。つまり、ビジネス価値に集中でき、クリエイティブな仕事に専念できるのです。
::
サーバーレスのもう一つの優れた点は、ライブラリーを何度も構築する必要がないことです。
::
Auth0のようなサービスを直接利用できるのに、なぜ独自の認証メソッドを作成するのでしょうか？結局のところ、サーバーレスとは、開発者が頭の中にあるアイデアをすべて世の中に送り出すプログラムを、より簡単かつ迅速に構築する機会を提供することなのです。
::
なるほど！
::
手いっぱいの荷物を持って、とあるドアに向かってよろめいたとします。このドアがスライドして開くと、シンプルでフレンドリーな ... 続きを読む
::
::
......方法。これがサーバーレスです。サーバーレスによって、開発の煩雑さが軽減されます。実際、組織がハイブリッド・クラウド環境に傾倒し、サーバーレス・ムーブメントが高まるにつれ、開発への障壁はなくなりつつあります。
::
アンドレアは、開発者でない人たちが開発について話すのをよく耳にします。
::
従来はコードを書けないと思っていた人たちが、サーバーレスのおかげでソフトウェア・エンジニアリングの世界に飛び込むことができ、自分のワークフローを自動化するツールなどを開発できるようになったという話です。何を生業にしているかは関係ありません。
::
仕事でやらなければならないことの中には、毎日やっているルーティンワークのような、とても退屈でつまらないものや、"これってコンピューターがやってくれないの？"と思うようなものもありますよね。コンピューターがやってくれないかな」と思うようなこと。私がそう感じるようになったのは、たまたまサーバーレスという会社で働くようになってからです。"今作られている製品は、あなたの役に立つということに気づいているよね？"という感じでした。
::
アンドレアは、自分が開発者だと考えたことのない多くの人々が、いつの間にか、簡単なアプリケーションを自分たちで、基本的に無料で作れることに気づくだろうと考えています。
::
Lambdaを使えば、どんな小さなアプリにもお金を払う必要はありません。ボットに仕事の一部を代行してもらうことで、生産性は上がります。でも、もう退屈な仕事をする必要もありません。もっと面白いことができます。
::
プロの開発者にとっても、この自動ドアの効果は、雑然とした世界では魅力的です。
::
人々は、1人か2人のチームを結成し、短期間でプロトタイプを完成させることに興味があるのだと思います。数日以内にプロトタイプを立ち上げて動かすことができるのです。そうすることで、アプリケーションや製品、会社のビジネス価値を高める部分に集中できることに、人々は気づき始めると思います。ビジネス価値に集中できるというのは、とてもエキサイティングなことです。
::
別の言葉を投げかけますよ。Ready？AWS LambdaやApache OpenWhiskのようなサーバーレス製品のことです。"サービスとしての機能 "とは、トリガーされたときだけ機能を実行する方がプログラムにとって効率的だということです。
::
それに、コンピュート・パワーやアップタイムの心配がかなり減ります。最終的には、サーバーレスはかなり優れた基本構成になるかもしれません。実際、サーバーレスにするかどうか迷っている人もいます。サーバーレスはコンテナに取って代わるのか？
::
こういう考え方は理解できます。
::
Michael Hausenblas は Red Hat OpenShift チームの開発アドボケイトです。
::
::
そうです。なかなか良さそうですね。すべてが自動化され、抽象化された、開発者版ミニマルインテリアデザインのような、ちょっと夢のような「環境」のようですね。素晴らしい、クリーンなインターフェース。
::
でも、マイケルはあなたに現実を知ってほしいのです。
::
O&Mはありません！あるんですか？魔法のように消えてしまうんです。Hacker newsやTwitterなど、あらゆるところでこのようなジョークを目にすることができます。サーバーがない？もちろんありますよ！もちろんありますよ。メンテナンスもあるし。
::
誰かがこれをやらなければなりません。誰かがサーバーをセットアップし、オペレーティング・システムにパッチを当て、コンテナ・イメージを作成しなければなりません。もちろん、何らかのコンピューター上です。
::
これはゼロサムゲームではありません。ファンクション・アズ・ア・サービスはコンテナを直接置き換えるものではなく、ツールボックスにツールを追加するものなのです。さらにお伝えしたいことがあります。この新しいツールを使うことで、サーバーレスへの移行はOpsが他人事になることを意味するだけではありません。
::
インフラ側では、運用の仕事も少しあります。しかし、開発者の仕事も少しあります。Lambdaを使うような極端な状況であれば、管理者権限は一切ありませんよね？
::
インフラ管理者に電話やメールで照会ることはできません。当然、組織の誰かがやらなければなりません。しかし私は、多くの組織がそれをとても簡単で安上がりだと考えているのではないかと心配しています。これとこれとこれを動かして、誰が待機しているのか、実際に待機しているのは誰なのかを忘れる必要はありませんか？そのための戦略はありますか？
::
もしそうでないなら、まずは戦略を練ることをお勧めします。
::
誰かが待機している必要があります。サーバーレス」を選択したとしても、より大きなシナリオを念頭に置き、運用と保守を整える必要があります。
::
先ほど私が「Functions as a Service」という用語を投げかけたとき、少しゾッとしましたか？これまでクラウドベースの開発では、「サービスとしてのxx」という用語が数多く使われてきました。Infrastructure as a Service、Platform as a Service、Software as a Service、Data as a Service、Database as a Service......などなど。
::
その違いを理解するのに苦労しているのは、あなただけではありません。そこで、ヒマンシュ・パントの登場です。彼はインドのデリーにあるロイヤル・スコットランド銀行の技術部長です。彼は何年もかけて違いを分析してきました。
::
これらの他のコンピューティング・パラダイムはサーバーレスと名前が似ているため、人々は忘れがちで、なぜサーバーレスと呼ばれないのか、なぜこれがサーバーレスと呼ばれるのか混乱しがちです。
::
ですから、サーバーレスはコンテナとは違いますし、サーバーレスはPlatform as a Serviceではありません。しかし、Himanshu氏はそれを明確にしたいと考えています。FaaSは何を提供するのか？そして何を提供しないのか？
::
彼は、サーバーレスを使うタイミングと諦めるタイミングを見極めた2つの逸話を披露。1つ目は24時間のハッカソン。 ヒマンシュウは当時チャットボットを開発しようとしていました。
::
その選択に影響を与えるさまざまな指標があります。例えば、論理カバレッジ、発生する可能性のあるコスト、スケーラビリティなどです。そして私はこれをサーバーレス環境で行うことにしました。
::
開発をしているときに、コストという次元があることに気づきました。ですから、他の参加者がもっと優れているとしても......私はカバレッジ、つまり論理的なカバレッジを言いたいのです。ここではNLPの文脈やシナリオについて話しています。
::
しかし、コストとスケーラビリティの面では、私の圧勝です。なぜなら、サーバーレスの場合、チャットボットを呼び出す回数と、それに応じた機能のトリガーに完全に依存するからです。このユースケースは、サーバーレスにすることに非常に満足しています。開発時間も短縮され、率直に言って、当時は本番規模のワークロードではありませんでした。
::
私はプラットフォーム上の特定の新興ツールにアクセスできます。これは私にとっての勝利です。
::
それはいいことです。サーバーレスが理にかなっているのはそのときです。しかし、ヒマンシュウが現在働いている銀行では、レガシーからクラウドにシステムを移行しています。そして、それは異なる目標を提起しています。
::
どのワークロードがどのパラダイムに当てはまるかを確認しようとしています。例えば、IaaS、BaaS、FaaSなどです。1つ目は、信頼できるベンダーを見つけるのが難しいこと、2つ目は、テクノロジーが広く実証されていることです。これは、銀行のようなリスクを嫌う業界には特に当てはまります。
::
それはPlatform-as-a-Serviceですが、より良い証明、より良い機能性、そして従来のツールよりも優れている点についてのニーズはまだあります。
::
ヒマンシュウは、自分自身のニーズと快適な環境を見極め、どのワークロードがどのクラウド仕様に適しているかを検討しています。
::
例えば、ポータルサイトのようなものを作りたいと考えている人がいるとしましょう。そのようなアプリケーションでは、特定のマシン上でレイテンシが発生することは想定されていないからです。
::
結局のところ、すべてを1つのバケツに放り込むのではなく、慎重なアプローチが必要なのです。どのクラウドベースのアーキテクチャが本当に自分がやりたい仕事なのかを考える際に、もうひとつ考慮すべきことがあります。これらの抽象化されたもの、つまりあなたの手を自由にするものすべてが、最終的に仕事の進め方だけでなく、仕事そのものをどのように変えるのか、ということです。
::
作業の一部を抽象化することは、カスタマイズの選択肢が少なくなることを意味します。購入した車を想像してみてください。動くし、走ります。しかし、自分で組み立てた車を想像してみてください。
::
それには代償が伴います。
::
IBM ResearchのAIエンジニアリング・ディレクター。
::
このようなサーバーレスアプリケーションを使用する場合、起こっていることすべてを完全にコントロールできるわけではありません。完全なスケジュールや、いつ、どこでプログラムが実行されるかをコントロールすることはできません。
::
トレードオフですよね？サーバーレスを使う場合、きめ細かい制御は的外れになる可能性があります。
::
エンドユーザーにとっては、もっとコントロールしたい、もっと違う計画を立てたい、もっとチェックとバランスを取りたい、もっと違う値で機能を実行したい、などなど、抽象化されすぎています。本当にシステムに入っていじくり回したいのであれば、自分でデプロイ環境を作ればいいでしょう。
::
ラニアと彼女のIBMチームはその動きに参加しています。
::
最初に調べるべきは、ある言語です......それは基本的にJavaScriptの拡張で、より軽量なサービスを持つ方法の出発点として、こうしたマルチスレッドの対話型サービスの組み合わせを作成することができます。同じ頃、クラウドやマイクロサービス、Platform-as-a-Serviceが本格的に普及し始めました。
::
この2つのトレンドを組み合わせるだけで、あなたや他の人から提供されるかもしれない多くのウィジェットで、さらに高次の機能を構築することが可能になります。
::
ラニアと彼女のチームは、オープンソースの機能的プラットフォームであるApache OpenWhiskを構築しています。
::
OpenWhiskは、最初からオープンソースでした。その大部分は、コミュニティと一緒に参加するためでした。また、自分たちでサーバーレス・コンピューティング環境を運用したい人たちが、自分たちのニーズに合わせてカスタマイズしたり、自分たちの管理下に置いたりして、実際にどのように機能するかを確認し、よりよくコントロールできるようにするためでもあります。
::
また、通常のサービスでは得られないようなきめ細かなコントロールが可能です。
::
自分たちでサーバーレスの運用環境を運営したい人たちに、コントロールを取り戻しましょう。これがサーバーレスの次のステージです。OpenWhiskに参加すれば、FissionやGestaltのような他のオープンソースプラットフォームを手に入れることができます。サーバーレス空間がこれまで以上に適応性が高く、強力に進化するのを見始めましょう。
::
サーバーレスのオープンソース版がなぜ重要なのかを本当に理解するために、私はOpenWhiskの創設者の一人に話を聞きました。
::
こんにちは、ロドリック。
::
それはいいですね。お元気ですか？番組に呼んでくれてありがとうございます。
::
ロドリック・ラバは、OpenWhiskを構想し、設立した3人の開発者の一人です。以下はその会話です。
::
他の人は混乱するかもしれませんし、"サーバーがないのにどうやって計算するんだ？"と鼻で笑われるかもしれません。
::
はい。サーバーはどこかにあるので、わざわざ考える必要はないんです。
::
その通りです。これがこのモデルの本当に素晴らしいところです。サーバーレスで開発を始めると、もう元には戻れません。私はもう4年近くサーバーレス開発に携わっていて、プロダクションクオリティのアプリケーションをいくつか開発してきました。
::
これが今の私の唯一の開発方法です。コンピュータを設定し、オペレーティング・システムをインストールしなければならないと言われても、私にはまったく理解できません。どうすればいいのかさえわかりません。
::
そうです。そう言われると、肩の荷が下りたような気がします。あのね。サーバーレスについて聞いた当初は、"またひとつ学ばなければならないことが増えた "と思ったものです。
::
でも、そう言われると聞こえはいいですね。
::
素晴らしいと思います。しかし、この幻想の泡から少し空気を抜かなければならないことに、もうお気づきでしょう。それは万能薬ではありません。
::
起業した当初は気づかなかったような、意外なリスクや問題とは？
::
透明性の欠如が最大の問題でしょう。コンピュータの抽象度を上げる新しい言語が登場したときに出てきた技術を思い出させます。今日のサーバーレス環境でも、同じような衝撃があります。
::
::
::
ちょっとした透明性を得ることは、あなたにとって難しくなっています。そこで役立つのがツールです。しかし、ツールがないために、人々は大きな罠にはまってしまうのです。
::
::
このプロジェクトは、Amazon Lambdaが製品として発表された瞬間に始まりました。それは実は、サーバーレスという言葉が使われ始め、この分野で注目を集め始めた瞬間でもありました。Lambdaを見たとき、「ここには開発すべき技術がたくさんある」と思いました。クラウド・コンピューティングの新しい基盤レイヤーの上だけでなく、その上に配置されたプログラミング・モデルの上にも。IBM研究所出身ということで、プログラミング言語の設計、コンパイラの専門知識、ランタイムの専門知識だけでなく、非常に強力なスキルがあります。
::
基本的に3人の小さなチーム......。
::
すごい。
これは、今日のサーバーレスの実際のプログラミング・インターフェースです。プログラミング・モデルのコンセプトと、それをサポートする実際のアーキテクチャは、本質的に、サーバーレスがサポートするすべての利点を提供するサーバー・モデルの機能です。
::
本当の発端はAmazon Lambdaの登場であり、間違いなくコンピューティングの新しいモデルであることに注意してください。
::
どのくらい時間がかかったのですか？最初のバージョンはいつ出たのですか？
::
実際、かなり早いです。実際、IBMが発表したときは......まだIBM OpenWhiskでした。
::
::
これは本当にエキサイティングです。
::
実に印象的ですね。実際、最初に起動するときはOpenWhiskという名前ではなく、Whiskなんですよね？
::
ウィスクは社内の名前です。私が名付けました。名前に込められた意味は、素早く柔軟に動くということです。
::
それはいいですね。
::
かき混ぜる」だけ。オーブンで焼くこともできます。
::
素晴らしい、これを見たとき、私は間違いなく卵を考えていましたから。卵を買おうと思っていたんです。
::
そうですね。この名前については、肯定的な意見も否定的な意見もあります。ある技術をオープンソース化してGitHubに載せる際、その技術がオープンソースと同様にオープンであり、自由に使用、ダウンロード、貢献できることを強調するために、先頭にopenを付けます。
::
はい。
::
オープンソースにした目的は、今日のサーバーレスプラットフォームに実装できる標準をいくらか強化するためです。本番環境で使えるだけでなく、世界と共有でき、学術的な研究や一般的な研究にも使えるプラットフォームを作ることが重要でした。IBMの研究組織出身ということもあって、少しはそういう意味もあったのかもしれません。
::
プリンストン大学からコーネル大学まで、多くの大学が研究にOpenWhiskを使っています。ブラウン、ウィリアムズ、マサチューセッツ工科大学（MIT）、CMU、その他いくつかの大学に行き、学生たちにサーバーレスやサーバー機能に関する問題やツール、プログラミングモデルに目を向けてもらい、この技術に興味を持ってもらうための講演をしてきました。
::
オープンソースプロジェクトに貢献した場合、IBMのクラウド機能がそれを受け入れ、通常1週間以内に本番環境で稼働させる道があることを示します。
::
すごい。速い。
::
これには驚く人もいました。
::
とても効率的なプロセスです。
::
これは、いかに多くの技術がオープンソース環境で開発できるかを如実に示しています。オープン・コア・モデルではなく、一部のコンポーネントは予約されています。IBMのクラウドで実際に稼働しているのは、Apache OpenWhiskプロジェクトです。
::
サーバーレスの将来や、前進するために選択された道について考えるとき、オープンソースへの移行は避けられないと思いますか？
::
最近、オープンソースの価値について、特にクラウド・コンピューティングの分野で激しい議論が交わされていると思います。
::
そうですね。
::
人々がなぜクラウドに目を向けるのか、あるいはなぜクラウドに踏み切ることを嫌がるのかについて考えるなら、それはベンダーロックインの問題......透明性の喪失です。オープンソースは、こうした問題をある程度緩和する上で重要な役割を果たしています。Kubernetesのようなサービスは、コンテナやシステム管理の面でクラウドとの共食いに成功しています！
::
もしあなたがやっていることがコンテナに触れているのであれば、その優位性を考えると、クローズドソースを維持するかどうかを議論する価値はあるのでしょうか？私は、オープンであることは助けになると考える傾向がありますし、開発者の観点からは魅力的です。
::
サーバーレスエコシステムとそのツール、プロジェクト、サービスの未来を考えるとき、あなたは何を見ますか？あなたにとってサーバーレスの未来はどのようなものですか？
::
基礎となるテクノロジーについてはあまり考えなくなり、プログラミング体験や、デバッグ、デプロイメント管理、パフォーマンス分析、セキュリティなど、その周辺のツールについて考えるようになると思います。
::
どれも非常に重要だと思います。機能をどのように実行するかという根本的なメカニズム--コンテナで実行するのか、将来のテクノロジーで実行するのか、1つのクラウドで実行するのか、複数のクラウドで実行するのか--は重要ではないと思います。Kubernetesがコンテナやコンテナ管理でやっているようなものです。
::
同様に、サーバーレスのコンセプトを可能にするサービス・レイヤリング機能で、その上に置くレイヤがあります。そして、それが実際にどのように機能するかは、ミドルウェア次第です。開発者がこの新しいクラウドベースのコンピュータを実際に活用できるように、そして開発者の体験を楽しくするために、どのようなハードワークを提供するのか。
::
はい。この権限委譲はどのようなものですか？
::
一言で言えば、効率です。開発者として、あるいは会社で働いているのであれば、会社にとって価値のあることだけに集中できるのです。そうすれば、インフラやハードウェア・レベルでのスケーリングやセキュリティーについて考える必要がなくなり、脳細胞が解放されるため、問題をより早く回避することができます。
::
今、あなたは本当に革新することができ、あなたの頭脳をより速く革新することに振り向けることができます。結局は、より効率的であることだと思います。
::
ロドリック・ラバはOpenWhiskの創設者です。このエピソードの冒頭で私が言ったことを覚えていますか？インターネットがベースにしている古いクライアント・サーバー・モデルはなくなりません。変わるのは、つまり根本的に変わるのは、サーバーについての考え方です。
::
いわゆるサーバーレスの世界では、インフラを気にせずコードそのものに集中したいものです。しかし、どの抽象化レベルを選択するか、そして抽象化されていない作業をどのように制御し続けるかが、サーバーレスの世界を本当に興味深いものにしています。
::
サーバーレスは最終的に、開発者の権限を強化するものであるべきです。パッチの適用、スケーリング、インフラ管理から解放されます。しかしその間、一部のタスクが抽象化されたとしても、全体がどのように機能するかに焦点を当てることが重要です。どのようなコントロールを放棄し、どのようなコントロールを取り戻すのか？
::
次回のエピソードは、Heroes of Codeが火星に向かう壮大なシーズン2のフィナーレです。NASAの火星探査機がどのように独自のオープンソース革命を起こしているのかに迫ります。また、NASAジェット推進研究所のCTOに話を聞き、オープンソースが宇宙探査の未来をどのように形作るかを学びます。
::
サーバーレス開発や今シーズンのトピックをもっと深く知りたい方は、無料のリソースをご覧ください。その間に、あなた自身のコード・ヒーロー・ゲームに貢献することもできます。
::
ご清聴ありがとうございました。プログラミングはもう結構です。
LCTT SIGおよびLCTT LCRH SIGとは何ですか？
参加して貢献すると、レッドハットと共同貢献者限定の証明書が発行されます。
経由
