However, this picture changes when creating libraries that need to interact with arbitrary code and unknown type hierarchies. In this context, a library implementer must often choose between either requiring a user to implement library-proprietary interfaces or to generate code at runtime when the user’s type hierarchy becomes first known to the library.
CAP 定理の意図は本来、設計者にこのトレードオフを真剣に考えてもらうことにありました。ですが、ここでは 2 つの注意すべきことを挙げます。第 1 に、一貫性や可用性を犠牲にしなければならないのは、実際に分断が起こっている間だけで、その間であっても、それを緩和する方法は多くあるということ。第 2 に、定理には 100% の可用性とありますが、そこで議論すべきなのは、現実的な高可用性の実現に伴うトレードオフについてです。
基本、CAで、分断時はCPシステムである
1 2
はたして Spanner は CAP で定義されているような CA システムなのだろうかと。端的に答えると、技術的には違いますが、実際のところ CA システムだと考えて構いません。 分断が起きると Spanner は C を選択し、A を犠牲にします。つまり技術的に見ると、Spanner は CP システムなのです。
Partition Tolerance (terribly misnamed) basically means that you’re communicating over an asynchronous network that may delay or drop messages. The internet and all our data centres have this property, so you don’t really have any choice in this matter.
we’re observing a pattern of traditional ESBs rebranding themselves, creating ESBs in API gateway’s clothing that naturally encourage overambitious API gateways
もともとESBとしての製品が、たしかに API Gatewayという服着てるだけで、本質的にはESBであることに変わりはない。実体験とも合致する。 無駄にレイヤを増やして開発物が増えている印象。
API gateways can still act as a useful abstraction for crosscutting concerns, but we believe the smarts should live in the APIs themselves.
any domain smarts should live in applications or services.
concerned about business logic and process orchestration implemented in middleware, especially where it requires expert skills and tooling while creating single points of scaling and control.
API Gateway is essentially a reverse proxy
このMagic QuadrantのFull Lifecycle API Managementの中にも、入っているはずで、製品ベンダの謳い文句にも疑いを持っていきましょうですね。
/dev/disk5 (synthesized): #: TYPE NAME SIZE IDENTIFIER 0: APFS Container Scheme - +750.1 GB disk5 Physical Store disk4s2 1: APFS Volume TimeMachine 1.2 MB disk5s1
/dev/disk6 (synthesized): #: TYPE NAME SIZE IDENTIFIER 0: APFS Container Scheme - +750.1 GB disk6 Physical Store disk4s4 1: APFS Volume a 1.2 MB disk6s1
コマンド
yusuke@yusukenoMacBook-Air–>/Users/yusuke::: $ diskutil apfs deleteContainer disk4s4 Started APFS operation on disk6 Deleting APFS Container with all of its APFS Volumes Unmounting Volumes Unmounting Volume “a” on disk6s1 Deleting Volumes Deleting Container Wiping former APFS disks Switching content types 1 new disk created or changed due to APFS operation Disk from APFS operation: disk4s4 Finished APFS operation on disk6 Removing disk4s4 from partition map
/dev/disk4 (external, physical): #: TYPE NAME SIZE IDENTIFIER 0: GUID_partition_scheme *3.0 TB disk4 1: EFI EF 209.7 MB disk4s1 2: Apple_APFS Container disk 750.1 GB disk4s2 3: Microsoft Basic Data ExternalDa 1.5 TB disk4s3 (free space) 750.2 GB -
/dev/disk5 (synthesized): #: TYPE NAME SIZE IDENTIFIER 0: APFS Container Scheme - +750.1 GB disk5 Physical Store disk4s2 1: APFS Volume TimeMachin 1.2 MB disk5s1
一度、全消し
$ diskutil apfs deleteContainer disk4s2 Started APFS operation on disk5 Deleting APFS Container with all of its APFS Volumes Unmounting Volumes Unmounting Volume “TimeMachine” on disk5s1 Deleting Volumes Deleting Container Wiping former APFS disks Switching content types 1 new disk created or changed due to APFS operation Disk from APFS operation: disk4s2 Finished APFS operation on disk5 Removing disk4s2 from partition map
コマンド実行後
$ diskutil list /dev/disk0 (internal): #: TYPE NAME SIZE IDENTIFIER 0: GUID_partition_scheme 251.0 GB disk0 1: Apple_APFS_ISC 524.3 MB disk0s1 2: Apple_APFS Container disk 245.1 GB disk0s2 3: Apple_APFS_Recovery 5.4 GB disk0s3
