Internal iteration並沒有如傳統iteration有next()用來指示走訪下一個元素的方法。Internal iteration由你的應用程式決定要被迭代的集合，但該如何走訪集合中的的每一個元素則是由JDK決定；而External iteration則是被迭代的集合及迭代的方式兩者皆由應用程式來決定。
而主要的差別是，External iteration只能以序列方式(serial)迭代集合，而Internal iteration除了可以序列方式，也支援以平行方式(parallel)來迭代集合。
也就是說Sream的forEach可以利用平行計算將迭代的程式拆分為多個子程式來平行處理，最後在將子程式的執行結果組合起來。其意味著Stream的forEach比原本的iteration更彈性且高效
聽起來是個從 iteration 改用 stream 的好處
從 ec2 instance 搬到 k8s 之後發現，現在 cluster 一死掉，就是全部服務一起死。不像以前 ec2 個個虛擬主機是獨立的，隨便掛一個都沒差
k8s 適合跑的應用都是 stateless，更廣泛一點說，就是 cloud native app。因為這樣，所以Pod、Job…等等元件要 scale 和重啟都好輕鬆啊！但其實有另一大塊是 stateful app 很難搞定，許多人乾脆 stateful 的通通不放 k8s 裡了。然後更妙的是 k8s cluster 本身就是個 stateful app，而且不符合 cloud native 的定義。這算是呼應第一點，當 cluster 壞掉時，你沒辦法很容易啟動新的 cluster 原地復活。
k8s 太複雜了，而且未來只會更複雜，因為目前不斷有新的標準產生。依照過去十幾年的經驗，過度複雜的系統最後會被簡化過的新架構取代，感覺 k8s 也是個過渡性產品。
與 k8s 成對的是 microservice，甚至有人還說: 如果沒要要用 microservice，何必用 k8s ? 問題是 microservice 這種分散式泡沫一定很快就會消失，因為前例太多了，像是 EJB、WebService、SOA... 等等
k8s 現在有很多小廠商提供產品和服務，大廠則是不斷推出相關的新產品，然後又有証照可考，未來很多企業都會導入的。從這角度來看似乎很正面，但這個超級像過去的 J2EE，有標準、有証照、有一堆免費和商用 container 可選 (以前 J2EE server 也叫 container，這不是巧合)。你看看 J2EE 現在還剩什麼廠商吧…
當然啦，技術本來就會隨時代迭代，這個十年可能就是 k8s 稱霸，而十年也夠久了，投身這門技術可以讓自己有競爭力，企業也會因為標準化，尋求人材時會簡單許多。要說短期內會出現的缺失，就是因為 k8s 變成顯學、標準化，造成大家不適用 k8s 的系統也會硬套，然後又難學難管理，白白增加成本。
現在k8s好像是顯學，但偶爾也會看到一些如 Maybe You Don't Need Kubernetes1 這類的文章，所以有機會想多方聽聽各種經驗，可以請教一下為什麼嗎?
通常 second level cache 可做的事都會在更前面擋掉 (例如網頁的 cache) 所以 2nd cache 沒事不用去碰，用比較宏觀的角度去最佳化比較好
在通常情況下會將具有以下特徵的資料放入到二級快取中：
- 很少被修改的資料。
- 不是很重要的資料，允許出現偶爾併發的資料。
- 不會被併發訪問的資料。
- 常量資料。
- 不會被第三方修改的資料
而對於具有以下特徵的資料則不適合放在二級快取中：
- 經常被修改的資料。
- 財務資料，絕對不允許出現併發。
- 與其他應用共享的資料。
在這裡特別要注意的是對放入快取中的資料不能有第三方的應用對資料進行更改（其中也包括在自己程式中使用其他方式進行資料的修改，例如，JDBC），因為那樣Hibernate將不會知道資料已經被修改，也就無法保證快取中的資料與資料庫中資料的一致性。
雖然很早就知道有二級快取這功能，但考慮到以下項目，所以都沒有機會用：
- 資料一致性的問題
- 與其下多個 SQL 然後 cache 起來，不如下一個 SQL 就把多筆資料都撈回來應該還比較有效率
security best practice, No.1:
Always blocks pastebin in production, here are steps to configure security group via aws cli...