Gleyzer両氏によって共同開発されました。2019で、同言語の発表を行いました。InfoQはPurdy氏に言語と、氏らが解決を目指した問題について聞きました。設計/アーキテクチャアジャイルマニュフェスト:ソフトウェアアーキテクトの視点ソフトウェアアーキテクトの役割と責任はアジャイルソフトウェア開発のためのマニフェストの価値と矛盾していると見えますが、優れたアーキテクトはアジャイル開発チームをサポートするテクニックを見つけています。Streamingは、ストリーミングデータのためのSQLライクなインターフェースを提供します。Streamsによって、Redisがストリーミングデータを複数のプロデューサとコンシューマの間で消費、保持、配信することができるようになります。ソフトウェア開発のマニフェストたゆまず息もつかずに市場に突進することで、会社を静かに消滅の崖っぷちへと追い込みます。それは設計してコードを書く方法を再考する時です。簡単さへの投資は、速さへの投資です。簡単さは知的財産の主鉱脈でもあります。競争上の優位性は、一度失ったら、もう一度手に入れることはほとんど不可能です。Buytaerts氏が過去10年間にわたって、企業がDevOps採用のハイプサイクルをくぐり抜け、変革に対する誤解を解消する過程を支援してきた経験について語ります。APIの今後について話を聞いた。氏は10年に及ぶ豊富な経験をもとに,WebサービスにおけるAPIの爆発的な普及に影響を与えたRESTの歴史と,そのシンプルな設計方針について説明してくれた。話の中で氏は,APIがビジネスに広く採用されていった経緯について述べるとともに,今後のAPIやプラットフォーム,ネットワークについてもヒントを示している。自己紹介として,バックグラウンドや主な活動について教えてください。今は7Summitsの最高戦略責任者として,開発者コミュニティにAPIなどを提供しています。ディジタル関連の調査や分析も多数行なっていて,ZDNetを始めとするオンラインアウトレットに記事を提供している他,自分でも関連した著作をいくつか書いています。APIに初めて興味を持ったのは,それまでのヘビーウェイトなWebサービスに代わって,開発者コミュニティの間でRESTが話題になり始めた頃です。従来よりシンプルでWeb指向のAPIが人気を集め始めていました。使いやすく,開発者のツールやテクノロジ,さらに通常のビジネスアプリケーションとの相性もよいことを示すデータが現れ始めたのです。当時Amazonが公開したSOAPとRESTの採用数を比較したデータからは,旧態依然としたWebサービスの人気が凋落し,Web上のサービスにエキサイティングな事が起きつつあることが明らかに現れていました。それが現在ではAPIと呼ばれているものです。ライトウェイトなAPIに関して言えば,現在のAPIマーケットと開発者の進展状況は,当初の期待を非常によく実現していると思います。技術革新については,もっと期待していました。ライトウェイトなWebサービスを開発する新たな方法としては,JSONなどが現れています。いった意味で,当初はそれまでよりも多くのサポートツールが現れることを期待していたのですが,現時点ではスタブの提供などといった重量級のWebサービス用の豊富な機能を備えたEclipseのような,現在ではもはや必要とは言えないプラットフォームが主流となっています。意外だったのは,おそらくはセキュリティの問題でしょう。当初の予測とは違って,初期のシンプルなAPIモデルが極めてレジリエントであって,必要十分なセキュリティを備えていることが実際に証明されたのです。セキュリティ業界においては,これも予想されていたことでした。テクノロジで興味深いのは,その採用状況がいつも偏ることです。一般的な企業,という呼び方はできないと思います。APIでも同じですが,アーリアダプタは本当に早いのです。私は,平均的な企業はAPIを完全に意識しており,戦略的ではないにせよ利用している,と言っても間違いではないと思います。API担当課やAPI部門といったものについては,まだ先進的なテクノロジ企業やスタートアップの新機軸というところでしょう。Things)などでしょう。どの会社でも,最初のユーザとして自社のAPIを使用するでしょう。ほとんどのAPIは,もともと社内用なのです。企業が組織としてAPIに習熟するには,組織内での開発と利用の両方を習得する必要があるのは間違いありません。社外から社内へ,社内から社外へといったように,APIに対する何らかのニーズが明らかになり,それが使われるようになることで,社内外のサービスがミックスされて,かつてはまったく違った多くのサービスやAPIから,ディジタルエクスペリエンスが生み出されるのです。APIをオープンにすることで利用は増えますが,最近ではNetflixやTwitterのようにAPIをシャットダウンする企業も現れ始めています。一方では多数の公開APIプログラムが,開発者のマインドシェアを巡って競い合っています。ルールを証明するという意味では,NetflixやTwitterは例外だと言いたいですね。企業にとってAPIは,成長の初期段階では非常に有効であっても業界リーダの位置に達するとデメリットにもなり得る,という考え方は確かに広まっています。Amazonのように,反例もすぐに見つかります。彼らのAPIは彼らのビジネスそのものなのです。APIが本質的に企業成長の初期段階のものである,という結論がでた訳ではないのは間違いありません。APIゲートウェイに代表されるように,API管理ベンダは主に自分たちを,レガシなIT資産と新しいユーザエクスペリエンスとのゲートウェイとして位置付けています。Twilloなどといったクラウドネイティブな企業は,分散APIネットワークを構築することで,従来型ビジネスを過去のものにしようとしています。どちらも正しいのですが,後者の方がはるかに正確だと思います。ゲートウェイは前提として必要です。それがなくてはエコシステムにアクセスできません。どちらか一方という訳にはいきませんが,マーケットへのアクセスさえ確保できれば,APIは健全で成長を続けるディジタルエコシステムを発展させ,促進させるように設計するべきですね。その2つは,排他的な関係ではないということです。私自身は常々,全サイズ対応という考え方は何においても危険だと思っています。複雑なインタラクションを持つディジタル技術や人的ニーズについては,特にそれが顕著です。ひとつのAPIからスタートする企業が多いのは確かですが,そのプロダクトや外部ユーザが増えてサービスが充実し,単一モデルのアプローチの妥当性に疑問が生じるまでに時間は掛かりません。凝ったアプローチが必要な場合が多いと思いますね。明確に言えるのは,RESTがWebの動作にネイティブに沿ったものであり,それゆえにオープンAPIの基本モデルの基盤となっていることです。すべてのシナリオに対する答になることはありません。ビデオやリアルタイム通信など,当初のWeb設計では予想されていなかった現代的なシナリオにおいてはそうです。中心的な標準に可能な限り近いものの中から,目的に対して最も適したツールを使用するのがよいと思います。設計上の制約が多いほど,適用可能なシナリオは少なくなります。この点では,IaaSもPaaSも大きな違いはありません。IaaSが非常に多くのシナリオ,実質的にはコンピューティングやネットワークに関するすべてのシナリオに適応できるのに対して,PaaSのドメインははるかに限られています。この議論はフレームワークに関するもの,つまり大規模かつ複雑なフレームワークほど本質的にソリューション空間の制限が大きくなる,いう問題に立ち戻ることになります。IaaSの適用範囲は,必ずPaaSよりも広くなります。PaaSに大規模なマーケットの存在することは確実です。どちらも成功すると思いますが,どちらかが他方を圧倒する状態はこれからも続くでしょう。現時点では,一般的な企業に普及するためのカスプ上にあると思います。APIを実際に持っていた先進的な企業では,かなり前から実践しています。素晴らしいことに,APIが提供されると,このようなツールがすぐに現れるのです。現在の開発モデルは,単純なイベント駆動アプリケーションのレベルを脱却して,シチズンデベロッパによるユーザアプリケーションと簡単なアプリケーションフローの構築という段階に入っています。企業のIT部門はアプリケーションロジックを充足し,補完することでこれを支援しています。シチズンデベロッパが実際の存在として開花しようとしている,その初期段階に私たちがいると確証するに十分な証拠もあります。この極めてエキサイティングな世界もまた,APIが実現したものなのです。技術者ではないユーザコミュニティにAPIが広く理解されたのは,私自身はよいことだと思っています。実情は,APIをうまく表現できるメタファが存在しないということでしょう。ユーザは,単純な”アプリ”のような概念であれば,機能やデータな単位として理解できると思います。APIのように,データソースとアプリが混同されることも少なくありません。APIが実際にそうであるように,アプリがデータソースであるという一般的な理解も最近はありますから,問題にはならないと思いますね。Musser氏と話したのですが,現在私たちが話題にしているような,ディジタルビジネス成功に必要な非集中型システムを構築する上で,APIそれ自体が重要であることは間違いない,という点で意見が一致しました。APIレベルより上のメタ概念については,その戦略的な重要性が高まりつつあり,APIそのものと同じように中心的な課題になってきています。Hagel氏のチームによるエコシステムパターンに関する研究でも,APIアーキテクチャを越える,アーキテクチャレベルの大きなステップの存在が示されています。私たちがこの3~4年で理解を深め,現在も戦略的な議論が行なわれているのは,まさにこの部分なのです。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見るあなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。登録するとさまざまなことができます。アカウント登録をしてInfoQをお楽しみください。あなたの意見をお聞かせください。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見る様々なイノベーターとアーリーアダプターがお送りするテクノロジーの概要を見る。自分がまだ知らないことに気づいていないと知るあなたが興味のあるトピックスをいつでも最新な情報に。あなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。よい世界へ私たちが暮らす世界を大切に思い、よりよいものにしたいと考えています。人のためのソフトウェア開発を加速し私たちのミッションを実現することで、この思いを成し遂げようとしています。私たちは利益の1%をさまざまな慈善団体に寄付しています。会社として、また従業員として、そうしたことの価値を強く信じているからです。with.プライバシーBTあなたのプロファイルは最新ですか?プロフィールを確認してアップデートしてください。アドレス*Eメールを変更すると確認のメールが配信されます。会社名:現在の会社名をご入力ください。Other組織規模:現在の組織規模をご入力ください。2,501+国:現在の国を設定してください。Zimbabwe都道府県:現在の都道府県に設定してください。次の都道府県にアップデートする:ニュースレターを購読しますか?インダストリーメールを購読しますか?本Eメールに登録すると、以前より関心のあったトピックの関連情報をお送りする場合がございます。詳細はこちらのプライバシーポリシーをご覧ください。newsletter?新しいメールアドレスに確認用のメールを送信します。このポップアップ画面は自動的に閉じられます。