前言

昨天認識了前6種方式，今天要來理解剩下的6種!

VII. Port binding

Export services via port binding

這個意思是我們應該要自己管理app的port，並透過port來跟外部世界對話，不應該依賴於外部server或者容器來分配port，應該要由自己來負責處理port。
假設由外部來分配，外部如果分配與app不一致，可能會導致app運行失敗，例如有些app在8888 port啟動，有些可能在3000 port。
自己決定的話可以透過env來對不同環境來做設定，使部屬的config更加簡單。

VIII. Concurrency

Scale out via the process model

In the twelve-factor app, processes are a first class citizen.

不同的工作可以分配不同的process，例如HTTP可以給web process做處理，後台工作則交給worker process負責。
這樣的好處是水平擴展很方便，我們不需要增加單一process的資源，還是建置更多的process來幫我們做事情XD
在流量多的時候就可以快速建置更多的process為我們服務，如果流量減少時，就可以把這些process關閉。

IX. Disposability

Maximize robustness with fast startup and graceful shutdown

The twelve-factor app’s processes are disposable, meaning they can be started or stopped at a moment’s notice.

Processes should strive to minimize startup time.

我們app要能快速開啟或停止，這樣代表著甚麼呢? 代表我們的可靠性很高，在遇到問題時可以快速地重啟。又或者我們要上新版的code，快速的停止舊的版本，然後又快速的上了新版，對我們的維運成本就降低了XD

X. Dev/prod parity

Keep development, staging, and production as similar as possible

The twelve-factor app is designed for continuous deployment by keeping the gap between development and production small.

當我們的環境大不相同時，在dev環境沒問題的程式碼，可能會在production環境遇到大問題，那麼我們就不能安心的一直release code了。
有一樣環境的話，我們可以CICD，讓我們在早期可以發現問題，讓我們不會到production才知道錯誤，在dev環境就可以知道錯誤了。
如果使用docker container，很容易做到這一點。

XI. Logs

Treat logs as event streams

A twelve-factor app never concerns itself with routing or storage of its output stream.

概念就是我們的app不用去處理存日誌這件事件，應該直接輸出到stdout之類的事件流，處理日誌的部分應該交由app運行的環境做管理，例如利用EFK來處理日誌，這樣就可以一次管理多個app的日誌了，而不是一個一個進去app裡面去看log，相當不方便。

XII. Admin processes

Run admin/management tasks as one-off processes

admin process應該要作為獨立的process執行，而不是跟我們一般的process混合在一起，例如我們想做data migrate時，不會希望migrate時user就不能使用我們的app了。

總結

今天又學到6種不同的概念，主要都是為了開發順利，部屬方便，維運簡單，比較不用擔心很難控管app，對app的建置也有信心不會出錯，學會了這12種概念，對開發、部屬方面一定能更加順利。

reference

https://12factor.net/