Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...
![OpenStack Foundationが新たなコンテナプロジェクトを発表](https://cdn-ak-scissors.b.st-hatena.com/image/square/02955ccf4ba8556bc832717c6e4cfa5863327ddc/height=288;version=1;width=512/https%3A%2F%2Fcdn.infoq.com%2Fstatics_s2_20240618082437%2Fstyles%2Fstatic%2Fimages%2Flogo%2Flogo-big.jpg)
ネットワークの次は、さまざまなAPIやエンドポイント、つまり、リソースバインディング - 他のプロトコルやさまざまなデータ形式と通信できるようにします。おそらく、あるデータ形式から別のデータ形式に変換することも必要でしょう。ここには、ろ光器 (light filtering) なども含めます。つまり、トピックをサブスクライブするときに、特定のイベントにのみ関心があるかもしれません。 最後のカテゴリーは何だと思いますか? それは状態です。私が状態とステートフル抽象化と言うときは、データベースの機能やファイルシステムなど、実際の状態管理については話していません。私は開発者が状態に依存している舞台裏の抽象化についてもっと話しています。おそらく、ワークフロー管理を行う能力が必要です。実行時間の長いプロセスを管理したり、一時的なスケジューリングやcronジョブを実行して、サービスを定期的に実行したい
最も基本的なOperatorがデプロイメントを処理します。APIリソースに応答してデータベースを作成することは、kubectl applyと同じくらい簡単です。ただし、これは、StatefulSetsやDeploymentsなどの組み込みのKubernetesリソースよりも少し優れています。Operatorが価値を提供し始めるのは、より複雑な操作です。データベースを拡張したい場合はどうなりますか ? StatefulSetを使用すれば、kubectl scale statefulset my-db --replicas 3を実行でき、3つのインスタンスを取得できます。しかし、それらのインスタンスが異なる構成を必要とする場合はどうなるのでしょうか ? 1つのインスタンスをプライマリとして指定し、他のインスタンスをレプリカとして指定する必要がありますか ? 新しいレプリカを追加する前に必要なセ
原文(投稿日:2019/07/04)へのリンク 先日の論文で、MITの研究者たちが、汎用確率的言語(general-purpose probabilistic language)のGenを発表した。Juliaをベースとするこのプログラム言語の目的は、高レベルのプログラミング構造によるモデル表現と推論アルゴリズムの作成を可能にすることだ。 この目的のため、Genには、確率モデルをカプセル化する生成関数インターフェイス(generative function interface)、既存の生成関数から新たな生成関数を作成するコンビネータ(combonator)、提供する高レベル推論アルゴリズムをユーザが選択可能な推論ライブラリなど、斬新な言語構成要素が数多く含まれている。 Genは最初の確率的プログラミング言語ではないが、既存の言語にはモデリングレベルでの汎用性や、ジェネリックモデリングをサポー
このパターンには2つの背景があります。ひとつは、技術者がマイクロサービスアーキテクチャパターンを採用して、複数の(理想的には単一目的で、独立してデプロイ可能な)サービスで構成されるアプリケーションを開発するようになったことです。ふたつめは、企業がコンテナ(Dockerなど)、オーケストレータ(Kubernetesなど)、プロキシ/ゲートウェイ(Envoyなど)といった、クラウドネイティブなプラットフォームテクノロジを支持するようになったことです。 意図 サービスメッシュが解決しようとする問題は次のようなものです。 サービスディスカバリ、ルーティング、アプリケーションレベル(レイヤ7)の非機能通信要件を処理する言語対応の通信ライブラリを、個々のサービス用にコンパイルする必要性の排除 外部サービスのネットワークロケーション、セキュリティ認証、サービス品質(QoS)目標など、サービス通信設定の外
How to Use Multiple GitHub Accounts Git is a popular tool for version control in software development. It is not uncommon to use multiple Git accounts. Correctly configuring and switching Git accounts is challenging. In this article, we show what Git provides for account configuration, its limitations, and the solution to switch accounts automatically based on a project parent directory location.
設計者は分割が発生したとき一貫性と可用性のどちらかを選ぶ必要がありますが、分割の扱い方と分割の復旧には柔軟な対処方法があります。現在のCAPの目的は特定のアプリケーションが必要とする一貫性と可用性を最適化することでしょう。このような方法には分割発生中の計画や分割の復旧計画が組み込まれています。したがって、設計者はこのような方法を採用することで、従来受け取られてきたCAPの限界を超えてCAPについて考えることができます。 なぜ"3つのうち2つ"がミスリーディングなのか CAPを理解する最も簡単な方法は分割の両側にひとつずつノードがある場合を考えることです。片方のノードだけ状態を更新できるようにすると、2つのノードに一貫性がなくなります。つまり、Cが失われます。一貫性を維持しようとすれば、一方のノードは利用できない状態であるかのように動作しなければなりません。この場合、Aが失われます。一貫性と
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く