为什么云开发最终将成为编程新标准？ 云计算
程序员文章站
2022-05-26 09:14:14
...
云开发是一个已经存在了很多年的概念，但在过去未能真正成为主流。
然而，由于云和软件即服务的宏观趋势的结合，以及技术的进步，如容器技术 Docker 和 Kubernetes，云开发现在有机会最终成为基于云的应用程序的新标准开发。
作者 | Daniel Thiry
以下为译文：
云开发，或者说基于云的开发，已经存在了好几年了。然而到目前为止，从未真正成为主流。
我认为，软件市场的一些变化可能会导致这种开发方式的复兴，甚至是最终的突破。
在我开始介绍这些之前，让我们来看一下云开发的含义。
什么是云开发？
云开发或基于云的开发有许多定义（我将交替使用这些术语）。
本文我将使用这个定义：云开发是一种软件开发方法，它使用云环境（而不是本地计算机）在实际的开发阶段执行未完成的软件。
这意味着你的软件在云中运行，它通常不会在你的本地计算机上运行。如果你开发的软件是在云环境中运行的，那么项目的临时环境、测试和生产环境也会在云上。
其他一些人将云开发定义为使用基于浏览器和在线的 IDE。虽然基于浏览器的编辑器通常链接到云环境来执行软件，但也可以使用本地编辑器并在云中执行软件(例如，使用 Visual Studio 的远程环境特性) ，这就是为什么我选择使用上面那种更广泛定义的原因。
来自 Kubernetes 和 CNCF 社区的另一个更近期的术语是“云原生开发”(cloud-native development) ，它也与我对云开发的定义有关，但是它是一个更普遍的概念，指的是“基于容器的、动态编排的、利用微服务架构的应用程序开发”。因此，它更关注开发什么，而不是如何开发。
云开发从未成为主流
云开发的想法并不新鲜。你可以在八年前的文章中就可以找到相关的讨论。
随着在线 IDEs（如 Cloud9 和 Eclipse Che）的出现，云开发经历了第一次人气飙升。这可能就是为什么有些人直接将这些工具与云开发这个术语联系起来的原因。这些基于浏览器的 ide 为你提供了在云中运行的工具和编辑器，可以通过普通浏览器(如 Google Chrome)直接访问。
由于源代码已经在云中编写，所以它通常也在连接的云环境中执行，这使得根据我的定义它成为实际的云开发。
还有一些额外的工具可以为这些环境提供执行软件所需的云计算资源，比如 Codenvy 或 Koding。总体而言，这些工具向用户承诺，无论计算机的计算能力有多强，用户都可以在任何计算机上编写软件，而且不需要任何设置。
上面提到的一些产品已经不再活跃，或者已经被收购，所以他们的工具现在被集成到其他产品中 —— 例如，Cloud9 现在是 AWS 的一部分 ，Codenvy 被 Red Hat 收购。
然而，这种面向开发者的工具从未被大规模采用，主要是因为它迫使用户转向一个功能并不是特别强大、与开发者习惯于本地开发的在线 IDE 不同的在线 IDE。此外，对于这种开发方式来说，现在可能还为时过早，甚至云计算本身也不像今天这样普遍。
那么，现在有啥变化吗？
为什么云开发现在有了突破？
商业环境已经发生了变化。
在过去的几年里，软件世界发生了很多变化，使得云开发变得更加顺理成章和简单：
使用云来运行软件已经成为常态。
如今，使用云来处理生产工作负载已经成为许多公司的标准。这种转变与软件即服务（Software-as-a-Service，SaaS）销售模式的出现有关，也是云开发必不可少的第一步—— 只有当生产负载在云中时，将开发运行时间转移到云中才有意义。因此，云计算的广泛采用也增加了云开发的潜在用户基础。
软件变得越来越复杂。
随着人工智能（AI）、机器学习（ML）和微服务的兴起，软件的复杂性以及运行这些软件所需的计算资源显著增加。由于本地计算机本身的计算能力有限，它们不能够运行用户想要开发的每一个软件。在某些情况下，这甚至可能使得在开发过程中不可避免地使用云。
软件已经独立于运行环境。
由于使用了 Docker 和 Kubernetes 等容器技术，软件现在通常被打包在可以在任何环境下运行的容器中，无论是云还是本地环境，只要基础技术是可用的。这意味着，如果你已经在生产负载中使用了 Kubernetes，并且使用了容器，那么从本地开发切换到基于云的开发将非常简单。
一些障碍已被扫除！
过去的一些挑战现在（至少部分）得到了解决，这使得云开发更具可行性：
网络传输。
如果你想在云中开发，你总是需要一个互联网连接来与云进行通信。幸运的是，在过去的几年里，人们的平均网络连接速度越来越快，而且 WiFi 无处不在。由于出于开发目的，通常只更改很小的源代码文件，因此在开发过程中不需要传输太多数据，所以现在的延迟通常是无关紧要的。
部署耗时。
如果你不使用在线 IDE，那么你的代码需要以某种方式转移到云中，并且你的应用程序还需要更新。特别是对于容器技术，新的解决方案例如 DevSpace 可以自动将你的变更传输到云中，并且不需要重新启动容器就可以更新你的应用程序。这样可以减少部署时间ーー因为你不需要为每个小变更重新编译运行所有代码，云开发就像是本地开发。
拥抱云的必要性。
调整遗留应用程序以便它能够在云环境中顺利运行可能 需要相当长的时间。尽管对于是否会有一个（完美的）工具可以将每个软件应用程序转换成完美的本地云应用程序仍然存在疑问，但考虑到云和 SaaS 的宏观趋势，对于越来越多的公司来说，转向云似乎是必要的。
控制云访问。
如果每个开发人员都与云进行交互，他们就需要以某种方式访问云。集中管理和控制这种访问可能是一个巨大的挑战，特别是对于较大的团队。然而，由于公共云解决方案，创建新的基于云的开发实例非常容易。甚至可以只使用一个实例，然后在开发人员之间共享访问权。例如，如果你正在使用 Kubernetes，每个开发人员都可以获得一个独立的名称空间，如果你将你的 Kubernetes 环境连接到 DevSpace Cloud，那么开发人员可以根据需要创建这个名称空间。
安全问题。
在开发过程中，在云中运行代码意味着从一开始，所有的源代码都在云中。这不一定是个问题 ーー 因为大多数公司已经在使用云中的代码库了。尽管如此，一些人可能担心有人可能未经授权访问你的开发机密。对他们来说，私有云可能是一个更好的解决方案。
云成本。
如果你使用的是公共云，你必须为你使用的资源付费。如果你的团队中的所有开发人员都需要自己的云环境，那么计算资源的成本可能会很快变得相当高。这是云开发的存在一个普遍问题，目前还不能完全解决，但是有一些方法可以降低成本。
使用容器技术，你甚至有机会在本地模拟云环境。为此，你可以使用 Docker Desktop 和 Docker Compose（或用于 Kubernetes、 minikube 和 DevSpace）在感觉像云环境的本地环境中工作。由于它是在本地运行的，所以你只消耗了计算机资源，而不需要支付任何额外的费用。
云开发的好处
因此，总的来说，条件已经变得更好了，使用云开发比以往任何时候都更容易。
现在的问题是你为什么要这么做。
无限的计算能力
尽管你的计算机只能为本地开发提供有限的资源，但使用云实际上可以提供无穷无尽的计算能力。
你还可能需要使用特定的硬件，否则就无法使用。在这里，尤其是 GPUs 至关重要，因为它们是许多人工智能和机器学习应用程序所需要的。
对于微服务应用程序，你可能需要大量的电力来启动和运行所有的服务，有时候这在本地是完全不可能的。在这种情况下，企业如果想继续有效地改进其应用程序，就只能转向云计算ーー这也是为了开发。
减少准备工作
不管运行环境如何，运行一个应用程序可能需要有很多步骤。
但是，如果使用云开发，团队中的一个人可以设置和配置所有东西，所有其他团队成员都可以直接启动。在 Kubernetes 的世界中，这可以通过诸如 Helm 和 DevSpace 等开源工具来实现，在这些工具中，你可以配置整个环境，然后必须将其部署到云环境中。
这种可复制性是云的一个主要优势，因为硬件或操作系统之间没有差异（除非你希望有不同的配置）。
它也非常灵活，你可以根据个人需要进行调整。此外，公共云供应商提供了一系列工具和构建模块ーー只要看看 Google Cloud 或 AWS 的服务就知道了。
加上可以用 CNCF landscape 描述的大量云应用程序和环境的开放源码项目，你可以非常快速地开始工作。
新的合作可能性和标准化
由于标准化（表示为云环境的共享配置文件），很容易在团队中复制 bug 并相互支持。
甚至可以让同事直接访问你的云环境来修复某些内容或分享你的工作成果。这可以带来更多的团队合作，形成一种新的团队合作形式，每个人都可以贡献自己的力量。
从任何地方访问
由于你的应用程序在开发过程中已经在云中运行，因此你不必总是使用具有非常特定设置的同一台计算机。
你可以随意切换本地硬件，这样当你的计算机出现故障需要更换时就更容易了。这也支持现代的工作文化，比如在家工作或者在外工作。
生活在 DevOps 文化中
在云中直接开发针对云的软件非常有意义，因为在应用程序的整个生命周期中始终使用非常类似的环境。
这可以减少将应用程序部署到生产环境后可能出现的错误和问题的数量。为此，基于云的开发将在你的团队中培养 DevOps 文化。
总结
云开发是一个已经存在了很多年的概念，但在过去未能真正成为主流。
然而，由于云和软件即服务的宏观趋势的结合，以及技术的进步，如容器技术 Docker 和 Kubernetes，云开发现在有机会最终成为基于云的应用程序的新标准开发。
即使可能不是每个人都会（在不久的将来）离开本地环境，它也可能在采用 DevOps 实践并希望开发真正的本地云应用程序的公司中得到广泛采用。
英文：Why Cloud Development Could (Finally) Become the New Standard
然而，由于云和软件即服务的宏观趋势的结合，以及技术的进步，如容器技术 Docker 和 Kubernetes，云开发现在有机会最终成为基于云的应用程序的新标准开发。
作者 | Daniel Thiry
以下为译文：
云开发，或者说基于云的开发，已经存在了好几年了。然而到目前为止，从未真正成为主流。
我认为，软件市场的一些变化可能会导致这种开发方式的复兴，甚至是最终的突破。
在我开始介绍这些之前，让我们来看一下云开发的含义。
什么是云开发？
云开发或基于云的开发有许多定义（我将交替使用这些术语）。
本文我将使用这个定义：云开发是一种软件开发方法，它使用云环境（而不是本地计算机）在实际的开发阶段执行未完成的软件。
这意味着你的软件在云中运行，它通常不会在你的本地计算机上运行。如果你开发的软件是在云环境中运行的，那么项目的临时环境、测试和生产环境也会在云上。
其他一些人将云开发定义为使用基于浏览器和在线的 IDE。虽然基于浏览器的编辑器通常链接到云环境来执行软件，但也可以使用本地编辑器并在云中执行软件(例如，使用 Visual Studio 的远程环境特性) ，这就是为什么我选择使用上面那种更广泛定义的原因。
来自 Kubernetes 和 CNCF 社区的另一个更近期的术语是“云原生开发”(cloud-native development) ，它也与我对云开发的定义有关，但是它是一个更普遍的概念，指的是“基于容器的、动态编排的、利用微服务架构的应用程序开发”。因此，它更关注开发什么，而不是如何开发。
云开发从未成为主流
云开发的想法并不新鲜。你可以在八年前的文章中就可以找到相关的讨论。
随着在线 IDEs（如 Cloud9 和 Eclipse Che）的出现，云开发经历了第一次人气飙升。这可能就是为什么有些人直接将这些工具与云开发这个术语联系起来的原因。这些基于浏览器的 ide 为你提供了在云中运行的工具和编辑器，可以通过普通浏览器(如 Google Chrome)直接访问。
由于源代码已经在云中编写，所以它通常也在连接的云环境中执行，这使得根据我的定义它成为实际的云开发。
还有一些额外的工具可以为这些环境提供执行软件所需的云计算资源，比如 Codenvy 或 Koding。总体而言，这些工具向用户承诺，无论计算机的计算能力有多强，用户都可以在任何计算机上编写软件，而且不需要任何设置。
上面提到的一些产品已经不再活跃，或者已经被收购，所以他们的工具现在被集成到其他产品中 —— 例如，Cloud9 现在是 AWS 的一部分 ，Codenvy 被 Red Hat 收购。
然而，这种面向开发者的工具从未被大规模采用，主要是因为它迫使用户转向一个功能并不是特别强大、与开发者习惯于本地开发的在线 IDE 不同的在线 IDE。此外，对于这种开发方式来说，现在可能还为时过早，甚至云计算本身也不像今天这样普遍。
那么，现在有啥变化吗？
为什么云开发现在有了突破？
商业环境已经发生了变化。
在过去的几年里，软件世界发生了很多变化，使得云开发变得更加顺理成章和简单：
使用云来运行软件已经成为常态。
如今，使用云来处理生产工作负载已经成为许多公司的标准。这种转变与软件即服务（Software-as-a-Service，SaaS）销售模式的出现有关，也是云开发必不可少的第一步—— 只有当生产负载在云中时，将开发运行时间转移到云中才有意义。因此，云计算的广泛采用也增加了云开发的潜在用户基础。
软件变得越来越复杂。
随着人工智能（AI）、机器学习（ML）和微服务的兴起，软件的复杂性以及运行这些软件所需的计算资源显著增加。由于本地计算机本身的计算能力有限，它们不能够运行用户想要开发的每一个软件。在某些情况下，这甚至可能使得在开发过程中不可避免地使用云。
软件已经独立于运行环境。
由于使用了 Docker 和 Kubernetes 等容器技术，软件现在通常被打包在可以在任何环境下运行的容器中，无论是云还是本地环境，只要基础技术是可用的。这意味着，如果你已经在生产负载中使用了 Kubernetes，并且使用了容器，那么从本地开发切换到基于云的开发将非常简单。
一些障碍已被扫除！
过去的一些挑战现在（至少部分）得到了解决，这使得云开发更具可行性：
网络传输。
如果你想在云中开发，你总是需要一个互联网连接来与云进行通信。幸运的是，在过去的几年里，人们的平均网络连接速度越来越快，而且 WiFi 无处不在。由于出于开发目的，通常只更改很小的源代码文件，因此在开发过程中不需要传输太多数据，所以现在的延迟通常是无关紧要的。
部署耗时。
如果你不使用在线 IDE，那么你的代码需要以某种方式转移到云中，并且你的应用程序还需要更新。特别是对于容器技术，新的解决方案例如 DevSpace 可以自动将你的变更传输到云中，并且不需要重新启动容器就可以更新你的应用程序。这样可以减少部署时间ーー因为你不需要为每个小变更重新编译运行所有代码，云开发就像是本地开发。
拥抱云的必要性。
调整遗留应用程序以便它能够在云环境中顺利运行可能 需要相当长的时间。尽管对于是否会有一个（完美的）工具可以将每个软件应用程序转换成完美的本地云应用程序仍然存在疑问，但考虑到云和 SaaS 的宏观趋势，对于越来越多的公司来说，转向云似乎是必要的。
控制云访问。
如果每个开发人员都与云进行交互，他们就需要以某种方式访问云。集中管理和控制这种访问可能是一个巨大的挑战，特别是对于较大的团队。然而，由于公共云解决方案，创建新的基于云的开发实例非常容易。甚至可以只使用一个实例，然后在开发人员之间共享访问权。例如，如果你正在使用 Kubernetes，每个开发人员都可以获得一个独立的名称空间，如果你将你的 Kubernetes 环境连接到 DevSpace Cloud，那么开发人员可以根据需要创建这个名称空间。
安全问题。
在开发过程中，在云中运行代码意味着从一开始，所有的源代码都在云中。这不一定是个问题 ーー 因为大多数公司已经在使用云中的代码库了。尽管如此，一些人可能担心有人可能未经授权访问你的开发机密。对他们来说，私有云可能是一个更好的解决方案。
云成本。
如果你使用的是公共云，你必须为你使用的资源付费。如果你的团队中的所有开发人员都需要自己的云环境，那么计算资源的成本可能会很快变得相当高。这是云开发的存在一个普遍问题，目前还不能完全解决，但是有一些方法可以降低成本。
使用容器技术，你甚至有机会在本地模拟云环境。为此，你可以使用 Docker Desktop 和 Docker Compose（或用于 Kubernetes、 minikube 和 DevSpace）在感觉像云环境的本地环境中工作。由于它是在本地运行的，所以你只消耗了计算机资源，而不需要支付任何额外的费用。
云开发的好处
因此，总的来说，条件已经变得更好了，使用云开发比以往任何时候都更容易。
现在的问题是你为什么要这么做。
无限的计算能力
尽管你的计算机只能为本地开发提供有限的资源，但使用云实际上可以提供无穷无尽的计算能力。
你还可能需要使用特定的硬件，否则就无法使用。在这里，尤其是 GPUs 至关重要，因为它们是许多人工智能和机器学习应用程序所需要的。
对于微服务应用程序，你可能需要大量的电力来启动和运行所有的服务，有时候这在本地是完全不可能的。在这种情况下，企业如果想继续有效地改进其应用程序，就只能转向云计算ーー这也是为了开发。
减少准备工作
不管运行环境如何，运行一个应用程序可能需要有很多步骤。
但是，如果使用云开发，团队中的一个人可以设置和配置所有东西，所有其他团队成员都可以直接启动。在 Kubernetes 的世界中，这可以通过诸如 Helm 和 DevSpace 等开源工具来实现，在这些工具中，你可以配置整个环境，然后必须将其部署到云环境中。
这种可复制性是云的一个主要优势，因为硬件或操作系统之间没有差异（除非你希望有不同的配置）。
它也非常灵活，你可以根据个人需要进行调整。此外，公共云供应商提供了一系列工具和构建模块ーー只要看看 Google Cloud 或 AWS 的服务就知道了。
加上可以用 CNCF landscape 描述的大量云应用程序和环境的开放源码项目，你可以非常快速地开始工作。
新的合作可能性和标准化
由于标准化（表示为云环境的共享配置文件），很容易在团队中复制 bug 并相互支持。
甚至可以让同事直接访问你的云环境来修复某些内容或分享你的工作成果。这可以带来更多的团队合作，形成一种新的团队合作形式，每个人都可以贡献自己的力量。
从任何地方访问
由于你的应用程序在开发过程中已经在云中运行，因此你不必总是使用具有非常特定设置的同一台计算机。
你可以随意切换本地硬件，这样当你的计算机出现故障需要更换时就更容易了。这也支持现代的工作文化，比如在家工作或者在外工作。
生活在 DevOps 文化中
在云中直接开发针对云的软件非常有意义，因为在应用程序的整个生命周期中始终使用非常类似的环境。
这可以减少将应用程序部署到生产环境后可能出现的错误和问题的数量。为此，基于云的开发将在你的团队中培养 DevOps 文化。
总结
云开发是一个已经存在了很多年的概念，但在过去未能真正成为主流。
然而，由于云和软件即服务的宏观趋势的结合，以及技术的进步，如容器技术 Docker 和 Kubernetes，云开发现在有机会最终成为基于云的应用程序的新标准开发。
即使可能不是每个人都会（在不久的将来）离开本地环境，它也可能在采用 DevOps 实践并希望开发真正的本地云应用程序的公司中得到广泛采用。
英文：Why Cloud Development Could (Finally) Become the New Standard