API開発のためのプログラミング言語"Ballerina"の直感的な構文について解説します。認証や承認、OpenAPIツール、可観測性、SQL/NoSQLクライアントライブラリなど、重要な言語機能についても論じます。記事を読み終えれば、Ballerinaが次のバックエンドAPI開発の有力な候補である理由がよく理解できるでしょう。2022年4月InfoQ編集チームが2022年に進化するソフトウェアアーキテクチャと設計のトピックをどのように見ているかの概要です。アーキテクトが今、何を設計しているかに焦点を当てています。Pan氏が、分散データベースシステムにおけるシャーディングアーキテクチャのパターンについて論じます。ShardingSphereプロジェクトがデータシャーディングの課題にいかに対処しているかを説明した上で、DistSQLを使って分散データベースと暗号化テーブルを生成する方法の実例2つを論じています。カルチャー&手法カオステストで、見えない課題からアプリケーションのレジリエンスを改善するこの記事では、Netflixが提唱するカオステストの原則を列挙した。読者は、カオステストが提供するメリットとデメリットを理解できるはずだ。することで、カオステストを行うかどうかの判断材料となる。リスクに対するすべてのメリットを考慮して、カオステストを行うために経営陣を説得すべき理由も説明した。management.原文(投稿日:2021/04/15)へのリンク過去数年間にわたって、DevOpsとDevSecOpsは、多くの企業のソフトウェア開発や管理に対するアプローチを革新してきました。これらの用語は頻繁に使用されるようになり、事実上、綿密な計画の下で実践されるソフトウェア開発の代名詞になっています。DevOpsとDevSecOpsの価値を理解することは重要ですが、しかしこれらは、あらゆる規模に適合するような、堅牢かつ不変のパラダイムという訳ではありません。それどころか、どちらのアプローチも、それ自体がいまだ発展途上なのです。来年のDevSecOpsは、もしかすると今年のDevSecOpsとはまったく違っているかも知れません。DevOpsとDevSecOpsの採用を推進し、影響を与える9つの重要なトレンドを探し出し、そのそれぞれについて、開発や管理に関わる数多くのアプローチとともに説明します。どちらのアプローチも、この数年間で人気が爆発的に高まっているという事実があります。サイバーセキュリティのリスクを管理するための、より統合的な手段を提供するのはもちろんですが、同時に(直感的でない部分もありますが)開発プロセスやチームを極めてアジャイルな存在にしてくれる、という理由があるのです。これはDevOpsが、運用チームと開発チームに対して、必要なタスクを効果的に拡散してくれるからです。作業をする人数が少ないほど、チームはより効率的になるのです。これらのアプローチを採用するには課題もありますが、それによって得られる潜在的メリットは、一般論として、このリスクを正当化するには十分なものです。大部分の開発チームにとって、これはまず、DevOpsプロセスに移行することを意味しています。その後、DevOpsが発展してDevSecOpsになるのです。この移行中に得られる運用面でのメリットの他にも、たくさんのメリットがあります。見落とされがちなメリットのひとつが、DevOpsが広く普及したことにより、多くの開発者にとってDevOpsが既定の作業方法になっていることです。DevOpsは、それを実現するためのツールやベストプラクティスを超えて広がっているのです。DevOpsの導入を成功させるには、文化や考え方を変える必要があります。"この傾向は今後も続いていく可能性が高いので、DevOpsへの移行に後れを取っている企業は、将来的に才能のある開発者を採用することが難しくなるかも知れません。モノリスからマイクロサーバへそれでは、DevOps採用を後押しし、今後もその将来を定義し続けるであろう、技術的トレンドに話題を変えましょう。広い技術的レベルにおいては、DevOpsへの移行は、モノリシックなアーキテクチャからの離別と、より小さく、よりアジャイルなコンポーネントのネットワークによって構成されるアーキテクチャへの移行が同時並列的に成し遂げられたものです。この一般的な傾向は、いくつかの形で現実となって現れています。よって、ソフトウェアのデプロイメントは、コンテナ階層を通じて処理されるのがごく普通になりました。独立的にデプロイ可能なサービスのスイートとしてソフトウェアアプリケーションを設計する手法へという、広範な移行の兆候なのです。この傾向に批判がないわけではありません。企業にとっては、機会と同じ位の数の課題がもたらされることも少なくないのですが、マルチクラウドセキュリティ管理のための堅牢で成熟したアプローチが開発され続けることで、全体的なこの方向性は、もはや後戻りできないものになっています。既定としてのクラウドマイクロサービスとコンテナ化に向けた動きは、関連するトレンドを加速する上でも有効です。そのひとつが、すでに10年近く実施されている、既定のアプローチとしてのクラウドにおけるソフトウェア管理です。事実、多くの若い開発者にとっては、もはやこれが"トレンド"であること自体が不自然かも知れません。データ保護が特に重要な要件である場合を除けば、私たちは常に、データの透明性を追求していたのではなかったでしょうか?そうなのです。抱えたチームが、効率的かつ安全にアクセスできるクラウドサービスを構築することでした。現在ではこのニーズに合った、よく設計されたサービスがたくさん存在するので、クラウド上での実行を前提としたソフトウェアを立案できるようになりました。これは、DevOpsモデルが出現した時点で前提条件として持っていたものではなく、成功を積み重ねていった結果なのです。Kubernetesもう少し具体的な話をしましょう。DevOpsとDevSecOpsの発展におけるコンテナ化の影響については、誇張し過ぎるということはありません。Kubernetesなのです。Kubernetesの普及は、コンテナ化インフラストラクチャの一部としてのDockerとともに、これまで述べた移行のいくつかの部分に直接的な関わりを持っています。事実としてコンテナ化は、現在のソフトウェア開発に使用されている分散型超並列アプローチにおいて、必要不可欠な存在になっています。コンテナ化のないDevOpsは、もはや想像すらできません。anarchy)をベースとしたインフラストラクチャの構築を促進してくれるからです。現在は、大半のDevOpsチームが、経験の浅いメンバに対しても、アクティブなソフトウェアリポジトリに比較的大きな変更を加えることを許可していますが、これはコンテナ化による継続的な検出機構が、このような変更を裏で支えてくれているからです。これによって、アップデートやアップグレードの管理が大幅に高速化されているのです。実際に、Kubernetesとコンテナ管理システムを最大限に活用すれば、運用チームによるソフトウェアによる更新管理作業の必要性は低くなります。プラットフォームがシステムのスタックを運用して、個々のチームが、それぞれ適切と思われるタイミングで変更をリリースできるような権限とアイソレーションを持てばよいのです。これは一般的に'NoOps'と呼ばれるシナリオで、オートメーションが高度化してデプロイが容易になるにつれて、今後普及していくものと思われます。アジャイルインフラストラクチャ柔軟性を指向するこれらの動きは、ソフトウエア開発ライフサイクルの一部として最も身近なものですが、そのルーツが他の分野にあるということも覚えておく価値があると思います。運用プロセスにおけるリアルタイムな柔軟性への要求は、事実として、過去何十年にもわたって発展を続けてきた製造業での設計における同様のトレンドに、その起源をたどることができます。製造業の世界では、フレキシブルなインフラストラクチャ設計には長い間、"アジャイル"アプローチという名称がありました。このアプローチでは、高度に堅牢で、高度に接続され、それでいて比較的安価なインフラストラクチャの重要性が強調されていました。大手の製造企業に対して、コラボレーション、組織化、レジリエンスを達成するためのスキルセットの多様化、短期のイテレーション、自己改善型の作業プロセスといった、ソフトウェア企業の持つ数多くの特性を教えたのもこのアプローチでした。その影響力は今、逆の方向に変わったように思えます。ソフトウェア開発者は現在、製造業の設計者たちがIoTネットワークに関する豊富な経験を持ち、特にこれらのシステムをアジャイルかつ安全に保つことのできるハードウェアインフラストラクチャ設計のためのアプローチを実践していることを認めているのです。エンドユーザ・オートメーションDevOpsがもたらすものは、しかしながら、開発者や運用スタッフの作業を簡単にすることだけではありません。両方のチームをひとつのユニットにまとめることによって、相互のコミュニケーションが大幅に効率的になり、両チームがこれまで関与してきたプロセスがより効果的になる、ということも期待されるメリットのひとつです。大部分の企業において、この2つのチームからのインプットを必要とする最も重要な協調的プロセスは、ソフトウェアのリリースでしょう。過去数年間、新しいソフトウェアのリリースやデプロイメントの簡略化を目的とした、オートメーションツールの新たなファミリが現れているのは、この理由からなのです。参照コード検索ツールという、コードデリバリに関わる一般的な手作業を自動化するツールなどは、この一例と言っていいでしょう。ここで得られるのは、新たなソフトウェアをリリースする(あるいは既存のソフトウェアをアップデートする)技術的プロセスの完全な自動化です。当然ですがこれは、開発チームや運用チームがソフトウェアのリリースに関与しなくなる、という意味ではありません。集中できるようになる、という意味なのです。保護ではなく回復力をDevOpsやDevSecOpsはおもに管理上のソリューションとして開発されたものですが、ソフトウェア会社がサイバーセキュリティにアプローチする方法に対しても影響力を持っています。指摘したように、DevOps時代におけるインシデント管理は、かつて行われていた危機管理の類とは大きく異なっています。ソフトウェアパッケージの新バージョンの出荷(文字通り船で出荷(shipping)される場合もありました!)が年1回であった時代には、リリース毎にセキュリティ上の脆弱性を厳密にテストする時間がありましたし、見落としていた部分を数か月費やして修正するようなことも珍しくはありませんでした。それが悪いとは言いませんが、今はそんな時代ではありません。DevOps時代がもたらした短期間のリリーススケジュールによって、多くのセキュリティアナリストが、自身の仕事はソフトウェアを保護することではなく、ソフトウェアに回復力(レジリエンス)を提供することである、と考えるようになりました。すべてのセキュリティ上の脆弱性が修正可能であるという非現実的な期待をするのではなく、DevSecOpsチームの多くは今、ソフトウェアはすべての部分が脆弱であるという前提に立って、その結果から他の部分を保護することに注目しているのです。高度なマルウェアとAPT分散型クラウド、マイクロサービス、クラウドファーストなソフトウェア開発への移行は、最高のDevOpsチームというものを、ソフトウェア開発や管理に対する従来型のアプローチよりも、はるかにフレキシブルな存在にしました。そこには大きな課題もあります。その最も直接的なものは、高度な形式のマルウェアの台頭です。これらは、現代的なソフトウェア開発アーキテクチャの持つ分散性を利用して、APTによって展開されることが少なくありません。Rembert氏によると、マルウェアは今日のソフトウェアにおいても依然として大きなリスクなのです。"無害に見えるソフトウェアパッケージに、悪意を持ったソフトウェアが組み込まれている場合もあります。これらのWebサイトは、悪意を持った者に攻撃された正当なWebサイトである場合もありますし、悪意を持ったソフトウェアに感染させる目的のみで作成されたWebサイトの場合もあります。"さらに高度なマルウェアの中には、分散型クラウドシステムのさまざまなコンポーネント間で渡されるデータを傍受することで、そのセキュリティを損なうものも存在します。移行を慎重に計画して、セキュリティチームを開発プロセスやメンテナンスプロセスに関与させることで、ソフトウェアの安全性は大きく向上します。これは、後付けて追加するのではなく、インフラストラクチャ設計時に重要な部分として捉えておくことによって、初めて実現可能なものです。AIとML最後に忘れてならないのは、AIツールとMLツールです。DevSecOpsチームがこれらの技術を大々的に展開する方法はいまだ模索中ですが、AIが将来のDevOpsに大きな影響を与えることはほぼ間違いないでしょう。どのようなものになるのかは、いまだ不明な部分があります。すると、AIツールやMLツールの提供可能な高度なオートメーションによって、多くのチームがDevOpsのOps部分を完全に忘れ去ることができるかも知れません。この想像上のユートピアでは、運用はすべてAIによって処理されます。開発者は現実のコード実装に関する複雑さに対処することなく、コードを自由にリリースすることが可能になります。夢物語に聞こえるとすれば、おそらく、そのとおりだからです。work)"作業をソフトウェア管理から取り除くのは可能ですが、完全に排除することはできません。それよりも、運用担当チームが自動化された管理システムのマネージャになる、という方が現実的でしょう。将来像ここまでで、DevSecOpsの導入を推し進める重要なトレンドが分かりました。DevSecOpsのさまざまな形式、と言うべきかも知れません。DevOpsを採用している数と同じくらい多くのプラクティスが存在して、それぞれが自身のロジックに基づいて発展しているのです。あっても、ソフトウェア開発が将来的にどの方向に進むのかを把握することはほぼ可能であって、ここまで説明した方法がそれです。それは、よりアジャイルな、より分散的な、より自動化されたものになるでしょう。最終的には、開発チームと運用チームの双方にとって、素晴らしいニュースです。Bocetta氏は元セキュリティアナリストで、海軍のネットワークエンジニアとして長く勤務していました。現在はセミリタイアして、セキュリティやプライバシ技術に関する教育に広く携わっています。氏の仕事の多くは弾道システムの侵入テストに関するもので、ネットワークを分析してエントリポイントを探し、その結果に基づいてセキュリティ上の脆弱性評価を作成していました。氏は、高度な"倫理的"ハッキング演習の計画、管理、実施を通じて、海軍(陸上と海上の両方)で使用されているエンタープライズシステムにおける、脆弱性の特定やリスク状況の軽減を支援していました。アプリケーションやネットワークに対する脅威の特定と阻止、攻撃ベクトル領域の低減、脆弱性の除去、一般的な報告作業が業務の中心でした。氏はネットワークの弱点を特定し、さまざまなサイバー脅威に対してネットワークを強化するための新たな戦略を立案することができます。アーキテクトや開発者と緊密なパートナシップを築くことによって、氏は、アプリケーションにおいて特定された脆弱性を緩和するコントロール方法を特定し、さまざまな脅威の戦術、技法、手順の模倣によりセキュリティ評価を実施してきました。毎週火曜日に前週のまとめコンテンツをお送りいたします。(日本語版は不定期リリース)25万人のシニアな開発者コミュニティーにぜひご参加ください。サンプルを見るあなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。登録するとさまざまなことができます。アカウント登録をしてInfoQをお楽しみください。あなたの意見をお聞かせください。毎週火曜日に前週のまとめコンテンツをお送りいたします。(日本語版は不定期リリース)25万人のシニアな開発者コミュニティーにぜひご参加ください。サンプルを見る様々なイノベーターとアーリーアダプターがお送りするテクノロジーの概要を見る。自分がまだ知らないことに気づいていないと知るあなたが興味のあるトピックスをいつでも最新な情報に。あなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。Inc.プライバシーBT。