軟體設計的原則

隨著雲端的普及，選擇適當的工具和資源來進行軟體架構的設計，顯然已經是趨勢，基於雲的軟體設計與開發，和早期的軟體設計的架構思維也有些不同，我們不能把雲端的架構設計當成一般的應用來設計， 而是需要用雲端架構的思維跟背後想要解決的問題，來分析跟設計架構。但是仍然有一些架構設計的原則，我覺得仍然沒有改變，這篇文章會簡單說明幾個我自己覺得設計架構時需要注意的原則

減少實作、評估是否有既有的元件能使用 (Don't reinvent the wheel)

想像一下，我們今天有一個業務需求，需要讓公司內部的員工能管理和收發 Email，我們會怎麼做？很顯然我們會選擇直接使用 MicroSoft 所提供的服務 Outlook 和 SSO 來管理每一個員工的帳戶及信件收發，為什麼？

原因很簡單，因為這個服務為我們節省了開發時間，並不是自己公司的 RD, IT 沒辦法做一套軟體，而是在研發的過程中可能會花費一樣或更多的時間在解決一個與公司商業價值毫無關係的問題上，尤其是當公司的組織規模變大之後， 要關注的問題反而是公司營利的核心價值，不要花時間在 "造輪子"，因為這個問題顯然已經被其他公司解決，且更穩定。

那我們什麼時候應該要自己動手做呢？

如果這個問題在市場上沒有任何的解決方案，但是我們透過自己實作可以符合我們的需求，且市場調查後沒有這樣子的應用，那這個 "輪子“ 就變得非常有價值，因為我們不僅能解決自己的問題，還可以透過這個方案來解決別人的問題跟盈利，舉凡 Facebook, Google, AWS ... 等等服務，都是從為了解決自己的問題開始到後來發展成商業應用

Don't reinvent the wheel 在透過購買或別人的服務前，先思考手邊是否有可重用的工具
        在自己實作之前，先考慮是否有既有的商業應用符合自己需求，可以直接使用，以節省時間

架構的可擴展性 (Scalable)

這邊說的可擴展性和我們早期的擴展有些不同，我們指的不是加一條 RAM、硬碟或 CPU 這種垂直擴充 (Scale Up)，這種方式有很明顯的缺點，那就是我們需要重啟 Server，也因此需要承擔服務中斷(Downtime)的損失！

在現今的系統及架構設計上，我們應該要避免 Downtime，並且可以依照使用者的數量或者服務運行的狀況來做側展，透過水平擴充(Scale out)，我們幾乎可以沒有限制的去擴充所需的硬體，可擴展軟件隨負載變化穩定運行。不需要關機跟重啟就可以部署更新和升級， 不會像早期開發時需要去評估需要多大的儲存空間、CPU 和 RAM 才能承受尖峰流量時的負載！現今的技術，我們甚至只需要像是 AWS, GCP, Azure 的服務來建置，這樣我們不僅不需要自己去運帷也不需要去承擔硬體的折舊問題

因此在設計架構時，我們需要將系統是否能水平擴充考慮進去！

減少架構的複雜性 (Reduce Complexity)

不管是軟體設計還是現實生活，只要牽涉的元素一多，所需要的成本就會提高!

只要保持應用簡單，就可以節少成本，具體的原則就是在做設計系統架構時，遵循 KISS 原則，減少複雜度的方法，在於對需求的釐清，因此我們在設計時可以透過不斷反思，理解這個元件或服務是否必要，藉以降低過度設計或不必要的設計產生出的複雜問題，因而產生 額外的成本支出

API First

這個觀念和傳統的專案思維也不太相同，傳統的專案思維，我們只會把 API 用於一次性的專案，因此不會考慮重用性或未來的可用性。然而 API First 的設計可以讓我們更容易的跟其他服務交互，可以達到很好的重用、擴展，為什麼？

透過 API 我們可以不需要了解這個服務背後如何實作，我們可以透過不同 API 的組合及應用組合成新的服務，雖然微服務不是軟體架構的最佳解，但是基於微服務所構建的商業應用，確實有助於提高使用者體驗，畢竟和傳統的架構不同，不再是牽一髮動全身

從雲出發 (Build for Cloud)

現今的軟體架構設計，開始會朝是否能建置在雲上去考慮，相較於雲架構，傳統的架構需要去考慮可靠度、擴充性、安全性與運維的成本，現在大部分的公司也開始意識到這件事情，也因此逐漸把自己的架構轉移至雲端，以減少成本跟維運的支出。

三大雲服務商在安全和可用性方面也有更多的經驗和更高的可靠性，雖然雲很方便，但設計時，我們還是需要確保自己的商業應用和雲服務商沒有太緊密的連結，否則我們還是需要承擔跟服務商高度耦合的風險