SlideShare a Scribd company logo

104 meets cloud

•Download as PPTX, PDF•
•
Cliff Chao-kuan Lu
Cliff Chao-kuan Lu

Conflicts we at 104 Corp. faced in cloud migration. Most of the contents are in English except for presenter notes and title pages.

Related slideshows

Meetup #3: Migrate a fast scale system to AWS
Meetup #3: Migrate a fast scale system to AWSMeetup #3: Migrate a fast scale system to AWS
Meetup #3: Migrate a fast scale system to AWS
 
Meetup #3: Migrating an Oracle Application from on-premise to AWS
Meetup #3: Migrating an Oracle Application from on-premise to AWSMeetup #3: Migrating an Oracle Application from on-premise to AWS
Meetup #3: Migrating an Oracle Application from on-premise to AWS
 
Sas 2015 event_driven
Sas 2015 event_drivenSas 2015 event_driven
Sas 2015 event_driven
 
1 of 22
104 Meets Cloud 撥雲見日甘苦談 104 資訊科技 資深架構師 呂昭寬 ©2016, 104 Corp. CC-BY 4.0
Cliff Chao-kuan Lu • Sr. Architect @ 104 Corp • Full-stack Web Dev / SA • Certified AWS Professional SA • AWS Community Hero since ‘16 • AWS User Group Taiwan Organizer since ‘14
CLOUD COMPUTING
Cloud - NIST Definition • Characteristics: –On-demand self-service –Broad network access –Resource pooling –Rapid elasticity –Measured service NIST 800-145, Sep. 2011
NIST Definition (cont.) Deployment Models • Private cloud • Community cloud • Public cloud • Hybrid cloud Service Models • Software as a Service • Platform as a Service • Infrastructure as a Service • Function as a Service • Security as a Service • … as a Service
Cloud Native • Externalized services and solutions • Micro-services – Stateless – Scalable – Highly Available • Idempotency • Immutable architecture
IMPACT ON ARCHITECTURE
Pricey Made Accessible • Premium services: –Load balancer –Software-defined network –Datacenter • Network, Storage and VM • Power and cooling • Use them well in YOUR cloud
Armory of Services • Just works … • Gentle learning curve, inevitably RTFM • Details abstracted away just works Features, gotcha, … Tutorial Manual & Work
Baseline Complexity • Solution-based architecture is king • (Micro-)Services instead of tiers • Every component adds some complexity
104 meets cloud
Shifted Uptime Responsibility 99.9% Applications (8h46m down) 99.999% Infrastructure ($$$$) 99.999% Applications (5m down) 99% Infrastructure ($$) Enterprise Model Cloud Model Pets vs. Cattle: The Elastic Cloud Story by Randy Bias, CC-BY-ND
Availability • N=3 Quorum • 𝐴 𝑁𝑜𝑑𝑒 = 𝐴 𝐻𝑎𝑟𝑑𝑤𝑎𝑟𝑒 × 𝐴 𝑆𝑜𝑓𝑡𝑤𝑎𝑟𝑒 • 𝐴 𝐶𝑙𝑢𝑠𝑡𝑒𝑟 = 3𝐴 𝑁𝑜𝑑𝑒 2 − 2𝐴 𝑁𝑜𝑑𝑒 3
CONFLICT WITH CULTURE
CAPEX vs. OPEX • Cloud costs are mostly operational – Tough to plan budget – A posteriori analysis only • Quota instead of budgeting • Taxation
Time to Market • A common goal to adopt Cloud • Necessary Conditions: – Infrastructure – Level of Automation – Knowledge & skill – General affairs
DevOps • Waterfall sucks in the cloud • DevOps emphasize on… – Automated workflow – Minimal turnover & information loss • With great power comes great responsibility
STAY MODERN
Cloud App Evolution • Handcraft • AWS Auto Scaling • AWS Elastic Beanstalk • AWS OpsWorks • AWS ECS • AWS Lambda machine image code repo chef recipe docker image function
Serverless - Lambda • Announced AWS re:Invent 2014, accepted by communities and competitors • Managed Java, JavaScript, or Python runtime • Supports versioning, IAM Role, and VPC • Configurable timeout and RAM • Default concurrency = 100
Serverless - ECS • Announced re:Invent ‘14 • Docker scheduler with monitoring, logging, and authorization • Flexible privilege control with task role • Okay-ish data persistence with EBS • Rusty Load balancing and inter-host access control • Works seamlessly with Application Load Balancer launched Aug. ‘16
Fog Computing • Push workloads to end-user clients or edge devices • Emphasizes proximity, relies on geographical density and local resource pooling • Similar design principles as Cloud Computing

More Related Content

104 meets cloud

  • 1. 104 Meets Cloud 撥雲見日甘苦談 104 資訊科技 資深架構師 呂昭寬 ©2016, 104 Corp. CC-BY 4.0
  • 2. Cliff Chao-kuan Lu • Sr. Architect @ 104 Corp • Full-stack Web Dev / SA • Certified AWS Professional SA • AWS Community Hero since ‘16 • AWS User Group Taiwan Organizer since ‘14
  • 4. Cloud - NIST Definition • Characteristics: –On-demand self-service –Broad network access –Resource pooling –Rapid elasticity –Measured service NIST 800-145, Sep. 2011
  • 5. NIST Definition (cont.) Deployment Models • Private cloud • Community cloud • Public cloud • Hybrid cloud Service Models • Software as a Service • Platform as a Service • Infrastructure as a Service • Function as a Service • Security as a Service • … as a Service
  • 6. Cloud Native • Externalized services and solutions • Micro-services – Stateless – Scalable – Highly Available • Idempotency • Immutable architecture
  • 8. Pricey Made Accessible • Premium services: –Load balancer –Software-defined network –Datacenter • Network, Storage and VM • Power and cooling • Use them well in YOUR cloud
  • 9. Armory of Services • Just works … • Gentle learning curve, inevitably RTFM • Details abstracted away just works Features, gotcha, … Tutorial Manual & Work
  • 10. Baseline Complexity • Solution-based architecture is king • (Micro-)Services instead of tiers • Every component adds some complexity
  • 12. Shifted Uptime Responsibility 99.9% Applications (8h46m down) 99.999% Infrastructure ($$$$) 99.999% Applications (5m down) 99% Infrastructure ($$) Enterprise Model Cloud Model Pets vs. Cattle: The Elastic Cloud Story by Randy Bias, CC-BY-ND
  • 13. Availability • N=3 Quorum • 𝐴 𝑁𝑜𝑑𝑒 = 𝐴 𝐻𝑎𝑟𝑑𝑤𝑎𝑟𝑒 × 𝐴 𝑆𝑜𝑓𝑡𝑤𝑎𝑟𝑒 • 𝐴 𝐶𝑙𝑢𝑠𝑡𝑒𝑟 = 3𝐴 𝑁𝑜𝑑𝑒 2 − 2𝐴 𝑁𝑜𝑑𝑒 3
  • 15. CAPEX vs. OPEX • Cloud costs are mostly operational – Tough to plan budget – A posteriori analysis only • Quota instead of budgeting • Taxation
  • 16. Time to Market • A common goal to adopt Cloud • Necessary Conditions: – Infrastructure – Level of Automation – Knowledge & skill – General affairs
  • 17. DevOps • Waterfall sucks in the cloud • DevOps emphasize on… – Automated workflow – Minimal turnover & information loss • With great power comes great responsibility
  • 19. Cloud App Evolution • Handcraft • AWS Auto Scaling • AWS Elastic Beanstalk • AWS OpsWorks • AWS ECS • AWS Lambda machine image code repo chef recipe docker image function
  • 20. Serverless - Lambda • Announced AWS re:Invent 2014, accepted by communities and competitors • Managed Java, JavaScript, or Python runtime • Supports versioning, IAM Role, and VPC • Configurable timeout and RAM • Default concurrency = 100
  • 21. Serverless - ECS • Announced re:Invent ‘14 • Docker scheduler with monitoring, logging, and authorization • Flexible privilege control with task role • Okay-ish data persistence with EBS • Rusty Load balancing and inter-host access control • Works seamlessly with Application Load Balancer launched Aug. ‘16
  • 22. Fog Computing • Push workloads to end-user clients or edge devices • Emphasizes proximity, relies on geographical density and local resource pooling • Similar design principles as Cloud Computing

Editor's Notes

  1. NIST: National Institute of Standards and Technology
  2. 同篇文章中較不重要的部份： 雲的部署方式完全離題（如果你喜歡，也可以定義出熱帶雲、溫帶雲、溫熱混合雲） Service Model 隨著趨勢演變 「雲」對外隱藏實作細節，僅承諾或暗示自動伸縮、高可用、固定接口等幾項特性。
  3. 實現這些特性後的軟體，比較容易在雲端運行。 Idempotency 與 RPC 的 Exactly / At-least-once 有關，後者操作較簡單，在關鍵處再 dedupe 即可 (註: 每個部件都可能各自損壞，因此廣域 dedupe 又要面對域內部份元件失效問題)
  4. 大多開發者在雲端見到的第一項差異，便是許多企業級 Solution 現今唾手可得。 LB 與 SDN 隨便都是 十萬 NTD 起跳，而雲端則是立即歸你所有，也由你所管。 對於原本就有這些設備的工程師來說，若原本運用了廠家的獨家功能，便又要尋覓解決之道；也就是說，Platform Lock-in ?
  5. 雲端服務眾多，甚至周邊服務（與費用、穩定性）才是服務商間的決勝點。 若根骨精奇，點點介面並跑完 Tutorial，就能對服務有最粗淺的了解；但終究要念 Manual 與其它文件，才能補足基礎知識。 雲端服務只能節省操作成本 (更好的介面，或者 API)，非學習成本； 這與企業長久依賴的的 Premium Model (MA + 提問，要求客制化）有很大不同。
  6. 比起 Monolithic 時代的標準 UML::Class Diagram， 雲端更重視服務間的互通；要對工具與服務有足夠理解，才能避免架構牽連複雜。
  7. 要讓單一服務可伸縮，有如將他們視為 Cattle：彼此間可替代、可取代；總數量是唯一外顯參數。 依存於： Stateless Idempotency
  8. 傳統企業喜歡依賴非常穩定的 infrastructure，再運行普通的程式；uptime 為兩者相乘，而影響可用性。 雲端又稱為 RAIN (Redundancy of Inexpensive Nodes)，選用低成本硬體並犧牲穩定性；但因為軟體能有效容錯，反而提升整體可用性。 Yearly downtime: 99%: 87.6hr (3.5 day) 99.9%: 8.76 hr 99.99%: 53 min 99.999%: 5.3 min
  9. 以 N=3 Quorum 機制為例，若總合可用性為 A ( = A硬體 * A軟體), 則叢集可用性為 3A^2 – 2A^3 假設 A = 0.99, 則 A_{Cluster} = 0.999702
  10. 大部份公司以成本模型設計制度，因此隨用即付的雲端運算反而麻煩； 實際上線的預算不好抓 (取決於多成功)，因此計算「預算執行率」更是互相找麻煩。 採用 Quota 模式，甚至是把放上 AWS 的產品都先當成實驗 (Experiment)，會比較健康。 依照 94 年財政部解釋，使用海外公司線上服務時，台灣公司需負擔預付稅款 20% + 營業稅 5%
  11. 大多企業選用雲端的主要原因包含「加快產品上線時間」 然而有其它必要條件： Infrastructure: 工作要有模組分工的概念，若底���服務不快，上面也快不起來；底層可能是 vm、網路、又或者是其它依賴服務 Level of Automation: 工作流程必需高度自動化，舉凡 CI/CD、監控 Knowledge & Skill: 小孩玩大車很恐怖 General affairs: 若庶務（規範、總務、財務）佔用相當可觀的時間，企業再怎樣也快不起來
  12. Waterfall 太過專注於「現在就要做對」，這與雲端高度自動化、高度變動的環境相悖； 因而我們傾向往 DevOps 靠攏，透過各種自動化（測試、監控、反應）維繫品質，並避免 Waterfall 最引人垢病，因換手造成的資訊丟失。 然而 DevOps pattern 下，工程師與（自動化）系統便要仔細關注。
  13. Handcraft 工人智慧, 可利用 UserData, Custom Image Launch Dates: AutoScaling: May ’09 EB: Dec. ’10 OpsWorks: Feb. ’13 ECS: April ’15 Lambda: March ‘15
  14. GA March ‘15 Lambda Alternatives: Azure Service Fabric, Google Cloud Function (Alpha), IBM OpenWhisk, … Frameworks: Apex, Cloudia, Serverless (JAWS), …
  15. 內建 Autoscaling (metric- and time- based)，整合 CloudWatch, Logs, ECR 利用 EBS 或 EFS 實現 disk persistence；後者在 daemon 可透過共享儲存建立 cluster 的場景是王道，前者適用性較廣，但要在 host 實現 bind EBS (OpsWorks 自帶此功能，可以考慮；但其 `Auto` Scaling 較麻煩。)
  16. 歷史演進周而復始，這只是 mobile / edge device 回歸強勢的另一波反轉。Fog Computing 透過將運算與儲存機能推向 Edge device (要感謝行動裝置創造出的技術），來縮減響應時間，並減低傳輸流量。這其實是順著 Web/Cloud 的潮流，網路可連可斷、運算可強可弱、儲存可有可無，在設計時便考量這些需求，自然能提升系統的可用性。