資料庫DBA為什麼拒絕DevOps？
許多傳統的DBA都不願意接受DevOps，因為擔心他們的角色會被淘汰，讓我們首先消除對單個資料庫的誤解。DBA的作用並沒有消失，而是在不斷髮展。DevOps雖然對大多數企業來說都是必不可少的，但必須以資料為中心點來完成。資料庫將通過減少依賴於特定平臺並更好地快速透明地提供資料來為業界提供最佳服務。
DBA和開發之間的中斷溝通幾乎就是IT的代名詞，DBA不崇尚變革，因為他們注重資料一致性與穩定性。Devops開發週期就是變革。由於開發週期是持續交付的一部分，並且持續整合給穩定性帶來了巨大壓力，DBA可以開始向開發週期的減緩施加壓力。最重要的目標是讓DBA成為devops流程的一部分，儘可能消除中斷或影響的可能性。
消除影響開發週期的最好方法之一是確保重現生產的開發和測試環境。使用虛擬化來提供儘可能多的開發和測試環境 - 在程序中同時進行多個開發週期所需的數量 - 應該是任何DevOps組的優先順序。請注意，我已將此責任分配給DevOps組而不是DBA組。這種區別的原因是我們讓DBA對此負責的時間太長了。
團隊也可以考慮容器化環境。Docker之外有許多型別的容器技術。一種流行的解決方案Kubernetes可用於建立“pods”，以便識別彼此屬於哪些層，以及將這些單獨層組合為一個層的能力。與使用虛擬機器相比，它將節省資源並最終節省資金。容器化在資料庫級別也非常有用。
隨著對資料庫源的外殼的這種改變，可能不需要用於中央分析的輔助資料來源。SQL可能在資料庫平臺之間具有類似的“風格”，但語句可能會導致不同的結果，具體取決於資料庫平臺。通過將資料庫僅用作資料儲存並消除大部分專有程式碼，將其強制到資料庫層之外，資料庫引擎之間的更改影響將會更小。資料庫層只負責索引管理，查詢優化和統計資訊收集，這些也可由資料庫引擎自動化實現。此時資料庫只不過是一個數據儲存，這就是DBA不願意看到的地方。DBA必須超越自己的資料庫平臺技能或對任何產品的忠誠度；DevOps工程師必須擁抱比任何獨特平臺更高級別的解決方案。
最後，我們希望看到具有與資料庫平臺互動的能力的介面（命令列和圖形），不會繫結到任何供應商如Oracle。
需要從具有中心資料庫的緊密耦合的架構環境中脫離出來，解決此問題的一種方法是在資料庫之上構建微服務。通過授予每個微服務自己的資料庫 - 特別是資料庫的虛擬化副本 - DevOps能夠像任何程式碼一樣快速地移動，並且它與其他開發週期的衝突更少，只需要最後一步就可部署。