From 65e8f64dd1566dc54d1511f8e0391a967f51610c Mon Sep 17 00:00:00 2001 From: Frank Jia <474165491@qq.com> Date: Sat, 21 Sep 2019 16:53:44 +0800 Subject: [PATCH 01/21] Initial Commit --- ...ology changes the rules for doing agile.md | 95 +++++++++++++++++++ 1 file changed, 95 insertions(+) create mode 100644 translated/tech/20180117 How technology changes the rules for doing agile.md diff --git a/translated/tech/20180117 How technology changes the rules for doing agile.md b/translated/tech/20180117 How technology changes the rules for doing agile.md new file mode 100644 index 0000000000..1b67935509 --- /dev/null +++ b/translated/tech/20180117 How technology changes the rules for doing agile.md @@ -0,0 +1,95 @@ +How technology changes the rules for doing agile +====== + +![](https://enterprisersproject.com/sites/default/files/styles/620x350/public/images/CIO%20Containers%20Ecosystem.png?itok=lDTaYXzk) + +More companies are trying agile and [DevOps][1] for a clear reason: Businesses want more speed and more experiments - which lead to innovations and competitive advantage. DevOps helps you gain that speed. But doing DevOps in a small group or startup and doing it at scale are two very different things. Any of us who've worked in a cross-functional group of 10 people, come up with a great solution to a problem, and then tried to apply the same patterns across a team of 100 people know the truth: It often doesn't work. This path has been so hard, in fact, that it has been easy for IT leaders to put off agile methodology for another year. + +But that time is over. If you've tried and stalled, it's time to jump back in. + +Until now, DevOps required customized answers for many organizations - lots of tweaks and elbow grease. But today, [Linux containers ][2]and Kubernetes are fueling standardization of DevOps tools and processes. That standardization will only accelerate. The technology we are using to practice the DevOps way of working has finally caught up with our desire to move faster. + +Linux containers and [Kubernetes][3] are changing the way teams interact. Moreover, on the Kubernetes platform, you can run any application you now run on Linux. What does that mean? You can run a tremendous number of enterprise apps (and handle even previously vexing coordination issues between Windows and Linux.) Finally, containers and Kubernetes will handle almost all of what you'll run tomorrow. They're being future-proofed to handle machine learning, AI, and analytics workloads - the next wave of problem-solving tools. + +**[ See our related article,[4 container adoption patterns: What you need to know. ] ][4]** + +Think about machine learning, for example. Today, people still find the patterns in much of an enterprise's data. When machines find the patterns (think machine learning), your people will be able to act on them faster. With the addition of AI, machines can not only find but also act on patterns. Today, with people doing everything, three weeks is an aggressive software development sprint cycle. With AI, machines can change code multiple times per second. Startups will use that capability - to disrupt you. + +Consider how fast you have to be to compete. If you can't make a leap of faith now to DevOps and a one week cycle, think of what will happen when that startup points its AI-fueled process at you. It's time to move to the DevOps way of working now, or get left behind as your competitors do. + +### How are containers changing how teams work? + +DevOps has frustrated many groups trying to scale this way of working to a bigger group. Many IT (and business) people are suspicious of agile: They've heard it all before - languages, frameworks, and now models (like DevOps), all promising to revolutionize application development and IT process. + +**[ Want DevOps advice from other CIOs? See our comprehensive resource, [DevOps: The IT Leader's Guide][5]. ]** + +It's not easy to "sell" quick development sprints to your stakeholders, either. Imagine if you bought a house this way. You're not going to pay a fixed amount to your builder anymore. Instead, you get something like: "We'll pour the foundation in 4 weeks and it will cost x. Then we'll frame. Then we'll do electrical. But we only know the timing on the foundation right now." People are used to buying homes with a price up front and a schedule. + +The challenge is that building software is not like building a house. The same builder builds thousands of houses that are all the same. Software projects are never the same. This is your first hurdle to get past. + +Dev and operations teams really do work differently: I know because I've worked on both sides. We incent them differently. Developers are rewarded for changing and creating, while operations pros are rewarded for reducing cost and ensuring security. We put them in different groups and generally minimize interaction. And the roles typically attract technical people who think quite differently. This situation sets IT up to fail. You have to be willing to break down these barriers. + +Think of what has traditionally happened. You throw pieces over the wall, then the business throws requirements over the wall because they are operating in "house-buying" mode: "We'll see you in 9 months." Developers build to those requirements and make changes as needed for technical constraints. Then they throw it over the wall to operations to "figure out how to run this." Operations then works diligently to make a slew of changes to align the software with their infrastructure. And what's the end result? + +More often than not, the end result isn't even recognizable to the business when they see it in its final glory. We've watched this pattern play out time and time again in our industry for the better part of two decades. It's time for a change. + +It's Linux containers that truly crack the problem - because containers close the gap between development and operations. They allow both teams to understand and design to all of the critical requirements, but still uniquely fulfill their team's responsibilities. Basically, we take out the telephone game between developers and operations. With containers, we can have smaller operations teams, even teams responsible for millions of applications, but development teams that can change software as quickly as needed. (In larger organizations, the desired pace may be faster than humans can respond on the operations side.) + +With containers, you're separating what is delivered from where it runs. Your operations teams are responsible for the host that will run the containers and the security footprint, and that's all. What does this mean? + +First, it means you can get going on DevOps now, with the team you have. That's right. Keep teams focused on the expertise they already have: With containers, just teach them the bare minimum of the required integration dependencies. + +If you try and retrain everyone, no one will be that good at anything. Containers let teams interact, but alongside a strong boundary, built around each team's strengths. Your devs know what needs to be consumed, but don't need to know how to make it run at scale. Ops teams know the core infrastructure, but don't need to know the minutiae of the app. Also, Ops teams can update apps to address new security implications, before you become the next trending data breach story. + +Teaching a large IT organization of say 30,000 people both ops and devs skills? It would take you a decade. You don't have that kind of time. + +When people talk about "building new, cloud-native apps will get us out of this problem," think critically. You can build cloud-native apps in 10-person teams, but that doesn't scale for a Fortune 1000 company. You can't just build new microservices one by one until you're somehow not reliant on your existing team: You'll end up with a siloed organization. It's an alluring idea, but you can't count on these apps to redefine your business. I haven't met a company that could fund parallel development at this scale and succeed. IT budgets are already constrained; doubling or tripling them for an extended period of time just isn't realistic. + +### When the remarkable happens: Hello, velocity + +Linux containers were made to scale. Once you start to do so, [orchestration tools like Kubernetes come into play][6] - because you'll need to run thousands of containers. Applications won't consist of just a single container, they will depend on many different pieces, all running on containers, all running as a unit. If they don't, your apps won't run well in production. + +Think of how many small gears and levers come together to run your business: The same is true for any application. Developers are responsible for all the pulleys and levers in the application. (You could have an integration nightmare if developers don't own those pieces.) At the same time, your operations team is responsible for all the pulleys and levers that make up your infrastructure, whether on-premises or in the cloud. With Kubernetes as an abstraction, your operations team can give the application the fuel it needs to run - without being experts on all those pieces. + +Developers get to experiment. The operations team keeps infrastructure secure and reliable. This combination opens up the business to take small risks that lead to innovation. Instead of having to make only a couple of bet-the-farm size bets, real experimentation happens inside the company, incrementally and quickly. + +In my experience, this is where the remarkable happens inside organizations: Because people say "How do we change planning to actually take advantage of this ability to experiment?" It forces agile planning. + +For example, KeyBank, which uses a DevOps model, containers, and Kubernetes, now deploys code every day. (Watch this [video][7] in which John Rzeszotarski, director of Continuous Delivery and Feedback at KeyBank, explains the change.) Similarly, Macquarie Bank uses DevOps and containers to put something in production every day. + +Once you push software every day, it changes every aspect of how you plan - and [accelerates the rate of change to the business][8]. "An idea can get to a customer in a day," says Luis Uguina, CDO of Macquarie's banking and financial services group. (See this [case study][9] on Red Hat's work with Macquarie Bank). + +### The right time to build something great + +The Macquarie example demonstrates the power of velocity. How would that change your approach to your business? Remember, Macquarie is not a startup. This is the type of disruptive power that CIOs face, not only from new market entrants but also from established peers. + +The developer freedom also changes the talent equation for CIOs running agile shops. Suddenly, individuals within huge companies (even those not in the hottest industries or geographies) can have great impact. Macquarie uses this dynamic as a recruiting tool, promising developers that all new hires will push something live within the first week. + +At the same time, in this day of cloud-based compute and storage power, we have more infrastructure available than ever. That's fortunate, considering the [leaps that machine learning and AI tools will soon enable][10]. + +This all adds up to this being the right time to build something great. Given the pace of innovation in the market, you need to keep building great things to keep customers loyal. So if you've been waiting to place your bet on DevOps, now is the right time. Containers and Kubernetes have changed the rules - in your favor. + +**Want more wisdom like this, IT leaders? [Sign up for our weekly email newsletter][11].** + +-------------------------------------------------------------------------------- + +via: https://enterprisersproject.com/article/2018/1/how-technology-changes-rules-doing-agile + +作者：[Matt Hicks][a] +译者：[译者ID](https://github.com/译者ID) +校对：[校对者ID](https://github.com/校对者ID) + +本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出 + +[a]:https://enterprisersproject.com/user/matt-hicks +[1]:https://enterprisersproject.com/tags/devops +[2]:https://www.redhat.com/en/topics/containers?intcmp=701f2000000tjyaAAA +[3]:https://www.redhat.com/en/topics/containers/what-is-kubernetes?intcmp=701f2000000tjyaAAA +[4]:https://enterprisersproject.com/article/2017/8/4-container-adoption-patterns-what-you-need-know?sc_cid=70160000000h0aXAAQ +[5]:https://enterprisersproject.com/devops?sc_cid=70160000000h0aXAAQ +[6]:https://enterprisersproject.com/article/2017/11/how-enterprise-it-uses-kubernetes-tame-container-complexity +[7]:https://www.redhat.com/en/about/videos/john-rzeszotarski-keybank-red-hat-summit-2017?intcmp=701f2000000tjyaAAA +[8]:https://enterprisersproject.com/article/2017/11/dear-cios-stop-beating-yourselves-being-behind-transformation +[9]:https://www.redhat.com/en/resources/macquarie-bank-case-study?intcmp=701f2000000tjyaAAA +[10]:https://enterprisersproject.com/article/2018/1/4-ai-trends-watch +[11]:https://enterprisersproject.com/email-newsletter?intcmp=701f2000000tsjPAAQ From 18a3ad71ab1affa3b00571cc1e0e82834c09123d Mon Sep 17 00:00:00 2001 From: Frank Jia <474165491@qq.com> Date: Sat, 21 Sep 2019 17:05:29 +0800 Subject: [PATCH 02/21] Update 20180117 How technology changes the rules for doing agile.md --- ...0117 How technology changes the rules for doing agile.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/translated/tech/20180117 How technology changes the rules for doing agile.md b/translated/tech/20180117 How technology changes the rules for doing agile.md index 1b67935509..d267fa2769 100644 --- a/translated/tech/20180117 How technology changes the rules for doing agile.md +++ b/translated/tech/20180117 How technology changes the rules for doing agile.md @@ -1,11 +1,11 @@ -How technology changes the rules for doing agile +技术如何改变敏捷的规则 ====== ![](https://enterprisersproject.com/sites/default/files/styles/620x350/public/images/CIO%20Containers%20Ecosystem.png?itok=lDTaYXzk) -More companies are trying agile and [DevOps][1] for a clear reason: Businesses want more speed and more experiments - which lead to innovations and competitive advantage. DevOps helps you gain that speed. But doing DevOps in a small group or startup and doing it at scale are two very different things. Any of us who've worked in a cross-functional group of 10 people, come up with a great solution to a problem, and then tried to apply the same patterns across a team of 100 people know the truth: It often doesn't work. This path has been so hard, in fact, that it has been easy for IT leaders to put off agile methodology for another year. +越来越多的公司正因为一个非常明显的原因开始尝试敏捷和[DevOps][1]: 企业需要借助更快的速度和更多的实验来提供创新和竞争性优势。而DevOps将帮助我们得到所想要达到的创新速度。但是，在小团队或初创企业中实践DevOps和进行大规模实践完全是两码事。我们都明白这样的一个事实，那就是在10人的跨职能团队中能够很好地解决问题的方案，当将同样的模式应用到100人的团队中时就可能无法奏效。这条道路是如此艰难，以至于IT领导者很容易将敏捷方法的推行再推迟一年。 -But that time is over. If you've tried and stalled, it's time to jump back in. +但那样的时代已经结束了。如果你已经尝试过，但是没有成功，那么现在是时候重新开始了。 Until now, DevOps required customized answers for many organizations - lots of tweaks and elbow grease. But today, [Linux containers ][2]and Kubernetes are fueling standardization of DevOps tools and processes. That standardization will only accelerate. The technology we are using to practice the DevOps way of working has finally caught up with our desire to move faster. From a39c3d5cb99e85b22d0cdab895385db5276f6020 Mon Sep 17 00:00:00 2001 From: Frank Jia <474165491@qq.com> Date: Sat, 21 Sep 2019 17:19:07 +0800 Subject: [PATCH 03/21] Update 20180117 How technology changes the rules for doing agile.md --- ...0117 How technology changes the rules for doing agile.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/translated/tech/20180117 How technology changes the rules for doing agile.md b/translated/tech/20180117 How technology changes the rules for doing agile.md index d267fa2769..e0579205b1 100644 --- a/translated/tech/20180117 How technology changes the rules for doing agile.md +++ b/translated/tech/20180117 How technology changes the rules for doing agile.md @@ -7,9 +7,9 @@ 但那样的时代已经结束了。如果你已经尝试过，但是没有成功，那么现在是时候重新开始了。 -Until now, DevOps required customized answers for many organizations - lots of tweaks and elbow grease. But today, [Linux containers ][2]and Kubernetes are fueling standardization of DevOps tools and processes. That standardization will only accelerate. The technology we are using to practice the DevOps way of working has finally caught up with our desire to move faster. +直到现在，DevOps需要为许多组织提供个性化的解决方案，因此往往需要进行大量的调整以及额外的工作。但在今天，[Linux容器][2]和Kubernetes正在推动DevOps工具和过程的标准化。而这样的标准化将会加速整个软件开发过程。因此，我们用来实践DevOps工作方式的技术最终能够满足我们加快软件开发速度的愿望。 -Linux containers and [Kubernetes][3] are changing the way teams interact. Moreover, on the Kubernetes platform, you can run any application you now run on Linux. What does that mean? You can run a tremendous number of enterprise apps (and handle even previously vexing coordination issues between Windows and Linux.) Finally, containers and Kubernetes will handle almost all of what you'll run tomorrow. They're being future-proofed to handle machine learning, AI, and analytics workloads - the next wave of problem-solving tools. +Linux容器和[Kubernetes][3]正在改变团队交互的方式。此外，你可以在Kubernetes平台上运行任何能够在Linux运行的应用程序。这意味着什么呢？你可以运行大量的企业及应用程序(甚至可以解决以前令人烦恼的Windows和Linux之间的协调问题)。最后，容器和Kubernetes将能够满足未来所有运行内容的需求。它们正在经受着未来的考验，以应对机器学习、人工智能和分析工作等下一代解决问题工具。 **[ See our related article,[4 container adoption patterns: What you need to know. ] ][4]** @@ -76,7 +76,7 @@ This all adds up to this being the right time to build something great. Given th via: https://enterprisersproject.com/article/2018/1/how-technology-changes-rules-doing-agile 作者：[Matt Hicks][a] -译者：[译者ID](https://github.com/译者ID) +译者：[JayFrank](https://github.com/JayFrank) 校对：[校对者ID](https://github.com/校对者ID) 本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出 From 99ffea86365e83683f0675fbf52acb61fb6b695f Mon Sep 17 00:00:00 2001 From: Frank Jia <474165491@qq.com> Date: Sat, 21 Sep 2019 23:49:09 +0800 Subject: [PATCH 04/21] Update 20180117 How technology changes the rules for doing agile.md --- ...0117 How technology changes the rules for doing agile.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/translated/tech/20180117 How technology changes the rules for doing agile.md b/translated/tech/20180117 How technology changes the rules for doing agile.md index e0579205b1..a539994baf 100644 --- a/translated/tech/20180117 How technology changes the rules for doing agile.md +++ b/translated/tech/20180117 How technology changes the rules for doing agile.md @@ -11,11 +11,11 @@ Linux容器和[Kubernetes][3]正在改变团队交互的方式。此外，你可以在Kubernetes平台上运行任何能够在Linux运行的应用程序。这意味着什么呢？你可以运行大量的企业及应用程序(甚至可以解决以前令人烦恼的Windows和Linux之间的协调问题)。最后，容器和Kubernetes将能够满足未来所有运行内容的需求。它们正在经受着未来的考验，以应对机器学习、人工智能和分析工作等下一代解决问题工具。 -**[ See our related article,[4 container adoption patterns: What you need to know. ] ][4]** +**[ 参考相关文章,[4 container adoption patterns: What you need to know. ] ][4]** -Think about machine learning, for example. Today, people still find the patterns in much of an enterprise's data. When machines find the patterns (think machine learning), your people will be able to act on them faster. With the addition of AI, machines can not only find but also act on patterns. Today, with people doing everything, three weeks is an aggressive software development sprint cycle. With AI, machines can change code multiple times per second. Startups will use that capability - to disrupt you. +让我们以机器学习为例来思考一下。今天，人们可以在大量的企业数据中找到一些模式。当机器发现这些模式时(想想机器学习)，你的员工就能更快地采取行动。随着人工智能的加入，机器不仅可以发现模式，还可以对模式进行操作。如今，三个星期已经成为了一个积极的软件开发冲刺周期。有了人工智能，机器每秒可以多次修改代码。创业公司会利用这种能力来“打扰你”。 -Consider how fast you have to be to compete. If you can't make a leap of faith now to DevOps and a one week cycle, think of what will happen when that startup points its AI-fueled process at you. It's time to move to the DevOps way of working now, or get left behind as your competitors do. +考虑一下你需要多快才能参与到竞争当中。如果你对于无法对于DevOps和每周一个迭代周期充满信心，那么考虑一下当那个创业公司将AI驱动的过程指向你时会发生什么？现在是时候转向DevOps的工作方式了，否认就会像你的竞争对手一样被甩在后面。 ### How are containers changing how teams work? From 7394b50a55b4e37405ca0bd1de466f97e8f82cc6 Mon Sep 17 00:00:00 2001 From: Frank Jia <474165491@qq.com> Date: Sun, 22 Sep 2019 13:25:12 +0800 Subject: [PATCH 05/21] Update 20180117 How technology changes the rules for doing agile.md --- ...w technology changes the rules for doing agile.md | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/translated/tech/20180117 How technology changes the rules for doing agile.md b/translated/tech/20180117 How technology changes the rules for doing agile.md index a539994baf..941a980ae3 100644 --- a/translated/tech/20180117 How technology changes the rules for doing agile.md +++ b/translated/tech/20180117 How technology changes the rules for doing agile.md @@ -17,13 +17,17 @@ Linux容器和[Kubernetes][3]正在改变团队交互的方式。此外，你可 考虑一下你需要多快才能参与到竞争当中。如果你对于无法对于DevOps和每周一个迭代周期充满信心，那么考虑一下当那个创业公司将AI驱动的过程指向你时会发生什么？现在是时候转向DevOps的工作方式了，否认就会像你的竞争对手一样被甩在后面。 -### How are containers changing how teams work? +### 容器技术如何改变团队的工作？ -DevOps has frustrated many groups trying to scale this way of working to a bigger group. Many IT (and business) people are suspicious of agile: They've heard it all before - languages, frameworks, and now models (like DevOps), all promising to revolutionize application development and IT process. +DevOps使得许多试图将这种工作方式扩展到更大范围的团队感到沮丧。即使许多IT(和业务)人员之前都听说过语言、框架、模型(如DevOps)等承诺将会彻底应用程序开发和IT过程的全部相关内容，但他们还是对于敏捷持怀疑态度。 -**[ Want DevOps advice from other CIOs? See our comprehensive resource, [DevOps: The IT Leader's Guide][5]. ]** +**[ 想要获取来自其他CIO们的建议吗？不放参考下我们的综述性资源, [DevOps: The IT Leader's Guide][5]. ]** -It's not easy to "sell" quick development sprints to your stakeholders, either. Imagine if you bought a house this way. You're not going to pay a fixed amount to your builder anymore. Instead, you get something like: "We'll pour the foundation in 4 weeks and it will cost x. Then we'll frame. Then we'll do electrical. But we only know the timing on the foundation right now." People are used to buying homes with a price up front and a schedule. +向你的涉众“推销”快速开发冲刺也不是一件容易的事情。 + +想象一下，如果你以这种方式买了一栋房子。你不再需要向建造者支付固定的金额。相反，你会得到这样的信息:“我们将在4周内倒好粉底，它的成本是x。然后我们将构建框架。”然后我们要做电学。但我们现在只知道基金会成立的时间。”人们已经习惯了买房子的时候有一个预先的价格和时间表。 + +Imagine if you bought a house this way. You're not going to pay a fixed amount to your builder anymore. Instead, you get something like: "We'll pour the foundation in 4 weeks and it will cost x. Then we'll frame. Then we'll do electrical. But we only know the timing on the foundation right now." People are used to buying homes with a price up front and a schedule. The challenge is that building software is not like building a house. The same builder builds thousands of houses that are all the same. Software projects are never the same. This is your first hurdle to get past. From 1bbc1e0177866e6af2cdb518928c2670c82eaecc Mon Sep 17 00:00:00 2001 From: Frank Jia <474165491@qq.com> Date: Sun, 22 Sep 2019 13:48:04 +0800 Subject: [PATCH 06/21] Update 20180117 How technology changes the rules for doing agile.md --- ...nology changes the rules for doing agile.md | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/translated/tech/20180117 How technology changes the rules for doing agile.md b/translated/tech/20180117 How technology changes the rules for doing agile.md index 941a980ae3..415ac6d29e 100644 --- a/translated/tech/20180117 How technology changes the rules for doing agile.md +++ b/translated/tech/20180117 How technology changes the rules for doing agile.md @@ -23,17 +23,23 @@ DevOps使得许多试图将这种工作方式扩展到更大范围的团队感 **[ 想要获取来自其他CIO们的建议吗？不放参考下我们的综述性资源, [DevOps: The IT Leader's Guide][5]. ]** -向你的涉众“推销”快速开发冲刺也不是一件容易的事情。 +向你的涉众“推销”快速开发冲刺也不是一件容易的事情。想象一下，如果你以这种方式买了一栋房子： -想象一下，如果你以这种方式买了一栋房子。你不再需要向建造者支付固定的金额。相反，你会得到这样的信息:“我们将在4周内倒好粉底，它的成本是x。然后我们将构建框架。”然后我们要做电学。但我们现在只知道基金会成立的时间。”人们已经习惯了买房子的时候有一个预先的价格和时间表。 +你将不再需要向开发商支付固定的金额，而是会得到这样的信息：“我们将在4周内浇筑完地基，其成本是X，之后再搭建房屋框架和铺设电路，但是我们现在只能够知道地基完成的时间表。”人们已经习惯了买房子的时候有一个预先的价格和交付时间表。 -Imagine if you bought a house this way. You're not going to pay a fixed amount to your builder anymore. Instead, you get something like: "We'll pour the foundation in 4 weeks and it will cost x. Then we'll frame. Then we'll do electrical. But we only know the timing on the foundation right now." People are used to buying homes with a price up front and a schedule. +挑战在于构建软件与构建房屋不同。同一个建筑商建造了成千上万个完全相同的房子，而软件项目从来都各不相同。这是你要克服的第一个障碍。 -The challenge is that building software is not like building a house. The same builder builds thousands of houses that are all the same. Software projects are never the same. This is your first hurdle to get past. +开发和运维团队的工作方式确实不同：我之所以知道这一点是因为我曾经从事过这两方面的工作。我们往往会用不同的方式来激励他们，开发人员会因为更改和创建而获得奖励，而运维专家则会因降低成本和确保安全性而获得奖励。我们会把他们分成不同的小组，并且尽量减少互动。而这些角色通常会吸引那些想法完全不同的技术人员。但是这样的解决方案注定会失败，你必须打破横亘在开发和运维之间的藩篱。 + +想想传统情况下会发生什么。业务会把需求扔过墙，这是因为他们在“买房”模式下运作：“我们9个月后见。”开发人员根据这些需求进行开发，并根据技术约束的需要进行更改。然后，他们把它扔过墙传递给运维人员，并说一句“搞清楚如何运行这个软件”。 + +“找出如何运行这个。”然后，操作人员勤奋地进行大量更改，使软件与其基础设施保持一致。最终的结果是什么? + + + + Then they throw it over the wall to operations to "figure out how to run this." Operations then works diligently to make a slew of changes to align the software with their infrastructure. And what's the end result? -Dev and operations teams really do work differently: I know because I've worked on both sides. We incent them differently. Developers are rewarded for changing and creating, while operations pros are rewarded for reducing cost and ensuring security. We put them in different groups and generally minimize interaction. And the roles typically attract technical people who think quite differently. This situation sets IT up to fail. You have to be willing to break down these barriers. -Think of what has traditionally happened. You throw pieces over the wall, then the business throws requirements over the wall because they are operating in "house-buying" mode: "We'll see you in 9 months." Developers build to those requirements and make changes as needed for technical constraints. Then they throw it over the wall to operations to "figure out how to run this." Operations then works diligently to make a slew of changes to align the software with their infrastructure. And what's the end result? More often than not, the end result isn't even recognizable to the business when they see it in its final glory. We've watched this pattern play out time and time again in our industry for the better part of two decades. It's time for a change. From d2a650e38e1b465dfaaf9ac7d66b2692119c6733 Mon Sep 17 00:00:00 2001 From: Frank Jia <474165491@qq.com> Date: Sun, 22 Sep 2019 14:34:47 +0800 Subject: [PATCH 07/21] Update 20180117 How technology changes the rules for doing agile.md --- ...ology changes the rules for doing agile.md | 29 +++++++++---------- 1 file changed, 13 insertions(+), 16 deletions(-) diff --git a/translated/tech/20180117 How technology changes the rules for doing agile.md b/translated/tech/20180117 How technology changes the rules for doing agile.md index 415ac6d29e..40f7ef3f66 100644 --- a/translated/tech/20180117 How technology changes the rules for doing agile.md +++ b/translated/tech/20180117 How technology changes the rules for doing agile.md @@ -31,25 +31,22 @@ DevOps使得许多试图将这种工作方式扩展到更大范围的团队感 开发和运维团队的工作方式确实不同：我之所以知道这一点是因为我曾经从事过这两方面的工作。我们往往会用不同的方式来激励他们，开发人员会因为更改和创建而获得奖励，而运维专家则会因降低成本和确保安全性而获得奖励。我们会把他们分成不同的小组，并且尽量减少互动。而这些角色通常会吸引那些想法完全不同的技术人员。但是这样的解决方案注定会失败，你必须打破横亘在开发和运维之间的藩篱。 -想想传统情况下会发生什么。业务会把需求扔过墙，这是因为他们在“买房”模式下运作：“我们9个月后见。”开发人员根据这些需求进行开发，并根据技术约束的需要进行更改。然后，他们把它扔过墙传递给运维人员，并说一句“搞清楚如何运行这个软件”。 +想想传统情况下会发生什么。业务会把需求扔过墙，这是因为他们在“买房”模式下运作：“我们9个月后见。”开发人员根据这些需求进行开发，并根据技术约束的需要进行更改。然后，他们把它扔过墙传递给运维人员，并说一句“搞清楚如何运行这个软件”。然后，运维人员勤就会奋地进行大量更改，使软件与基础设施保持一致。然而，最终的结果是什么呢？ -“找出如何运行这个。”然后，操作人员勤奋地进行大量更改，使软件与其基础设施保持一致。最终的结果是什么? +通常情况下，当业务人员看到需求实现的最终结果时甚至根本辨认不出。在过去20年的大部分时间里，我们一次又一次地目睹了这种模式在软件行业中上演。而现在，是时候改变了。 + +Linux容器能够真正地解决这样的问题，这是因为容器缩小了开发和运维之间的间隙。容器技术允许两个团队共同理解和设计所有的关键需求，但仍然独立地履行各自团队的职责。基本上，我们去掉了开发人员和运维人员之间的电话游戏。 + +因为容器技术，我们可以使得运维团队的规模更小，但依旧能够承担起数百万应用程序的运维工作，并且能够使得开发团队可以更加快速地根据需要更改软件。(在较大的组织中，所需的速度可能比运维人员的响应速度更快。) + +使用容器，您可以将所需要交付的内容与它运行的位置分开。你的运维团队只需要负责运行容器的主机和安全的内存占用，仅此而已。这意味着什么呢？ + +首先，这意味着你现在可以和团队一起实践DevOps了。没错，只需要让团队专注于他们已经拥有的专业知识，而对于容器，只需让团队了解所需集成依赖关系的必要知识即可。 + +如果你想要重新训练每个人，往往会收效甚微。 - - Then they throw it over the wall to operations to "figure out how to run this." Operations then works diligently to make a slew of changes to align the software with their infrastructure. And what's the end result? - - - -More often than not, the end result isn't even recognizable to the business when they see it in its final glory. We've watched this pattern play out time and time again in our industry for the better part of two decades. It's time for a change. - -It's Linux containers that truly crack the problem - because containers close the gap between development and operations. They allow both teams to understand and design to all of the critical requirements, but still uniquely fulfill their team's responsibilities. Basically, we take out the telephone game between developers and operations. With containers, we can have smaller operations teams, even teams responsible for millions of applications, but development teams that can change software as quickly as needed. (In larger organizations, the desired pace may be faster than humans can respond on the operations side.) - -With containers, you're separating what is delivered from where it runs. Your operations teams are responsible for the host that will run the containers and the security footprint, and that's all. What does this mean? - -First, it means you can get going on DevOps now, with the team you have. That's right. Keep teams focused on the expertise they already have: With containers, just teach them the bare minimum of the required integration dependencies. - -If you try and retrain everyone, no one will be that good at anything. Containers let teams interact, but alongside a strong boundary, built around each team's strengths. Your devs know what needs to be consumed, but don't need to know how to make it run at scale. Ops teams know the core infrastructure, but don't need to know the minutiae of the app. Also, Ops teams can update apps to address new security implications, before you become the next trending data breach story. +容器技术允许团队之间进行交互，但同时也会为每个团队提供一个围绕该团队优势而构建的强大边界。开发人员会知道需要消耗什么，但不需要知道如何使其大规模运行。运维团队了解核心基础设施，但不需要了解应用程序的细节。此外，运维团队也可以通过更新应用程序来解决新的安全问题，以免你成为下一个数据泄露的热门话题。 Teaching a large IT organization of say 30,000 people both ops and devs skills? It would take you a decade. You don't have that kind of time. From cc35826d14c531f837ca6a0c9c7d544139496e55 Mon Sep 17 00:00:00 2001 From: Frank Jia <474165491@qq.com> Date: Sun, 22 Sep 2019 14:44:37 +0800 Subject: [PATCH 08/21] Update 20180117 How technology changes the rules for doing agile.md --- ...ow technology changes the rules for doing agile.md | 11 ++++------- 1 file changed, 4 insertions(+), 7 deletions(-) diff --git a/translated/tech/20180117 How technology changes the rules for doing agile.md b/translated/tech/20180117 How technology changes the rules for doing agile.md index 40f7ef3f66..64782d66c3 100644 --- a/translated/tech/20180117 How technology changes the rules for doing agile.md +++ b/translated/tech/20180117 How technology changes the rules for doing agile.md @@ -43,16 +43,13 @@ Linux容器能够真正地解决这样的问题，这是因为容器缩小了开 首先，这意味着你现在可以和团队一起实践DevOps了。没错，只需要让团队专注于他们已经拥有的专业知识，而对于容器，只需让团队了解所需集成依赖关系的必要知识即可。 -如果你想要重新训练每个人，往往会收效甚微。 +如果你想要重新训练每个人，往往会收效甚微。容器技术允许团队之间进行交互，但同时也会为每个团队提供一个围绕该团队优势而构建的强大边界。开发人员会知道需要消耗什么，但不需要知道如何使其大规模运行。运维团队了解核心基础设施，但不需要了解应用程序的细节。此外，运维团队也可以通过更新应用程序来解决新的安全问题，以免你成为下一个数据泄露的热门话题。 +想要为一个大型IT组织，比如30000人的团队教授运维和开发技能？那或许需要花费你十年的时间，而你可能并没有那么多时间。 -容器技术允许团队之间进行交互，但同时也会为每个团队提供一个围绕该团队优势而构建的强大边界。开发人员会知道需要消耗什么，但不需要知道如何使其大规模运行。运维团队了解核心基础设施，但不需要了解应用程序的细节。此外，运维团队也可以通过更新应用程序来解决新的安全问题，以免你成为下一个数据泄露的热门话题。 +当人们谈论“构建新的云原生应用程序将帮助我们摆脱这个问题”时，请批判性地进行思考。你可以在10个人的团队中构建云原生应用程序，但这对《财富》杂志前1000强的企业而言或许并不适用。除非你不再需要依赖现有的团队，否则你无法一个接一个地构建新的微服务：你最终将得到一个竖井式的组织。这是一个诱人的想法，但你不能指望这些应用程序来重新定义你的业务。我还没见过哪家公司能在如此大规模的并行开发中获得成功。IT预算已经受到限制；在很长一段时间内将预算翻倍甚至三倍是不现实的。 -Teaching a large IT organization of say 30,000 people both ops and devs skills? It would take you a decade. You don't have that kind of time. - -When people talk about "building new, cloud-native apps will get us out of this problem," think critically. You can build cloud-native apps in 10-person teams, but that doesn't scale for a Fortune 1000 company. You can't just build new microservices one by one until you're somehow not reliant on your existing team: You'll end up with a siloed organization. It's an alluring idea, but you can't count on these apps to redefine your business. I haven't met a company that could fund parallel development at this scale and succeed. IT budgets are already constrained; doubling or tripling them for an extended period of time just isn't realistic. - -### When the remarkable happens: Hello, velocity +### 当奇迹发生时: 你好, 速度 Linux containers were made to scale. Once you start to do so, [orchestration tools like Kubernetes come into play][6] - because you'll need to run thousands of containers. Applications won't consist of just a single container, they will depend on many different pieces, all running on containers, all running as a unit. If they don't, your apps won't run well in production. From 402f915daa29014e228d8346e5194581448a4a8c Mon Sep 17 00:00:00 2001 From: laingke Date: Sun, 22 Sep 2019 14:56:50 +0800 Subject: [PATCH 09/21] 20181227-Linux-commands-for-measuring-disk-activity translated --- ...ux commands for measuring disk activity.md | 42 +++++++++---------- 1 file changed, 21 insertions(+), 21 deletions(-) diff --git a/sources/tech/20181227 Linux commands for measuring disk activity.md b/sources/tech/20181227 Linux commands for measuring disk activity.md index d15643adae..1c93b212c4 100644 --- a/sources/tech/20181227 Linux commands for measuring disk activity.md +++ b/sources/tech/20181227 Linux commands for measuring disk activity.md @@ -7,16 +7,16 @@ [#]: via: (https://www.networkworld.com/article/3330497/linux/linux-commands-for-measuring-disk-activity.html) [#]: author: (Sandra Henry-Stocker https://www.networkworld.com/author/Sandra-Henry_Stocker/) -Linux commands for measuring disk activity +用于测量磁盘活动的 Linux 命令 ====== ![](https://images.idgesg.net/images/article/2018/12/tape-measure-100782593-large.jpg) -Linux systems provide a handy suite of commands for helping you see how busy your disks are, not just how full. In this post, we examine five very useful commands for looking into disk activity. Two of the commands (iostat and ioping) may have to be added to your system, and these same two commands require you to use sudo privileges, but all five commands provide useful ways to view disk activity. +Linux 系统提供了一套方便的命令，帮助您查看磁盘有多忙，而不仅仅是磁盘有多满。在本文中，我们将研究五个非常有用的命令，用于查看磁盘活动。其中两个命令（iostat 和 ioping）可能必须添加到您的系统中，这两个相同的命令要求您使用 sudo 特权，但是这五个命令都提供了查看磁盘活动的有用方法。 -Probably one of the easiest and most obvious of these commands is **dstat**. +这些命令中最简单、最明显的一个可能是 **dstat** 了。 ### dtstat -In spite of the fact that the **dstat** command begins with the letter "d", it provides stats on a lot more than just disk activity. If you want to view just disk activity, you can use the **-d** option. As shown below, you’ll get a continuous list of disk read/write measurements until you stop the display with a ^c. Note that after the first report, each subsequent row in the display will report disk activity in the following time interval, and the default is only one second. +尽管 **dstat** 命令以字母 "d" 开头，但它提供的统计信息远远不止磁盘活动。如果您只想查看磁盘活动，可以使用 **-d** 选项。如下所示，您将得到一个磁盘读/写测量值的连续列表，直到使用 a ^c 停止显示为止。注意，在第一个报告之后，显示中的每个后续行将在接下来的时间间隔内报告磁盘活动，缺省值仅为一秒。 ``` $ dstat -d @@ -29,7 +29,7 @@ $ dstat -d 0 0 ^C ``` -Including a number after the -d option will set the interval to that number of seconds. +在 -d 选项后面包含一个数字将把间隔设置为其秒数。 ``` $ dstat -d 10 @@ -41,9 +41,9 @@ $ dstat -d 10 0 9011B ^C ``` -Notice that the reported data may be shown in a number of different units — e.g., M (megabytes), k (kilobytes), and B (bytes). +请注意，报告的数据可能以许多不同的单位显示——例如，M (megabytes), k (kilobytes), and B (bytes). -Without options, the dstat command is going to show you a lot of other information as well — indicating how the CPU is spending its time, displaying network and paging activity, and reporting on interrupts and context switches. +如果没有选项，dstat 命令还将显示许多其他信息——指示 CPU 如何使用时间、显示网络和分页活动、报告中断和上下文切换。 ``` $ dstat @@ -55,11 +55,11 @@ usr sys idl wai stl| read writ| recv send| in out | int csw 0 1 99 0 0| 0 16k| 64B 468B| 0 0 | 64 81 ^C ``` -The dstat command provides valuable insights into overall Linux system performance, pretty much replacing a collection of older tools, such as vmstat, netstat, iostat, and ifstat, with a flexible and powerful command that combines their features. For more insight into the other information that the dstat command can provide, refer to this post on the [dstat][1] command. +dstat 命令提供了关于整个 Linux 系统性能的有价值的见解，几乎可以用它灵活而功能强大的命令来代替 vmstat，netstat，iostat 和 ifstat 等较旧的工具集合，该命令结合了这些旧工具的功能。要深入了解 dstat 命令可以提供的其它信息，请参阅这篇关于 [dstat][1] 命令的文章。 ### iostat -The iostat command helps monitor system input/output device loading by observing the time the devices are active in relation to their average transfer rates. It's sometimes used to evaluate the balance of activity between disks. +iostat 命令通过观察设备活动的时间与其平均传输速率之间的关系，帮助监视系统输入/输出设备的加载情况。它有时用于评估磁盘之间的活动平衡。 ``` $ iostat @@ -90,7 +90,7 @@ loop15 0.01 0.01 0.00 20026 0 loop16 0.00 0.00 0.00 24 0 ``` -Of course, all the stats provided on Linux loop devices can clutter the display when you want to focus solely on your disks. The command, however, does provide the **-p** option, which allows you to just look at your disks — as shown in the commands below. +当然，当您只想关注磁盘时，Linux loop 设备上提供的所有统计信息都会使结果显得杂乱无章。但是，该命令也确实提供了 **-p** 选项，该选项使您可以仅查看磁盘——如以下命令所示。 ``` $ iostat -p sda @@ -104,9 +104,9 @@ sda 1.06 0.89 72.54 2843737 232815784 sda1 1.04 0.88 72.54 2821733 232815784 ``` -Note that **tps** refers to transfers per second. +请注意 **tps** 是指每秒的传输量。 -You can also get iostat to provide repeated reports. In the example below, we're getting measurements every five seconds by using the **-d** option. +您还可以让 iostat 提供重复的报告。在下面的示例中，我们使用 **-d** 选项每五秒钟进行一次测量。 ``` $ iostat -p sda -d 5 @@ -121,7 +121,7 @@ sda 0.80 0.00 11.20 0 56 sda1 0.80 0.00 11.20 0 56 ``` -If you prefer to omit the first (stats since boot) report, add a **-y** to your command. +如果您希望省略第一个（自启动以来的统计信息）报告，请在命令中添加 **-y**。 ``` $ iostat -p sda -d 5 -y @@ -132,7 +132,7 @@ sda 0.80 0.00 11.20 0 56 sda1 0.80 0.00 11.20 0 56 ``` -Next, we look at our second disk drive. +接下来，我们看第二个磁盘驱动器。 ``` $ iostat -p sdb @@ -149,7 +149,7 @@ sdb1 0.00 0.01 0.00 35344 0 ### iotop -The **iotop** command is top-like utility for looking at disk I/O. It gathers I/O usage information provided by the Linux kernel so that you can get an idea which processes are most demanding in terms in disk I/O. In the example below, the loop time has been set to 5 seconds. The display will update itself, overwriting the previous output. +**iotop** 命令是类似 top 的实用程序，用于查看磁盘 I/O。它收集 Linux 内核提供的 I/O 使用信息，以便您了解哪些进程在磁盘 I/O 方面的要求最高。在下面的示例中，循环时间被设置为5秒。显示将自动更新，覆盖前面的输出。 ``` $ sudo iotop -d 5 @@ -167,7 +167,7 @@ Current DISK READ: 0.00 B/s | Current DISK WRITE: 12.39 K/s ### ioping -The **ioping** command is an altogether different type of tool, but it can report disk latency — how long it takes a disk to respond to requests — and can be helpful in diagnosing disk problems. +**ioping** 命令是一种完全不同的工具，但是它可以报告磁盘延迟——也就是磁盘响应请求需要多长时间，而这有助于诊断磁盘问题。 ``` $ sudo ioping /dev/sda1 @@ -184,7 +184,7 @@ min/avg/max/mdev = 831.0 us / 947.9 us / 1.17 ms / 158.0 us ### atop -The **atop** command, like **top** provides a lot of information on system performance, including some stats on disk activity. +**atop** 命令，像 **top** 一样提供了大量有关系统性能的信息，包括有关磁盘活动的一些统计信息。 ``` ATOP - butterfly 2018/12/26 17:24:19 37d3h13m------ 10ed @@ -212,7 +212,7 @@ NET | enp0s25 0% | pcki 10 | pcko 8 | si 1 Kbps | so 3 Kbp0.73 ms | 3362 0.00s 0.00s 0K 0K NE 0 0 E - 0% ``` -If you want to look at _just_ the disk stats, you can easily manage that with a command like this: +如果您 _只_ 想查看磁盘统计信息，则可以使用以下命令轻松进行管理： ``` $ atop | grep DSK @@ -228,11 +228,11 @@ DSK | sda | busy 2% | read 0 | write 92 | avio 2.43 ms | ^C ``` -### Being in the know with disk I/O +### 了解磁盘 I/O -Linux provides enough commands to give you good insights into how hard your disks are working and help you focus on potential problems or slowdowns. Hopefully, one of these commands will tell you just what you need to know when it's time to question disk performance. Occasional use of these commands will help ensure that especially busy or slow disks will be obvious when you need to check them. +Linux 提供了足够的命令，可以让您很好地了解磁盘的工作强度，并帮助您关注潜在的问题或慢速。希望这些命令中的一个可以告诉您何时需要质疑磁盘性能。偶尔使用这些命令将有助于确保当您需要检查磁盘，特别是忙碌或缓慢的磁盘时可以显而易见地发现它们。 -Join the Network World communities on [Facebook][2] and [LinkedIn][3] to comment on topics that are top of mind. +加入 [Facebook][2] 和 [LinkedIn][3] 上的 Network World 社区，对最重要的话题发表评论。 -------------------------------------------------------------------------------- From 4c1fd3b612207b42d3d07ed0339a6a40ff8c8e72 Mon Sep 17 00:00:00 2001 From: laingke Date: Sun, 22 Sep 2019 15:00:15 +0800 Subject: [PATCH 10/21] 20181227-Linux-commands-for-measuring-disk-activity moved to translated directory --- .../tech/20181227 Linux commands for measuring disk activity.md | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename {sources => translated}/tech/20181227 Linux commands for measuring disk activity.md (100%) diff --git a/sources/tech/20181227 Linux commands for measuring disk activity.md b/translated/tech/20181227 Linux commands for measuring disk activity.md similarity index 100% rename from sources/tech/20181227 Linux commands for measuring disk activity.md rename to translated/tech/20181227 Linux commands for measuring disk activity.md From 95d6fcbf809574d09cf9d3fc2dabed86833a8c6b Mon Sep 17 00:00:00 2001 From: Frank Jia <474165491@qq.com> Date: Sun, 22 Sep 2019 15:04:56 +0800 Subject: [PATCH 11/21] Update 20180117 How technology changes the rules for doing agile.md --- ...w technology changes the rules for doing agile.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/translated/tech/20180117 How technology changes the rules for doing agile.md b/translated/tech/20180117 How technology changes the rules for doing agile.md index 64782d66c3..a18794c83f 100644 --- a/translated/tech/20180117 How technology changes the rules for doing agile.md +++ b/translated/tech/20180117 How technology changes the rules for doing agile.md @@ -51,17 +51,17 @@ Linux容器能够真正地解决这样的问题，这是因为容器缩小了开 ### 当奇迹发生时: 你好, 速度 -Linux containers were made to scale. Once you start to do so, [orchestration tools like Kubernetes come into play][6] - because you'll need to run thousands of containers. Applications won't consist of just a single container, they will depend on many different pieces, all running on containers, all running as a unit. If they don't, your apps won't run well in production. +Linux容器就是为扩容而生的。一旦你开始这样做，[Kubernetes之类的编制工具就会发挥作用][6]，这是因为你将需要运行数千个容器。应用程序将不仅仅由一个容器组成，它们将依赖于许多不同的部分，所有的部分都会作为一个单元运行在容器上。如果不这样做，你的应用程序将无法在生产环境中很好地运行。 -Think of how many small gears and levers come together to run your business: The same is true for any application. Developers are responsible for all the pulleys and levers in the application. (You could have an integration nightmare if developers don't own those pieces.) At the same time, your operations team is responsible for all the pulleys and levers that make up your infrastructure, whether on-premises or in the cloud. With Kubernetes as an abstraction, your operations team can give the application the fuel it needs to run - without being experts on all those pieces. +思考一下有多少小滑轮和杠杆组合在一起来支撑你的业务，对于任何应用程序都是如此。开发人员负责应用程序中的所有滑轮和杠杆。(如果开发人员没有这些组件，您可能会在集成时做噩梦。)与此同时，无论是在线下还是在云上，运维团队都会负责构成基础设施的所有滑轮和杠杆。做一个较为抽象的比喻，使用Kubernetes，你的运维团队就可以为应用程序提供运行所需的燃料，但又不必成为所有方面的专家。 -Developers get to experiment. The operations team keeps infrastructure secure and reliable. This combination opens up the business to take small risks that lead to innovation. Instead of having to make only a couple of bet-the-farm size bets, real experimentation happens inside the company, incrementally and quickly. +开发人员可以进行实验，运维团队则保持基础设施的安全和可靠。这样的组合使得企业敢于承担小风险，从而实现创新。不同于打几个孤注一掷的赌，公司中真正的实验往往是循序渐进的和快速的。 -In my experience, this is where the remarkable happens inside organizations: Because people say "How do we change planning to actually take advantage of this ability to experiment?" It forces agile planning. +从个人经验来看，这就是组织内部发生的显著变化：因为人们说：“我们如何通过改变计划来真正地利用这种能力进行实验？”它强制执行敏捷计划。 -For example, KeyBank, which uses a DevOps model, containers, and Kubernetes, now deploys code every day. (Watch this [video][7] in which John Rzeszotarski, director of Continuous Delivery and Feedback at KeyBank, explains the change.) Similarly, Macquarie Bank uses DevOps and containers to put something in production every day. +举个例子，使用DevOps模型、容器和Kubernetes的KeyBank如今每天都会部署代码。(观看视频[7]，其中主导了KeyBank持续交付和反馈的John Rzeszotarski将解释这一变化。)类似地，Macquarie银行也借助DevOps和容器技术每天将一些东西投入生产环境。 -Once you push software every day, it changes every aspect of how you plan - and [accelerates the rate of change to the business][8]. "An idea can get to a customer in a day," says Luis Uguina, CDO of Macquarie's banking and financial services group. (See this [case study][9] on Red Hat's work with Macquarie Bank). +一旦你每天都推出软件，它就会改变你计划的每一个方面，并且会[加速业务的变化速度][8]。Macquarie银行和金融服务集团的CDO，Luis Uguina表示：“创意可以在一天内触达客户。”(参见[9]对Red Hat与Macquarie银行合作的案例研究)。 ### The right time to build something great From e3fd798a71af5cd33e590c4a04f10d0270b6984d Mon Sep 17 00:00:00 2001 From: Frank Jia <474165491@qq.com> Date: Sun, 22 Sep 2019 15:16:06 +0800 Subject: [PATCH 12/21] Update 20180117 How technology changes the rules for doing agile.md --- ...w technology changes the rules for doing agile.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/translated/tech/20180117 How technology changes the rules for doing agile.md b/translated/tech/20180117 How technology changes the rules for doing agile.md index a18794c83f..ddf933c4ff 100644 --- a/translated/tech/20180117 How technology changes the rules for doing agile.md +++ b/translated/tech/20180117 How technology changes the rules for doing agile.md @@ -63,17 +63,17 @@ Linux容器就是为扩容而生的。一旦你开始这样做，[Kubernetes之 一旦你每天都推出软件，它就会改变你计划的每一个方面，并且会[加速业务的变化速度][8]。Macquarie银行和金融服务集团的CDO，Luis Uguina表示：“创意可以在一天内触达客户。”(参见[9]对Red Hat与Macquarie银行合作的案例研究)。 -### The right time to build something great +### 是时候去创造一些伟大的东西了 -The Macquarie example demonstrates the power of velocity. How would that change your approach to your business? Remember, Macquarie is not a startup. This is the type of disruptive power that CIOs face, not only from new market entrants but also from established peers. +Macquarie的例子说明了速度的力量。这将如何改变你的经营方式？记住，Macquarie不是一家初创企业。这是CIO们所面临的颠覆性力量，它不仅来自新的市场进入者，也来自老牌同行。 -The developer freedom also changes the talent equation for CIOs running agile shops. Suddenly, individuals within huge companies (even those not in the hottest industries or geographies) can have great impact. Macquarie uses this dynamic as a recruiting tool, promising developers that all new hires will push something live within the first week. +开发人员的自由还改变了运营敏捷商店的CIO们的人才方程式。突然之间，大公司里的个体(即使不是在最热门的行业或地区)也可以产生巨大的影响。Macquarie利用这一变动作为招聘工具，并向开发人员承诺，所有新招聘的员工将会在第一周内推出新产品。 -At the same time, in this day of cloud-based compute and storage power, we have more infrastructure available than ever. That's fortunate, considering the [leaps that machine learning and AI tools will soon enable][10]. +与此同时，在这个基于云的计算和存储能力的时代，我们比以往任何时候都拥有更多可用的基础设施。考虑到[机器学习和人工智能工具将很快实现的飞跃][10]，这是幸运的。 -This all adds up to this being the right time to build something great. Given the pace of innovation in the market, you need to keep building great things to keep customers loyal. So if you've been waiting to place your bet on DevOps, now is the right time. Containers and Kubernetes have changed the rules - in your favor. +所有这些都说明现在正是打造伟大事业的好时机。考虑到市场创新的速度，你需要不断地创造伟大的东西来保持客户的忠诚度。因此，如果你一直在等待将赌注押在DevOps上，那么现在就是正确的时机。容器技术和Kubernetes改变了规则，并且对你有利。 -**Want more wisdom like this, IT leaders? [Sign up for our weekly email newsletter][11].** +**想要获取更多这样的智慧吗, IT领导者? [订阅每周邮件][11].** -------------------------------------------------------------------------------- From 139d6cff6c2725240bbe9696e0a81cb0c2037392 Mon Sep 17 00:00:00 2001 From: Frank Jia <474165491@qq.com> Date: Sun, 22 Sep 2019 15:19:27 +0800 Subject: [PATCH 13/21] Update 20180117 How technology changes the rules for doing agile.md --- ...180117 How technology changes the rules for doing agile.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/translated/tech/20180117 How technology changes the rules for doing agile.md b/translated/tech/20180117 How technology changes the rules for doing agile.md index ddf933c4ff..b5c1612912 100644 --- a/translated/tech/20180117 How technology changes the rules for doing agile.md +++ b/translated/tech/20180117 How technology changes the rules for doing agile.md @@ -3,11 +3,11 @@ ![](https://enterprisersproject.com/sites/default/files/styles/620x350/public/images/CIO%20Containers%20Ecosystem.png?itok=lDTaYXzk) -越来越多的公司正因为一个非常明显的原因开始尝试敏捷和[DevOps][1]: 企业需要借助更快的速度和更多的实验来提供创新和竞争性优势。而DevOps将帮助我们得到所想要达到的创新速度。但是，在小团队或初创企业中实践DevOps和进行大规模实践完全是两码事。我们都明白这样的一个事实，那就是在10人的跨职能团队中能够很好地解决问题的方案，当将同样的模式应用到100人的团队中时就可能无法奏效。这条道路是如此艰难，以至于IT领导者很容易将敏捷方法的推行再推迟一年。 +越来越多的企业正因为一个非常明显的原因开始尝试敏捷和[DevOps][1]: 企业需要通过更快的速度和更多的实验为创新和竞争性提供优势。而DevOps将帮助我们得到所需的创新速度。但是，在小团队或初创企业中实践DevOps与进行大规模实践完全是两码事。我们都明白这样的一个事实，那就是在10人的跨职能团队中能够很好地解决问题的方案，当将相同的模式应用到100人的团队中时就可能无法奏效。这条道路是如此艰难，以至于IT领导者很容易将敏捷方法的推行再推迟一年。 但那样的时代已经结束了。如果你已经尝试过，但是没有成功，那么现在是时候重新开始了。 -直到现在，DevOps需要为许多组织提供个性化的解决方案，因此往往需要进行大量的调整以及额外的工作。但在今天，[Linux容器][2]和Kubernetes正在推动DevOps工具和过程的标准化。而这样的标准化将会加速整个软件开发过程。因此，我们用来实践DevOps工作方式的技术最终能够满足我们加快软件开发速度的愿望。 +直到现在，DevOps需要为许多组织提供个性化的解决方案，因此往往需要进行大量的调整以及付出额外的工作。但在今天，[Linux容器][2]和Kubernetes正在推动DevOps工具和过程的标准化。而这样的标准化将会加速整个软件开发过程。因此，我们用来实践DevOps工作方式的技术最终能够满足我们加快软件开发速度的愿望。 Linux容器和[Kubernetes][3]正在改变团队交互的方式。此外，你可以在Kubernetes平台上运行任何能够在Linux运行的应用程序。这意味着什么呢？你可以运行大量的企业及应用程序(甚至可以解决以前令人烦恼的Windows和Linux之间的协调问题)。最后，容器和Kubernetes将能够满足未来所有运行内容的需求。它们正在经受着未来的考验，以应对机器学习、人工智能和分析工作等下一代解决问题工具。 From ecaeb0fee67b1d748cfb7885977b569ca1fb92cc Mon Sep 17 00:00:00 2001 From: Frank Jia <474165491@qq.com> Date: Sun, 22 Sep 2019 15:23:16 +0800 Subject: [PATCH 14/21] Update 20180117 How technology changes the rules for doing agile.md --- ...w technology changes the rules for doing agile.md | 12 +++++------- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/translated/tech/20180117 How technology changes the rules for doing agile.md b/translated/tech/20180117 How technology changes the rules for doing agile.md index b5c1612912..1d7fec9083 100644 --- a/translated/tech/20180117 How technology changes the rules for doing agile.md +++ b/translated/tech/20180117 How technology changes the rules for doing agile.md @@ -19,19 +19,17 @@ Linux容器和[Kubernetes][3]正在改变团队交互的方式。此外，你可 ### 容器技术如何改变团队的工作？ -DevOps使得许多试图将这种工作方式扩展到更大范围的团队感到沮丧。即使许多IT(和业务)人员之前都听说过语言、框架、模型(如DevOps)等承诺将会彻底应用程序开发和IT过程的全部相关内容，但他们还是对于敏捷持怀疑态度。 +DevOps使得许多试图将这种工作方式扩展到更大范围的团队感到沮丧。即使许多IT(和业务)人员之前都听说过敏捷相关的语言、框架、模型(如DevOps)等承诺将会彻底应用程序开发和IT过程的全部相关内容，但他们还是对此持怀疑态度。 **[ 想要获取来自其他CIO们的建议吗？不放参考下我们的综述性资源, [DevOps: The IT Leader's Guide][5]. ]** -向你的涉众“推销”快速开发冲刺也不是一件容易的事情。想象一下，如果你以这种方式买了一栋房子： +向你的涉众“推销”快速开发冲刺也不是一件容易的事情。想象一下，如果你以这种方式买了一栋房子：你将不再需要向开发商支付固定的金额，而是会得到这样的信息：“我们将在4周内浇筑完地基，其成本是X，之后再搭建房屋框架和铺设电路，但是我们现在只能够知道地基完成的时间表。”人们已经习惯了买房子的时候有一个预先的价格和交付时间表。 -你将不再需要向开发商支付固定的金额，而是会得到这样的信息：“我们将在4周内浇筑完地基，其成本是X，之后再搭建房屋框架和铺设电路，但是我们现在只能够知道地基完成的时间表。”人们已经习惯了买房子的时候有一个预先的价格和交付时间表。 +挑战在于构建软件与构建房屋不同。同一个建筑商往往建造了成千上万个完全相同的房子，而软件项目从来都各不相同。这是你要克服的第一个障碍。 -挑战在于构建软件与构建房屋不同。同一个建筑商建造了成千上万个完全相同的房子，而软件项目从来都各不相同。这是你要克服的第一个障碍。 +开发和运维团队的工作方式确实不同，我之所以知道这一点是因为我曾经从事过这两方面的工作。企业往往会用不同的方式来激励他们，开发人员会因为更改和创建而获得奖励，而运维专家则会因降低成本和确保安全性而获得奖励。我们会把他们分成不同的小组，并且尽量减少互动。而这些角色通常会吸引那些思维方式完全不同的技术人员。但是这样的解决方案注定会失败，你必须打破横亘在开发和运维之间的藩篱。 -开发和运维团队的工作方式确实不同：我之所以知道这一点是因为我曾经从事过这两方面的工作。我们往往会用不同的方式来激励他们，开发人员会因为更改和创建而获得奖励，而运维专家则会因降低成本和确保安全性而获得奖励。我们会把他们分成不同的小组，并且尽量减少互动。而这些角色通常会吸引那些想法完全不同的技术人员。但是这样的解决方案注定会失败，你必须打破横亘在开发和运维之间的藩篱。 - -想想传统情况下会发生什么。业务会把需求扔过墙，这是因为他们在“买房”模式下运作：“我们9个月后见。”开发人员根据这些需求进行开发，并根据技术约束的需要进行更改。然后，他们把它扔过墙传递给运维人员，并说一句“搞清楚如何运行这个软件”。然后，运维人员勤就会奋地进行大量更改，使软件与基础设施保持一致。然而，最终的结果是什么呢？ +想想传统情况下会发生什么。业务会把需求扔过墙，这是因为他们在“买房”模式下运作，并且说上一句“我们9个月后见。”开发人员根据这些需求进行开发，并根据技术约束的需要进行更改。然后，他们把它扔过墙传递给运维人员，并说一句“搞清楚如何运行这个软件”。然后，运维人员勤就会奋地进行大量更改，使软件与基础设施保持一致。然而，最终的结果是什么呢？ 通常情况下，当业务人员看到需求实现的最终结果时甚至根本辨认不出。在过去20年的大部分时间里，我们一次又一次地目睹了这种模式在软件行业中上演。而现在，是时候改变了。 From 12502ffe9563c22ecf073ebafe4891720d87d3bf Mon Sep 17 00:00:00 2001 From: Frank Jia <474165491@qq.com> Date: Sun, 22 Sep 2019 15:24:27 +0800 Subject: [PATCH 15/21] Update 20180117 How technology changes the rules for doing agile.md --- ...20180117 How technology changes the rules for doing agile.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/translated/tech/20180117 How technology changes the rules for doing agile.md b/translated/tech/20180117 How technology changes the rules for doing agile.md index 1d7fec9083..4c5b66f133 100644 --- a/translated/tech/20180117 How technology changes the rules for doing agile.md +++ b/translated/tech/20180117 How technology changes the rules for doing agile.md @@ -53,7 +53,7 @@ Linux容器就是为扩容而生的。一旦你开始这样做，[Kubernetes之 思考一下有多少小滑轮和杠杆组合在一起来支撑你的业务，对于任何应用程序都是如此。开发人员负责应用程序中的所有滑轮和杠杆。(如果开发人员没有这些组件，您可能会在集成时做噩梦。)与此同时，无论是在线下还是在云上，运维团队都会负责构成基础设施的所有滑轮和杠杆。做一个较为抽象的比喻，使用Kubernetes，你的运维团队就可以为应用程序提供运行所需的燃料，但又不必成为所有方面的专家。 -开发人员可以进行实验，运维团队则保持基础设施的安全和可靠。这样的组合使得企业敢于承担小风险，从而实现创新。不同于打几个孤注一掷的赌，公司中真正的实验往往是循序渐进的和快速的。 +开发人员进行实验，运维团队则保持基础设施的安全和可靠。这样的组合使得企业敢于承担小风险，从而实现创新。不同于打几个孤注一掷的赌，公司中真正的实验往往是循序渐进的和快速的。 从个人经验来看，这就是组织内部发生的显著变化：因为人们说：“我们如何通过改变计划来真正地利用这种能力进行实验？”它强制执行敏捷计划。 From 6a1d71012f1dbd4b408581f392d17773eb05e038 Mon Sep 17 00:00:00 2001 From: Frank Jia <474165491@qq.com> Date: Sun, 22 Sep 2019 16:12:17 +0800 Subject: [PATCH 16/21] Delete 20180117 How technology changes the rules for doing agile.md --- ...ology changes the rules for doing agile.md | 95 ------------------- 1 file changed, 95 deletions(-) delete mode 100644 sources/talk/20180117 How technology changes the rules for doing agile.md diff --git a/sources/talk/20180117 How technology changes the rules for doing agile.md b/sources/talk/20180117 How technology changes the rules for doing agile.md deleted file mode 100644 index 1b67935509..0000000000 --- a/sources/talk/20180117 How technology changes the rules for doing agile.md +++ /dev/null @@ -1,95 +0,0 @@ -How technology changes the rules for doing agile -====== - -![](https://enterprisersproject.com/sites/default/files/styles/620x350/public/images/CIO%20Containers%20Ecosystem.png?itok=lDTaYXzk) - -More companies are trying agile and [DevOps][1] for a clear reason: Businesses want more speed and more experiments - which lead to innovations and competitive advantage. DevOps helps you gain that speed. But doing DevOps in a small group or startup and doing it at scale are two very different things. Any of us who've worked in a cross-functional group of 10 people, come up with a great solution to a problem, and then tried to apply the same patterns across a team of 100 people know the truth: It often doesn't work. This path has been so hard, in fact, that it has been easy for IT leaders to put off agile methodology for another year. - -But that time is over. If you've tried and stalled, it's time to jump back in. - -Until now, DevOps required customized answers for many organizations - lots of tweaks and elbow grease. But today, [Linux containers ][2]and Kubernetes are fueling standardization of DevOps tools and processes. That standardization will only accelerate. The technology we are using to practice the DevOps way of working has finally caught up with our desire to move faster. - -Linux containers and [Kubernetes][3] are changing the way teams interact. Moreover, on the Kubernetes platform, you can run any application you now run on Linux. What does that mean? You can run a tremendous number of enterprise apps (and handle even previously vexing coordination issues between Windows and Linux.) Finally, containers and Kubernetes will handle almost all of what you'll run tomorrow. They're being future-proofed to handle machine learning, AI, and analytics workloads - the next wave of problem-solving tools. - -**[ See our related article,[4 container adoption patterns: What you need to know. ] ][4]** - -Think about machine learning, for example. Today, people still find the patterns in much of an enterprise's data. When machines find the patterns (think machine learning), your people will be able to act on them faster. With the addition of AI, machines can not only find but also act on patterns. Today, with people doing everything, three weeks is an aggressive software development sprint cycle. With AI, machines can change code multiple times per second. Startups will use that capability - to disrupt you. - -Consider how fast you have to be to compete. If you can't make a leap of faith now to DevOps and a one week cycle, think of what will happen when that startup points its AI-fueled process at you. It's time to move to the DevOps way of working now, or get left behind as your competitors do. - -### How are containers changing how teams work? - -DevOps has frustrated many groups trying to scale this way of working to a bigger group. Many IT (and business) people are suspicious of agile: They've heard it all before - languages, frameworks, and now models (like DevOps), all promising to revolutionize application development and IT process. - -**[ Want DevOps advice from other CIOs? See our comprehensive resource, [DevOps: The IT Leader's Guide][5]. ]** - -It's not easy to "sell" quick development sprints to your stakeholders, either. Imagine if you bought a house this way. You're not going to pay a fixed amount to your builder anymore. Instead, you get something like: "We'll pour the foundation in 4 weeks and it will cost x. Then we'll frame. Then we'll do electrical. But we only know the timing on the foundation right now." People are used to buying homes with a price up front and a schedule. - -The challenge is that building software is not like building a house. The same builder builds thousands of houses that are all the same. Software projects are never the same. This is your first hurdle to get past. - -Dev and operations teams really do work differently: I know because I've worked on both sides. We incent them differently. Developers are rewarded for changing and creating, while operations pros are rewarded for reducing cost and ensuring security. We put them in different groups and generally minimize interaction. And the roles typically attract technical people who think quite differently. This situation sets IT up to fail. You have to be willing to break down these barriers. - -Think of what has traditionally happened. You throw pieces over the wall, then the business throws requirements over the wall because they are operating in "house-buying" mode: "We'll see you in 9 months." Developers build to those requirements and make changes as needed for technical constraints. Then they throw it over the wall to operations to "figure out how to run this." Operations then works diligently to make a slew of changes to align the software with their infrastructure. And what's the end result? - -More often than not, the end result isn't even recognizable to the business when they see it in its final glory. We've watched this pattern play out time and time again in our industry for the better part of two decades. It's time for a change. - -It's Linux containers that truly crack the problem - because containers close the gap between development and operations. They allow both teams to understand and design to all of the critical requirements, but still uniquely fulfill their team's responsibilities. Basically, we take out the telephone game between developers and operations. With containers, we can have smaller operations teams, even teams responsible for millions of applications, but development teams that can change software as quickly as needed. (In larger organizations, the desired pace may be faster than humans can respond on the operations side.) - -With containers, you're separating what is delivered from where it runs. Your operations teams are responsible for the host that will run the containers and the security footprint, and that's all. What does this mean? - -First, it means you can get going on DevOps now, with the team you have. That's right. Keep teams focused on the expertise they already have: With containers, just teach them the bare minimum of the required integration dependencies. - -If you try and retrain everyone, no one will be that good at anything. Containers let teams interact, but alongside a strong boundary, built around each team's strengths. Your devs know what needs to be consumed, but don't need to know how to make it run at scale. Ops teams know the core infrastructure, but don't need to know the minutiae of the app. Also, Ops teams can update apps to address new security implications, before you become the next trending data breach story. - -Teaching a large IT organization of say 30,000 people both ops and devs skills? It would take you a decade. You don't have that kind of time. - -When people talk about "building new, cloud-native apps will get us out of this problem," think critically. You can build cloud-native apps in 10-person teams, but that doesn't scale for a Fortune 1000 company. You can't just build new microservices one by one until you're somehow not reliant on your existing team: You'll end up with a siloed organization. It's an alluring idea, but you can't count on these apps to redefine your business. I haven't met a company that could fund parallel development at this scale and succeed. IT budgets are already constrained; doubling or tripling them for an extended period of time just isn't realistic. - -### When the remarkable happens: Hello, velocity - -Linux containers were made to scale. Once you start to do so, [orchestration tools like Kubernetes come into play][6] - because you'll need to run thousands of containers. Applications won't consist of just a single container, they will depend on many different pieces, all running on containers, all running as a unit. If they don't, your apps won't run well in production. - -Think of how many small gears and levers come together to run your business: The same is true for any application. Developers are responsible for all the pulleys and levers in the application. (You could have an integration nightmare if developers don't own those pieces.) At the same time, your operations team is responsible for all the pulleys and levers that make up your infrastructure, whether on-premises or in the cloud. With Kubernetes as an abstraction, your operations team can give the application the fuel it needs to run - without being experts on all those pieces. - -Developers get to experiment. The operations team keeps infrastructure secure and reliable. This combination opens up the business to take small risks that lead to innovation. Instead of having to make only a couple of bet-the-farm size bets, real experimentation happens inside the company, incrementally and quickly. - -In my experience, this is where the remarkable happens inside organizations: Because people say "How do we change planning to actually take advantage of this ability to experiment?" It forces agile planning. - -For example, KeyBank, which uses a DevOps model, containers, and Kubernetes, now deploys code every day. (Watch this [video][7] in which John Rzeszotarski, director of Continuous Delivery and Feedback at KeyBank, explains the change.) Similarly, Macquarie Bank uses DevOps and containers to put something in production every day. - -Once you push software every day, it changes every aspect of how you plan - and [accelerates the rate of change to the business][8]. "An idea can get to a customer in a day," says Luis Uguina, CDO of Macquarie's banking and financial services group. (See this [case study][9] on Red Hat's work with Macquarie Bank). - -### The right time to build something great - -The Macquarie example demonstrates the power of velocity. How would that change your approach to your business? Remember, Macquarie is not a startup. This is the type of disruptive power that CIOs face, not only from new market entrants but also from established peers. - -The developer freedom also changes the talent equation for CIOs running agile shops. Suddenly, individuals within huge companies (even those not in the hottest industries or geographies) can have great impact. Macquarie uses this dynamic as a recruiting tool, promising developers that all new hires will push something live within the first week. - -At the same time, in this day of cloud-based compute and storage power, we have more infrastructure available than ever. That's fortunate, considering the [leaps that machine learning and AI tools will soon enable][10]. - -This all adds up to this being the right time to build something great. Given the pace of innovation in the market, you need to keep building great things to keep customers loyal. So if you've been waiting to place your bet on DevOps, now is the right time. Containers and Kubernetes have changed the rules - in your favor. - -**Want more wisdom like this, IT leaders? [Sign up for our weekly email newsletter][11].** - --------------------------------------------------------------------------------- - -via: https://enterprisersproject.com/article/2018/1/how-technology-changes-rules-doing-agile - -作者：[Matt Hicks][a] -译者：[译者ID](https://github.com/译者ID) -校对：[校对者ID](https://github.com/校对者ID) - -本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出 - -[a]:https://enterprisersproject.com/user/matt-hicks -[1]:https://enterprisersproject.com/tags/devops -[2]:https://www.redhat.com/en/topics/containers?intcmp=701f2000000tjyaAAA -[3]:https://www.redhat.com/en/topics/containers/what-is-kubernetes?intcmp=701f2000000tjyaAAA -[4]:https://enterprisersproject.com/article/2017/8/4-container-adoption-patterns-what-you-need-know?sc_cid=70160000000h0aXAAQ -[5]:https://enterprisersproject.com/devops?sc_cid=70160000000h0aXAAQ -[6]:https://enterprisersproject.com/article/2017/11/how-enterprise-it-uses-kubernetes-tame-container-complexity -[7]:https://www.redhat.com/en/about/videos/john-rzeszotarski-keybank-red-hat-summit-2017?intcmp=701f2000000tjyaAAA -[8]:https://enterprisersproject.com/article/2017/11/dear-cios-stop-beating-yourselves-being-behind-transformation -[9]:https://www.redhat.com/en/resources/macquarie-bank-case-study?intcmp=701f2000000tjyaAAA -[10]:https://enterprisersproject.com/article/2018/1/4-ai-trends-watch -[11]:https://enterprisersproject.com/email-newsletter?intcmp=701f2000000tsjPAAQ From 3a836d341edbe08b1c8d389371f19ffea2be9c4f Mon Sep 17 00:00:00 2001 From: Xingyu Wang Date: Sun, 22 Sep 2019 16:13:59 +0800 Subject: [PATCH 17/21] APL --- .../tech/20190505 Blockchain 2.0 - What Is Ethereum -Part 9.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sources/tech/20190505 Blockchain 2.0 - What Is Ethereum -Part 9.md b/sources/tech/20190505 Blockchain 2.0 - What Is Ethereum -Part 9.md index a4669a2eb0..af9b75c974 100644 --- a/sources/tech/20190505 Blockchain 2.0 - What Is Ethereum -Part 9.md +++ b/sources/tech/20190505 Blockchain 2.0 - What Is Ethereum -Part 9.md @@ -1,5 +1,5 @@ [#]: collector: (lujun9972) -[#]: translator: ( ) +[#]: translator: (wxy) [#]: reviewer: ( ) [#]: publisher: ( ) [#]: url: ( ) From a554e9144602a3b5f6bed32368537fe59dba90bb Mon Sep 17 00:00:00 2001 From: Frank Jia <474165491@qq.com> Date: Sun, 22 Sep 2019 16:16:10 +0800 Subject: [PATCH 18/21] 20180117 translated 20180117 How technology changes the rules for doing agile translated --- ...ology changes the rules for doing agile.md | 97 +++++++++++++++++++ 1 file changed, 97 insertions(+) create mode 100644 translated/talk/20180117 How technology changes the rules for doing agile.md diff --git a/translated/talk/20180117 How technology changes the rules for doing agile.md b/translated/talk/20180117 How technology changes the rules for doing agile.md new file mode 100644 index 0000000000..4c5b66f133 --- /dev/null +++ b/translated/talk/20180117 How technology changes the rules for doing agile.md @@ -0,0 +1,97 @@ +技术如何改变敏捷的规则 +====== + +![](https://enterprisersproject.com/sites/default/files/styles/620x350/public/images/CIO%20Containers%20Ecosystem.png?itok=lDTaYXzk) + +越来越多的企业正因为一个非常明显的原因开始尝试敏捷和[DevOps][1]: 企业需要通过更快的速度和更多的实验为创新和竞争性提供优势。而DevOps将帮助我们得到所需的创新速度。但是，在小团队或初创企业中实践DevOps与进行大规模实践完全是两码事。我们都明白这样的一个事实，那就是在10人的跨职能团队中能够很好地解决问题的方案，当将相同的模式应用到100人的团队中时就可能无法奏效。这条道路是如此艰难，以至于IT领导者很容易将敏捷方法的推行再推迟一年。 + +但那样的时代已经结束了。如果你已经尝试过，但是没有成功，那么现在是时候重新开始了。 + +直到现在，DevOps需要为许多组织提供个性化的解决方案，因此往往需要进行大量的调整以及付出额外的工作。但在今天，[Linux容器][2]和Kubernetes正在推动DevOps工具和过程的标准化。而这样的标准化将会加速整个软件开发过程。因此，我们用来实践DevOps工作方式的技术最终能够满足我们加快软件开发速度的愿望。 + +Linux容器和[Kubernetes][3]正在改变团队交互的方式。此外，你可以在Kubernetes平台上运行任何能够在Linux运行的应用程序。这意味着什么呢？你可以运行大量的企业及应用程序(甚至可以解决以前令人烦恼的Windows和Linux之间的协调问题)。最后，容器和Kubernetes将能够满足未来所有运行内容的需求。它们正在经受着未来的考验，以应对机器学习、人工智能和分析工作等下一代解决问题工具。 + +**[ 参考相关文章,[4 container adoption patterns: What you need to know. ] ][4]** + +让我们以机器学习为例来思考一下。今天，人们可以在大量的企业数据中找到一些模式。当机器发现这些模式时(想想机器学习)，你的员工就能更快地采取行动。随着人工智能的加入，机器不仅可以发现模式，还可以对模式进行操作。如今，三个星期已经成为了一个积极的软件开发冲刺周期。有了人工智能，机器每秒可以多次修改代码。创业公司会利用这种能力来“打扰你”。 + +考虑一下你需要多快才能参与到竞争当中。如果你对于无法对于DevOps和每周一个迭代周期充满信心，那么考虑一下当那个创业公司将AI驱动的过程指向你时会发生什么？现在是时候转向DevOps的工作方式了，否认就会像你的竞争对手一样被甩在后面。 + +### 容器技术如何改变团队的工作？ + +DevOps使得许多试图将这种工作方式扩展到更大范围的团队感到沮丧。即使许多IT(和业务)人员之前都听说过敏捷相关的语言、框架、模型(如DevOps)等承诺将会彻底应用程序开发和IT过程的全部相关内容，但他们还是对此持怀疑态度。 + +**[ 想要获取来自其他CIO们的建议吗？不放参考下我们的综述性资源, [DevOps: The IT Leader's Guide][5]. ]** + +向你的涉众“推销”快速开发冲刺也不是一件容易的事情。想象一下，如果你以这种方式买了一栋房子：你将不再需要向开发商支付固定的金额，而是会得到这样的信息：“我们将在4周内浇筑完地基，其成本是X，之后再搭建房屋框架和铺设电路，但是我们现在只能够知道地基完成的时间表。”人们已经习惯了买房子的时候有一个预先的价格和交付时间表。 + +挑战在于构建软件与构建房屋不同。同一个建筑商往往建造了成千上万个完全相同的房子，而软件项目从来都各不相同。这是你要克服的第一个障碍。 + +开发和运维团队的工作方式确实不同，我之所以知道这一点是因为我曾经从事过这两方面的工作。企业往往会用不同的方式来激励他们，开发人员会因为更改和创建而获得奖励，而运维专家则会因降低成本和确保安全性而获得奖励。我们会把他们分成不同的小组，并且尽量减少互动。而这些角色通常会吸引那些思维方式完全不同的技术人员。但是这样的解决方案注定会失败，你必须打破横亘在开发和运维之间的藩篱。 + +想想传统情况下会发生什么。业务会把需求扔过墙，这是因为他们在“买房”模式下运作，并且说上一句“我们9个月后见。”开发人员根据这些需求进行开发，并根据技术约束的需要进行更改。然后，他们把它扔过墙传递给运维人员，并说一句“搞清楚如何运行这个软件”。然后，运维人员勤就会奋地进行大量更改，使软件与基础设施保持一致。然而，最终的结果是什么呢？ + +通常情况下，当业务人员看到需求实现的最终结果时甚至根本辨认不出。在过去20年的大部分时间里，我们一次又一次地目睹了这种模式在软件行业中上演。而现在，是时候改变了。 + +Linux容器能够真正地解决这样的问题，这是因为容器缩小了开发和运维之间的间隙。容器技术允许两个团队共同理解和设计所有的关键需求，但仍然独立地履行各自团队的职责。基本上，我们去掉了开发人员和运维人员之间的电话游戏。 + +因为容器技术，我们可以使得运维团队的规模更小，但依旧能够承担起数百万应用程序的运维工作，并且能够使得开发团队可以更加快速地根据需要更改软件。(在较大的组织中，所需的速度可能比运维人员的响应速度更快。) + +使用容器，您可以将所需要交付的内容与它运行的位置分开。你的运维团队只需要负责运行容器的主机和安全的内存占用，仅此而已。这意味着什么呢？ + +首先，这意味着你现在可以和团队一起实践DevOps了。没错，只需要让团队专注于他们已经拥有的专业知识，而对于容器，只需让团队了解所需集成依赖关系的必要知识即可。 + +如果你想要重新训练每个人，往往会收效甚微。容器技术允许团队之间进行交互，但同时也会为每个团队提供一个围绕该团队优势而构建的强大边界。开发人员会知道需要消耗什么，但不需要知道如何使其大规模运行。运维团队了解核心基础设施，但不需要了解应用程序的细节。此外，运维团队也可以通过更新应用程序来解决新的安全问题，以免你成为下一个数据泄露的热门话题。 + +想要为一个大型IT组织，比如30000人的团队教授运维和开发技能？那或许需要花费你十年的时间，而你可能并没有那么多时间。 + +当人们谈论“构建新的云原生应用程序将帮助我们摆脱这个问题”时，请批判性地进行思考。你可以在10个人的团队中构建云原生应用程序，但这对《财富》杂志前1000强的企业而言或许并不适用。除非你不再需要依赖现有的团队，否则你无法一个接一个地构建新的微服务：你最终将得到一个竖井式的组织。这是一个诱人的想法，但你不能指望这些应用程序来重新定义你的业务。我还没见过哪家公司能在如此大规模的并行开发中获得成功。IT预算已经受到限制；在很长一段时间内将预算翻倍甚至三倍是不现实的。 + +### 当奇迹发生时: 你好, 速度 + +Linux容器就是为扩容而生的。一旦你开始这样做，[Kubernetes之类的编制工具就会发挥作用][6]，这是因为你将需要运行数千个容器。应用程序将不仅仅由一个容器组成，它们将依赖于许多不同的部分，所有的部分都会作为一个单元运行在容器上。如果不这样做，你的应用程序将无法在生产环境中很好地运行。 + +思考一下有多少小滑轮和杠杆组合在一起来支撑你的业务，对于任何应用程序都是如此。开发人员负责应用程序中的所有滑轮和杠杆。(如果开发人员没有这些组件，您可能会在集成时做噩梦。)与此同时，无论是在线下还是在云上，运维团队都会负责构成基础设施的所有滑轮和杠杆。做一个较为抽象的比喻，使用Kubernetes，你的运维团队就可以为应用程序提供运行所需的燃料，但又不必成为所有方面的专家。 + +开发人员进行实验，运维团队则保持基础设施的安全和可靠。这样的组合使得企业敢于承担小风险，从而实现创新。不同于打几个孤注一掷的赌，公司中真正的实验往往是循序渐进的和快速的。 + +从个人经验来看，这就是组织内部发生的显著变化：因为人们说：“我们如何通过改变计划来真正地利用这种能力进行实验？”它强制执行敏捷计划。 + +举个例子，使用DevOps模型、容器和Kubernetes的KeyBank如今每天都会部署代码。(观看视频[7]，其中主导了KeyBank持续交付和反馈的John Rzeszotarski将解释这一变化。)类似地，Macquarie银行也借助DevOps和容器技术每天将一些东西投入生产环境。 + +一旦你每天都推出软件，它就会改变你计划的每一个方面，并且会[加速业务的变化速度][8]。Macquarie银行和金融服务集团的CDO，Luis Uguina表示：“创意可以在一天内触达客户。”(参见[9]对Red Hat与Macquarie银行合作的案例研究)。 + +### 是时候去创造一些伟大的东西了 + +Macquarie的例子说明了速度的力量。这将如何改变你的经营方式？记住，Macquarie不是一家初创企业。这是CIO们所面临的颠覆性力量，它不仅来自新的市场进入者，也来自老牌同行。 + +开发人员的自由还改变了运营敏捷商店的CIO们的人才方程式。突然之间，大公司里的个体(即使不是在最热门的行业或地区)也可以产生巨大的影响。Macquarie利用这一变动作为招聘工具，并向开发人员承诺，所有新招聘的员工将会在第一周内推出新产品。 + +与此同时，在这个基于云的计算和存储能力的时代，我们比以往任何时候都拥有更多可用的基础设施。考虑到[机器学习和人工智能工具将很快实现的飞跃][10]，这是幸运的。 + +所有这些都说明现在正是打造伟大事业的好时机。考虑到市场创新的速度，你需要不断地创造伟大的东西来保持客户的忠诚度。因此，如果你一直在等待将赌注押在DevOps上，那么现在就是正确的时机。容器技术和Kubernetes改变了规则，并且对你有利。 + +**想要获取更多这样的智慧吗, IT领导者? [订阅每周邮件][11].** + +-------------------------------------------------------------------------------- + +via: https://enterprisersproject.com/article/2018/1/how-technology-changes-rules-doing-agile + +作者：[Matt Hicks][a] +译者：[JayFrank](https://github.com/JayFrank) +校对：[校对者ID](https://github.com/校对者ID) + +本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出 + +[a]:https://enterprisersproject.com/user/matt-hicks +[1]:https://enterprisersproject.com/tags/devops +[2]:https://www.redhat.com/en/topics/containers?intcmp=701f2000000tjyaAAA +[3]:https://www.redhat.com/en/topics/containers/what-is-kubernetes?intcmp=701f2000000tjyaAAA +[4]:https://enterprisersproject.com/article/2017/8/4-container-adoption-patterns-what-you-need-know?sc_cid=70160000000h0aXAAQ +[5]:https://enterprisersproject.com/devops?sc_cid=70160000000h0aXAAQ +[6]:https://enterprisersproject.com/article/2017/11/how-enterprise-it-uses-kubernetes-tame-container-complexity +[7]:https://www.redhat.com/en/about/videos/john-rzeszotarski-keybank-red-hat-summit-2017?intcmp=701f2000000tjyaAAA +[8]:https://enterprisersproject.com/article/2017/11/dear-cios-stop-beating-yourselves-being-behind-transformation +[9]:https://www.redhat.com/en/resources/macquarie-bank-case-study?intcmp=701f2000000tjyaAAA +[10]:https://enterprisersproject.com/article/2018/1/4-ai-trends-watch +[11]:https://enterprisersproject.com/email-newsletter?intcmp=701f2000000tsjPAAQ From 7e12dc3cf4cfb6d70985eb254b08b33922d1e485 Mon Sep 17 00:00:00 2001 From: Frank Jia <474165491@qq.com> Date: Sun, 22 Sep 2019 16:16:35 +0800 Subject: [PATCH 19/21] Delete 20180117 How technology changes the rules for doing agile.md --- ...ology changes the rules for doing agile.md | 97 ------------------- 1 file changed, 97 deletions(-) delete mode 100644 translated/tech/20180117 How technology changes the rules for doing agile.md diff --git a/translated/tech/20180117 How technology changes the rules for doing agile.md b/translated/tech/20180117 How technology changes the rules for doing agile.md deleted file mode 100644 index 4c5b66f133..0000000000 --- a/translated/tech/20180117 How technology changes the rules for doing agile.md +++ /dev/null @@ -1,97 +0,0 @@ -技术如何改变敏捷的规则 -====== - -![](https://enterprisersproject.com/sites/default/files/styles/620x350/public/images/CIO%20Containers%20Ecosystem.png?itok=lDTaYXzk) - -越来越多的企业正因为一个非常明显的原因开始尝试敏捷和[DevOps][1]: 企业需要通过更快的速度和更多的实验为创新和竞争性提供优势。而DevOps将帮助我们得到所需的创新速度。但是，在小团队或初创企业中实践DevOps与进行大规模实践完全是两码事。我们都明白这样的一个事实，那就是在10人的跨职能团队中能够很好地解决问题的方案，当将相同的模式应用到100人的团队中时就可能无法奏效。这条道路是如此艰难，以至于IT领导者很容易将敏捷方法的推行再推迟一年。 - -但那样的时代已经结束了。如果你已经尝试过，但是没有成功，那么现在是时候重新开始了。 - -直到现在，DevOps需要为许多组织提供个性化的解决方案，因此往往需要进行大量的调整以及付出额外的工作。但在今天，[Linux容器][2]和Kubernetes正在推动DevOps工具和过程的标准化。而这样的标准化将会加速整个软件开发过程。因此，我们用来实践DevOps工作方式的技术最终能够满足我们加快软件开发速度的愿望。 - -Linux容器和[Kubernetes][3]正在改变团队交互的方式。此外，你可以在Kubernetes平台上运行任何能够在Linux运行的应用程序。这意味着什么呢？你可以运行大量的企业及应用程序(甚至可以解决以前令人烦恼的Windows和Linux之间的协调问题)。最后，容器和Kubernetes将能够满足未来所有运行内容的需求。它们正在经受着未来的考验，以应对机器学习、人工智能和分析工作等下一代解决问题工具。 - -**[ 参考相关文章,[4 container adoption patterns: What you need to know. ] ][4]** - -让我们以机器学习为例来思考一下。今天，人们可以在大量的企业数据中找到一些模式。当机器发现这些模式时(想想机器学习)，你的员工就能更快地采取行动。随着人工智能的加入，机器不仅可以发现模式，还可以对模式进行操作。如今，三个星期已经成为了一个积极的软件开发冲刺周期。有了人工智能，机器每秒可以多次修改代码。创业公司会利用这种能力来“打扰你”。 - -考虑一下你需要多快才能参与到竞争当中。如果你对于无法对于DevOps和每周一个迭代周期充满信心，那么考虑一下当那个创业公司将AI驱动的过程指向你时会发生什么？现在是时候转向DevOps的工作方式了，否认就会像你的竞争对手一样被甩在后面。 - -### 容器技术如何改变团队的工作？ - -DevOps使得许多试图将这种工作方式扩展到更大范围的团队感到沮丧。即使许多IT(和业务)人员之前都听说过敏捷相关的语言、框架、模型(如DevOps)等承诺将会彻底应用程序开发和IT过程的全部相关内容，但他们还是对此持怀疑态度。 - -**[ 想要获取来自其他CIO们的建议吗？不放参考下我们的综述性资源, [DevOps: The IT Leader's Guide][5]. ]** - -向你的涉众“推销”快速开发冲刺也不是一件容易的事情。想象一下，如果你以这种方式买了一栋房子：你将不再需要向开发商支付固定的金额，而是会得到这样的信息：“我们将在4周内浇筑完地基，其成本是X，之后再搭建房屋框架和铺设电路，但是我们现在只能够知道地基完成的时间表。”人们已经习惯了买房子的时候有一个预先的价格和交付时间表。 - -挑战在于构建软件与构建房屋不同。同一个建筑商往往建造了成千上万个完全相同的房子，而软件项目从来都各不相同。这是你要克服的第一个障碍。 - -开发和运维团队的工作方式确实不同，我之所以知道这一点是因为我曾经从事过这两方面的工作。企业往往会用不同的方式来激励他们，开发人员会因为更改和创建而获得奖励，而运维专家则会因降低成本和确保安全性而获得奖励。我们会把他们分成不同的小组，并且尽量减少互动。而这些角色通常会吸引那些思维方式完全不同的技术人员。但是这样的解决方案注定会失败，你必须打破横亘在开发和运维之间的藩篱。 - -想想传统情况下会发生什么。业务会把需求扔过墙，这是因为他们在“买房”模式下运作，并且说上一句“我们9个月后见。”开发人员根据这些需求进行开发，并根据技术约束的需要进行更改。然后，他们把它扔过墙传递给运维人员，并说一句“搞清楚如何运行这个软件”。然后，运维人员勤就会奋地进行大量更改，使软件与基础设施保持一致。然而，最终的结果是什么呢？ - -通常情况下，当业务人员看到需求实现的最终结果时甚至根本辨认不出。在过去20年的大部分时间里，我们一次又一次地目睹了这种模式在软件行业中上演。而现在，是时候改变了。 - -Linux容器能够真正地解决这样的问题，这是因为容器缩小了开发和运维之间的间隙。容器技术允许两个团队共同理解和设计所有的关键需求，但仍然独立地履行各自团队的职责。基本上，我们去掉了开发人员和运维人员之间的电话游戏。 - -因为容器技术，我们可以使得运维团队的规模更小，但依旧能够承担起数百万应用程序的运维工作，并且能够使得开发团队可以更加快速地根据需要更改软件。(在较大的组织中，所需的速度可能比运维人员的响应速度更快。) - -使用容器，您可以将所需要交付的内容与它运行的位置分开。你的运维团队只需要负责运行容器的主机和安全的内存占用，仅此而已。这意味着什么呢？ - -首先，这意味着你现在可以和团队一起实践DevOps了。没错，只需要让团队专注于他们已经拥有的专业知识，而对于容器，只需让团队了解所需集成依赖关系的必要知识即可。 - -如果你想要重新训练每个人，往往会收效甚微。容器技术允许团队之间进行交互，但同时也会为每个团队提供一个围绕该团队优势而构建的强大边界。开发人员会知道需要消耗什么，但不需要知道如何使其大规模运行。运维团队了解核心基础设施，但不需要了解应用程序的细节。此外，运维团队也可以通过更新应用程序来解决新的安全问题，以免你成为下一个数据泄露的热门话题。 - -想要为一个大型IT组织，比如30000人的团队教授运维和开发技能？那或许需要花费你十年的时间，而你可能并没有那么多时间。 - -当人们谈论“构建新的云原生应用程序将帮助我们摆脱这个问题”时，请批判性地进行思考。你可以在10个人的团队中构建云原生应用程序，但这对《财富》杂志前1000强的企业而言或许并不适用。除非你不再需要依赖现有的团队，否则你无法一个接一个地构建新的微服务：你最终将得到一个竖井式的组织。这是一个诱人的想法，但你不能指望这些应用程序来重新定义你的业务。我还没见过哪家公司能在如此大规模的并行开发中获得成功。IT预算已经受到限制；在很长一段时间内将预算翻倍甚至三倍是不现实的。 - -### 当奇迹发生时: 你好, 速度 - -Linux容器就是为扩容而生的。一旦你开始这样做，[Kubernetes之类的编制工具就会发挥作用][6]，这是因为你将需要运行数千个容器。应用程序将不仅仅由一个容器组成，它们将依赖于许多不同的部分，所有的部分都会作为一个单元运行在容器上。如果不这样做，你的应用程序将无法在生产环境中很好地运行。 - -思考一下有多少小滑轮和杠杆组合在一起来支撑你的业务，对于任何应用程序都是如此。开发人员负责应用程序中的所有滑轮和杠杆。(如果开发人员没有这些组件，您可能会在集成时做噩梦。)与此同时，无论是在线下还是在云上，运维团队都会负责构成基础设施的所有滑轮和杠杆。做一个较为抽象的比喻，使用Kubernetes，你的运维团队就可以为应用程序提供运行所需的燃料，但又不必成为所有方面的专家。 - -开发人员进行实验，运维团队则保持基础设施的安全和可靠。这样的组合使得企业敢于承担小风险，从而实现创新。不同于打几个孤注一掷的赌，公司中真正的实验往往是循序渐进的和快速的。 - -从个人经验来看，这就是组织内部发生的显著变化：因为人们说：“我们如何通过改变计划来真正地利用这种能力进行实验？”它强制执行敏捷计划。 - -举个例子，使用DevOps模型、容器和Kubernetes的KeyBank如今每天都会部署代码。(观看视频[7]，其中主导了KeyBank持续交付和反馈的John Rzeszotarski将解释这一变化。)类似地，Macquarie银行也借助DevOps和容器技术每天将一些东西投入生产环境。 - -一旦你每天都推出软件，它就会改变你计划的每一个方面，并且会[加速业务的变化速度][8]。Macquarie银行和金融服务集团的CDO，Luis Uguina表示：“创意可以在一天内触达客户。”(参见[9]对Red Hat与Macquarie银行合作的案例研究)。 - -### 是时候去创造一些伟大的东西了 - -Macquarie的例子说明了速度的力量。这将如何改变你的经营方式？记住，Macquarie不是一家初创企业。这是CIO们所面临的颠覆性力量，它不仅来自新的市场进入者，也来自老牌同行。 - -开发人员的自由还改变了运营敏捷商店的CIO们的人才方程式。突然之间，大公司里的个体(即使不是在最热门的行业或地区)也可以产生巨大的影响。Macquarie利用这一变动作为招聘工具，并向开发人员承诺，所有新招聘的员工将会在第一周内推出新产品。 - -与此同时，在这个基于云的计算和存储能力的时代，我们比以往任何时候都拥有更多可用的基础设施。考虑到[机器学习和人工智能工具将很快实现的飞跃][10]，这是幸运的。 - -所有这些都说明现在正是打造伟大事业的好时机。考虑到市场创新的速度，你需要不断地创造伟大的东西来保持客户的忠诚度。因此，如果你一直在等待将赌注押在DevOps上，那么现在就是正确的时机。容器技术和Kubernetes改变了规则，并且对你有利。 - -**想要获取更多这样的智慧吗, IT领导者? [订阅每周邮件][11].** - --------------------------------------------------------------------------------- - -via: https://enterprisersproject.com/article/2018/1/how-technology-changes-rules-doing-agile - -作者：[Matt Hicks][a] -译者：[JayFrank](https://github.com/JayFrank) -校对：[校对者ID](https://github.com/校对者ID) - -本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出 - -[a]:https://enterprisersproject.com/user/matt-hicks -[1]:https://enterprisersproject.com/tags/devops -[2]:https://www.redhat.com/en/topics/containers?intcmp=701f2000000tjyaAAA -[3]:https://www.redhat.com/en/topics/containers/what-is-kubernetes?intcmp=701f2000000tjyaAAA -[4]:https://enterprisersproject.com/article/2017/8/4-container-adoption-patterns-what-you-need-know?sc_cid=70160000000h0aXAAQ -[5]:https://enterprisersproject.com/devops?sc_cid=70160000000h0aXAAQ -[6]:https://enterprisersproject.com/article/2017/11/how-enterprise-it-uses-kubernetes-tame-container-complexity -[7]:https://www.redhat.com/en/about/videos/john-rzeszotarski-keybank-red-hat-summit-2017?intcmp=701f2000000tjyaAAA -[8]:https://enterprisersproject.com/article/2017/11/dear-cios-stop-beating-yourselves-being-behind-transformation -[9]:https://www.redhat.com/en/resources/macquarie-bank-case-study?intcmp=701f2000000tjyaAAA -[10]:https://enterprisersproject.com/article/2018/1/4-ai-trends-watch -[11]:https://enterprisersproject.com/email-newsletter?intcmp=701f2000000tsjPAAQ From 3405fc18af88d7e1597a3007b85a4d38c814fc91 Mon Sep 17 00:00:00 2001 From: laingke Date: Sun, 22 Sep 2019 16:21:13 +0800 Subject: [PATCH 20/21] 20190812-Cloud-native-Java,-open-source-security,-and-more-industry-trends translating --- ...ve Java, open source security, and more industry trends.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sources/tech/20190812 Cloud-native Java, open source security, and more industry trends.md b/sources/tech/20190812 Cloud-native Java, open source security, and more industry trends.md index cbc42dbbbd..58791aba9c 100644 --- a/sources/tech/20190812 Cloud-native Java, open source security, and more industry trends.md +++ b/sources/tech/20190812 Cloud-native Java, open source security, and more industry trends.md @@ -1,5 +1,5 @@ [#]: collector: (lujun9972) -[#]: translator: ( ) +[#]: translator: (laingke) [#]: reviewer: ( ) [#]: publisher: ( ) [#]: url: ( ) @@ -62,7 +62,7 @@ via: https://opensource.com/article/19/8/cloud-native-java-and-more 作者：[Tim Hildred][a] 选题：[lujun9972][b] -译者：[译者ID](https://github.com/译者ID) +译者：[laingke](https://github.com/laingke) 校对：[校对者ID](https://github.com/校对者ID) 本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出 From ace5c0bb6260fce51b0e1a53929abdebdcf940d4 Mon Sep 17 00:00:00 2001 From: Xingyu Wang Date: Sun, 22 Sep 2019 22:52:40 +0800 Subject: [PATCH 21/21] TSL --- ...ockchain 2.0 - What Is Ethereum -Part 9.md | 83 ------------------- ...ockchain 2.0 - What Is Ethereum -Part 9.md | 79 ++++++++++++++++++ 2 files changed, 79 insertions(+), 83 deletions(-) delete mode 100644 sources/tech/20190505 Blockchain 2.0 - What Is Ethereum -Part 9.md create mode 100644 translated/tech/20190505 Blockchain 2.0 - What Is Ethereum -Part 9.md diff --git a/sources/tech/20190505 Blockchain 2.0 - What Is Ethereum -Part 9.md b/sources/tech/20190505 Blockchain 2.0 - What Is Ethereum -Part 9.md deleted file mode 100644 index af9b75c974..0000000000 --- a/sources/tech/20190505 Blockchain 2.0 - What Is Ethereum -Part 9.md +++ /dev/null @@ -1,83 +0,0 @@ -[#]: collector: (lujun9972) -[#]: translator: (wxy) -[#]: reviewer: ( ) -[#]: publisher: ( ) -[#]: url: ( ) -[#]: subject: (Blockchain 2.0 – What Is Ethereum [Part 9]) -[#]: via: (https://www.ostechnix.com/blockchain-2-0-what-is-ethereum/) -[#]: author: (editor https://www.ostechnix.com/author/editor/) - -Blockchain 2.0 – What Is Ethereum [Part 9] -====== - -![Ethereum][1] - -In the previous guide of this series, we discussed about [**Hyperledger Project (HLP)**][2], a fastest growing product developed by **Linux Foundation**. In this guide, we are going to discuss about what is **Ethereum** and its features in detail. Many researchers opine that the future of the internet will be based on principles of decentralized computing. Decentralized computing was in fact among one of the broader objectives of having the internet in the first place. However, the internet took another turn owing to differences in computing capabilities available. While modern server capabilities make the case for server-side processing and execution, lack of decent mobile networks in large parts of the world make the case for the same on the client side. Modern smartphones now have **SoCs** (system on a chip or system on chip) capable of handling many such operations on the client side itself, however, limitations owing to retrieving and storing data securely still pushes developers to have server-side computing and data management. Hence, a bottleneck in regards to data transfer capabilities is currently observed. - -All of that might soon change because of advancements in distributed data storage and program execution platforms. [**The blockchain**][3], for the first time in the history of the internet, basically allows for secure data management and program execution on a distributed network of users as opposed to central servers. - -**Ethereum** is one such blockchain platform that gives developers access to frameworks and tools used to build and run applications on such a decentralized network. Though more popularly known in general for its cryptocurrency, Ethereum is more than just **ethers** (the cryptocurrency). It’s a full **Turing complete programming language** that is designed to develop and deploy **DApps** or **Distributed APPlications** [1]. We’ll look at DApps in more detail in one of the upcoming posts. - -Ethereum is an open-source, supports by default a public (non-permissioned) blockchain, and features an extensive smart contract platform **(Solidity)** underneath. Ethereum provides a virtual computing environment called the **Ethereum virtual machine** to run applications and [**smart contracts**][4] as well[2]. The Ethereum virtual machine runs on thousands of participating nodes all over the world, meaning the application data while being secure, is almost impossible to be tampered with or lost. - -### Getting behind Ethereum: What sets it apart - -In 2017, a 30 plus group of the who’s who of the tech and financial world got together to leverage the Ethereum blockchain’s capabilities. Thus, the **Ethereum Enterprise Alliance (EEA)** was formed by a long list of supporting members including _Microsoft_ , _JP Morgan_ , _Cisco Systems_ , _Deloitte_ , and _Accenture_. JP Morgan already has **Quorum** , a decentralized computing platform for financial services based on Ethereum currently in operation, while Microsoft has Ethereum based cloud services it markets through its Azure cloud business[3]. - -### What is ether and how is it related to Ethereum - -Ethereum creator **Vitalik Buterin** understood the true value of a decentralized processing platform and the underlying blockchain tech that powered bitcoin. He failed to gain majority agreement for his idea of proposing that Bitcoin should be developed to support running distributed applications (DApps) and programs (now referred to as smart contracts). - -Hence in 2013, he proposed the idea of Ethereum in a white paper he published. The original white paper is still maintained and available for readers **[here][5]**. The idea was to develop a blockchain based platform to run smart contracts and applications designed to run on nodes and user devices instead of servers. - -The Ethereum system is often mistaken to just mean the cryptocurrency ether, however, it has to be reiterated that Ethereum is a full stack platform for developing applications and executing them as well and has been so since inception whereas bitcoin isn’t. **Ether is currently the second biggest cryptocurrency** by market capitalization and trades at an average of $170 per ether at the time of writing this article[4]. - -### Features and technicalities of the platform[5] - - * As we’ve already mentioned, the cryptocurrency called ether is simply one of the things the platform features. The purpose of the system is more than taking care of financial transactions. In fact, the key difference between the Ethereum platform and Bitcoin is in their scripting capabilities. Ethereum is developed in a Turing complete programming language which means it has scripting and application capabilities similar to other major programming languages. Developers require this feature to create DApps and complex smart contracts on the platform, a feature that bitcoin misses on. - * The “mining” process of ether is more stringent and complex. While specialized ASICs may be used to mine bitcoin, the basic hashing algorithm used by Ethereum **(EThash)** reduces the advantage that ASICs have in this regard. - * The transaction fees itself to be paid as an incentive to miners and node operators for running the network is calculated using a computational token called **Gas**. Gas improves the system’s resilience and resistance to external hacks and attacks by requiring the initiator of the transaction to pay ethers proportionate to the number of computational resources that are required to carry out that transaction. This is in contrast to other platforms such as Bitcoin where the transaction fee is measured in tandem with the transaction size. As such, the average transaction costs in Ethereum is radically less than Bitcoin. This also implies that running applications running on the Ethereum virtual machine will require a fee depending straight up on the computational problems that the application is meant to solve. Basically, the more complex an execution, the more the fee. - * The block time for Ethereum is estimated to be around _**10-15 seconds**_. The block time is the average time that is required to timestamp and create a block on the blockchain network. Compared to the 10+ minutes the same transaction will take on the bitcoin network, it becomes apparent that _**Ethereum is much faster**_ with respect to transactions and verification of blocks. - * _It is also interesting to note that there is no hard cap on the amount of ether that can be mined or the rate at which ether can be mined leading to less radical system design than bitcoin._ - - - -### Conclusion - -While Ethereum is comparable and far outpaces similar platforms, the platform itself lacked a definite path for development until the Ethereum enterprise alliance started pushing it. While the definite push for enterprise developments are made by the Ethereum platform, it has to be noted that Ethereum also caters to small-time developers and individuals as well. As such developing the platform for end users and enterprises leave a lot of specific functionality out of the loop for Ethereum. Also, the blockchain model proposed and developed by the Ethereum foundation is a public model whereas the one proposed by projects such as the Hyperledger project is private and permissioned. - -While only time can tell which platform among the ones put forward by Ethereum, Hyperledger, and R3 Corda among others will find the most fans in real-world use cases, such systems do prove the validity behind the claim of a blockchain powered future. - -**References:** - - * [1] [**Gabriel Nicholas, “Ethereum Is Coding’s New Wild West | WIRED,” Wired , 2017**][6]. - * [2] [**What is Ethereum? — Ethereum Homestead 0.1 documentation**][7]. - * [3] [**Ethereum, a Virtual Currency, Enables Transactions That Rival Bitcoin’s – The New York Times**][8]. - * [4] [**Cryptocurrency Market Capitalizations | CoinMarketCap**][9]. - * [5] [**Introduction — Ethereum Homestead 0.1 documentation**][10]. - - - --------------------------------------------------------------------------------- - -via: https://www.ostechnix.com/blockchain-2-0-what-is-ethereum/ - -作者：[editor][a] -选题：[lujun9972][b] -译者：[译者ID](https://github.com/译者ID) -校对：[校对者ID](https://github.com/校对者ID) - -本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出 - -[a]: https://www.ostechnix.com/author/editor/ -[b]: https://github.com/lujun9972 -[1]: https://www.ostechnix.com/wp-content/uploads/2019/04/Ethereum-720x340.png -[2]: https://www.ostechnix.com/blockchain-2-0-an-introduction-to-hyperledger-project-hlp/ -[3]: https://www.ostechnix.com/blockchain-2-0-an-introduction/ -[4]: https://www.ostechnix.com/blockchain-2-0-explaining-smart-contracts-and-its-types/ -[5]: https://github.com/ethereum/wiki/wiki/White-Paper -[6]: https://www.wired.com/story/ethereum-is-codings-new-wild-west/ -[7]: http://www.ethdocs.org/en/latest/introduction/what-is-ethereum.html#ethereum-virtual-machine -[8]: https://www.nytimes.com/2016/03/28/business/dealbook/ethereum-a-virtual-currency-enables-transactions-that-rival-bitcoins.html -[9]: https://coinmarketcap.com/ -[10]: http://www.ethdocs.org/en/latest/introduction/index.html diff --git a/translated/tech/20190505 Blockchain 2.0 - What Is Ethereum -Part 9.md b/translated/tech/20190505 Blockchain 2.0 - What Is Ethereum -Part 9.md new file mode 100644 index 0000000000..b80271af21 --- /dev/null +++ b/translated/tech/20190505 Blockchain 2.0 - What Is Ethereum -Part 9.md @@ -0,0 +1,79 @@ +[#]: collector: (lujun9972) +[#]: translator: (wxy) +[#]: reviewer: ( ) +[#]: publisher: ( ) +[#]: url: ( ) +[#]: subject: (Blockchain 2.0 – What Is Ethereum [Part 9]) +[#]: via: (https://www.ostechnix.com/blockchain-2-0-what-is-ethereum/) +[#]: author: (editor https://www.ostechnix.com/author/editor/) + +区块链 2.0 ：以太坊（九） +====== + +![Ethereum][1] + +在本系列的上一指南中，我们讨论了 [Hyperledger 项目（HLP）][2]，这是一个由 Linux 基金会开发的增长最快的产品。在本指南中，我们将详细讨论什么是“以太坊Ethereum”及其功能。许多研究人员认为，互联网的未来将基于去中心化计算decentralized computing的原理。实际上，去中心化计算是互联网放在首位的更广泛目标之一。但是，由于可用的计算能力不同，互联网发生了另一次变化。尽管现代服务器功能使服务器端处理和执行成为可能，但在世界上大部分地区缺乏像样的移动网络使客户端也是如此。现在，现代智能手机具有 SoC（片上系统），在客户端本身上也能够处理许多此类操作，但是，由于安全地检索和存储数据而受到的限制仍然迫使开发人员进行服务器端计算和数据管理。因此，当前可以观察到数据传输能力的瓶颈。 + +由于分布式数据存储和程序执行平台的进步，所有这些可能很快就会改变。[区块链][3]允许在分布式用户网络（而不是中央服务器）上进行安全的数据管理和程序执行，这在互联网历史上基本上是第一次。 + +以太坊就是一个这样的区块链平台，使开发人员可以访问用于在这样的去中心化网络上构建和运行应用程序的框架和工具。尽管它以其加密货币而广为人知，以太坊不只是以太币ether（加密货币）。这是一种完整的图灵完备Turing complete编程语言，旨在开发和部署 DApp（即分布式应用Distributed APPlication） [^1]。我们会在接下来的一篇文章中详细介绍 DApp。 + +以太坊是开源的，默认情况下是一个公共（非许可）区块链，并具有一个大范围的智能合约平台底层（Solidity）。以太坊提供了一个称为“以太坊虚拟机（EVM）”的虚拟计算环境，以运行应用程序和[智能合约][4] [^2]。 以太坊虚拟机在世界各地成千上万个参与节点上运行，这意味着应用程序数据在保证安全的同时，几乎不可能被篡改或丢失。 + +### 以太坊的背后：什么使之不同 + +在 2017 年，为了推广以太坊区块链的功能的利用，30 多个技术和金融领域的名人聚集在一起。因此，“以太坊企业联盟Ethereum Enterprise Alliance”（EEA）由众多支持成员组成，包括微软、摩根大通、思科、德勤和埃森哲。摩根大通已经拥有 Quorum，这是一个基于以太坊的去中心化金融服务计算平台，目前正在运营中；而微软拥有通过其 Azure 云业务销售的基于以太坊的云服务[^3]。 + +### 什么是以太币，它和以太坊有什么关系 + +以太坊的创建者维塔利克·布特林Vitalik Buterin深谙去中心化处理平台的真正价值以及为比特币提供动力的底层区块链技术。他提议比特币应该开发以支持运行分布式应用程序（DApp）和程序（现在称为智能合约）的想法，未能获得多数同意。 + +因此，他在 2013 年发表的白皮书中提出了以太坊的想法。原始白皮书仍在维护中，读者可从[此处][5]获得。这个想法是开发一个基于区块链的平台来运行智能合约和应用程序，这些合约和应用程序设计为在节点和用户设备而非服务器上运行。 + +以太坊系统经常被误认为就是加密货币以太币，但是，必须重申，以太坊是一个用于开发和执行应用程序的全栈平台，自成立以来一直如此，而比特币并非如此。**以太网目前是按市值计算的第二大加密货币**，在撰写本文时，其平均交易价格为每个以太币 170 美元 [^4]。 + +### 该平台的功能和技术特性 [^5] + +* 正如我们已经提到的，称为以太币的加密货币只是该平台功能之一。该系统的目的不仅仅是处理金融交易。 实际上，以太坊平台和比特币之间的主要区别在于它们的脚本功能。以太坊是以图灵完备的编程语言开发的，这意味着它具有类似于其他主要编程语言的脚本和应用程序功能。开发人员需要此功能才能在平台上创建 DApp 和复杂的智能合约，而该功能是比特币缺失的。 +* 以太币的“挖矿”过程更加严格和复杂。尽管可以使用专用的 ASIC 来开采比特币，但以太坊使用的基本哈希算法（EThash）降低了 ASIC 在这方面的优势。 +* 为激励矿工和节点运营者运行网络而支付的交易费用本身是使用称为 “燃料Gas”的计算令牌来计算的。通过要求交易的发起者支付与执行交易所需的计算资源数量成比例的以太币，燃料提高了系统的弹性以及对外部黑客和攻击的抵抗力。这与其他平台（例如比特币）相反，在该平台上，交易费用与交易规模一并衡量。因此，以太坊的平均交易成本从根本上低于比特币。这也意味着在以太坊虚拟机上运行的应用程序需要付费，具体取决于应用程序要解决的计算问题。基本上，执行越复杂，费用就越高。 +* 以太坊的出块时间估计约为 10 - 15 秒。出块时间是在区块链网络上打时间戳和创建区块所需的平均时间。与将在比特币网络上进行同样的交易要花费 10 分钟以上的时间相比，很明显，就交易和区块验证而言，以太坊要快得多。 +* *有趣的是，对可开采的以太币数量或开采速度没有硬性限制，这导致其系统设计不像比特币那么激进*。 + +### 总结 + +尽管与以太坊相比，它远远超过了类似的平台，但在以太坊企业联盟开始推动之前，该平台本身尚缺乏明确的发展道路。虽然以太坊平台确实推动了企业发展，但必须注意，以太坊还可以满足小型开发商和个人的需求。 这样一来，为最终用户和企业开发的平台就为以太坊遗漏了许多特定功能。另外，以太坊基金会提出和开发的区块链模型是一种公共模型，而 Hyperledger 项目等项目提出的模型是私有的和需要许可的。 + +虽然只有时间才能证明以太坊、Hyperledger 和 R3 Corda 等平台中，哪一个平台会在现实场景中找到最多粉丝，但此类系统确实证明了以区块链为动力的未来主张的正确性。 + +[^1]: [Gabriel Nicholas, “Ethereum Is Coding’s New Wild West | WIRED,” Wired , 2017][6]. +[^2]: [What is Ethereum? — Ethereum Homestead 0.1 documentation][7]. +[^3]: [Ethereum, a Virtual Currency, Enables Transactions That Rival Bitcoin’s – The New York Times][8]. +[^4]: [Cryptocurrency Market Capitalizations | CoinMarketCap][9]. +[^5]: [Introduction — Ethereum Homestead 0.1 documentation][10]. + + + +-------------------------------------------------------------------------------- + +via: https://www.ostechnix.com/blockchain-2-0-what-is-ethereum/ + +作者：[editor][a] +选题：[lujun9972][b] +译者：[wxy](https://github.com/wxy) +校对：[校对者ID](https://github.com/校对者ID) + +本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出 + +[a]: https://www.ostechnix.com/author/editor/ +[b]: https://github.com/lujun9972 +[1]: https://www.ostechnix.com/wp-content/uploads/2019/04/Ethereum-720x340.png +[2]: https://www.ostechnix.com/blockchain-2-0-an-introduction-to-hyperledger-project-hlp/ +[3]: https://www.ostechnix.com/blockchain-2-0-an-introduction/ +[4]: https://www.ostechnix.com/blockchain-2-0-explaining-smart-contracts-and-its-types/ +[5]: https://github.com/ethereum/wiki/wiki/White-Paper +[6]: https://www.wired.com/story/ethereum-is-codings-new-wild-west/ +[7]: http://www.ethdocs.org/en/latest/introduction/what-is-ethereum.html#ethereum-virtual-machine +[8]: https://www.nytimes.com/2016/03/28/business/dealbook/ethereum-a-virtual-currency-enables-transactions-that-rival-bitcoins.html +[9]: https://coinmarketcap.com/ +[10]: http://www.ethdocs.org/en/latest/introduction/index.html