本文翻譯自：Freecodecamp, 原文地址：An intro to Amazon Fargate: what it is, why it’s awesome (and not), and when to use it, 英文原作者為 Emmanuel Marboeuf
當(dāng)亞馬遜在2017年底的AWS re:Invent大會上和EKS一起宣布 Fargate的時候，它還備受冷落，當(dāng)時我所關(guān)注的博客和大佬只是輕描淡寫地說：
哦糖驴，有這么個新玩意芥被，它將允許ECS用戶直接在云中運行容器。
作為開發(fā)人員冲粤，這真的讓我大吃一驚恢着。讓我們看看為什么途凫。
解放生產(chǎn)力
我覺得軟件開發(fā)領(lǐng)域已有五次重大革命桐汤，大大提高了開發(fā)者的工作效率，并以最高效率編寫與部署應(yīng)用靶壮。他們都解決了一系列的重大問題：
- 云服務(wù)（IaaS）的出現(xiàn)：解決了基礎(chǔ)架構(gòu)的成本和可擴展性問題
- 開源社區(qū)怔毛，會議，工作坊腾降，技術(shù)博客拣度，StackOverflow等：讓知識惠及到更多人
- 版本控制系統(tǒng)，協(xié)作工具螃壤，持續(xù)集成工具 解決了項目的并行開發(fā)和集成問題
- 容器化架構(gòu)
- 無服務(wù)器計算服務(wù)（PaaS） 降低服務(wù)器和系統(tǒng)管理成本
這些革命中的都有一個共同特點：它們都為軟件工程師賦予了更多的控制權(quán)抗果，降低了對服務(wù)器的系統(tǒng)管理員，DevOps奸晴，IT支持人員等的依賴冤馏。
所以，F(xiàn)argate算其中的哪一種呢寄啼？
你的“船”才是問題所在
Docker使容器技術(shù)普及開來逮光，便很快成為開發(fā)中被廣泛采用的新標(biāo)準(zhǔn)代箭。
不久之后，隨著Kubernetes的成功涕刚，AWS推出了自己的（更基本的）容器管理服務(wù)：Amazon Elastic Container Service（ECS）嗡综，它引入了任務(wù)（Task）的概念。
一個任務(wù)可以是一起工作的容器的任何實例杜漠。它可以是從運行一個服務(wù)的Web應(yīng)用极景，多個微服務(wù)，數(shù)據(jù)庫和反向代理驾茴，還可以是定期運行的批處理shell腳本盼樟。
作為使用ECS的“老司機”，我很喜歡它沟涨，曾經(jīng)在一段時間內(nèi)用得很爽恤批，但到最后，我發(fā)現(xiàn)在管理EC2 Instance的同時裹赴，還必須管理一些額外的層（任務(wù)和容器）喜庞，這讓ECS變得越來越復(fù)雜。（譯者注棋返，請參考AWS“層”的概念）
同時延都，我對ECS的安全性也不甚滿意，層越多睛竣，就越要保持警惕晰房，而每一層都帶來了更多的復(fù)雜性，以及誤配置射沟、漏洞的可能性殊者。
使用ECS在集群中運行中的EC2 實例（Instance）配置彈性伸縮時，每個實例上可以承載多個不同的Task验夯，每個Task都可以運行多個容器猖吴。
由于任務(wù)（Task）會在具有可用資源的相同類型的EC2實例上隨機部署（默認(rèn)情況下），將面臨以下問題：
- 一個集群必須遵循相同的彈性伸縮規(guī)則挥转，伸縮的EC2實例類型必須相同海蔽。
- 有些容器需要完全不同的資源（譯者注，AWS將網(wǎng)絡(luò)绑谣、虛擬機党窜、負(fù)載均衡都稱為資源），但仍需要協(xié)同工作借宵。
- 某些容器不一定遵循相同的彈性伸縮規(guī)則幌衣。
- 有時同一任務(wù)中的多個容器都需要有自己的負(fù)載均衡，無法為同一任務(wù)設(shè)置多個負(fù)載均衡器暇务。
面對這些問題時泼掠，首選的解決方法是：
- 根據(jù)需求手動部署一些具有不同資源的EC2實例
- 將這些EC2實例添加到您的集群
- 為任務(wù)運行一個容器
- 手動鏈接到您的EC2實例
- 在ECS上配置復(fù)雜的任務(wù)策略怔软，把不用任務(wù)根據(jù)他它們的需求配置在適當(dāng)?shù)腅C2上
這需要大量、繁瑣的工作择镇，還不易維護挡逼，這違背了使用容器的初衷。
有人不得不提出一個更好的主意腻豌。
讓它們“漂”起來
事實證明家坎，AWS團隊在過去一年中也遇到了同樣的問題，他們考慮過并致力于解決這些問題：
我們怎樣才能運行容器而不必?fù)?dān)心服務(wù)器和集群吝梅？
這就是AWS Fargate的意義所在虱疏。它完全抽象了底層基礎(chǔ)架構(gòu)，你可以把每個容器視為一臺機器苏携。
你只需定義每個容器所需的資源做瞪，它將為你完成復(fù)雜的任務(wù)而不必再管理多個“層”之間的訪問規(guī)則，您可以像在單個EC2實例之間那樣調(diào)度容器那樣右冻。
這就讓你的容器像水面上的船只擁有自己的帆装蓬、船舵、船員一樣纱扭，自己可以漂流到想要去的地方牍帚。
容器即服務(wù)（CaaS）
我一直堅信容器即服務(wù)（CaaS）是開發(fā)人員夢寐以求的、真正的平臺及服務(wù)（PaaS）乳蛾。它允許開發(fā)人員直接在云中部署他們的容器暗赶，而不必?fù)?dān)心底層細(xì)節(jié)。
當(dāng)然肃叶，已經(jīng)有很多技術(shù)允許您在云上無縫運行代碼蹂随，而不必?fù)?dān)心擴展或服務(wù)器管理（比如Heroku，Lambda因惭，甚至以自己的方式使用Google應(yīng)用引擎）糙及，但它們都有局限性。
- 必須選擇喪失一點靈活性
- 必須使用它們所支持的語言
- 無法使用它們所支持的語言完成擬定項目筛欢，因為可能您的項目需要在指定操作系統(tǒng)系統(tǒng)上可用的低版本的原生庫
- 您的項目采用了尖端技術(shù)，未來幾年將無法為大眾所用
- 其中一些平臺非常非常昂貴唇聘，特別是在擴展時
Fargate（或CaaS）為您帶來兩全其美的方案版姑。
容器化架構(gòu)為您提供所需的靈活性和控制權(quán)，它允許您在任何類型的系統(tǒng)中使用任何技術(shù)迟郎。而容器技術(shù)能確保你的應(yīng)用在每個主機上具有相同的行為剥险，無論是開發(fā)（Dev），測試(Testing/QA)宪肖，預(yù)發(fā)布（Staging）還是生產(chǎn)(Production)環(huán)境表制。
我覺得這一點對眾多的科技初創(chuàng)公司至關(guān)重要健爬。事實上，有時您的競爭優(yōu)勢之一就是么介，您參與開發(fā)出最先進的技術(shù)娜遵，或者是把機智地原有的技術(shù)用在新的應(yīng)用場景中。
無服務(wù)器部署使您可以專注于編寫優(yōu)秀的代碼壤短，沒有配置设拟，易于擴展。
限制
CaaS vs PaaS
也許確實你放棄了真正的“平臺即服務(wù)”的一些優(yōu)勢久脯，比如您仍然需要手動更新容器的鏡像纳胧，有時您必須編寫自己的Docker鏡像。如果您不了解系統(tǒng)管理的基礎(chǔ)知識帘撰，這的確很麻煩跑慕。
但是，這也意味著您可以放手地做任何您能想做的事情摧找，并且在您想要使用的系統(tǒng)上核行，保證語言，工具慰于，庫和版本中的靈活性和自由度钮科。
成本
讓我們直面這樣的現(xiàn)實：云服務(wù)（IaaS）比擁有自己的基礎(chǔ)架構(gòu)更昂貴（如果你想要按需擴展你的基礎(chǔ)架構(gòu)）。同樣的道理婆赠，不必關(guān)心配置绵脯、管理和擴展服務(wù)器是要需要付出代價。如果你的應(yīng)用十分簡單休里，云服務(wù)并不是最優(yōu)解蛆挫。
Fargate實好，但是其價格幾乎是等配置EC2實例的價格的 4 倍（例如t2.medium）這讓我們很難抉擇妙黍，讓我們期待它能夠降價悴侵。
我應(yīng)該將所有ECS任務(wù)都切換到Fargate嗎？
當(dāng)然不是拭嫁。如上所述可免，在某些情況下，您的成本將增加三倍以上做粤，所以在它們降低成本之前浇借，您可能最好使用標(biāo)準(zhǔn)EC2實例。
但是怕品，在以下情況下妇垢，F(xiàn)argate可能對您更有益：
- 如果您無法很好地伸縮你的ECS任務(wù)，會導(dǎo)致大量空閑的CPU或內(nèi)存，而使用Fargate闯估，您只需為在任務(wù)中定義的資源付費灼舍。
- 對于按需或按定時計劃運行的任務(wù)，并不需要一直運行著的EC2實例涨薪。使用Fargate骑素，您只需在任務(wù)運行時付款。
- 適用于有內(nèi)存和/或CPU使用率峰值的任務(wù)尤辱。這僅僅是因為使用Fargate可以在這類情況下節(jié)省您配置和管理的時間砂豌。
彩蛋
對于那些喜歡Kubernetes而非ECS的人來說，F(xiàn)argate很快就會支持EKS了光督。
