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