Cloud Computing Infrastructure 3 - storages

Storage types and protocols

從low-level access到high level access看起的話:

1. block storage: data bytes以block為單位儲存在裝置中，硬碟或SSD就是此類。如果直接(非透過網路)連接storage，稱為DAS (direct attached storage)。
block storage的速度會以IOPS (IO operations per sec)來判定。

DAS採用的access protocols包括 SATA/USB/SCSI。
非DAS採用的protocols包括iSCSI (internet SCSI) /SAN (storage area network)。


2. file storage: 人類會以files/folders來理解操作storage。
DAS對應的file-level protocol包括FAT/NTFS
非DAS對應的protocol: NFS/SMB等，這類storage又稱為NAS (network attached storage)。

3. object storage: 這又更高階抽象化的儲存單元，這在cloud applications中特別常見，protocols主要的設計方向就是horizontal scaling，這符合cloud的精神。

DAS Storages in the Cloud

<Storage for virtual servers>
cloud vendor為了達成share resources，會採用block storage，實際上是一個DAS，但對每一個virtual machine來說看到的是"local storage instance"。

雖然block storage擁有最快速的access time，但由於一個storage instance是shared resource虛擬化出來的，所以其儲存時間是暫時性的，一旦virtual server關閉，此shared storage instance也將會被釋放資源，回歸shared pool，使用者必須把data儲存在更為persistent的storage上。

當然如果client使用的是bare metal架構，那要裝幾個DAS都可以，也可以組成RAID。

<Storage for containers and serverless computing>
containers採用的是file storage，虛擬化之後containers看到的也是namespace中的temporary local storage，不過containers之間可以share storage。

serverless computing通常不會有storage (因為這是一種state)，不過cloud vendor有可能給予暫時性的storage。

SAN storage in the cloud

當然cloud也可以佈署SAN (storage area networks)，這是block storage的protocol。SAN storage可以跟virtual server分開佈署，所以不受限於virtual server的life cycle。

不過每次跟某一個virtual server連接(邏輯上的)時，這個SAN storage就必須要format/partition並且重新mount file systems，所以一次只能跟一個virtual server attach。

SAN storage的IOPS取決於網路的速度。

NAS storage in the cloud

SAN storage要format/partition，當然cloud vendors也可以提供快速mounting的file system，前提就是non-attached。

Object storage in the cloud

object就是non-structured data，俗稱blobs，通常是media/backups 等binary raw data。
blob會友伴隨著meta data，方便search和indexing。

S3 (simple storage service)就是Amazon的object storage implementation。

由於blobs通常檔案size很大(例如照片影像)，所以storage consistency通常可以容忍delay，以秒為計算單位，這在internet application (e.g. FB)是可以接受的時間，但不適合需要極度synchronization的applicatoin，例如金融或是安全applications。

CDN (content delivery network)

CDN是比storage更上位的單位，通常是為了加速access而將資訊複製在不同geological的data center中，看資訊型態而言，通常會以object storage的方式在低階儲存，因為CDN通常是serve media。

Cloud Computing Infrastructure 2 - virtual server introduction

Virtual Server

virtual server就是hypervisor software創造出來的虛擬的邏輯運算單元，彷彿一個真的獨立運行的機器，在其上可以安裝不同的OS，即便完全跟host machine的OS不同也沒關係。

有兩種架構:

第一種是bare metal，hypervisor軟體直接跑在硬體上，另一種是hosted，hypervisor軟體仍然跑在host machine的OS之上。

資源如何分享呢? host machine上的CPU通常是多核心的，每個核心當然又可以跑多執行緒，而hypervisor軟體利用intel的hyperthreading技術，把每個thread可以視為一個"virtual cpu"，所以這樣所有的virtual server都有了運算資源，當然記憶體和storage的虛擬化分享也可以類似泡製。

每個host machine也配備多個網路卡介面(NICs)，所以virtual servers也能有獨立的網路資源。

Auto scaling

virtual server可以依照客戶使用量做自動的資源增減。
由於virtual server是虛擬的單元，這樣的scaling是橫向的，也就是需要的時候就多開幾個virtual servers，而不是去縱向置換成硬體能力更強大的server。

橫向的scaling才會沒有限制。

Load balancing

利用一台gateway機器來分配incoming requests給不同的virtual server，避免某幾台virtual server負擔過重。

分配不受地理條件的限制，亦即有可能分配到不同地理區域的host machine上的virtual servers。

Bare metal servers

意思是cloud vendor可以出租整個physical host machine給需要的客戶，也就是非分享的machine，所以不會有"noisy neighbors effect"，這讓客戶可以建立off-premises private cloud，有充分的主控權。

Colocation

這算是一種機房配置，客戶可以把自己的私人機器放入cloud vendor的機房內，享有cloud vendor的硬體配置與安全保護，但又有自己的私人機器安全性與隱私。

舉例來說，安裝一個colocation的gateway來連接on-premises與off-premises 的hybrid cloud。

Containers

containers跑在OS上面，一個container image封裝了需要執行某個application所需要的一切runtime libraries，而且被高度的isolated，只看到自己的namespace下的file system (in memory)。

有名的container management software為Docker。

containers和virtual server的異同:

container算是sandboxes，可以快速deploy，不像provision virtual server那樣花費時間，但也由於share同一個host OS，這也樣containers受限了，也就是一台機器上不能有不同OS 的application sandboxes。

containers適合用來開發micro services，因為不同的micro services之間的開發時間和流程不一樣，用containers來deploy就不會影響彼此services之間的版本衝突等。(?! 好像有點牽強，不熟悉這種開發過程)

Server-less computing

這是最lightweight的compute (意思是computation unit)，這不用host server / container apps，而是只做request/event handlers，可以稱為Function as a Service, FaaS。

之前在erlang有玩過，因為erlang沒有state，沒有mutables，所以在語法層面可以支援stateless server，也就是server-less。

AWS的implementation為 AWS Lambda。

Cloud Computing Infrastructure 1 - cloud service model overview

Cloud computing實現的背後技術

1. virtualization: 透過hypervisor software來把資源邏輯化切割成可以量化, on-demand的資源。

2. internet: 任何地方都可以存取

Cloud services models

綜觀如下：

on-premises意思是公司有機房自己host infrastructure，從左到右公司需要維護的infrastructure越來越少，當然掌控程度也越來越低。

Cloud Deployment Models

public cloud: 跟所有人share virtualized resources，資源使用性可能會被其他使用者影響到(noisy neighbor effect)。

private cloud: 不跟任何人share virtualized resources，可以自建機房（on-premises)，或是託管 (off-premises)。也可以自己安裝與掌控virtualization software，例如OpenStack, VMWare vCenter。

Hybrid cloud: 以上兩種的混合，可以把適合的application放上public cloud。

iOS testing 3 - XCode 9 new testing features

這是WWDC 2017 #409 "What's new in testing" 筆記。

New Async waiting API

通常會用到async API的情況如下：

之前Xcode6 我們需要這樣做async waiting:

上面程式要開啟遠端某個文件， 在實際上開啟之前（document.open())，我們先定義一個expectation，然後為此async operation設定expectation，當此operation真的完成的話，在success closure裡面我們就要關閉或說fulfill 這個expectation。

限制如下：
1. timeout會被判定成failure
2. waiting (e.g. waitForExpectations()) 是XCUITest instance method，綁死了
3. 沒有nested waiting


XCTWaiter
這是針對上面限制的改良，主要是把waiting從XCUITest分離出來：

timeout的處理方式提供了delegate或是 closure，或是XCTWaiter intance，更加彈性了。

另外記得去看XCTestExpectation的new features。

Multiple App UI Testing

現在可以在不同的target app間測試互動情況，有需要再研究。

不知道可不可以launch 3rd party來測試?

Performance of UI Testing

要找到畫面中的一個ui element，我們必須去做query。XCUIQuery是需要用到accessibility data，舊的做法是test app藉由interprocess communication，去要某個時間點target app的serialized "snapshot"，就是app state snapshot：

這個做法在state相當龐大的時候（例如app使用超多記憶體），會有testing performance impact，甚至會造成某些testing timeout，使得test case被誤判成failure。更極端有可能因為query使用太多記憶體而process被killed。

要到snapshot，判別query的責任是落在test app身上。


xcode9的做法是：
(1) remote query： 減少interprocess data

現在改成只傳query data給target app，然後query在target app身上做（那還不是會造成target app performance impact？！），最後再把query results傳回給testing app。

所以這樣能夠減少testing app負擔，以及減少interprocess communication，這得到30%的記憶體與速度改善：

(2) query analysis: 透過分析來減少一個query要實現需要的最小的app states snapshot，這樣當然也可以減少運算時間與memory。

(3) programmer tools: 透過programmer對不同測試情境的知識，可以決定是何時可以做較短的query，提供"firstMatch"這類method讓query不用走完整個query data hierarchy。

firstMatch是改善最多的，但這是需要programmer對ui layout的了解才有辦法達成！

一個原則就是，你query的越精確，越會有好的testing performance，所以這樣也同樣無法依賴所謂的UI Recording，基本上是個廢物說實在的:

新架構避免使用的寫法

不要用block(closure) based NSPredicate，因為block不能被serialized，也不能在runtime被optimize:

上面說道的optimization都不能用了，所以避免使用block based NSPredicate 。

更好的test report: Activities / Attachments / Screen shots

activity是把一堆test command group起來，變成一個存活較久的test:

這個好處是讓test report看起來很簡潔，也比較有表達性:

XCode 9提供了screenshot api，可以讓XCUIElement或是整個screen都擷取快照圖片。
attachment則是讓test report把一些(包括screen shots) 想要跟activity 一起呈現在test report中的data包裹起來:

所以在test report中就會看到activity包含了attachments (此例中是screenshots):

動工吧!!!!