- Practical DevOps
- Joakim Verona
- 417字
- 2021-07-16 09:48:05
The monolithic scenario
One way to understand the issues that a problematic architecture can cause for Continuous Delivery is to consider a counterexample for a while.
Let's suppose we have a large web application with many different functions. We also have a static website inside the application. The entire web application is deployed as a single Java EE application archive. So, when we need to fix a spelling mistake in the static website, we need to rebuild the entire web application archive and deploy it again.
While this might be seen as a silly example, and the enlightened reader would never do such a thing, I have seen this anti-pattern live in the real world. As DevOps engineers, this could be an actual situation that we might be asked to solve.
Let's break down the consequences of this tangling of concerns. What happens when we want to correct a spelling mistake? Let's take a look:
- We know which spelling mistake we want to correct, but in which code base do we need to do it? Since we have a monolith, we need to make a branch in our code base's revision control system. This new branch corresponds to the code that we have running in production.
- Make the branch and correct the spelling mistake.
- Build a new artifact with the correction. Give it a new version.
- Deploy the new artifact to production.
Okay, this doesn't seem altogether too bad at first glance. But consider the following too:
- We made a change in the monolith that our entire business critical system comprises. If something breaks while we are deploying the new version, we lose revenue by the minute. Are we really sure that the change affects nothing else?
- It turns out that we didn't really just limit the change to correcting a spelling mistake. We also changed a number of version strings when we produced the new artifact. But changing a version string should be safe too, right? Are we sure?
The point here is that we have already spent considerable mental energy in making sure that the change is really safe. The system is so complex that it becomes difficult to think about the effects of changes, even though they might be trivial.
Now, a change is usually more complex than a simple spelling correction. Thus, we need to exercise all aspects of the deployment chain, including manual verification, for all changes to a monolith.
We are now in a place that we would rather not be.
- C# 7 and .NET Core Cookbook
- 深度學習經典案例解析:基于MATLAB
- Windows Presentation Foundation Development Cookbook
- 深度強化學習算法與實踐:基于PyTorch的實現
- Getting Started with SQL Server 2012 Cube Development
- Unity Shader入門精要
- Linux Shell核心編程指南
- C++反匯編與逆向分析技術揭秘(第2版)
- MySQL入門很輕松(微課超值版)
- SciPy Recipes
- Arduino電子設計實戰指南:零基礎篇
- HTML5程序設計基礎教程
- Yii框架深度剖析
- iOS程序員面試筆試真題與解析
- Ext JS源碼分析與開發實例寶典