跳轉至內容

大型資料/相關工作實用DevOps

來自Wikibooks,開放世界中的開放書籍

大型資料對業務的重要性

[編輯 | 編輯原始碼]

資料不僅是我們社會幾乎所有經濟和社會活動的一部分,而且已經成為所有行業、組織、國家和地區的必不可少資源。但為什麼會這樣呢?預計到2020年,將會有超過16澤位元組的有用資料(16萬億GB)。資料不僅是我們社會幾乎所有經濟和社會活動的一部分,例如速度、多樣性和社會經濟價值,標誌著向資料驅動的社會經濟模式轉變,這表明從2013年到2020年每年增長236%。因此,資料爆發確實是一個現實,歐洲必須以有組織、有力、以使用者為中心和目標導向的方式來應對和努力。很明顯,資料開發可以成為創新的先鋒,推動尖端技術,增強競爭力,併產生社會和經濟影響。

DICE價值主張

[編輯 | 編輯原始碼]

業務計劃的價值主張是在專案早期必須定義的最關鍵因素。價值主張應該是一個簡短但同時又全面的專案陳述,解決諸如以下問題:為利益相關者提供了什麼價值?解決了哪些業務問題/需求,滿足了哪些需求?為每個利益相關者群體提供了哪些產品和服務組合?

為了達成一個強大且切中要害的價值主張,該主張將涉及整個DICE,並將其所有創新都呈現出來,並確定在其生命週期中產生的專案的實物資產。儘管強烈建議持續監控市場並根據專案生命週期中開發活動的成果修訂這些資產,但初始分析應考慮專案的核心目標和預期結果。此類方面包括創新、動機以及為DICE利益相關者提供的增值。

最後,前面提到的分析應有助於定義DICE開發戰略的其他重要部分,即專案的細分市場、趨勢和目標群體。從利益相關者需求的角度出發,對現有開發功能與DICE生態系統預期功能進行定性比較,是專案長期可持續性的關鍵。

為了定義DICE價值主張,DICE開發團隊為財團的所有合作伙伴分配了多項任務。因此,合作伙伴致力於填寫與他們在DICE背景下實施的工具、他們帶來的技術、他們提供的服務、類似的計劃以及相較於它們的優勢等相關的多個模板。在接下來的章節中,我們將詳細介紹這些貢獻。

DICE價值主張如下:DICE提供創新的開發方法和工具,以增強中小獨立軟體供應商在業務關鍵型資料密集型應用程式(DIA)市場中的競爭力。利用DevOps正規化和當今創新的大型資料技術,DICE為基於雲的DIA的質量驅動開發提供完整的開源解決方案。

DICE的市場定位

[編輯 | 編輯原始碼]

分析資訊的最終目標是將DICE定位到市場。DICE創新型生態系統有哪些有意義的市場領域可以滲透,當今的趨勢是什麼,DICE是否處於這些趨勢之中,等等。所有這些問題在專案的早期階段都需要得到解答,以便將開發階段引向創造創新的方向,從而確保其長期可持續性。很明顯,只有有前景的想法才能確保專案在專案資金結束之後也能保持活力。

從宏觀角度來看,下圖透過呈現其“宏觀”和“微觀”市場領域來將DICE定位到市場。

DICE市場定位

業務需求和DICE

[編輯 | 編輯原始碼]

DICE可以被視為DevOps運動的一部分,因為它提供了一套工具,這些工具可以透過模型驅動的方法促進從開發到運維的資訊流,並使運維監控和異常檢測功能能夠促進從運維到開發的資訊流。此外,DICE在DevOps的背景下提供了以下原則

  • 藉助DICE的特性,它可以使用適當的操作註釋進行DIA設計,從而促進設計時模擬和最佳化。“開發”和“運維”可以並肩工作,使用提供的重構架構設計的模擬和最佳化工具來改進和增強應用程式設計。
  • 包括監控和工具,這些工具利用監控資料來檢測異常並最佳化應用程式配置,監控資料還被工具利用來向架構設計提供反饋,以識別瓶頸並重構架構。
  • DICE還提供用於自動化交付和持續整合的工具,這些工具有助於將設計時和執行時工具整合到DICE中,並提供DevOps自動化。

組織現在面臨著一個挑戰,即如何以更智慧的方式利用資料,使用能夠在短時間內快速分析海量資料的資料密集型應用程式。但是,大資料系統是複雜的系統,涉及許多相互關聯的不同框架來處理資料。軟體供應商如何在日益增長的複雜性中實現越來越高的水平?他們如何在不降低服務質量的情況下加快產品上市時間?這增加了大資料應用程式設計和操作需求,也需要一種共同的方法,使開發和運營團隊能夠在整個應用程式生命週期中即時做出反應,並確保質量和效能需求。因此,大資料系統開發為系統開發人員和運營商帶來了一些技術挑戰和要求,這些挑戰和要求將嚴重影響業務模式的可持續性,特別是對於資源有限且無力影響市場的軟體供應商和中小企業。特別是DICE團隊在實踐中發現了以下問題

  • 缺乏用於質量感知開發和持續交付產品的自動化工具,這些產品已在質量保證方面得到驗證。換句話說,存在許多不同的框架,軟體供應商可以採用這些框架來開發其資料密集型應用程式。但是,沒有自動機制能夠使他們能夠以自動化方式跨越如此不同的技術堆疊驗證軟體質量。
  • 缺乏用於質量驅動架構改進的自動化工具。為了開發資料密集型應用程式,軟體供應商需要採用架構風格來整合系統的不同元件。在開發過程中,這種資料架構的複雜性會增加,並且沒有自動化工具能夠使設計人員根據基於在真實平臺上監控系統而檢測到的效能瓶頸和可靠性問題來改進架構。
  • 缺乏與行業異構流程成熟度互操作的工具和方法。開發和維護資料密集型應用程式是IT市場多樣性的關鍵,涵蓋大型工業企業和中小型企業。但是,在這種多樣性中存在大量不同的軟體流程。這種多樣性很少從方法論和技術角度加以考慮。例如,很少有評估表明某些資料密集型設計方法在符合能力成熟度模型整合(CMMI)4級(定量管理)或2級(管理)的IT公司中的適用性,然而,這些設計方法的行業採用可能在很大程度上取決於此類評估。DICE提出了一種輕量級模型驅動方法來設計和部署資料密集型應用程式,其中模型成為與行業中已建立的密集編碼或原型設計程式(例如,在CMMI 5級參與者中)並駕齊驅的資產。DICE模型在幫助開發人員獲得所需的QoS屬性以及準備其資料密集型業務邏輯方面發揮著作用。這種方法論方法提供了與任何CMMI級別的具體整合,從具有初始成熟度的新興中小企業——他們可以在最簡單的形式下使用DICE,例如,使用敏捷方法——到可能需要細粒度和框架特定支援以實現質量的大型企業IT企業。

軟體供應商始終能夠找到適應新情況的方法,以幫助組織採用並實現其目標。在過去幾年中,DevOps實踐獲得了巨大的發展勢頭。來自各行各業的組織都認識到,如果他們想要保持創新並對當今不斷增長的業務需求做出響應,則需要縮小開發和運營之間的差距。這種新的正規化側重於一種新的做事方式,一種試圖改進開發人員和運營人員的協作和溝通,同時自動化軟體交付和基礎設施更改流程的方法。因此,需要一個新的生態系統來透過提供以下功能來促進此類自動化流程

  • 業務需求和技術服務質量:所有型別的組織都需要快速發展,並且需要將其IT資產與自身需求保持一致(建立新的資產或調整現有資產)。因此,ICT部門需要確保其ICT平臺和基礎設施足夠靈活,以適應業務變化,而不管用於建立這些資料密集型應用程式的IT基礎設施型別如何,無論它們是使用開源軟體構建還是由公共雲提供商提供的雲服務。換句話說,他們應該儘可能避免技術鎖定。

  • 架構重構:應用程式的效率、可靠性和安全性應在測試和生產環境中進行監控,並透過指標和資料直接快速反饋給開發團隊,以便更快地進行測試、改進和調整,以滿足服務水平目標。
  • 應用程式監控和異常檢測:監控引擎收集的即時資料訪問許可權還應提供生產環境中觀察到的應用程式的效能和可靠性資料,以評估識別異常值和檢測任何可能損害依賴於此類資料密集型應用程式的持續業務流程的異常的需求。此外,此類監控資料應協助應用程式架構師和開發人員構建面向最佳化的目標基礎設施。
  • 效率和最佳配置:大資料應用程式通常會消耗公司透過公有云獲得的昂貴資源。因此,最佳化此類應用程式以減少資源需求並提高輸出至關重要。因此,組織需要擁有自動化工具來最佳化配置此類應用程式,而無需聘請專家來最佳化其大資料應用程式。
華夏公益教科書