問及什么是“美”，每個人都會有屬于自己的答案。大自然的美就宛如天上的彩虹與浩瀚的星空，人們對于自然規(guī)律的認識最早就源于對大自然的觀測，基本的規(guī)律體現(xiàn)出的就是自然的美；而那些傳世畫作以及無數(shù)優(yōu)美的樂章則是由人類所創(chuàng)造出的美。
科學可以很美，技術(shù)的發(fā)展源自科學，也同樣具有美感。搜索一下亞馬遜的計算機類圖書，我們會發(fā)現(xiàn)各類以xx之美命名的書籍，從開發(fā)人員關(guān)注的“編程之美”到“測試之美”以及“算法之美”，架構(gòu)師推崇的“系統(tǒng)之美”、“集群之美”……
談?wù)摰郊夹g(shù)之美，似乎每個工程師都有自己的見解，每個人都能從自己的視角發(fā)掘技術(shù)的美感。楊振寧老先生說：“科學?終極的美是客觀的，沒有?類的時候就已經(jīng)有這些美了”。盡管技術(shù)中會表現(xiàn)出與科學、藝術(shù)相似的美感，可是在技術(shù)之美中，人表現(xiàn)出的創(chuàng)造力才是技術(shù)之美的本源。軟件是由人設(shè)計出來的，構(gòu)成軟件的每一行代碼都直接或間接的由工程師創(chuàng)造，人們工作、生活中使用的各類軟件都運行在由人類工程師搭建的基礎(chǔ)設(shè)施之上。沒有?類就沒有軟件技術(shù)，也就沒有技術(shù)中的美。
開發(fā)者都需要親自感受和體驗技術(shù)之美
理解并感受技術(shù)之美是工程師成長歷程中不可或缺的一部分。被譽為技術(shù)之美的軟件設(shè)計與代碼實現(xiàn)通常來源于前輩們工作中的最佳實踐；被推崇為技術(shù)之美的項目管理方法與團隊協(xié)作模式則是凝聚了無數(shù)天才的智慧與經(jīng)驗。技術(shù)之美充斥在技術(shù)開發(fā)與研發(fā)創(chuàng)新的每一個角落，和藝術(shù)家一樣，每一個優(yōu)秀軟件工程師都會用自己的方式從不同的維度去書寫技術(shù)之美。
要理解、感受并學習技術(shù)之美，我們應(yīng)該從哪里開始呢？我給出的答案是 “簡潔之美”。
伴隨著各行業(yè)數(shù)字化程度的不斷加深，互聯(lián)網(wǎng)以及各類軟件平臺承載的業(yè)務(wù)也必然會越來越復(fù)雜，當復(fù)雜到達一定程度，軟件產(chǎn)品的開發(fā)迭代難度將指數(shù)級增加，甚至到無法完成交付。在軟件設(shè)計與項目管理中運用“簡潔之美”則是對抗復(fù)雜最有效的辦法。
軟件的“能力增長”與技術(shù)的“簡潔之美”相互成就
作為一名擁有長達 24 年碼齡的 IT 工程師，一名擁有多個用戶超千萬的平臺架構(gòu)設(shè)計經(jīng)驗的架構(gòu)師，幾乎經(jīng)歷了中國互聯(lián)網(wǎng)與軟件行業(yè)發(fā)展的所有重大節(jié)點與多次技術(shù)革命，就由我來帶大家看一看軟件開發(fā)行業(yè)是怎樣從刀耕火種的蠻荒時代一步步走到現(xiàn)在的云原生時代。
最初的美好
早期的程序設(shè)計其實并不復(fù)雜，編寫代碼是只屬于少數(shù)人的游戲，還記得自己通過編碼賺取的第一筆收入是幫人寫一個用于數(shù)據(jù)處理的 Pascal 腳本，而報酬則是客戶公司按代碼的行數(shù)來支付換取程序的版權(quán)。整個程序開發(fā)一個人就能完成，只需要能精確的描述問題，創(chuàng)造合適的數(shù)據(jù)結(jié)構(gòu)，編寫對應(yīng)的算法，問題很快就能得到解決。
毫無疑問，這樣的工作方式和程序代碼都是極其簡潔的，也是程序員最初喜愛的編程方式，每一行代碼你都知道他是如何執(zhí)行的，每一個函數(shù)你都清楚他做了哪些事情；哪怕只有一個函數(shù)，也可以是一個完整的程序；每次修改完程序，代碼立刻就可以編譯運行得到結(jié)果，即便有 bug 也能立刻發(fā)現(xiàn)并解決。
這樣的程序腳本曾經(jīng)很流行，這是每個程序員都渴望的工作狀態(tài)，這就是簡潔，是無數(shù)工程師一直追求的狀態(tài)。
軟件因何變得復(fù)雜
隨著軟件需求越發(fā)復(fù)雜，軟件項目的編碼量，開發(fā)周期，迭代次數(shù)都在不斷的增長，成熟的軟件產(chǎn)品很難再由個人獨自開發(fā)完成。
代碼量的不斷增長，意味著每一次更新代碼后都需要更長的時間去編譯和構(gòu)建項目，等待編譯的過程從一個哈欠到一根煙、一杯茶、甚至一整天。
多個人協(xié)作怎么分工？各自編寫的代碼如何整合？或許你很難想象，但手工管理代碼的時代確實存在過，每個程序員分一個模塊，各自編寫代碼，最后通過名叫“QQ”或者“飛鴿傳書”的軟件發(fā)送給項目的 leader，再由 leader 去把多個人的代碼放到一個文件夾下，手動去一個一個 include 其他人開發(fā)的模塊，其中還可能遇到各種代碼沖突，調(diào)用失敗，編譯錯誤……搞定一切后，還需要再對項目進行打包存檔，然后標注好存檔的日期和時間。如此繁瑣的工作，大量的精力浪費在了寫代碼以外的事情上。
因為互聯(lián)網(wǎng)軟件與互聯(lián)網(wǎng)服務(wù)的普及，我們開發(fā)的軟件再也不是只運行在本地計算機里，我們需要配置好遠程環(huán)境，需要把代碼上傳到遠程服務(wù)器，在代碼上傳后，還需要去處理本地 Windows 與遠程 Linux 之間的差異，環(huán)境變量、數(shù)據(jù)庫配置……。每次發(fā)布一個新的版本，開發(fā)團隊通常都會選擇深夜，每一次版本上線都是一次戰(zhàn)役。
遇到上規(guī)模的項目，多條業(yè)務(wù)線并行是常態(tài)，通過 SOAP、RPC 等協(xié)議構(gòu)建面向服務(wù)的分布式應(yīng)用（SOA 架構(gòu)）是實現(xiàn)服務(wù)重用的常見辦法，但隨著項目運營的不斷迭代，服務(wù)線的增加，服務(wù)間相互依賴、耦合的加深，必然會讓服務(wù)間相互調(diào)用變得極其復(fù)雜，如果將服務(wù)間的關(guān)系圖像化，你將看到一堆打結(jié)的繩子擰巴在一起，把你綁住讓你寸步難行，呼吸困難。
這一切的一切都使得軟件開發(fā)的過程變得復(fù)雜，工程師每天大量的時間花在管理代碼，編譯軟件，更改配置等一系列繁瑣的工作之上，我們很清楚我們想要的只是回到最初的美好。
在軟件和軟件開發(fā)本身變得麻煩的時候，不斷有天才般的工程師站出來解決問題，因為工程師們都酷愛簡潔，希望精力能專注于代碼編寫之上：
工程師希望代碼修改后能立即執(zhí)行，不需要漫長的等待，因此構(gòu)建工具被開發(fā)出來；
工程師希望多人協(xié)作也能足夠的自由，并且不再為版本合并和分支管理發(fā)愁，因此發(fā)明的版本管理工具與代碼倉庫；
工程師希望本地開發(fā)和遠程生產(chǎn)環(huán)境能保持一致，希望在本地開發(fā)應(yīng)用原生為云設(shè)計，希望應(yīng)用在云端以最佳狀態(tài)運行，因此容器技術(shù)、云原生以及DevOps被創(chuàng)造出來；
工程師希望剝離業(yè)務(wù)將服務(wù)中的能力抽象出來，并且將能力變成服務(wù)和組件獨立維護和迭代，這樣就能實現(xiàn)更小顆粒度的代碼復(fù)用與更高級別的抽象，因此微服務(wù)設(shè)計迅速崛起，Serverless架構(gòu)也為更多項目提供了更好的選擇。
這些技術(shù)的誕生源于工程師對簡潔的執(zhí)戀，而這些技術(shù)的普及和發(fā)展就要歸功于開源社區(qū)以及眾多技術(shù)廠商的交流與協(xié)作。
說到這里，不得不提當下引領(lǐng)技術(shù)發(fā)展方向的重要力量之一：亞馬遜云科技（Amazon Web Services），作為云計算行業(yè)的先驅(qū)，早在20年初就開始布局云計算業(yè)務(wù)的亞馬遜云科技，他們從無數(shù)的客戶現(xiàn)場獲得反饋，他們很清楚開發(fā)者遇到的難題。
盡管讓復(fù)雜的開發(fā)過程變得簡潔的各個工具都已經(jīng)被發(fā)明出來，但想要通盤使用依然有較高的門檻。
通過開源的Gitlab，開發(fā)者能獲得一個屬于自己的代碼托管平臺，但Gitlab需要至少一臺主機，而且內(nèi)存不少于8G，哪怕只有一個項目要托管，哪怕項目只編寫了一個函數(shù)，托管主機的費用都省不了，除此之外，還需要開發(fā)者安裝配置好ruby環(huán)境，安裝好數(shù)據(jù)庫，下載好軟件源碼……，哦，別忘了，Gitlab有更新時，開發(fā)者還需要考慮是否要同步去更新自己的Gitlab。
就像你們看到的，事情又又又變得復(fù)雜了?。?！
除了版本倉庫，其他工具也一樣，比如容器的鏡像倉庫，CI/CD 等一系列工具，完整的搭建起開發(fā)平臺并規(guī)范團隊的工作流程已經(jīng)成為一件極具挑戰(zhàn)的任務(wù)。
技術(shù)廠商給予的支持
如果開發(fā)者只需要托管代碼，那么 Amazon CodeCommit，直接給你一個安全、高度可擴展的托管型源代碼控制服務(wù)；
將應(yīng)用容器化，你可以直接將鏡像推到 Amazon ECR，擁有一個 docker hub如此簡單；
搭建 K8s 集群，從來都不是一個輕松的事情，無論物理主機還是云主機，作為日后軟件服務(wù)運行的基礎(chǔ)，我們不得不全勤投入，Amazon EKS，讓我們可以輕松的獲得 k8s 集群，Amazon EKS Anywhere 讓我們可以通過默認組件配置幫助簡化本地 Kubernetes 集群的創(chuàng)建和運維，實現(xiàn)隨時隨地 K8s 集群管理自動化。Amazon App2Container 能把你多年前部署的傳統(tǒng)應(yīng)用直接打包為容器鏡像，應(yīng)用的部署與集群的管理再次被簡化。
廠商給予的支持僅此而已嗎？當然不是，如果說有些復(fù)雜很難被徹底根除，那么就把這些復(fù)雜留給廠商，把簡潔重新還給開發(fā)者。
上面提到的各類應(yīng)用已經(jīng)能解決很多團隊當前面臨的眾多棘手問題，但廠商做到的比我們預(yù)想的更多。
DevOps工具鏈，現(xiàn)代化應(yīng)用開發(fā)“簡潔之美”的最佳體驗
Amazon CodePipeline，可以實現(xiàn)快速而可靠的應(yīng)用程序和基礎(chǔ)設(shè)施更新，只要代碼發(fā)生變化，CodePipeline 便會構(gòu)建、測試和部署代碼；
Amazon CodeBuild 是完全托管的生成服務(wù)，可編譯源代碼、運行測試以及生成可供部署的軟件包。反復(fù)配置、管理和擴展生成服務(wù)器將成為歷史；
Amazon CodeDeploy 可將代碼自動部署至任何實例，快速發(fā)布新功能，從此告別凌晨三點的版本發(fā)布日?；顒印?/div>
Amazon CodeStar 提供一個統(tǒng)一的用戶界面，您可以在此界面輕松管理您的軟件開發(fā)活動，面對復(fù)雜的項目集群，項目運行與開發(fā)情況了然于胸。
作為獨立的服務(wù)，上面提到的這些產(chǎn)品已經(jīng)十分出色，但這還不夠，因為在開發(fā)過程中管理和使用一堆產(chǎn)品本身就會增加項目的復(fù)雜度。既然我們將發(fā)布作為我們的目標，那么按設(shè)定的動作自動的逐個使用這一系列軟件完成項目的發(fā)布將是一件輕松愉快的事情，而這一系列的軟件就構(gòu)成了 DevOps 工具鏈。
擁抱簡潔，我們應(yīng)該行動起來
類似亞馬遜云科技這樣的企業(yè)，他們服務(wù)了無數(shù)的技術(shù)團隊，無數(shù)的技術(shù)團隊又反饋給他們最真實貼切的需求，當這些需求演變成相應(yīng)的技術(shù)產(chǎn)品和服務(wù)以后，引領(lǐng)了技術(shù)的發(fā)展再次回饋開發(fā)者。
文章中所提到的技術(shù)創(chuàng)新和產(chǎn)品只是眾多大廠產(chǎn)品和服務(wù)中的很小一部分，從大廠的產(chǎn)品和服務(wù)中，我們能看到當前技術(shù)的最前沿成果和發(fā)展趨勢，獲得行業(yè)沉淀下來的成果，汲取最佳實踐，如果此刻你還沒有嘗試過我所說的這些產(chǎn)品和服務(wù)，還沒有體驗過現(xiàn)代化的應(yīng)用開發(fā)，沒能真正感受過簡潔之美，那么你應(yīng)該立刻行動起來，親身投入到應(yīng)用現(xiàn)代化的大潮之中。
報名開啟 | 自由構(gòu)建 探索無限
亞馬遜云科技2022 Dev Day 重磅來襲，不容錯過！
多位大咖現(xiàn)身說法
如何用充滿“技術(shù)美感”的方式
幫助開發(fā)者
實現(xiàn)更簡單、自由、高效的開發(fā)
此外，還有大量專家觀點碰撞
技術(shù)展、創(chuàng)新賽、動手實操等環(huán)節(jié)
精彩不斷，干貨滿滿
攜手大家一起“自由構(gòu)建，探索無限”
京公網(wǎng)安備 11010502049343號