解決策
サーバーレスプラットフォームは、異なるクラウドで同じ問題を引き起こしていた。つまり、あらゆるイベントが独自の形を持っていたのだ。開発者はストレージ、キュー、データベース、SaaSのイベントを消費する方法を何度も学び直す必要があり、ツールはカスタムアダプターなしではイベントのルーティングやトレースができなかった。
CloudEventsは、あらゆるイベント本体を標準化するという不可能な課題を避けた。共通のコンテキスト属性とトランスポートバインディングを定義する一方で、ペイロードはドメイン固有のままにした。秘訣は、プロデューサーにビジネスデータの書き換えを強いることなく、インフラストラクチャが動作するのに十分なメタデータを与えることだった。
2019年10月までに、CloudEventsはバージョン1.0に到達し、CNCFのSandboxからIncubationへと移行した。CNCFはAWS、Google、Microsoft、IBM、SAP、Red Hat、VMwareからのサポートと貢献を挙げ、Knative Eventing、Debezium、Kyma、Azure Event Gridを含む実装を列挙した。
達成したこと
イベントではなくエンベロープを標準化する
うまくいった理由
必須のコア属性により、ルーティングと重複排除がベンダー間でポータブルになった。
イベントデータをそのままにしておくことで、既存のプロデューサーにとって導入コストが低く抑えられた。
プロトコルバインディングにより、同じイベントモデルをHTTP、Kafka、MQTT、その他のトランスポート上で伝送できた。
中立的なCNCFの拠点により、1つのクラウドがイベントの文法を所有するのではないかというベンダーの懸念が軽減された。
応用できること
ペイロードが多様すぎて標準化できない場合は、インフラストラクチャがルーティングと検査を行える最小のエンベロープを標準化せよ。
その後
CloudEventsはサーバーレスおよびイベント駆動型システムの共通メタデータ層となり、後にCNCFの卒業に到達した。その設計により、ツールがペイロードを理解する前にエンベロープを検査できるため、アダプターとSDKがプラットフォーム間で有用になった。
出典をたどる
出典
- Serverless specification CloudEvents reaches Version 1.0 Cloud Native Computing Foundation · cncf.io ·
- CloudEvents Specification v1.0.2 CloudEvents · raw.githubusercontent.com