下載自視覺中國
科學可以很美，技術的發展源自科學，也同樣具有美感。搜尋一下亞馬遜的計算機類圖書，我們會發現各類以xx之美命名的書籍，從開發人員關注的“程式設計之美”到“測試之美”以及“演算法之美”，架構師推崇的“系統之美”、“叢集之美”……
談論到技術之美，似乎每個工程師都有自己的見解，每個人都能從自己的視角發掘技術的美感。楊振寧老先生說：“科學⾥終極的美是客觀的，沒有⼈類的時候就已經有這些美了”。儘管技術中會表現出與科學、藝術相似的美感，可是在技術之美中，人表現出的創造力才是技術之美的本源。軟體是由人設計出來的，構成軟體的每一行程式碼都直接或間接的由工程師創造，人們工作、生活中使用的各類軟體都執行在由人類工程師搭建的基礎設施之上。沒有⼈類就沒有軟體技術，也就沒有技術中的美。
下載自視覺中國
開發者都需要親自感受和體驗技術之美
理解並感受技術之美是工程師成長曆程中不可或缺的一部分。被譽為技術之美的軟體設計與程式碼實現通常來源於前輩們工作中的最佳實踐；被推崇為技術之美的專案管理方法與團隊協作模式則是凝聚了無數天才的智慧與經驗。技術之美充斥在技術開發與研發創新的每一個角落，和藝術家一樣，每一個優秀軟體工程師都會用自己的方式從不同的維度去書寫技術之美。
要理解、感受並學習技術之美，我們應該從哪裡開始呢？我給出的答案是 “簡潔之美”。
伴隨著各行業數字化程度的不斷加深，網際網路以及各類軟體平臺承載的業務也必然會越來越複雜，當複雜到達一定程度，軟體產品的開發迭代難度將指數級增加，甚至到無法完成交付。在軟體設計與專案管理中運用“簡潔之美”則是對抗複雜最有效的辦法。
軟體的“能力增長”與技術的“簡潔之美”相互成就
作為一名擁有長達 24 年碼齡的 IT 工程師，一名擁有多個使用者超千萬的平臺架構設計經驗的架構師，幾乎經歷了中國網際網路與軟體行業發展的所有重大節點與多次技術革命，就由我來帶大家看一看軟體開發行業是怎樣從刀耕火種的蠻荒時代一步步走到現在的雲原生時代。
下載自視覺中國
最初的美好
早期的程式設計其實並不複雜，編寫程式碼是隻屬於少數人的遊戲，還記得自己透過編碼賺取的第一筆收入是幫人寫一個用於資料處理的 Pascal 指令碼，而報酬則是客戶公司按程式碼的行數來支付換取程式的版權。整個程式開發一個人就能完成，只需要能精確的描述問題，創造合適的資料結構，編寫對應的演算法，問題很快就能得到解決。
下載自視覺中國
毫無疑問，這樣的工作方式和程式程式碼都是極其簡潔的，也是程式設計師最初喜愛的程式設計方式，每一行程式碼你都知道他是如何執行的，每一個函式你都清楚他做了哪些事情；哪怕只有一個函式，也可以是一個完整的程式；每次修改完程式，程式碼立刻就可以編譯執行得到結果，即便有 bug 也能立刻發現並解決。
這樣的程式指令碼曾經很流行，這是每個程式設計師都渴望的工作狀態，這就是簡潔，是無數工程師一直追求的狀態。
軟體因何變得複雜
隨著軟體需求越發複雜，軟體專案的編碼量，開發週期，迭代次數都在不斷的增長，成熟的軟體產品很難再由個人獨自開發完成。
程式碼量的不斷增長，意味著每一次更新程式碼後都需要更長的時間去編譯和構建專案，等待編譯的過程從一個哈欠到一根菸、一杯茶、甚至一整天。
多個人協作怎麼分工？各自編寫的程式碼如何整合？或許你很難想象，但手工管理程式碼的時代確實存在過，每個程式設計師分一個模組，各自編寫程式碼，最後透過名叫“QQ”或者“飛鴿傳書”的軟體傳送給專案的 leader，再由 leader 去把多個人的程式碼放到一個資料夾下，手動去一個一個 include 其他人開發的模組，其中還可能遇到各種程式碼衝突，呼叫失敗，編譯錯誤……搞定一切後，還需要再對專案進行打包存檔，然後標註好存檔的日期和時間。如此繁瑣的工作，大量的精力浪費在了寫程式碼以外的事情上。
因為網際網路軟體與網際網路服務的普及，我們開發的軟體再也不是隻執行在本地計算機裡，我們需要配置好遠端環境，需要把程式碼上傳到遠端伺服器，在程式碼上傳後，還需要去處理本地 Windows 與遠端 Linux 之間的差異，環境變數、資料庫配置……。每次釋出一個新的版本，開發團隊通常都會選擇深夜，每一次版本上線都是一次戰役。
遇到上規模的專案，多條業務線並行是常態，透過 SOAP、RPC 等協議構建面向服務的分散式應用（SOA 架構）是實現服務重用的常見辦法，但隨著專案運營的不斷迭代，服務線的增加，服務間相互依賴、耦合的加深，必然會讓服務間相互呼叫變得極其複雜，如果將服務間的關係影象化，你將看到一堆打結的繩子擰巴在一起，把你綁住讓你寸步難行，呼吸困難。
下載自視覺中國
這一切的一切都使得軟體開發的過程變得複雜，工程師每天大量的時間花在管理程式碼，編譯軟體，更改配置等一系列繁瑣的工作之上，我們很清楚我們想要的只是回到最初的美好。
在軟體和軟體開發本身變得麻煩的時候，不斷有天才般的工程師站出來解決問題，因為工程師們都酷愛簡潔，希望精力能專注於程式碼編寫之上：
工程師希望程式碼修改後能立即執行，不需要漫長的等待，因此構建工具被開發出來；
工程師希望多人協作也能足夠的自由，並且不再為版本合併和分支管理發愁，因此發明的版本管理工具與程式碼倉庫；
工程師希望本地開發和遠端生產環境能保持一致，希望在本地開發應用原生為雲設計，希望應用在雲端以最佳狀態執行，因此容器技術、雲原生以及DevOps被創造出來；
工程師希望剝離業務將服務中的能力抽象出來，並且將能力變成服務和元件獨立維護和迭代，這樣就能實現更小顆粒度的程式碼複用與更高級別的抽象，因此微服務設計迅速崛起，Serverless架構也為更多專案提供了更好的選擇。
這些技術的誕生源於工程師對簡潔的執戀，而這些技術的普及和發展就要歸功於開源社群以及眾多技術廠商的交流與協作。
說到這裡，不得不提當下引領技術發展方向的重要力量之一：亞馬遜雲科技（Amazon Web Services），作為雲計算行業的先驅，早在20年初就開始佈局雲計算業務的亞馬遜雲科技，他們從無數的客戶現場獲得反饋，他們很清楚開發者遇到的難題。
儘管讓複雜的開發過程變得簡潔的各個工具都已經被髮明出來，但想要通盤使用依然有較高的門檻。
透過開源的Gitlab，開發者能獲得一個屬於自己的程式碼託管平臺，但Gitlab需要至少一臺主機，而且記憶體不少於8G，哪怕只有一個專案要託管，哪怕專案只編寫了一個函式，託管主機的費用都省不了，除此之外，還需要開發者安裝配置好ruby環境，安裝好資料庫，下載好軟體原始碼……，哦，別忘了，Gitlab有更新時，開發者還需要考慮是否要同步去更新自己的Gitlab。
就像你們看到的，事情又又又變得複雜了！！！
除了版本倉庫，其他工具也一樣，比如容器的映象倉庫，CI/CD 等一系列工具，完整的搭建起開發平臺並規範團隊的工作流程已經成為一件極具挑戰的任務。
技術廠商給予的支援
如果開發者只需要託管程式碼，那麼 Amazon CodeCommit，直接給你一個安全、高度可擴充套件的託管型原始碼控制服務；
將應用容器化，你可以直接將映象推到 Amazon ECR，擁有一個 docker hub如此簡單；
搭建 K8s 叢集，從來都不是一個輕鬆的事情，無論物理主機還是雲主機，作為日後軟體服務執行的基礎，我們不得不全勤投入，Amazon EKS，讓我們可以輕鬆的獲得 k8s 叢集，Amazon EKS Anywhere 讓我們可以透過預設元件配置幫助簡化本地 Kubernetes 叢集的建立和運維，實現隨時隨地 K8s 叢集管理自動化。Amazon App2Container 能把你多年前部署的傳統應用直接打包為容器映象，應用的部署與叢集的管理再次被簡化。
廠商給予的支援僅此而已嗎？當然不是，如果說有些複雜很難被徹底根除，那麼就把這些複雜留給廠商，把簡潔重新還給開發者。
上面提到的各類應用已經能解決很多團隊當前面臨的眾多棘手問題，但廠商做到的比我們預想的更多。
DevOps工具鏈，現代化應用開發“簡潔之美”的最佳體驗
Amazon CodePipeline，可以實現快速而可靠的應用程式和基礎設施更新，只要程式碼發生變化，CodePipeline 便會構建、測試和部署程式碼；
Amazon CodeBuild 是完全託管的生成服務，可編譯原始碼、執行測試以及生成可供部署的軟體包。反覆配置、管理和擴充套件生成伺服器將成為歷史；
Amazon CodeDeploy 可將程式碼自動部署至任何例項，快速釋出新功能，從此告別凌晨三點的版本釋出日常活動。
Amazon CodeStar 提供一個統一的使用者介面，您可以在此介面輕鬆管理您的軟體開發活動，面對複雜的專案叢集，專案執行與開發情況瞭然於胸。
作為獨立的服務，上面提到的這些產品已經十分出色，但這還不夠，因為在開發過程中管理和使用一堆產品本身就會增加專案的複雜度。既然我們將釋出作為我們的目標，那麼按設定的動作自動的逐個使用這一系列軟體完成專案的釋出將是一件輕鬆愉快的事情，而這一系列的軟體就構成了 DevOps 工具鏈。
下載自視覺中國
擁抱簡潔，我們應該行動起來
類似亞馬遜雲科技這樣的企業，他們服務了無數的技術團隊，無數的技術團隊又反饋給他們最真實貼切的需求，當這些需求演變成相應的技術產品和服務以後，引領了技術的發展再次回饋開發者。
文章中所提到的技術創新和產品只是眾多大廠產品和服務中的很小一部分，從大廠的產品和服務中，我們能看到當前技術的最前沿成果和發展趨勢，獲得行業沉澱下來的成果，汲取最佳實踐，如果此刻你還沒有嘗試過我所說的這些產品和服務，還沒有體驗過現代化的應用開發，沒能真正感受過簡潔之美，那麼你應該立刻行動起來，親身投入到應用現代化的大潮之中。
————————————————
版權宣告：本文為CSDN博主「CSDN 程式人生」的原創文章，遵循CC 4。0 BY-SA版權協議，轉載請附上原文出處連結及本宣告。
原文連結：https：//blog。csdn。net/csdnsevenn/article/details/126537200
